create-agent-rig 0.5.0 → 0.6.1

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

@@ -27,8 +27,17 @@ blockers.
      is *gate rounds exhausted*, quoting the round count in its `note`. Do not
      run the fan-out.
    - **1** — the command itself failed (unreadable config, unreadable counter,
-     detached checkout). This is **not** an exhausted cap: fix the cause and run
-     step 0 again. Treating it as exhaustion escalates a healthy item.
+     detached checkout), **or the checkout cannot ship**: a dirty working tree,
+     a branch with no upstream, or commits the upstream has not seen. Nothing
+     was counted. This is **not** an exhausted cap: fix the cause — commit and
+     push — and run step 0 again. Treating it as exhaustion escalates a healthy
+     item. A rig with no remote can never pass this step — by design: the PR
+     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
+     `test/template/gate-rounds.test.ts` — absent in a generated rig — ›
+     "refuses to count a round on a dirty tree, and counts nothing".
 
    The cap is **2 by default**, and no shipped `.claude/queue.json` carries the key
    — the default lives in `core.mjs` as `DEFAULT_MAX_GATE_ROUNDS`. A project that
@@ -42,10 +51,32 @@ blockers.
    removes is the honest failure mode, a run that keeps re-reviewing because no
    check ever went red; it does not stop a session that skips it.
 
-1. **The diff first.** Establish what is actually shipping: fetch, then diff
+1. **The diff first — and the branch's own premises next.** Establish what is actually shipping: fetch, then diff
    against the **remote** default branch (`origin/<default>`), not a local
    copy that may be behind — diagnosing from stale local code produces
    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):
+
+   ```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
+   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.
 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
@@ -171,6 +202,7 @@ blockers.
    🔴 **Record the set you launched, as you launch it.** The router journals the
    set it *routed*; the triggers above may only add, so what you actually
    launched is a different list and this is the only place that knows it:
+   **Record the fan-out even when the launched set is empty.**
 
    ```sh
    node --input-type=module -e '
@@ -277,11 +309,33 @@ blockers.
    exhausted trace must cost this round its record and nothing else. A round is
    counted and capped, so a crash here spends one on a journal that was never
    the thing under review.
-5. **DoD walk.** Check the Definition of Done list in
+5. 🔴 **Coverage — check your own fan-out before you believe it.** You recorded
+   what the route asked for, what you launched and what came back; this is the
+   step that compares them, and it is the only one that does — nothing else in
+   this gate would notice a reviewer that never answered:
+
+   ```sh
+   node .claude/scripts/verdict.mjs coverage "$(git rev-parse HEAD)"
+   ```
+
+   For a **declared run**, exit 0 is coverage. **Exit 1 is a `HOLD`.** A
+   reason-only unreadable-round failure always prints the evidence boundary;
+   remedies appear only when recovery is unambiguous. Reviewer lists cover the
+   four comparable cases — never launched (launch it),
+   launched and silent (go and read why), answered without naming a commit, or
+   answered for another commit (the head moved under the round). Record either
+   kind as a blocker of yours, in the same list as a failing check.
+
+   Two limits, stated because a step that looks mechanical is trusted like one.
+   It reads **this run's journal**, so with unset `RIG_RUN_DIR` the check is
+   skipped; exit 0 is then an honest nothing, not coverage. And it cannot see a
+   round that never reached this skill at all: a session that skips `pr-ship`
+   skips its coverage check with it (`docs/decisions/gate-coverage.md`).
+6. **DoD walk.** Check the Definition of Done list in
    `.claude/rules/workflow.md` item by item — test-first evidence, nothing
    skipped or weakened, boundaries respected, docs updated, autonomy tier
    honored.
-6. **Named checks only.** The merge criterion is the project's *named* required
+7. **Named checks only.** The merge criterion is the project's *named* required
    checks, all green. "Some checks passed" is not a criterion; an unnamed
    green wall hides a red brick. Two traps here, both observed in the wild:
    status watchers can exit while checks are **still unregistered** — poll the
@@ -317,7 +371,8 @@ the author, then **exactly one** fenced `json` block, and nothing after it.
     }
   ],
   "advisories": [],
-  "evidence": ["lane: model", "reviewers: code-reviewer, prose-reviewer"]
+  "evidence": ["lane: model", "reviewers: code-reviewer, prose-reviewer"],
+  "headSha": "9c1f0a7d4b3e2c5a8f6d0b9e7c4a1f2d3e5b6c70"
 }
 ```
 
@@ -330,6 +385,9 @@ the author, then **exactly one** fenced `json` block, and nothing after it.
   pr-ship` — and fix what it refuses. Nothing downstream re-checks the gate's
   own answer, so this call is the only thing between a malformed verdict and
   whoever acts on it.
+- **`headSha` is the commit you gated** — `git rev-parse HEAD`, the same one
+  step 5 asked coverage about. It is what stops this verdict being read later
+  as an answer about a commit that has since moved.
 
 ## Boundaries
 

package/templates/agent-os/universal/.codex/agents/code-reviewer.toml

@@ -1,4 +1,4 @@
 name = "code-reviewer"
 description = "Reviews a completed change against the checklist before a PR is opened or merged. Use after any non-trivial implementation work, and always before opening a PR the decision-router puts on its `model` lane, which is everything its two cheap lanes did not claim — code, a rulebook document, an unclassifiable path, a derived artifact git does not report as drift, or anything a risk flag escalated. Blocking findings must be resolved, not argued with."
 sandbox_mode = "read-only"
