review

jig:review

Everything mechanical is one command. You run it, read its result, and put the real decisions — keep, quiet, or retire — to the user. Never re-derive what the command already computed.

Every command is node "${CLAUDE_PLUGIN_ROOT}/scripts/jig.js" <review|rerun|fp|disarm|arm|retire> from the project root. If node is not on PATH (fnm/nvm setups), register it the way the project's CLAUDE.md says to, then rerun.

A guard's mode is a choice, not a rank. Checks install proven and blocking; observe is something the owner picks, in either direction, at any time. There is no clean-session count that earns anything, and nothing here is a waiting period.

Anything that takes enforcement AWAY — fp, disarm, retire — plans and stops. The command writes a change and changes nothing; its result carries applied: false, the change id, the path, and an apply string. Put the change to the user with ONE AskUserQuestion and run the apply only if they say yes. Never pre-tick it, never assume it, never run both halves in one breath. arm is the exception and applies itself: it puts enforcement up, and the owner already named the guard.

If a command here refuses because the install predates the rework, that install needs upgrading before any of this reads correctly. Send the user to /jig:jig, which runs the migration, and stop.

1. Read the ledger

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

installed: false is the whole report. There is no .jig/config.json here — jig was never installed, or revert took it back out — so there is no activity to read. Say why and stop; offer /jig:jig to install. Do not report the empty guards list as guards that never fired.

guards[] carries one row per installed guard:

• fired — times it matched, out of evaluated calls it was run on. Report the pair, never fired alone: four catches in four calls and four in four thousand are different guards. denied and wouldDeny split fired by what the guard was allowed to do — a wouldDeny count is coverage the user is not getting yet. lastFired is when the last catch was, or null; a guard that fired only long ago is as much a retirement candidate as one that never did. wavedOff — false positives recorded.
• evaluatedOn — the shell tool names those evaluated calls arrived on, for THIS guard. Empty means not yet observed. This is the per-guard field; lanes.session.shell.seen below is repository-wide and answers a different question.
• otherLanes — catches of this guard's class at COMMIT time, where the check runs with no guard and no denominator, which is why it is not part of fired. A guard with fired: 0 and a non-zero otherLanes is not a quiet guard: its class is being caught, in the lane that stops the commit. Never offer it for retirement. pendingWaveOff — a wave-off the user raised and never approved the change for. The guard is still doing whatever its config says, which is not what somebody who ran fp and walked away expects: say so, and offer the token again.
• problem — non-null means this guard is broken, not quiet: its check module would not load, or it carries nothing for the event it is registered on. Say so first and separately. A broken guard reported as "never fired" is coverage the user thinks they have.
• mode — armed (it blocks) or observe (it records and lets the call through). why states what put it there; print it verbatim, because paraphrasing an honest limit blurs it.
• demoted — non-null means the config says armed and the guard is running as observe anyway: drift, a stale proof, a standing false positive, a zone. The owner cannot see that gap anywhere else, so report it beside problem rather than leaving mode to imply somebody chose observe.
• provenance — how the row was chosen. An assumed row is a default the owner never saw, and it is labelled as one wherever it is reported.