create-agent-rig 0.6.2 → 0.7.0

package/CHANGELOG.md

@@ -11,6 +11,101 @@ Numbering is ordinary semver — **additive is a minor, a fix is a patch** — s
 that "I only take minors" remains a usable policy; 0.3.2 shipped additive
 content as a patch by the owner's call and stays recorded as one.
 
+## 0.7.0
+
+**A durable claim record under the revalidation 0.6.2 already had, and the
+governance fixes that followed it.** 0.6.2 could already re-check at a
+checkpoint whether the branch about to ship is still the branch the run took
+up. What a newly scaffolded project gains here is the layer under that: a
+content-blind record of what was claimed, so the re-check no longer rests on
+the run's own take-up snapshot. The public CLI is unchanged — no new command,
+no new flag, no new dependency.
+
+**Numbered a minor deliberately.** The rule at the top of this file is that
+additive is a minor and a fix is a patch, so that "I only take minors" stays a
+usable policy. **Five** files land in a generated rig that the published 0.6.2
+does not contain — the four listed under Added, plus
+`.claude/scripts/lib/shell-tools.mjs`, the shared shell-tool list the Never-tier
+guards read. One of the five is a config file the project owns. Shipping that as
+a patch is the case the rule exists to prevent.
+
+### Added
+
+- **Content-blind revalidation claims.** A run records what it claimed at each
+  checkpoint and compares it later without copying the tracker's content, so the
+  re-check does not depend on the run remembering correctly. A generated project
+  receives `.claude/scripts/lib/claim-records.mjs`,
+  `.claude/scripts/lib/revalidation-evidence.mjs`, `.rig/revalidation.json` and
+  the decision record `docs/decisions/content-blind-revalidation.md`.
+
+### Fixed
+
+- **The Never-tier guards, and the kill switch they carry, run on every shell
+  surface — where before they ran on one.** They were wired under a single tool
+  matcher, so a second shell surface reached none of them: a force-push of a shared branch, a filesystem wipe and a
+  pre-commit bypass all ran there with the brake armed. The guards now read one
+  shared list of shell tools rather than each comparing its own literal, and the
+  tests spawn them on every entry in that list instead of checking the wiring
+  alone — which is how the gap survived its own test suite.
+
+  ⚠ Running is not the same as covering, and the limit is stated where the list
+  is. The rules match a command NAME, so they refuse an operation only in that
+  spelling: with the brake armed, `gh pr merge …` is refused on both surfaces
+  while `gh.exe pr merge …` and `Remove-Item -Recurse -Force C:\` are not. That
+  bound belongs to the rule set rather than to the matcher — the `.exe` spelling
+  was allowed on the original surface too — and it is unchanged by this
+  release.
+
+- **An adapter it cannot read is `UNVERIFIABLE`, not a stack trace.** A
+  revalidation whose queue adapter could not be reached exited on a raw Node
+  stack trace, which a caller could read as noise rather than as a hold. It now
+  takes the same hold path a real drift takes and never returns a pass. The
+  reason it prints is withheld whenever it carries userinfo — as a class, not as
+  a list of spellings, after two rounds in which each fix closed the form just
+  found and left the next one open. A queue configuration that cannot be
+  resolved at all is a refusal with a readable message rather than a crash.
+
+- **The instruction surface no longer cites this repository's backlog.** The
+  `loop` and `pr-ship` skills and the Node/TypeScript stack rule carried ticket
+  identifiers, commit SHAs and PR numbers from the tracker that built them —
+  provenance a downstream reader cannot open, in artifacts whose only job is to
+  instruct. A mechanical check now scans every layer's rules, skills, agent
+  specs and top-level instruction files and fails on a backlog identifier,
+  without banning those letters repository-wide.
+
+  ⚠ Scoped deliberately, and the scope is not the whole rig. Two of the check's
+  exclusions ship: the `.claude/scripts/**` and `.claude/hooks/**` trees, whose
+  citations are comments addressed to whoever edits the mechanism rather than
+  instructions the agent follows, and `docs/decisions/`, where a record's whole
+  job is to say what happened. Together **86 citations across 27 files** still
+  arrive with a generated project — 78 in the first pair, 8 in the records.
+  Whether they are the same defect is a live question this release does not
+  settle.
+
+- **Evidence pointers are checked rather than trusted.** A pointer of the form
+  `file › "test name"` is what keeps a claim about a mechanism honest; several
+  named tests that had been renamed or moved. A check now resolves them, and a
+  pointer into a suite a generated project never receives has to say so.
+
+  ⚠ Its coverage is partial and it states that itself: it reads a citation's
+  names from the line the file is named on and the two after it, and resolves a
+  target by basename, so a test moved to another directory still passes. A green
+  run means no citation it read has gone dead — not that every pointer was
+  verified.
+
+- **The `loop` skill now describes how the run directory actually reaches each
+  command.** It had described a directory most of its own commands could not be
+  told about, so a reader could journal into one place while a check looked in
+  another. The correction is to the skill's text, not to the plumbing: the two
+  commands that take it as an argument rather than from the environment are now
+  named, and a correspondence check walks every script rather than a list
+  somebody maintains.
+
+### Documentation
+
+- `docs/command-contract.md` records what the CLI promises and which of its
+  commands conform today. Generator-only; it does not ship into a rig.
+
 ## 0.6.2
 
 **Patch hardening for the Agent OS shipped by 0.6.1.** This release closes six

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-agent-rig",
-  "version": "0.6.2",
+  "version": "0.7.0",
   "description": "Scaffold a new project with an agent operating system (rules, gates, hooks) and a runnable code skeleton",
   "keywords": [
     "create",

package/templates/agent-os/stack/node-ts/.claude/rules/node-ts.md

@@ -58,9 +58,8 @@ gh api "repos/{owner}/{repo}/commits/$SHA/check-runs" \
 **A head that gets no run at all is a third state, not a slow one.** A
 `pull_request` push can register no workflow run and emit no failure signal —
 the head sits with a scanner only, and the poll above waits forever while the
-previous head's green sits one line up in the same PR (AR-149: `69b5d65` on
-#130 got no `ci` run; `8ca26e7` on #134 got `ci` and no `e2e`). Tell "not
-registered" apart from "pending" by asking for runs by head, not by PR:
+previous head's green sits one line up in the same PR. Tell "not registered"
+apart from "pending" by asking for runs by head, not by PR:
 
 ```sh
 gh api "repos/{owner}/{repo}/actions/runs?head_sha=$SHA" \

package/templates/agent-os/universal/.agents/skills/loop/SKILL.md

@@ -45,7 +45,7 @@ composed file:
 
 ```bash
 node .claude/scripts/queue/index.mjs board        # the active board and the declared ones
-node .claude/scripts/queue/index.mjs board RP     # switch this checkout: writes .claude/queue.board
+node .claude/scripts/queue/index.mjs board <board-id>  # switch this checkout: writes .claude/queue.board
 ```
 
 The selector is per-checkout runtime state, the same class as
@@ -79,13 +79,14 @@ state-vs-queue split exists to prevent.
 node .claude/scripts/preflight.mjs
 ```
 
-Four items are scripted (kill switch absent · `RIG_RUN_DIR` not already
-exported · local default branch matches the remote · the last deploy concluded
-successfully) and the script **prints the ones it did not check, every time**. Paste the block into the journal: a checklist that
+Five items are scripted (kill switch absent · `RIG_RUN_DIR` not already
+exported · the versioned revalidation detection contract is supported · local
+default branch matches the remote · the last deploy concluded successfully)
+and the script **prints the ones it did not check, every time**. Paste the block into the journal: a checklist that
 leaves no record cannot tell you it was skipped.
 
 Verdicts: **STOP** → do not start, deal with the cause. **CAUTION** → start,
-knowing which ground is soft. **GO** → the scripted four are clean; the rest are
+knowing which ground is soft. **GO** → the scripted five are clean; the rest are
 still yours.
 
 **An `unknown` never becomes a `pass`.** A probe that could not run tells you
@@ -118,9 +119,31 @@ mkdir -p "$RIG_RUN_DIR"
 never with a variable the session exported — pinned in the generator's
 `test/template/guard-rulebook.test.ts` (absent in a generated rig) › "only a
 flag arms it — an exported RIG_UNATTENDED=1 with no flag changes nothing" —
-and in some harnesses the export does not even survive to the next Bash call,
-which is why every command in this skill can also take the run directory per
-invocation. What a hook CAN see is a file, so the unattended signal is one:
+and in some harnesses the export does not even survive to the next Bash call.
+
+🔴 **So re-export it in every call that needs it.** `RIG_RUN_DIR` is how the run
+directory reaches the commands that read it from the environment — and two of
+the commands this skill invokes read it from somewhere else instead.
+`unattended-flag.mjs` does not read the variable; it takes the directory as
+`--run-dir`, which is why the call below passes it explicitly.
+`revalidation-report.mjs` does not read it either; it takes `--runs <dir>`.
+For every other command this skill invokes the variable is the whole of it, and
+passing the flag is not a fallback but an unrecognised argument — after which a
+command writes into a run directory nobody declared, or refuses for want of one
+while the caller believes it was told. Modules this skill *imports* rather than
+invokes are a third case again: `run-journal.mjs` and `queue/state.mjs` are
+handed a `runDir` by their caller, which is why §9 lists it among the details
+that must be copied rather than re-derived.
+
+`--run-dir` is taken by `unattended-flag.mjs`, and by no other script under
+`.claude/scripts/`. That is measured over the whole tree rather than against a
+list, in both directions, by the generator's
+`test/template/correspondence.test.ts` (absent in a generated rig) › "names
+exactly the commands that take --run-dir, and only those" — so a script anywhere
+in that tree that gains the flag without this sentence gaining its name goes
+red.
+
+What a hook CAN see is a file, so the unattended signal is one:
 
 ```bash
 # at claim time, from the paths the item names (repo-relative prefixes, with
@@ -141,12 +164,11 @@ rig — › "blocks a hook-config edit with an empty allow-list, naming path, it
 
 ⚠ **The export outlives the run's own calls.** Everything the session spawns
 inherits it — and a test suite that spawns the queue CLI would write fixture
-records into this run's trace (AR-139: 38 fixture selections and 22 fixture
-revalidation events in one session, two tests exiting 1). So preflight refuses
-to start on a `RIG_RUN_DIR` already exported. The generator's own test harness
+records into this run's trace. So preflight refuses to start on a
+`RIG_RUN_DIR` already exported. The generator's own test harness
 also scrubs the variable before any test file loads — its `test/setup-env.ts`,
-pinned by its `test/template/rig-run-dir-scrub.test.ts` › "holds with the
-variable exported around the whole vitest process" — and **neither file ships
+pinned by its `test/template/rig-run-dir-scrub.test.ts` (absent in a generated
+rig) › "holds with the variable exported around the whole vitest process" — and **neither file ships
 into a generated rig**: here, nothing scrubs it, and a rig's own test setup is
 the place to do the same.
 
@@ -198,12 +220,12 @@ reported by `hygiene` as `owner-mismatch`. It clears the way `trigger-human`
 does: a human moves the item or re-marks it. An unmarked item is unconditional.
 Two items of another product once entered this queue as normal spacers and
 escalated `PREMISE FALSE` back to back — a run-level stop spent on work that
-was never this checkout's (AR-132). Pinned in the generator's
+was never this checkout's. Pinned in the generator's
 `test/template/queue-owner.test.ts` — absent in a generated rig — › "holds an
 item whose owner is another repository, with the cause named".
 
 🔴 **An item's lifecycle is a label a human wrote, and the loop infers none of
-it** (AR-144). Four words, read by `lifecycleOf` in `core.mjs` so every adapter
+it**. Four words, read by `lifecycleOf` in `core.mjs` so every adapter
 means the same thing — three of lifecycle, one of scheduling:
 
 - `keep-core` — the problem and the responsibility are valid and the item is
@@ -285,59 +307,72 @@ and the work turns out to touch an elevated path (`CLAUDE.md` →
 `elevated-paths`), run the gate anyway, record the verdict on the PR, and treat it
 as this run's elevated item for spacing.
 
-**Selection also revalidates the item against its last take-up.** `next`
-records the selected item's `updatedAt` marker in the run state (`takeUps`) and,
-when the item is offered again, compares the two — against this run's take-up
-when it has one, otherwise against the newest earlier run's under `.claude/runs/`
-(AR-138: before that, an item taken up yesterday compared against nothing and
-read as a first sight). A proposal the loop files carries its own baseline: the
-`jira` and `github-issues` adapters record the filed item's marker as a take-up
-in the run that filed it. The event names which it used — `baseline:
-this-run | previous-run | null` — pinned in the generator's
-`test/template/revalidation-baseline.test.ts` — absent in a generated rig — ›
-"holds when the marker moved past the earlier run’s take-up, and names that
-baseline". A marker that
-moved prints a `revalidate:` line and the JSON carries `revalidation.changed:
-true`: **re-read the item before acting on it**, then record what the re-read
-concluded — whether the change altered the action is the evidence this exists to
-collect, and the comparison alone cannot supply it:
+**Selection is the first point of the one revalidation chain.** On the first
+successful SELECT, `next` creates a versioned content-blind baseline at
+`.rig/claims/<item-id>.json` and reports `BASELINE_CREATED`. Add that record to
+the task's branch: a later SELECT, BEFORE_PR or BEFORE_CLOSE refuses an
+untracked record, and a resumed checkpoint with no record is `UNVERIFIABLE`.
+The `scope` fingerprint set is authoritative at SELECT and BEFORE_PR and
+includes workflow state normalised to the state that checkpoint expects;
+`commentary` is observed there but becomes hold-authoritative only at
+BEFORE_CLOSE. Neither set stores title, description or comment bodies.
+For Jira and GitHub issues, the adapter's successful `claim` writes its
+observable `in-progress` transition into that same record as `workflowClaim`.
+Only that durable acknowledgement makes the claimed state expected at a resumed
+SELECT, BEFORE_PR or BEFORE_CLOSE; the same tracker state reached without it is
+external drift and HOLDs. PLAN.md remains `open` because it has no observable
+claim transition. The checkpoint-aware edge is pinned in the generator's
+`test/template/content-blind-revalidation.test.ts` (absent in a generated rig)
+› "keeps a resumed SELECT current after the Jira adapter records its own claim
+transition", › "GitHub claim records the durable transition that makes
+in-progress CURRENT", › "holds claim:scope at resumed SELECT for the same transition
+made outside the adapter", › "accepts an in-progress transition performed by
+the Jira adapter claim operation", and › "holds claim:scope when an external
+actor moves the item to the expected claimed state".
+The durable/evidence boundary and rollback rule are recorded in
+`docs/decisions/content-blind-revalidation.md`.
+
+`takeUps` and `updatedAt` remain in run state and in the event's `task` field as
+evidence/compatibility state. They do not decide `CURRENT`, `CHANGED`,
+`CONFLICT` or `UNVERIFIABLE`, do not decide whether a first baseline may be
+created, and never appear as a drift source. The event may still name
+`baseline: this-run | previous-run | null` so older evidence remains readable.
+First sight versus resume comes only from the SELECT events in the current and
+bounded sibling run journals. If those journals cannot prove first sight, a
+missing claim is `UNVERIFIABLE`; an `updatedAt` marker can neither create nor
+withhold the claim. Hitting the sibling entry/read cap makes that proof
+incomplete and therefore fails closed; "not found in the bounded subset" never
+means "never selected".
+
+On `CHANGED`, `CONFLICT` or `UNVERIFIABLE`, **re-read before acting**, then
+record what the re-read concluded:
 
 ```bash
 node .claude/scripts/revalidate.mjs outcome --point SELECT --ticket <item-id> --action-changed <true | false> --note '<what changed, or why it changes nothing>'
 ```
 
-It appends one `revalidation-outcome` record whose `answers` names the
-revalidation it resolves, so the report can pair the two without guessing. The
+It appends one typed `revalidation-outcome` record whose `detectionId` names the
+stable detection it resolves (and retains the legacy `answers` sequence), so
+the report can pair the two across harness runs without guessing. The
 note is stored verbatim from argv, so keep it in single quotes: inside double
 quotes the shell expands a backtick or a `$` before the command sees it.
 Nothing forces this record — a `revalidation` event with no matching outcome is
 counted as `unresolved`, which is the honest word for a re-read the run skipped.
 
-Under a declared run directory, every selection logs one `revalidation` event
-`{ticket, point: SELECT, changed, source, action, task}` — the same shape the
-BEFORE_PR and BEFORE_CLOSE points write. **No-change is always recorded**, one
-line per selection and no sampling: the rule is explicit so the report's
-`opportunities` is a count and not an estimate. An adapter with no marker
-(`plan-md`) logs `changed: null`, never "unchanged". ⚠ The marker also moves on
-the run's own claim and comments. The `jira` and `github-issues` adapters
-re-record the take-up after each write they make — claim, comment, close,
-escalate — so a move made through the adapter is not a hold (AR-140, from the
-journal's RX3/RX4 entry: every BEFORE_PR catch of that run was the run's own
-comment, counted by `revalidation-report.mjs`); a
-comment posted by any other route — a REST call by hand, a connector — still
-moves it like anyone else's, and a `true` can still be self-inflicted that way
-— the re-read decides, which is why the outcome is recorded separately, and a
-hold the re-read overturns is counted as a false hold with its source named.
-Pinned in the generator's `test/template/self-inflicted-marker.test.ts` — absent
-in a generated rig — › "%s leaves the take-up at the marker the write produced",
-an `it.each` over claim, comment, close and escalate. The
+Under a declared run directory, every selection logs one versioned
+`revalidation` detection — the same shape BEFORE_PR and BEFORE_CLOSE write.
+**No-change is always recorded**, one line per selection and no sampling: the
+rule is explicit so the report's `opportunities` is a count and not an estimate.
+The `jira` and `github-issues` adapters still re-record take-ups after their own
+writes for compatibility and attribution evidence; that state is never the
+fingerprint baseline. The
 four-week view is `node .claude/scripts/revalidation-report.mjs --since <date>`,
 over this rig's `.claude/runs/` (or a `--runs <dir>`). The behaviour is pinned in the
-generator's `test/template/queue-revalidation.test.ts` — absent in a generated
-rig — › "an adapter with no marker records a blind spot, not \"unchanged\"", ›
-"a moved marker holds on task:updatedAt, re-snapshots, and journals the change"
-and › "the loop skill's outcome command records what the re-read concluded", and
-in `test/template/revalidation-evidence.test.ts`.
+generator's `test/template/content-blind-revalidation.test.ts` (absent in a generated rig) › "creates a
+versioned content-blind claim and returns BASELINE_CREATED" and › "defers an
+added comment through SELECT and BEFORE_PR, then holds at BEFORE_CLOSE", plus
+`test/template/revalidation-evidence.test.ts` (absent in a generated rig) › "the journaled events of SELECT,
+BEFORE_PR and BEFORE_CLOSE share exactly the common keys and value types".
 
 **Then, before the Red step: `check-premises`.** The item was written by someone
 who was not reading the code at the time, and everything downstream — the failing
@@ -371,7 +406,7 @@ exits 1 whatever the reviewer said. Save the whole answer to a file under the ru
 directory — `$RIG_RUN_DIR/check-premises.md`, one file per gate so two answers
 never overwrite each other — and pass that path (`-` reads stdin instead). The
 same holds for every `<report>` in this skill, as `pr-ship` already does for its
-reviewers (AR-117). Pinned in the generator's `test/template/loop-report-file.test.ts`
+reviewers. Pinned in the generator's `test/template/loop-report-file.test.ts`
 — absent in a generated rig — › "states that the report is a file the session
 writes from the subagent answer, before the first check".
 
@@ -416,8 +451,8 @@ reviewer verdict, an exhausted gate-round cap, a false premise in the item itsel
 
 The run-level conditions are in `stopConditionOf` in `core.mjs`, checked in
 severity order: **queue unreadable** · **runtime regression** · **kill switch** ·
-**two escalations in a row** · **budget** · **nothing selectable** · **queue
-empty**.
+**revalidation hold** · **two escalations in a row** · **budget** · **nothing
+selectable** · **queue empty**.
 
 🔴 **Their inputs come from a file, not from your memory — and that is why they
 fire at all.** `escalations` and `lastDeployVerdict` live in
@@ -567,7 +602,7 @@ inventory of findings** — and this had to be settled, because the two readings
 disagreed the first time a stop arrived without an inventory. An exhausted
 gate-round cap names its stage (the gate) and its wall (the branch's rounds are
 spent — the count, not a verdict on whether the fixes were converging, which the
-counter never measured; AR-115), while the individual blockers behind it are not persisted anywhere until
+counter never measured), while the individual blockers behind it are not persisted anywhere until
 per-round verdicts exist. That is a `documented-stall`: the record locates the wall
 and the next reader knows where to look.
 
@@ -703,10 +738,13 @@ declared in §1. Five things about it are worth knowing before relying on it:
   so a stale record cannot read as the current one — which is the whole failure a
   journal exists to prevent.
 - ⚠ **The trace can stop before the run does, and the two failures part ways
-  here.** A journal that can no longer accept records — a sequence already
-  broken, a file that will not parse, a run already marked ended — is a lost
-  trace, **not** a reason to withhold work the queue can still hand out: the
-  selection prints, stderr carries a `run journal:` line, the exit code stays 0.
+  here.** After a durable claim exists, a journal that can no longer accept
+  records — a sequence already broken, a file that will not parse, a run already
+  marked ended — is a lost trace, **not** by itself a reason to withhold work the
+  queue can still hand out: the selection prints, stderr carries a `run journal:`
+  line, and the claim still decides drift. Before the first claim, the boundary
+  is stricter: an unreadable current or bounded sibling journal means SELECT
+  cannot prove first sight, so an absent claim is `UNVERIFIABLE` and exits 2.
   The refusals are the ones where nothing has happened yet and a second fixes
   it, and there are **four**: the declaration is empty, its directory does not
   exist, the path is not a directory, or the journal module is missing. Each
@@ -793,10 +831,10 @@ node --input-type=module -e '
 
 A proposal missing any of the four parts is refused rather than filed half-formed.
 
-**A finding can say what it measured and what it inferred, as two paired fields**
-(AR-142). A proposal whose premise was never true had no check at filing, only at
-take-up — AR-124 was filed, promoted and claimed before its platform conclusion
-was traced to a probe that had touched one hook. So `measured` and `inferred`
+**A finding can say what it measured and what it inferred, as two paired fields.**
+A proposal whose premise was never true had no check at filing, only at take-up
+— one such proposal was filed, promoted and claimed before its platform
+conclusion was traced to a probe that had touched one hook. So `measured` and `inferred`
 are separate, and `validateProposal` refuses an `inferred` that cites a path
 `measured` does not, naming both fields and the path; one field without the
 other is refused too, and neither files as before. The surface is a cited path
@@ -805,7 +843,7 @@ catches the path-shaped overreach and nothing subtler.
 
 ⚠ **The pair is how a proposal opts into the check, and a proposal filed without
 it is not checked at all** — `validateProposal` keeps the four-part contract, so
-the AR-124 shape with neither field still files as it always did. That is the
+that shape with neither field still files as it always did. That is the
 stated limit, not an oversight: making the fields mandatory would refuse every
 proposal the three adapters already file, and the loop is the author this rule
 is for. So **every proposal this loop files carries both fields** — the snippet
@@ -826,7 +864,7 @@ reports one whose cited paths changed since its `asOf` as
 one git cannot diff from as `proposal-asof-unanswerable` — never as clean. Two
 proposals in a row once escalated `PREMISE FALSE` because the merge that
 falsified each landed after it was filed, and selection hands out the oldest
-first (AR-116). The behaviour is pinned in the generator's
+first. The behaviour is pinned in the generator's
 `test/template/proposal-asof.test.ts` — absent in a generated rig — ›
 "names the overtaken one, the unanswerable one, and stays silent on the current one".
 
@@ -843,7 +881,7 @@ the selection query cannot reach. Add the heading — never the Agent queue.
 
 One adapter needs the second argument the snippet above carries: `jira` requires
 `options.project` and throws rather than filing without it — loudly, so nothing
-is lost, but a call that drops it files nothing (AR-117).
+is lost, but a call that drops it files nothing.
 
 🔴 **The loop proposes; the owner patches.** Self-applying a change to its own
 rulebook is how an unattended run drifts irreversibly, and it collides head-on
@@ -879,20 +917,19 @@ three poisons the only channel by which this project learns.
   the very next query.
 - **Closing:** first ask whether the item is still the item you took up — a
   late comment or a status somebody else moved is not published as `Done`
-  underneath it (AR-135):
+  underneath it:
 
   ```bash
   node .claude/scripts/revalidate.mjs --point BEFORE_CLOSE --ticket <item-id>
   ```
 
-  It compares the item's marker against the newer of this run's last
-  validation and its take-up — an adapter re-records the take-up after each
-  write of its own (§2, AR-140), so a comment posted after BEFORE_PR does not
-  hold the close; pinned in the generator's
-  `test/template/self-inflicted-marker.test.ts` (absent in a generated rig) › "continues when the run’s own
-  write moved the marker after the last validation" — and its
-  state against the `in-progress` a close expects, journals one `revalidation`
-  event at `point: BEFORE_CLOSE`, and lists the item's dependants with each
+  It compares the tracked claim's `scope` and `commentary` fingerprint sets;
+  commentary becomes hold-authoritative only here. Marker/take-up movement is
+  retained in evidence but cannot decide drift. A missing claim is
+  `UNVERIFIABLE` and stops the close. The adapter's expected claimed state is
+  part of the same `claim:scope` comparison rather than a second state-drift
+  decision. The check journals one `revalidation` event at `point:
+  BEFORE_CLOSE` and lists the item's dependants with each
   one's state re-read for the write-back below — pinned in the generator's
   `test/template/revalidate.test.ts` (absent in a generated rig) › "appends
   exactly one BEFORE_CLOSE revalidation event after the BEFORE_PR one, and does

package/templates/agent-os/universal/.agents/skills/pr-ship/SKILL.md

@@ -35,7 +35,7 @@ blockers.
      flow, and this gate with it, begins when the project has a remote
      (`workflow.md`, "PR flow"). The refusal exists because two rounds were once counted ahead of a
      commit pre-commit then refused, so the counter and the fan-out's verdicts
-     named a head that never shipped (AR-141) — pinned in the generator's
+     named a head that never shipped — pinned in the generator's
      `test/template/gate-rounds.test.ts` — absent in a generated rig — ›
      "refuses to count a round on a dirty tree, and counts nothing".
 
@@ -57,26 +57,33 @@ blockers.
    confidently-wrong reviews. Everything below is scoped to this diff.
 
    Then, on the fetched ref, ask whether the branch is still the branch the run
-   took up (AR-134):
+   took up:
 
    ```sh
    node .claude/scripts/revalidate.mjs --point BEFORE_PR --ticket <item-id> --base origin/<default>
    ```
 
-   It compares two sources and names each one that moved: the item's `updatedAt`
-   against the take-up snapshot `next` recorded (`task:updatedAt`), and what the
-   default branch changed since this branch forked, on the paths the branch
-   touches or a `check-premises` record in this run cited (`main:<path>`). It
+   It runs the existing revalidation chain against the tracked, versioned
+   `.rig/claims/<item-id>.json`: the content-blind `scope` fingerprint set is
+   authoritative here, while `takeUps` / `updatedAt` remain evidence only. It
+   also names what the default branch changed since this branch forked on paths
+   the branch touches or a `check-premises` record cited (`main:<path>`). It
    journals one `revalidation` event at `point: BEFORE_PR`; **exit code 2 is a HOLD**, with one blocker per named source: re-read the item, or the default
    branch on that path, record what the re-read concluded —
    `node .claude/scripts/revalidate.mjs outcome --point BEFORE_PR --ticket <item-id> --action-changed <true | false> --note '…'`
    — and come back through step 0. A hold with no outcome is counted by the
-   report as a re-read the run skipped. Exit 0 with
-   `unverifiable` means the task side could not be compared — no take-up
-   snapshot in this run, or no marker — and is stated in the evidence, not read
-   as a pass. Exit 1 is the command refusing (unknown point, no ticket, a base
-   that is not a revision): fix the call. Its limits are its own header's; the
-   cited-path set is a labelled assumption, not a recorded fact.
+   report as a re-read the run skipped. A missing, untracked, unreadable or
+   unsupported claim is `UNVERIFIABLE`, exits 2, and stops automatic progress;
+   so is a tracker whose adapter the command cannot READ, which means the
+   question was never put rather than that the claim record is unreadable.
+   Neither is ever read as a pass. Exit 1 is the command refusing (unknown
+   point, no ticket, a base that is not a revision, or a queue config that does
+   not resolve): fix the call or the config — the message says which. Its limits are its own header's; the
+   cited-path set is a labelled assumption, not a recorded fact. Pinned in the
+   generator's `test/template/revalidate.test.ts` (absent in a generated rig) ›
+   "continues when only updatedAt moved and still reports the marker evidence"
+   and `test/template/content-blind-revalidation.test.ts` › "refuses a deleted
+   tracked claim in a fresh run without take-up markers".
 2. **Route the diff before you spend on it.** This gate always ran its most
    expensive path, so a typo fix in a README bought the same fan-out as a
    rewrite of the storage layer. The dispatcher decides which lane the change

package/templates/agent-os/universal/.claude/hooks/block-no-verify.mjs

@@ -12,13 +12,33 @@
 // to tokenise: it owns exactly one invariant and stays readable because of it
 // (see .claude/rules/invariants.md, "One invariant per hook"). Use a file rather
 // than a heredoc, or quote the example.
-import { readHookInput } from './lib/hook-input.mjs';
+import { readHookInput, refusalText, shellCommandOf } from './lib/hook-input.mjs';
+import { SHELL_TOOLS } from '../scripts/lib/shell-tools.mjs';
 
 function main() {
   const input = readHookInput();
   if (input === null) return 0;
-  if (input.tool_name !== 'Bash') return 0;
-  const raw = String(input.tool_input?.command ?? '');
+  // One list, not a literal: this hook was launched for every shell surface
+  // and then excused itself from all but Bash, so the pre-commit gate stayed
+  // bypassable on the other one.
+  if (!SHELL_TOOLS.includes(input.tool_name)) return 0;
+  // Three outcomes, from the one shared contract (RP-80). `String(argv)` used
+  // to stand here, and it did not merely fail to read an array — it produced a
+  // plausible-looking string: `["git","commit","--no-verify"]` became
+  // `git,commit,--no-verify`, where the tokeniser below never splits on a comma,
+  // so the one flag this hook exists to refuse was silently absent. A guard that
+  // converts what it cannot read into something it can is worse than one that
+  // refuses, because it reports a check it did not perform.
+  const parsed = shellCommandOf(input);
+  if (parsed.kind === 'unreadable') {
+    process.stderr.write(`${refusalText(parsed)}\n`);
+    return 2;
+  }
+  // Positive test, not a list of the others: a member added later must not
+  // reach `raw.replace(…)` below with `undefined`, which throws, exits 1, and
+  // is read as allow.
+  if (parsed.kind !== 'string') return 0;
+  const raw = parsed.command;
 
   // Strip quoted segments first: a commit message that merely MENTIONS a
   // forbidden flag is prose, not a bypass. Only unquoted flags count.