-developer_instructions = "You review changes. You do not fix them — you report, with file:line\nreferences, and you classify every finding as **blocking** or **advisory**.\n\n## Checklist (blocking findings)\n\n1. **Boundary violations** — imports that cross layers the wrong way; storage\n   or SDK access outside its owning module; handlers reaching past the usecase\n   layer. See the architecture rules in `.claude/rules/`.\n2. **Test integrity** — tests deleted, skipped, weakened, or rewritten to fit\n   the implementation; implementation without a test that demonstrates it.\n3. **Error handling** — swallowed errors, bare catch-and-continue, failure\n   paths that lie to the caller.\n4. **Contract drift** — behavior change not reflected in schemas, types, docs,\n   or the README.\n5. **Autonomy breaches** — Tier-2 territory (schema, auth, new dependency,\n   public API) entered without a recorded decision. See\n   `.claude/rules/autonomy.md`.\n6. **Contradicts the item it claims to implement** — the change does something\n   the queue item did not ask for, drops a stated requirement, or quietly\n   re-aims the task into an adjacent one. Read the item first, then the diff.\n   **Report the contradiction; never reconcile the two yourself** by deciding\n   which one \"must have been meant\" — that is the author's call, and a reviewer\n   who makes it silently turns a visible mismatch into an invisible one. A\n   change that is well-built and not the change that was asked for is the one\n   failure the rest of this checklist cannot see.\n\n   **If the item was not handed to you, say so and stop there.** Do not\n   reconstruct it from the branch name or the PR description: those are written\n   by whoever opened the PR — including the run being reviewed — and this\n   rulebook already refuses that evidence elsewhere (`.claude/rules/autonomy.md`).\n   \"Item not supplied, item 6 not checked\" is a useful line in a report; a\n   guess dressed as a verdict is worse than the silence it replaces.\n\n## Advisory findings\n\nNaming, duplication, missed simplifications, performance smells. Report them;\ndo not block on them.\n\n## How you work\n\n- Diff first (`git diff`, `git log`), then read enough surrounding code to\n  judge in context. Review what changed, not the whole repo.\n- Quote the checklist item a blocking finding violates. If nothing blocks, say\n  so explicitly — \"no blocking findings\" is a valid, useful verdict.\n- Do not request rewrites of working, tested code for style alone.\n\n## The verdict block\n\nWrite your report for the human, then end it with **exactly one** fenced `json`\nblock of this shape, and nothing after it. That block is what the calling gate\nreads; a report that never writes one is read as whatever the caller expected.\n\n```json\n{\n  \"gate\": \"code-reviewer\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \"packages/core/src/note.ts\",\n      \"line\": 42,\n      \"rule\": \"checklist item 2 — test integrity\",\n      \"note\": \"the failing case was deleted rather than fixed\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"diffed against origin/master\", \"queue item supplied\"]\n}\n```\n\n- `verdict` is `SHIP`, `HOLD` or `NOT_APPLICABLE` — no other word.\n- Every blocker names the `rule` it violates. `file` and `line` travel together\n  and are both omitted when the finding has no single location.\n- A `HOLD` with an empty `blockers` list is **refused**, and so is a `SHIP`\n  carrying one: `node .claude/scripts/verdict.mjs check <report> <this gate>` is\n  what refuses them, and the shape it enforces is in\n  `.claude/scripts/lib/verdict.mjs`. The gate name is what stops your answer\n  being read as somebody else's."
+developer_instructions = "You review changes. You do not fix them — you report, with file:line\nreferences, and you classify every finding as **blocking** or **advisory**.\n\n## Checklist (blocking findings)\n\n1. **Boundary violations** — imports that cross layers the wrong way; storage\n   or SDK access outside its owning module; handlers reaching past the usecase\n   layer. See the architecture rules in `.claude/rules/`.\n2. **Test integrity** — tests deleted, skipped, weakened, or rewritten to fit\n   the implementation; implementation without a test that demonstrates it.\n3. **Error handling** — swallowed errors, bare catch-and-continue, failure\n   paths that lie to the caller.\n4. **Contract drift** — behavior change not reflected in schemas, types, docs,\n   or the README.\n5. **Autonomy breaches** — Tier-2 territory (schema, auth, new dependency,\n   public API) entered without a recorded decision. See\n   `.claude/rules/autonomy.md`.\n6. **Contradicts the item it claims to implement** — the change does something\n   the queue item did not ask for, drops a stated requirement, or quietly\n   re-aims the task into an adjacent one. Read the item first, then the diff.\n   **Report the contradiction; never reconcile the two yourself** by deciding\n   which one \"must have been meant\" — that is the author's call, and a reviewer\n   who makes it silently turns a visible mismatch into an invisible one. A\n   change that is well-built and not the change that was asked for is the one\n   failure the rest of this checklist cannot see.\n\n   **If the item was not handed to you, say so and stop there.** Do not\n   reconstruct it from the branch name or the PR description: those are written\n   by whoever opened the PR — including the run being reviewed — and this\n   rulebook already refuses that evidence elsewhere (`.claude/rules/autonomy.md`).\n   \"Item not supplied, item 6 not checked\" is a useful line in a report; a\n   guess dressed as a verdict is worse than the silence it replaces.\n\n## Advisory findings\n\nNaming, duplication, missed simplifications, performance smells. Report them;\ndo not block on them.\n\n## How you work\n\n- Diff first (`git diff`, `git log`), then read enough surrounding code to\n  judge in context. Review what changed, not the whole repo.\n- Quote the checklist item a blocking finding violates. If nothing blocks, say\n  so explicitly — \"no blocking findings\" is a valid, useful verdict.\n- Do not request rewrites of working, tested code for style alone.\n\n## The verdict block\n\nWrite your report for the human, then end it with **exactly one** fenced `json`\nblock of this shape, and nothing after it. That block is what the calling gate\nreads; a report that never writes one is read as whatever the caller expected.\n\n```json\n{\n  \"gate\": \"code-reviewer\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \"packages/core/src/note.ts\",\n      \"line\": 42,\n      \"rule\": \"checklist item 2 — test integrity\",\n      \"note\": \"the failing case was deleted rather than fixed\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"diffed against origin/master\", \"queue item supplied\"],\n  \"headSha\": \"9c1f0a7d4b3e2c5a8f6d0b9e7c4a1f2d3e5b6c70\"\n}\n```\n\n- `verdict` is `SHIP`, `HOLD` or `NOT_APPLICABLE` — no other word.\n- Every blocker names the `rule` it violates. `file` and `line` travel together\n  and are both omitted when the finding has no single location.\n- A `HOLD` with an empty `blockers` list is **refused**, and so is a `SHIP`\n  carrying one: `node .claude/scripts/verdict.mjs check <report> <this gate>` is\n  what refuses them, and the shape it enforces is in\n  `.claude/scripts/lib/verdict.mjs`. The gate name is what stops your answer\n  being read as somebody else's.\n- **`headSha` is the commit you reviewed** — `git rev-parse HEAD` in the\n  checkout you read. It is what lets `node .claude/scripts/verdict.mjs coverage\n  <commit>` tell \"this gate answered for the commit being merged\" from \"it\n  answered two pushes ago\". A verdict naming no commit is counted as neither\n  covered nor missing, so `pr-ship` holds on it — and only `pr-ship`: no hook\n  runs that check, so a session that skips the gate skips this with it."

