jig

jig:jig

The engine does everything mechanical. You run it, read its result, and ask the questions it cannot answer. Never re-derive by hand what a command already computed, and never put to a human a fact the scan already read.

One rule holds for the whole run, and it is the only promise you have to remember: nothing unapproved. Every path jig writes — a linter config, a manifest entry, a CI file, a check module, a line in a committed hook — is named to the user and approved before a byte lands, and every write is journaled with its pre-image, so revert puts the original back exactly. Tool installs are the same shape: jig shows the exact command, and runs it only after the user ticks that tool by name. Say that plainly when the user asks what they just installed.

A check installs proven and blocking. Observe mode is a choice the owner can make per guard, not a probation every guard serves — never describe it as something a guard graduates from.

Flags in $ARGUMENTS: --quick (skip the rounds, pass --quick to scan and take the selection it computes, plan as assumed), --edition <id> (the user named the language, so work against that edition rather than detection — the flag a project that does not exist yet runs on), --select <classId,…> (the user already named the classes, so skip that question and treat them as elicited), --no-ci (pass through to plan, which then generates no CI workflow), --observe (every guard watches rather than blocks). The interview's own answers reach plan through four more flags, listed at step 6.

Every command runs from the project root and every one of them is node "${CLAUDE_PLUGIN_ROOT}/scripts/jig.js" <scan|toolchain|plan|apply|status|revert|selftest|migrate> or node "${CLAUDE_PLUGIN_ROOT}/scripts/forensics.js". (admit runs the fixture-pair test on its own; plan already does it, so this flow never needs the separate call.) There is no other entry point and nothing is on PATH. Flags take a space-separated value — --select a,b, never --select=a,b, which the parser reads as a flag named select=a,b. Every command accepts --root <path>; without it the working directory is the project.

When .jig/manifest.json already exists, this is a re-run, and there is one thing to do before anything else. An install made before the rework carries checks in the old single-function shape, which this engine does not read, so upgrade it in place first:

node "${CLAUDE_PLUGIN_ROOT}/scripts/jig.js" migrate

already on the pair shape with nothing else on it is the normal answer on a current install. It is not a problem and it is not worth a sentence — read it and move on. Any other refusal is real: migrate writes nothing unless the whole migration can land, and it refuses outright over an artifact somebody edited by hand. Name the file it reports and stop there.

When the 1.0.1 pass runs, it rewrites every installed check into the violation and near-miss pair shape, carries each guard's ledger history forward under its new name, and lands as one journaled transaction that revert undoes like any other. Every rewritten check faces the same admission test an authored one faces, so one whose pair does not pass is discarded and reported rather than quietly carried over. Say which guards were discarded and why.

A check that cannot be proven takes its guards with it, and migrate will not remove a guard the owner has not seen. It refuses before it writes anything, naming every guard it would drop with its mode and the reason. Put that list to the owner as it is — an [armed] row is enforcement they are about to lose — and only then run migrate --accept-drops. There is nothing to repair first: the drop is what the pair test decided, and the flag says the list was read.

There is a second pass, and it hands back a plan instead of applying one. An install made before 2.11.0 watches edits with edit-observe-guard, which denies at PostToolUse — after the host has written the file. migrate answers such an install with moving: one change per check, moving each guard to the edit-guard lever at PreToolUse and re-recording the proof over the rewritten module, because the proof it carries binds the lever it would no longer run. Nothing is applied. Show the owner what is moving and apply each change by its own --change/--path pair, exactly as an install item is applied — the modules first and the config last, because the one config change carries every moved row at once: a guard whose module change is left unapproved names PreToolUse with a module that still declares PostToolUse, warns on every call and guards nothing until that module lands too. A guard on refused cannot move and keeps running as it is — say which, and why.