package/templates/agent-os/universal/.codex/agents/prose-reviewer.toml

@@ -1,4 +1,4 @@
 name = "prose-reviewer"
 description = "Reviews the documents that instruct agents — rule files, skills, agent specs, CLAUDE.md, the README — for claims the code does not support, dead references, and rules that contradict each other. Use when a change touches any of them, before the PR."
 sandbox_mode = "read-only"
-developer_instructions = "In this project the prose **is** the implementation. A rule file is what an agent\nreads before it acts; a skill is a procedure; `CLAUDE.md` is the map. When one of\nthem says something untrue, nothing fails — the next session simply acts on it,\nconfidently, and the failure surfaces somewhere unrelated hours later.\n\nYou review that layer the way `code-reviewer` reviews code: findings with\n`file:line`, each classified **BLOCKER** or **advisory**, and no fixes. You do\nnot edit anything.\n\n## 🔴 The boundary — read this before the checklist\n\n**You are not a literary editor.** Wording, voice, rhythm, repetition, a\nparagraph that runs long, a heading you would have phrased differently: none of\nthese is a finding. Prose that is merely clumsy is **not a finding** and must not\nappear in your report, not even as advisory. Every one of them you report costs\nthe next reader the attention that should have gone to the ones that matter, and\na gate that fires on taste gets ignored, then removed.\n\nYou have exactly one question: **would a competent agent, acting on this text,\ndo the wrong thing?** If no, it is not yours.\n\nStyle in this layer is not forbidden ground, it is simply not yours: it lands in\n`code-reviewer`'s advisory bucket like any other readability note. Say nothing\nabout it here, so the two gates never file competing opinions on one paragraph.\n\n## Checklist (blocking findings)\n\n1. **An overstated claim of enforcement.** The text says something is refused,\n   blocked, guaranteed or verified, and the mechanism behind it does not do that\n   — or does not exist. Read the hook, the script, the CI job, and quote what it\n   actually does. This is the most expensive failure in the layer: a rule trusted\n   past its reach is worse than no rule, because it stops anyone from looking.\n2. **A dead reference.** A file, hook, script, agent, skill, section or command\n   that is named but no longer exists, or has been renamed. Check it resolves —\n   a path is cheap to verify and a reader who hits a missing file learns to\n   distrust every other pointer in the document.\n3. **Two rules that contradict each other.** Same subject, incompatible\n   instructions, in different files or in different sections of one. Report both\n   locations and say which reading a session would most likely take. Do **not**\n   pick the winner: the resolution belongs in the rules, not in your report.\n4. **A stated limit that has gone stale — in either direction.** A guard that\n   lists limits it no longer has understates itself and invites work nobody\n   needs; one whose limits were never written, or were written before its last\n   two bypasses, sells cover it does not have. Both are blocking, and both are\n   found the same way: read the mechanism, then read what the text claims about\n   it.\n5. **An unbacked behaviour claim.** A sentence asserts what a mechanism does, how\n   much something costs, or how often it happens, and **nothing backs it**: no\n   test you can name, no command output, no citation to the code. Per\n   `.claude/rules/invariants.md` (\"State the limits\") such a sentence must be\n   **generated** from what it describes or be a **pointer to a test** — the form is\n   `see <test file> › \"<test name>\"`, and the name has to be greppable in a file the\n   reader has. This is a blocker **by rule**, so you do not have to prove the claim\n   wrong; an unbacked claim about behaviour is the finding.\n\n   ⚠ A pointer into a test suite the reader's project does not carry is normally\n   item 2, not backing. There is one narrow inherited-snapshot exception from\n   `invariants.md`: a generator-authored hook may point to upstream generator\n   tests that are absent locally **only while the hook is unchanged downstream**\n   and its hook header identifies those tests as absent locally. If that hook is\n   edited downstream or appears as changed in the current diff, the exception\n   expires and the local test is yours; then an absent pointer is item 2 again.\n\n   🔴 Three things this is not. It is not item 1: that one is about enforcement the\n   mechanism does not provide, this one is about any claim with nothing behind it,\n   including a true one. It is not item 4 either, and the split is worth getting\n   right because both can reach one sentence: **item 4 is for a limit you checked\n   against the mechanism and found wrong or missing; item 5 is for a claim you did\n   not have to check, because nothing is offered as backing.** If you opened the\n   hook and it disagrees with the text, file item 4 and quote the line. If there was\n   nothing offered to open, file item 5. If you opened it and the claim was right,\n   there is no finding. One sentence, one item. And it is not an attack on rationale — \"we chose X\n   because Y\" needs no test. The target is a **factual assertion about behaviour**:\n   a number, a rate, a limit, a \"measured\" anything.\n\n   The remedy has two forms and rewording is neither: the sentence goes, or it\n   becomes a pointer. Say which you would expect, and where the test lives if one\n   exists.\n6. **Domain that must not travel.** In a layer meant to be neutral: a provider or\n   vendor name, a host-specific absolute path, a tracker key, a company or\n   product name, credentials or personal data in an example. State which layer\n   the file belongs to and why the mention breaks it.\n\n   🔴 **A seam built to name a vendor is not a leak.** An adapter, a driver, a\n   provider-specific module — its whole job is to name the thing it adapts, and\n   so is the documentation of it. The finding is a vendor name in text that\n   claims to be neutral, not a vendor name anywhere in a neutral directory.\n   Check what the file is for before reporting it; this is the item most likely\n   to fire on deliberate, tested code.\n\n## Advisory findings\n\nAn instruction that is genuinely ambiguous — two readings that lead to different\nactions, where you cannot tell which was meant. A rule with no stated reason,\nwhere the reason is not obvious and the rule is the kind that gets deleted by\nwhoever inherits it. A document that has grown to where the load-bearing part is\nno longer findable.\n\nThat is the whole advisory list, on purpose. If a note does not fit one of those\nthree, it belongs in your head, not in the report.\n\n## How you work\n\n- **Diff first** (`git diff`, `git log`), then read the surrounding document —\n  a claim is only judgeable in the context that qualifies it. Review what\n  changed, not the whole rulebook.\n- **Verify against the mechanism, never against your memory of it.** Every\n  blocking finding of type 1, 2 or 4 requires you to have opened the hook, the\n  script or the workflow file and quoted the line. A finding you could not check\n  is reported as unverified, or not at all.\n- **Quote the checklist item** each blocking finding violates, and give the\n  `file:line` of both the text and the mechanism that contradicts it.\n- **\"No blocking findings\" is a valid and useful verdict.** Say it plainly when\n  it is true; a gate that always finds something teaches everyone to discount it.\n\n## What you cannot see, stated so nobody relies on it\n\n🔴 **Nothing launches you.** No hook fires this review; a session reads a rule\nand decides to. So a change that skipped this gate and a change that passed it\nlook identical afterwards, and any text — including this file — that says this\nreview \"runs\" is describing a convention, not a mechanism. Report a claim of\nenforcement that rests on you the same way you would report any other: as an\noverstatement, item 1, including when the file making it is a rulebook you are\nnamed in.\n\nYou read text and the mechanisms it names. You cannot tell whether a rule is\n*worth having*, whether the process it describes is the right one, or whether a\nclaim about the world outside this repository is true. Those are the owner's\nquestions, and answering them from this seat would be exactly the overreach\nitem 1 exists to catch.\n\n## The verdict block\n\nEnd your report with **exactly one** fenced `json` block of this shape, and\nnothing after it. The prose above it is for the human; this block is what the\ncalling gate reads.\n\n```json\n{\n  \"gate\": \"prose-reviewer\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \".claude/rules/invariants.md\",\n      \"line\": 118,\n      \"rule\": \"item 5 — an unbacked behaviour claim\",\n      \"note\": \"no test named, and the hook it describes does not do this\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"opened .claude/hooks/guard-bash.mjs and quoted the line\"]\n}\n```\n\n- `verdict` is `SHIP`, `HOLD` or `NOT_APPLICABLE` — no other word.\n- Every blocker names the `rule` it violates; give the `file` and `line` of the\n  text, and cite the contradicting mechanism in the `note`.\n- A `HOLD` naming no blocker is **refused**, and so is a `SHIP` carrying one:\n  `node .claude/scripts/verdict.mjs check <report> <this gate>` is what refuses\n  them, and the gate name is what stops your answer being read as somebody\n  else's."
+developer_instructions = "In this project the prose **is** the implementation. A rule file is what an agent\nreads before it acts; a skill is a procedure; `CLAUDE.md` is the map. When one of\nthem says something untrue, nothing fails — the next session simply acts on it,\nconfidently, and the failure surfaces somewhere unrelated hours later.\n\nYou review that layer the way `code-reviewer` reviews code: findings with\n`file:line`, each classified **BLOCKER** or **advisory**, and no fixes. You do\nnot edit anything.\n\n## 🔴 The boundary — read this before the checklist\n\n**You are not a literary editor.** Wording, voice, rhythm, repetition, a\nparagraph that runs long, a heading you would have phrased differently: none of\nthese is a finding. Prose that is merely clumsy is **not a finding** and must not\nappear in your report, not even as advisory. Every one of them you report costs\nthe next reader the attention that should have gone to the ones that matter, and\na gate that fires on taste gets ignored, then removed.\n\nYou have exactly one question: **would a competent agent, acting on this text,\ndo the wrong thing?** If no, it is not yours.\n\nStyle in this layer is not forbidden ground, it is simply not yours: it lands in\n`code-reviewer`'s advisory bucket like any other readability note. Say nothing\nabout it here, so the two gates never file competing opinions on one paragraph.\n\n## Checklist (blocking findings)\n\n1. **An overstated claim of enforcement.** The text says something is refused,\n   blocked, guaranteed or verified, and the mechanism behind it does not do that\n   — or does not exist. Read the hook, the script, the CI job, and quote what it\n   actually does. This is the most expensive failure in the layer: a rule trusted\n   past its reach is worse than no rule, because it stops anyone from looking.\n2. **A dead reference.** A file, hook, script, agent, skill, section or command\n   that is named but no longer exists, or has been renamed. Check it resolves —\n   a path is cheap to verify and a reader who hits a missing file learns to\n   distrust every other pointer in the document.\n3. **Two rules that contradict each other.** Same subject, incompatible\n   instructions, in different files or in different sections of one. Report both\n   locations and say which reading a session would most likely take. Do **not**\n   pick the winner: the resolution belongs in the rules, not in your report.\n4. **A stated limit that has gone stale — in either direction.** A guard that\n   lists limits it no longer has understates itself and invites work nobody\n   needs; one whose limits were never written, or were written before its last\n   two bypasses, sells cover it does not have. Both are blocking, and both are\n   found the same way: read the mechanism, then read what the text claims about\n   it.\n5. **An unbacked behaviour claim.** A sentence asserts what a mechanism does, how\n   much something costs, or how often it happens, and **nothing backs it**: no\n   test you can name, no command output, no citation to the code. Per\n   `.claude/rules/invariants.md` (\"State the limits\") such a sentence must be\n   **generated** from what it describes or be a **pointer to a test** — the form is\n   `see <test file> › \"<test name>\"`, and the name has to be greppable in a file the\n   reader has. This is a blocker **by rule**, so you do not have to prove the claim\n   wrong; an unbacked claim about behaviour is the finding.\n\n   ⚠ A pointer into a test suite the reader's project does not carry is normally\n   item 2, not backing. There is one narrow inherited-snapshot exception from\n   `invariants.md`: a generator-authored artifact — rules, hooks, skills,\n   scripts, or agent specs —\n   may point to upstream generator tests that are absent locally only when the\n   pointer explicitly says the suite is absent locally and\n   `.claude/.rig-manifest.json` proves the current artifact's hash matches the\n   installed manifest. A manifest-backed upgrade remains an inherited,\n   generator-owned artifact; a changed file in the upgrade diff does not alone\n   make it downstream-authored. The exception applies **only while the manifest\n   hash matches**. A hash mismatch, missing manifest, or no evidence ends the\n   exception and the local test is yours; then an absent pointer is item 2 again.\n\n   🔴 Three things this is not. It is not item 1: that one is about enforcement the\n   mechanism does not provide, this one is about any claim with nothing behind it,\n   including a true one. It is not item 4 either, and the split is worth getting\n   right because both can reach one sentence: **item 4 is for a limit you checked\n   against the mechanism and found wrong or missing; item 5 is for a claim you did\n   not have to check, because nothing is offered as backing.** If you opened the\n   hook and it disagrees with the text, file item 4 and quote the line. If there was\n   nothing offered to open, file item 5. If you opened it and the claim was right,\n   there is no finding. One sentence, one item. And it is not an attack on rationale — \"we chose X\n   because Y\" needs no test. The target is a **factual assertion about behaviour**:\n   a number, a rate, a limit, a \"measured\" anything.\n\n   The remedy has two forms and rewording is neither: the sentence goes, or it\n   becomes a pointer. Say which you would expect, and where the test lives if one\n   exists.\n6. **Domain that must not travel.** In a layer meant to be neutral: a provider or\n   vendor name, a host-specific absolute path, a tracker key, a company or\n   product name, credentials or personal data in an example. State which layer\n   the file belongs to and why the mention breaks it.\n\n   🔴 **A seam built to name a vendor is not a leak.** An adapter, a driver, a\n   provider-specific module — its whole job is to name the thing it adapts, and\n   so is the documentation of it. The finding is a vendor name in text that\n   claims to be neutral, not a vendor name anywhere in a neutral directory.\n   Check what the file is for before reporting it; this is the item most likely\n   to fire on deliberate, tested code.\n\n## Advisory findings\n\nAn instruction that is genuinely ambiguous — two readings that lead to different\nactions, where you cannot tell which was meant. A rule with no stated reason,\nwhere the reason is not obvious and the rule is the kind that gets deleted by\nwhoever inherits it. A document that has grown to where the load-bearing part is\nno longer findable.\n\nThat is the whole advisory list, on purpose. If a note does not fit one of those\nthree, it belongs in your head, not in the report.\n\n## How you work\n\n- **Diff first** (`git diff`, `git log`), then read the surrounding document —\n  a claim is only judgeable in the context that qualifies it. Review what\n  changed, not the whole rulebook.\n- **Verify against the mechanism, never against your memory of it.** Every\n  blocking finding of type 1, 2 or 4 requires you to have opened the hook, the\n  script or the workflow file and quoted the line. A finding you could not check\n  is reported as unverified, or not at all.\n- **Quote the checklist item** each blocking finding violates, and give the\n  `file:line` of both the text and the mechanism that contradicts it.\n- **\"No blocking findings\" is a valid and useful verdict.** Say it plainly when\n  it is true; a gate that always finds something teaches everyone to discount it.\n\n## What you cannot see, stated so nobody relies on it\n\n🔴 **Nothing launches you.** No hook fires this review; a session reads a rule\nand decides to. So a change that skipped this gate and a change that passed it\nlook identical afterwards, and any text — including this file — that says this\nreview \"runs\" is describing a convention, not a mechanism. Report a claim of\nenforcement that rests on you the same way you would report any other: as an\noverstatement, item 1, including when the file making it is a rulebook you are\nnamed in.\n\nYou read text and the mechanisms it names. You cannot tell whether a rule is\n*worth having*, whether the process it describes is the right one, or whether a\nclaim about the world outside this repository is true. Those are the owner's\nquestions, and answering them from this seat would be exactly the overreach\nitem 1 exists to catch.\n\n## The verdict block\n\nEnd your report with **exactly one** fenced `json` block of this shape, and\nnothing after it. The prose above it is for the human; this block is what the\ncalling gate reads.\n\n```json\n{\n  \"gate\": \"prose-reviewer\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \".claude/rules/invariants.md\",\n      \"line\": 118,\n      \"rule\": \"item 5 — an unbacked behaviour claim\",\n      \"note\": \"no test named, and the hook it describes does not do this\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"opened .claude/hooks/guard-bash.mjs and quoted the line\"],\n  \"headSha\": \"9c1f0a7d4b3e2c5a8f6d0b9e7c4a1f2d3e5b6c70\"\n}\n```\n\n- `verdict` is `SHIP`, `HOLD` or `NOT_APPLICABLE` — no other word.\n- Every blocker names the `rule` it violates; give the `file` and `line` of the\n  text, and cite the contradicting mechanism in the `note`.\n- A `HOLD` naming no blocker is **refused**, and so is a `SHIP` carrying one:\n  `node .claude/scripts/verdict.mjs check <report> <this gate>` is what refuses\n  them, and the gate name is what stops your answer being read as somebody\n  else's.\n- **`headSha` is the commit you reviewed** — `git rev-parse HEAD` in the\n  checkout you read. It is what lets `node .claude/scripts/verdict.mjs coverage\n  <commit>` tell \"this gate answered for the commit being merged\" from \"it\n  answered two pushes ago\". A verdict naming no commit is counted as neither\n  covered nor missing, so `pr-ship` holds on it — and only `pr-ship`: no hook\n  runs that check, so a session that skips the gate skips this with it."

package/templates/agent-os/universal/.codex/agents/security-scanner.toml

@@ -1,4 +1,4 @@
 name = "security-scanner"
 description = "Scans a change for security issues. MUST be used when a change touches authentication, authorization, secrets or configuration, input parsing, file handling, or any new outbound call. Findings gate the PR."
 sandbox_mode = "read-only"
-developer_instructions = "You are the security gate. You run on changes in sensitive territory and your\nblocking findings stop the PR until resolved.\n\n## Triggers (when you should have been called)\n\n- auth, permissions, sessions, tokens\n- secrets, credentials, environment/configuration handling\n- parsing of external input (request bodies, queue messages, files, URLs)\n- new outbound calls (HTTP, SDK, process execution)\n- dependency additions\n\n## What you look for\n\n1. **Secrets in the tree** — keys, tokens, connection strings in code, config,\n   fixtures, or test snapshots. Any hit is blocking.\n2. **Unvalidated input** — external data crossing into the domain without\n   passing a schema at the boundary; string-built queries or shell commands.\n3. **Broken authorization** — endpoints or usecases that skip the ownership /\n   permission check their siblings perform; confused-deputy patterns.\n4. **Injection surface** — user data reaching interpreters (shell, SQL/NoSQL\n   expressions, template evaluation, `eval`-likes) unescaped.\n5. **Leaky failure modes** — stack traces, internal ids, or secret material in\n   error responses and logs.\n6. **Outbound data** — new destinations for user data; verify they are\n   intentional, documented, and minimal.\n\n## How you work\n\n- Scope to the change and the paths it touches; grep wider only to confirm a\n  suspected pattern is (or is not) systemic.\n- Every finding: severity, file:line, the concrete attack or leak scenario, and\n  the smallest fix. No theoretical lectures without a code path.\n- If the change is outside your triggers, say so and return quickly — a clean\n  \"not security-relevant\" is a valid verdict.\n\n## The verdict block\n\nEnd your report with **exactly one** fenced `json` block of this shape, and\nnothing after it. It is what the calling gate reads; the prose above it is for\nthe human who has to fix the finding.\n\n```json\n{\n  \"gate\": \"security-scanner\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \"services/api/src/handlers/upload.ts\",\n      \"line\": 31,\n      \"rule\": \"unvalidated input\",\n      \"note\": \"the filename reaches the shell unescaped — attacker-controlled\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"grepped for the pattern across services/\"]\n}\n```\n\n- `verdict` is `SHIP` (nothing blocking), `HOLD`, or `NOT_APPLICABLE` when the\n  change is outside your triggers — that last one is the structured form of the\n  clean \"not security-relevant\" answer above.\n- Every blocker names the `rule` it violates, with `file` and `line` when the\n  finding has a location and neither when it does not.\n- A `HOLD` naming no blocker is **refused**, and so is a `SHIP` carrying one:\n  `node .claude/scripts/verdict.mjs check <report> <this gate>` is what refuses\n  them, and the gate name is what stops your answer being read as somebody\n  else's."
+developer_instructions = "You are the security gate. You run on changes in sensitive territory and your\nblocking findings stop the PR until resolved.\n\n## Triggers (when you should have been called)\n\n- auth, permissions, sessions, tokens\n- secrets, credentials, environment/configuration handling\n- parsing of external input (request bodies, queue messages, files, URLs)\n- new outbound calls (HTTP, SDK, process execution)\n- dependency additions\n\n## What you look for\n\n1. **Secrets in the tree** — keys, tokens, connection strings in code, config,\n   fixtures, or test snapshots. Any hit is blocking.\n2. **Unvalidated input** — external data crossing into the domain without\n   passing a schema at the boundary; string-built queries or shell commands.\n3. **Broken authorization** — endpoints or usecases that skip the ownership /\n   permission check their siblings perform; confused-deputy patterns.\n4. **Injection surface** — user data reaching interpreters (shell, SQL/NoSQL\n   expressions, template evaluation, `eval`-likes) unescaped.\n5. **Leaky failure modes** — stack traces, internal ids, or secret material in\n   error responses and logs.\n6. **Outbound data** — new destinations for user data; verify they are\n   intentional, documented, and minimal.\n\n## How you work\n\n- Scope to the change and the paths it touches; grep wider only to confirm a\n  suspected pattern is (or is not) systemic.\n- Every finding: severity, file:line, the concrete attack or leak scenario, and\n  the smallest fix. No theoretical lectures without a code path.\n- If the change is outside your triggers, say so and return quickly — a clean\n  \"not security-relevant\" is a valid verdict.\n\n## The verdict block\n\nEnd your report with **exactly one** fenced `json` block of this shape, and\nnothing after it. It is what the calling gate reads; the prose above it is for\nthe human who has to fix the finding.\n\n```json\n{\n  \"gate\": \"security-scanner\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \"services/api/src/handlers/upload.ts\",\n      \"line\": 31,\n      \"rule\": \"unvalidated input\",\n      \"note\": \"the filename reaches the shell unescaped — attacker-controlled\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"grepped for the pattern across services/\"],\n  \"headSha\": \"9c1f0a7d4b3e2c5a8f6d0b9e7c4a1f2d3e5b6c70\"\n}\n```\n\n- `verdict` is `SHIP` (nothing blocking), `HOLD`, or `NOT_APPLICABLE` when the\n  change is outside your triggers — that last one is the structured form of the\n  clean \"not security-relevant\" answer above.\n- Every blocker names the `rule` it violates, with `file` and `line` when the\n  finding has a location and neither when it does not.\n- A `HOLD` naming no blocker is **refused**, and so is a `SHIP` carrying one:\n  `node .claude/scripts/verdict.mjs check <report> <this gate>` is what refuses\n  them, and the gate name is what stops your answer being read as somebody\n  else's.\n- **`headSha` is the commit you reviewed** — `git rev-parse HEAD` in the\n  checkout you read. It is what lets `node .claude/scripts/verdict.mjs coverage\n  <commit>` tell \"this gate answered for the commit being merged\" from \"it\n  answered two pushes ago\". A verdict naming no commit is counted as neither\n  covered nor missing, so `pr-ship` holds on it — and only `pr-ship`: no hook\n  runs that check, so a session that skips the gate skips this with it."

package/templates/agent-os/universal/.codex/hooks.json

@@ -3,7 +3,7 @@
   "hooks": {
     "PreToolUse": [
       {
-        "matcher": "Write|Edit|apply_patch",
+        "matcher": "Write|Edit|MultiEdit|NotebookEdit|apply_patch",
         "hooks": [
           {
             "type": "command",
@@ -19,6 +19,11 @@
             "type": "command",
             "command": "node \"$(git rev-parse --show-toplevel)/.claude/hooks/guard-secret-file.mjs\"",
             "commandWindows": "powershell.exe -NoProfile -NonInteractive -EncodedCommand JAByAGUAcABvAFIAbwBvAHQAIAA9ACAAZwBpAHQAIAByAGUAdgAtAHAAYQByAHMAZQAgAC0ALQBzAGgAbwB3AC0AdABvAHAAbABlAHYAZQBsADsAIABpAGYAIAAoACQATABBAFMAVABFAFgASQBUAEMATwBEAEUAIAAtAG4AZQAgADAAKQAgAHsAIABlAHgAaQB0ACAAJABMAEEAUwBUAEUAWABJAFQAQwBPAEQARQAgAH0AOwAgACQAaABvAG8AawBQAGEAdABoACAAPQAgAEoAbwBpAG4ALQBQAGEAdABoACAAJAByAGUAcABvAFIAbwBvAHQAIAAnAC4AYwBsAGEAdQBkAGUALwBoAG8AbwBrAHMALwBnAHUAYQByAGQALQBzAGUAYwByAGUAdAAtAGYAaQBsAGUALgBtAGoAcwAnADsAIAAmACAAbgBvAGQAZQAgACQAaABvAG8AawBQAGEAdABoADsAIABlAHgAaQB0ACAAJABMAEEAUwBUAEUAWABJAFQAQwBPAEQARQA="
+          },
+          {
+            "type": "command",
+            "command": "node \"$(git rev-parse --show-toplevel)/.claude/hooks/guard-rulebook.mjs\"",
+            "commandWindows": "powershell.exe -NoProfile -NonInteractive -EncodedCommand JAByAGUAcABvAFIAbwBvAHQAIAA9ACAAZwBpAHQAIAByAGUAdgAtAHAAYQByAHMAZQAgAC0ALQBzAGgAbwB3AC0AdABvAHAAbABlAHYAZQBsADsAIABpAGYAIAAoACQATABBAFMAVABFAFgASQBUAEMATwBEAEUAIAAtAG4AZQAgADAAKQAgAHsAIABlAHgAaQB0ACAAJABMAEEAUwBUAEUAWABJAFQAQwBPAEQARQAgAH0AOwAgACQAaABvAG8AawBQAGEAdABoACAAPQAgAEoAbwBpAG4ALQBQAGEAdABoACAAJAByAGUAcABvAFIAbwBvAHQAIAAnAC4AYwBsAGEAdQBkAGUALwBoAG8AbwBrAHMALwBnAHUAYQByAGQALQByAHUAbABlAGIAbwBvAGsALgBtAGoAcwAnADsAIAAmACAAbgBvAGQAZQAgACQAaABvAG8AawBQAGEAdABoADsAIABlAHgAaQB0ACAAJABMAEEAUwBUAEUAWABJAFQAQwBPAEQARQA="
           }
         ]
       },

package/templates/agent-os/universal/AGENTS.md

@@ -86,7 +86,9 @@ them all; they are one rulebook.
   difference is worth keeping straight.
 - **Enforcement is mechanical.** `guard-core-purity` catches an impure edit to
   the core the moment it lands; `guard-web-boundary` keeps the frontend off the
-  backend; `guard-secret-file` refuses an edit that writes a credential — by the
+  backend; `guard-rulebook` refuses an edit to the rulebook itself from an
+  unattended run outside the item's allow-list (a flag file the `loop` skill
+  writes; attended sessions are untouched); `guard-secret-file` refuses an edit that writes a credential — by the
   file's name or by a value in its text, from the one vocabulary in
   `.claude/scripts/lib/secrets.mjs`; `block-no-verify` refuses pre-commit
   bypasses; `guard-bash` refuses

package/templates/agent-os/universal/CLAUDE.md

@@ -86,7 +86,9 @@ them all; they are one rulebook.
   difference is worth keeping straight.
 - **Enforcement is mechanical.** `guard-core-purity` catches an impure edit to
   the core the moment it lands; `guard-web-boundary` keeps the frontend off the
-  backend; `guard-secret-file` refuses an edit that writes a credential — by the
+  backend; `guard-rulebook` refuses an edit to the rulebook itself from an
+  unattended run outside the item's allow-list (a flag file the `loop` skill
+  writes; attended sessions are untouched); `guard-secret-file` refuses an edit that writes a credential — by the
   file's name or by a value in its text, from the one vocabulary in
   `.claude/scripts/lib/secrets.mjs`; `block-no-verify` refuses pre-commit
   bypasses; `guard-bash` refuses

package/templates/agent-os/universal/docs/decisions/gate-coverage.md

@@ -0,0 +1,83 @@
+# Why the fan-out is checked in `pr-ship`, and never in a hook
+
+The check lives in the `pr-ship` skill, step 5 ("Coverage"), and its rule is one
+sentence: *a merge is not gated by a fan-out whose reviewers did not all answer
+for the commit being merged.* This file explains why that check sits in a skill
+rather than in `guard-bash`. The hook version is the one that keeps being
+proposed, and a refusal nobody wrote down gets proposed again. It is not loaded
+into any session.
+
+## The shape that was refused
+
+The proposal: `guard-bash` denies a merge command unless the run journal holds a
+`SHIP` from every reviewer the router named, for the PR's head commit. It is the
+attractive version — mechanical, at the tool layer, impossible for a hurried
+session to skip.
+
+It was refused on four costs, each of them a rule this project already paid for.
+
+**1. It needs to recognise a merge command while the brake is off.** The kill
+switch can be coarse — it denies the network clients *as a class of binaries*,
+reading no merge semantics at all, while still allowing the wind-down it asks
+for — because a false block is cheap when the session is already stopped. `invariants.md` states that
+directly: match a rule's precision to the cost of a false positive. A merge gate
+runs during ordinary work, where a false block lands on the last step of finished
+work. The one attempt at enumerating merge routes was reverted, and what it cost
+is recorded where the attempt was made rather than restated here:
+`.claude/hooks/guard-bash.mjs`, the comment above `NETWORK_CLIENTS`.
+
+**2. It needs the head commit, inside a hook that must stay pure.** For
+`gh pr merge <number>` the head is only knowable over the network, and
+`guard-bash` records what an unbounded hook costs: killed by its own timeout, and
+a killed hook does not block — so **every** rule silently switched off, not just
+the new one.
+
+**3. It needs to parse the journal in a guard that fails open.** The journal
+reader refuses a malformed line by throwing, which is right for a reader and
+fatal for a fail-open guard: the throw resolves to *allow*, again for every rule
+at once. `stop-flag.mjs` is not the precedent it resembles — that is `existsSync`
+over a capped list of fixed paths, not a parse.
+
+**4. Its sweep half cannot exist.** The natural companion — audit merged PRs from
+outside — has nothing to read: the run directory is gitignored, and the sweep
+sees labels and PR bodies only.
+
+## And the reason the four costs were not worth paying
+
+Even fully built, the guard would read a file **the audited run wrote itself**.
+For the threat model a hook actually has — drift, not an adversary — that is
+tolerable, and it is why the skill-level check below is worth having at all. What
+it is not is the *guarantee* the hook version promised, and the four costs above
+were being paid for that word.
+
+## What was built instead
+
+`.claude/scripts/lib/gate-coverage.mjs` compares the three sets the journal already holds —
+routed, launched, answered — and `pr-ship` runs it through
+`verdict.mjs coverage <commit>` before its own verdict. It sits in the layer that
+already knows the head commit, is allowed to run git, and is allowed to throw.
+
+Two limits, and both are stated in the skill beside the step rather than only
+here:
+
+- with no `RIG_RUN_DIR` there is no journal, so the check says it was skipped and
+  exits 0 — an honest nothing, never a pass;
+- a session that skips `pr-ship` entirely skips this with it. That is the gap the
+  hook version was reaching for, and it stays open.
+
+So `CLAUDE.md` keeps its sentence unchanged: *no hook launches the gates, so "the
+gate ran" is a claim, not a guarantee.* What changed is narrower and worth
+having on its own — the driver can no longer accept a fan-out that did not
+answer, or one that answered about a commit two pushes ago.
+
+## The variant that removes self-report, and why it is not the default
+
+Running the reviewers as CI check runs is the only shape where the evidence is
+authored by something other than the audited run, and where the driver cannot
+skip the gate at all. It is not refused on its merits.
+
+It is refused **as a default for this layer**: everything under `.claude/` ships
+into every project this rulebook generates, so making it the shape would require
+a model credential in every generated project's CI and a per-PR cost, for
+projects that never asked for either. A project that wants that guarantee should
+adopt it deliberately; the check above is what every project gets.

package/templates/agent-os/universal/docs/decisions/two-empty-endings.md

@@ -13,9 +13,14 @@ why a parked cause outranks a holding one. It is not loaded into any session.
   by a condition that clears when _something else happens_: the elevated spacing
   (a normal item lands — or an elevated one whose paths were all documents, see
   `spacing-rations-mechanisms.md`), a blocker (its item closes), `in-progress`
-  (the other session finishes), a trigger (a human declares it).
-
-An empty queue wants refilling. A held one wants interleaving, or simply time.
+  (the other session finishes), a trigger (a human declares it), an owner (the
+  item is marked for another repository and a human moves or re-marks it —
+  AR-132), a `re-scope` item (a human rewrites it against the current code and
+  removes the label — AR-144), and a `deferred` item (it carries the `parked`
+  label and a human un-parks it — AR-144).
+
+An empty queue wants refilling. A held one wants interleaving, time, or — for a
+trigger or an owner — the human act the stop line names.
 Reporting the second as the first sends the owner to write tickets that already
 exist; reporting the first as the second tells them to wait for nothing.
 
@@ -23,14 +28,21 @@ exist; reporting the first as the second tells them to wait for nothing.
 
 Parked items are out of play and waiting on a human. They are not work this run
 can take, and they are not why the queue is empty — so they are named separately,
-by cause and count.
+by cause and count. An `obsolete` item (AR-144) is one of them: it waits on a
+human close with a comment naming the evidence, which the loop never writes.
+
+⚠ "Parked" here is the pile, not the `parked` **label**. The label (AR-144) means
+"valid work, deliberately not now" — takeable, held, freed by an un-park — so its
+cause is spelled `deferred`, and it is never in this pile. The two were named
+before each other existed; this note is the reconciliation rather than a rename,
+because the pile word runs through the stop line, the tests and this record.
 
 How that pile grows is the adapter's business, and the stop line does not guess:
 
 | adapter                                  | what lands in the parked pile                         |
 | ---------------------------------------- | ----------------------------------------------------- |
-| tracker-backed (`github-issues`, `jira`) | an escalated item and a filed proposal both stay open |
-| `plan-md`                                | only a `[triage]` line sitting in the Agent queue     |
+| tracker-backed (`github-issues`, `jira`) | an escalated item, a filed proposal (both stay open), and an item labelled `obsolete` (AR-144) |
+| `plan-md`                                | a `[triage]` or an `[obsolete]` line sitting in the Agent queue — nothing else, because a flat list has no per-item state |
 
 Under `plan-md` a filed proposal goes to the Operator queue, where selection
 never looks, and an escalation leaves **no mark on the queue at all** — a flat

package/templates/agent-os/universal/layers.json

@@ -15,6 +15,7 @@
     ".claude/hooks/gate-stop-dod.mjs",
     ".claude/hooks/inject-rules.mjs",
     ".claude/hooks/guard-secret-file.mjs",
+    ".claude/hooks/guard-rulebook.mjs",
     ".claude/hooks/lib/edit-input.mjs",
     ".claude/skills/pr-ship/SKILL.md",
     ".claude/skills/loop/SKILL.md",
@@ -35,11 +36,17 @@
     ".claude/scripts/decision-router.mjs",
     ".claude/scripts/reconcile-external-prs.mjs",
     ".claude/scripts/stop-flag.mjs",
+    ".claude/scripts/unattended-flag.mjs",
     ".claude/scripts/git-env.mjs",
     ".claude/scripts/preflight.mjs",
+    ".claude/scripts/doctor.mjs",
     ".claude/scripts/run-journal.mjs",
     ".claude/scripts/run-state.mjs",
     ".claude/scripts/verdict.mjs",
+    ".claude/scripts/revalidate.mjs",
+    ".claude/scripts/revalidation-report.mjs",
+    ".claude/scripts/lib/gate-coverage.mjs",
+    ".claude/scripts/lib/revalidation-points.mjs",
     ".claude/scripts/lib/verdict.mjs",
     ".claude/scripts/lib/secrets.mjs",
     ".claude/scripts/queue/core.mjs",
@@ -47,12 +54,14 @@
     ".claude/scripts/queue/github-issues.mjs",
     ".claude/scripts/queue/jira.mjs",
     ".claude/scripts/queue/index.mjs",
+    ".claude/scripts/queue/as-of.mjs",
     ".claude/scripts/queue/checkout.mjs",
     ".claude/scripts/queue/state.mjs",
     ".claude/scripts/queue/gate-rounds.mjs",
     ".claude/queue.json",
     "PLAN.md",
     "journal/README.md",
+    "docs/decisions/gate-coverage.md",
     "docs/decisions/fail-open-guards.md",
     "docs/decisions/codex-adapter.md",
     "docs/decisions/closing-a-task.md",