create-agent-rig 0.4.0 → 0.6.0

package/CHANGELOG.md

@@ -11,6 +11,292 @@ 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.6.0
+
+**The loop now checks its premises against the tracker at three points, and
+the rulebook cannot be edited from an unattended run.** Everything below is what
+a newly scaffolded or `init`ed project receives.
+
+**The released-hash table no longer depends on tags** (AR-35). It is built
+from `templates/release-ledger.json` — the commit each version was published
+from — so it now carries 0.5.0's bytes, 0.4.0's real bytes (the stale `v0.4.0`
+tag is reported and ignored) and a 0.2.0 row; the consequence 0.5.0's notes
+state for a rig upgraded without a readable manifest is closed for every
+release the ledger records. This release itself is excluded, as every release
+being prepared is: commit `.claude/.rig-manifest.json`.
+
+### Added
+
+- **Revalidation at SELECT, BEFORE_PR and BEFORE_CLOSE** (AR-133, AR-134,
+  AR-135, AR-136). `.claude/scripts/revalidate.mjs` compares the item the run
+  took against the tracker's current state — at selection against this run's
+  take-up, before a PR against the item and the default branch, and before a
+  close against the item's fields and its dependants — and every point records
+  one evidence shape in the run directory; `revalidation-report.mjs` reads them
+  back. A close now proves it transitioned rather than reporting the write. The
+  points themselves have one spelling, `.claude/scripts/lib/revalidation-points.mjs`,
+  and the `loop` and `pr-ship` skills are checked against it in both directions
+  (AR-137).
+- **`guard-rulebook`** (AR-51): a `PreToolUse` hook that refuses an edit to the
+  hooks, their wiring, `.claude/queue.json`, the queue adapters, the router, the
+  gate sweep, the rules or `CLAUDE.md` while the unattended flag the `loop` skill
+  writes at claim time is on disk (`.claude/scripts/unattended-flag.mjs`), unless
+  the item's allow-list names the path. Attended sessions are untouched. Its
+  header states its limits, each one under test in the generator.
+- **`doctor`** (AR-5): `node .claude/scripts/doctor.mjs` reads
+  `.claude/.rig-manifest.json` and reports every hook the project owns — bytes
+  that differ from what the generator installed, or no manifest entry — that has
+  no `<hook>.test.mjs` beside it. Exemptions are an explicit list with reasons in
+  `.claude/doctor-exemptions.json`, a file the project writes (none ships); a
+  doctor that looked nowhere never says GO.
+- **Fan-out coverage is checked, not just recorded** (AR-79, AR-118): `pr-ship`
+  compares the reviewers that answered against the route the router gave the
+  head, bound to that head; `docs/decisions/gate-coverage.md` records the shape
+  and the unreadable states.
+- **Queue items carry more of the tracker's meaning into selection:**
+  - an item marked for another repository (`owner-<name>`; `[owner:<name>]` in
+    `PLAN.md`) is held, never taken — a checkout names itself in
+    `options.owner` (AR-132);
+  - the lifecycle vocabulary `keep-core` / `re-scope` / `obsolete` and the
+    `parked` pile are read above the adapter seam, and the loop infers none of
+    it (AR-144);
+  - a proposal the loop files records the commit it was measured against
+    (`asOf`), and `hygiene` reports the one git has overtaken (AR-116); it also
+    names what it measured and what it inferred, and an inference past the
+    measurement is refused at filing (AR-142);
+  - the take-up baseline reaches into earlier runs, so a marker the adapter's
+    own write produced is not read back as a catch (AR-138, AR-140);
+  - `gate-round` refuses to count a round on a checkout that cannot ship, and
+    states the cap as a spent count rather than a convergence verdict (AR-141,
+    AR-115).
+
+### Changed
+
+- **The Jira adapter is harder to knock over** (AR-54): a request timeout that
+  stays armed through the body read, transient retry honouring `Retry-After`
+  (capped at 60 s), cursor pagination with a stated page cap, a priority-id
+  fallback, and a JQL that is always project-qualified — an explicit
+  `options.jql` must begin with `project = <KEY>`.
+- **The adapter contract gained `find` and `listProposals`** (AR-135, AR-116)
+  and the ticket shape gained `updatedAt`, `owner`, `lifecycle` and `parked`.
+  On `jira`, `limit` is now the **page** size, not a result cap.
+- **A close is a close only when the tracker says so** (AR-135): all three
+  adapters read the item back and return `transitioned` from what they read,
+  instead of from the argument they were given or a `gh` exit code.
+- **`gate-stop-dod` measures the project the hook belongs to, not the cwd**, and
+  names the tree in its refusal (AR-119).
+- **`.claude/rules/node-ts.md` names the third state of a PR head** — one that
+  gets no workflow run at all — and says it is retriggered per required check,
+  never merged on an older head's green (AR-149).
+- **The autonomy and invariants rules state the enforcement they have exactly**:
+  `guard-secret-file`'s four blind spots, the unattended flag as what arms
+  `guard-rulebook`, and the unbacked-claim rule with its two exits (delete, or
+  point at the test).
+
+### Fixed
+
+- **`MultiEdit` and `NotebookEdit` reached every content guard and produced no
+  fragment**, so an impure edit to the core through either passed unchecked.
+  `hooks/lib/edit-input.mjs` now yields one fragment per edit for both (AR-51).
+- **`manifest.version` is held to the same value check its siblings get**, and
+  the comment no longer claims a prerelease the rig never wrote (AR-128).
+- **Hooks resolve the project root inside `main()`**, so a throw there announces
+  itself instead of failing open silently (AR-119).
+
+- **The upgrade plan's header told you your rig was old when it could not know
+  that.** It greeted every rig it could not read a manifest for with "no manifest
+  here (a pre-0.4.0 rig)". There are three ways to reach that branch and the
+  claim is false for two of them: a manifest you deleted, and one that is on disk
+  and voided by its own reader — the case 0.5.0's notes below single out. The
+  header now states the condition the code actually has, **no readable manifest
+  here**, and offers the three causes without asserting any of them.
+- **`--no-color` is accepted by `upgrade` and `init`**, not only by the
+  scaffolder. It was advertised under Options without being scoped to one
+  command, and the other two exited 1 with "Unknown option". **Nothing about
+  their output changes** — the CLI builds its palette on the `create` path alone,
+  so neither command had colour to switch off, and neither read `NO_COLOR`
+  either. What changes is that a flag the help offers is no longer a refusal.
+- **The plan's summary now accounts for every action, not four kinds out of
+  six.** It counted files to replace, new files, yours-kept and already-current,
+  while the plan above it also prints a line for a hook wiring hand-over and for
+  a file you removed — so the four buckets could not add up to what was printed.
+  Both are counted now, in the order the plan lists them, and they appear only
+  when they occurred: a plan without them reads exactly as it did.
+
+## 0.5.0
+
+**Codex is a harness of this rig now, not a thing you adapt it to.** A generated
+project carries one rulebook and two readers: `CLAUDE.md` for Claude Code and
+the same text as `AGENTS.md` for Codex, with repository skills in
+`.agents/skills/`, agent profiles in `.codex/agents/` and portable hook wiring
+in `.codex/hooks.json`. Neither harness gets the weaker policy, and the derived
+half is drift-checked rather than maintained twice.
+
+**This release ships untagged, by the owner's decision, and it has exactly one
+consequence — read it if you ever run `upgrade` on a rig whose
+`.claude/.rig-manifest.json` is missing or unreadable.**
+`templates/hash-history.json`, the table such a rig is measured against, is
+built from `v*` tags. So 0.5.0's bytes never enter it, and the `0.4.0` row it
+gained in this release carries the _previous_ release's bytes: that tag points at
+0.3.2's content, which is why the row adds no hash to any path. Both paths 0.4.0
+actually changed — `.claude/skills/loop/SKILL.md` and `PLAN.md` — are in the
+table with their 0.3.x hashes; what is absent is 0.4.0's bytes from their hash
+lists.
+
+**Who that reaches, and who it does not.** `create`, `init` and `upgrade` each
+write the manifest, and `upgrade` matches it **before** it consults the table, so
+a rig whose manifest is present and parseable is unaffected whatever the table
+says. Without a readable manifest the table decides, and it decides in the
+conservative direction: bytes it recognises are replaced, bytes it does not are
+kept and reported as yours — see `packages/cli/test/upgrade.test.ts` › "replaces
+a file that matches a released version, and reports the rest".
+
+A rig installed **before** 0.4.0 is not the exposed case: its 0.3.x bytes are in
+the table, so those two files are recognised and replaced. The rig that keeps
+them is one installed at **0.4.0** whose manifest is unreadable.
+
+**And the scale of it grows with this release, which matters more than those two
+files.** Because 0.5.0 is untagged, nothing it ships enters the table either — so
+a rig installed at 0.5.0 and later upgraded **without a readable manifest** has
+most of its agent-os files unrecognised, and many of them are paths the table has
+no row for at all. Every one is kept and reported as yours, so no edit is lost
+and no file is silently skipped, but almost nothing would be refreshed either. **Commit `.claude/.rig-manifest.json`** — that single habit makes the
+table irrelevant to you, and it is what `README.md` puts in bold.
+
+### Added
+
+- **Codex is now a native target of the Agent OS.** Generated and `init`ed
+  projects receive `AGENTS.md`, repository skills in `.agents/skills/`, custom
+  agent profiles in `.codex/agents/`, and portable `.codex/hooks.json` wiring.
+  These files are derived from the Claude Code sources and drift-checked.
+- Architecture guards now understand Codex `apply_patch` payloads, inspecting
+  additions and bounded existing content for moves, so removing an old
+  violation does not create a false block.
+
+### Changed
+
+- **`upgrade` now replaces `.claude/settings.json` when the manifest proves you
+  never touched it** — closing the decision 0.4.0's notes left open below. The
+  case it exists for is a release that adds a hook: the hook file arrived and
+  the wiring that calls it did not, so the guard sat on disk doing nothing. When
+  the on-disk bytes hash-match the entry the manifest recorded for the installed
+  release, they are provably the rig's own and the release's version is written.
+
+  **Three limits. The first two are there because not having them was tried,
+  and each produced a regression two reviewers reproduced independently.**
+
+  1. **The released-hash fallback does not apply to this file.** Every other
+     file the rig installed can be recognised by matching a tagged release even
+     with no manifest entry. This one cannot: a rig with no manifest that has
+     run `init` is recorded as `kind: "init"`, and the wiring that flavour
+     writes deliberately omits the hooks `init` does not install.
+  2. **A replacement that would stop calling a hook still present in
+     `.claude/hooks/` is handed over instead**, whatever the manifest says. This
+     is the guard that does not depend on getting `kind` right — a manifest
+     saying `init` on a rig `create` produced reaches the same wrong wiring
+     through the hash arm alone.
+  3. **Anything else is unchanged:** the new entries are printed for you to
+     merge, and nothing is written.
+
+- **`init --force` is deprecated.** It refuses, names `upgrade` as the command
+  that refreshes a rig, and writes nothing. It only ever replaced `CLAUDE.md`,
+  which `upgrade` now does per file and with the manifest behind it. **The flag
+  is removed in 0.6** — this release is the one warning you get.
+
+  The way into a `create` rig that `--force` used to provide is a deleted
+  `CLAUDE.md`; that is what `init`'s refusal is actually about, and it is the
+  case the manifest-preserving fix below was written for.
+
+### Security
+
+- 🔴 **A committed `.claude/.rig-manifest.json` could run code on the machine
+  of whoever upgraded the rig.** `project.name`, `project.scope`,
+  `project.region` and `stacks` were each validated — but only as _path_
+  segments, a predicate that asks whether a value can steer a write. Two of
+  them are also substituted into installed **files**:
+  `.claude/scripts/stop-flag.mjs` embeds the name inside a single-quoted
+  JavaScript string literal that `guard-bash` imports on every Bash call. A
+  value closing that quote steers no path at all and passed — it executed in
+  the hook process, **and** moved the kill switch's path off
+  `~/.claude/<name>-loop-STOP`, so the brake read as installed while doing
+  nothing. The manifest travels in pull requests, so the delivery was an
+  ordinary PR plus an `upgrade`. All four are now held to the shape the rig
+  actually produces (`^[a-z0-9_][a-z0-9._-]*$`), and a manifest carrying
+  anything else is void as a whole rather than corrected.
+
+  **Checking a rig you upgraded from a manifest you did not write — three
+  places, because the name is not the only value that travelled.**
+  `.claude/scripts/stop-flag.mjs` is the executable sink: its kill-switch line
+  must read your own project name. `region` lands in
+  `.claude/skills/ro-debug/SKILL.md` as `export AWS_REGION=…` on rigs carrying
+  the `aws-cdk` overlay — and a manifest also declares `stacks`, so it can
+  request that overlay on a rig that never had it. The name is substituted into
+  the documents the agent obeys as well (`CLAUDE.md`, `PLAN.md`, the `loop`
+  skill), where a hostile value arrives as injected text rather than as code.
+
+  Nothing `create` or `init` writes is rejected by the new rule — including an
+  empty `region` and a name with a leading underscore, which
+  `projectNameFor` really can produce.
+
+### Fixed
+
+- **`init --force` inside a generated project used to make `upgrade` stop
+  refreshing the stack overlays — silently.** ⚠ Read this next to the
+  deprecation above: `--force` is refused in this same release, so
+  the route described here is gone. The fix is not idle — the manifest is
+  preserved on **every** `init` over a `create` rig, and the remaining route in
+  is a deleted `CLAUDE.md`. `init` rewrote the rig manifest
+  as `kind: "init"`, `stacks: []`, empty `region`, and `upgrade` trusts a
+  manifest wholesale rather than re-detecting: the stack files simply left the
+  plan, reported neither as deleted nor as a conflict, and `CLAUDE.md` came
+  back in the `init` flavour. `init` now carries the `kind`, `project` and
+  `stacks` it found in the manifest through unchanged, and adds an entry for
+  each file it wrote without dropping the entries already there. It also says,
+  before writing anything, that this rig came from `create` and `upgrade` is
+  the command that refreshes it.
+
+  ⚠ **Both halves read the manifest, so a rig that has none — anything
+  installed before 0.4.0 — is not covered.** There `init` still writes
+  `kind: "init"`, `stacks: []`, empty `region`, and prints no advisory; worse,
+  such a rig could previously be recovered by `upgrade`, which re-detects the
+  install from the files on disk **only when there is no manifest at all**, and
+  the one `init` writes takes that route away. On a pre-0.4.0 rig, run
+  `upgrade` before `init`.
+
+  **Recovering a rig whose manifest was already flattened:** delete
+  `.claude/.rig-manifest.json` and run `upgrade` — the detection restores
+  `kind`, `stacks` and `region` from the files themselves; hand-writing the
+  manifest is not needed and `parseManifest` rejects the whole file on any
+  malformed field. What that does **not** repair is `CLAUDE.md`: the flattening
+  `init` overwrote it with the `init` flavour, so `upgrade` reports it as
+  `conflict` ("not a version this rig ever released — treated as yours") and
+  the create flavour has to be merged back by hand.
+
+- **The `jira` queue adapter was calling an endpoint Atlassian removed.** Both
+  selection and the triage dedupe went through `GET /rest/api/3/search`, which
+  answers `410 Gone`; the adapter threw on the status line and the loop read
+  that as an unreadable queue. It now uses `POST /rest/api/3/search/jql`. If
+  your rig is on the `jira` adapter, this is the difference between a loop that
+  works and one that reports an empty board. Cursor pagination
+  (`nextPageToken`) is **not** implemented yet, so a board with more open issues
+  than `limit` (default 100) still loses its tail.
+
+### Changed — action needed if your board uses the `jira` adapter
+
+- 🔴 **The elevated-tier marker on Jira is now the `elevated` label, not
+  `human-review`.** A board that marked elevated work with `human-review` will,
+  after this upgrade, hand every item to the loop as `normal` — the
+  elevated-spacing ration silently stops holding anything back. **Relabel those
+  issues to `elevated` before running the loop again.** The change is
+  deliberate: on a Jira board `human-review` reads as "a human is looking at
+  it", which is a different claim from "this change is expensive to reverse".
+  The `github-issues` adapter is unaffected and still reads `human-review`,
+  where it does mean a human reviewed the diff.
+- **Selection now excludes the `operator-queue` label as well as `triage`.** An
+  item in the owner's lane is work a human has taken, so the loop no longer
+  picks one up. If you used `operator-queue` for something else, rename it
+  first.
+
 ## 0.4.0
 
 Upgrading is a command now: **`npx create-agent-rig@0.4.0 upgrade`** (`@latest`
@@ -332,10 +618,27 @@ sometimes earlier (step 6). Everything before that is mechanical:
    tree, are in the tarball. This is where scaffolders break, and the git path
    cannot catch it.
 3. Version in `package.json` (and the private inner package, kept in step).
-4. `node scripts/build-hash-history.mjs` — regenerate the released-hash table
-   from the tags **after** the version bump, so the version now shipping is the
-   first one it excludes. Forgetting it would leave `upgrade` unable to
-   recognise the previous release.
+4. **Record where the previous release was published from, then regenerate
+   the released-hash table.** `templates/release-ledger.json` maps each released
+   version to the commit it was published from; the entry for the release
+   _before_ this one is written now, because a commit cannot carry its own sha:
+
+   ```sh
+   npm view create-agent-rig@<previous> gitHead   # → the sha for the ledger
+   node scripts/build-hash-history.mjs             # rebuilds the table from it
+   ```
+
+   The builder reads every `## X.Y.Z` this file lists below the version in
+   `package.json` and **refuses, naming the version and that command**, when
+   the ledger has no entry for one — it never drops a release silently, since a
+   dropped release is one `upgrade` can no longer recognise. A value of `null`
+   is the one other answer: the published bytes are not recoverable from git
+   (0.1.0 was published from a commit whose `package.json` already read
+   0.2.0), so that version deliberately gets no row. Pinned in
+   `test/template/hash-history.test.ts` › "throws for a released version the
+   ledger does not mention, naming the version and the npm command" and ›
+   "points at a commit whose package.json carries that version".
+
 5. This file, and `PLAN.md` if the plan's claims changed.
 6. **`pnpm test` again — this run, not step 1, is the one that can catch a
    stale hash table.** The check compares the table against the versions this
@@ -343,13 +646,15 @@ sometimes earlier (step 6). Everything before that is mechanical:
    comparing the _old_ release to the _old_ table and passes either way. A
    guard that can only fire after the thing it guards has changed has to be run
    after it.
-7. `git tag v<version> && git push --tags` — **first check that the tag does not
-   already exist** (`git ls-remote --tags origin`). A leftover from an abandoned
-   attempt is a published ref: deleting or moving it is an **owner** action, and
-   the release stops here until it is gone. A tag pointing at the wrong commit
-   is not cosmetic — the next release builds its hash table from it, and every
-   file that changed in between then reads as user-modified and stops being
-   upgradable.
+7. **Tagging is not part of this project's release process** — standing owner
+   decision, recorded at 0.5.0: the owner publishes by hand and does not tag.
+   Since 0.6.0 (AR-35) that costs nothing: the table is built from the ledger in
+   step 4, not from tags, and a `v*` tag is neither required nor trusted. One
+   that exists and points elsewhere than the ledger — `v0.4.0` does, at 0.3.2's
+   content — is printed as a warning by the builder and changes nothing:
+   `test/template/hash-history.test.ts` › "builds the table from the ledger
+   alone — tags are a warning source, never an input".
+
 8. **Owner:** `npm publish`.
 9. **Owner:** smoke the published artifact — `npx create-agent-rig@<version>` in
    an empty directory, then `pnpm install && pnpm check` inside it; and

package/README.md

@@ -3,6 +3,12 @@
 Scaffold a project that ships with an **agent operating system** — rules,
 gates, and hooks that hold the architecture mechanically, not by prose.
 
+The same Agent OS is native to both **Claude Code and Codex**. Claude-facing
+files remain the authoring surface; the generator derives Codex's `AGENTS.md`,
+repository skills under `.agents/skills/`, custom agents under `.codex/agents/`,
+and `.codex/hooks.json`. `node scripts/sync-codex-adapter.mjs --check` refuses
+drift between the two projections.
+
 ```sh
 npx create-agent-rig my-app                        # choose a target interactively
 npx create-agent-rig my-app --target node-service  # or name it up front
@@ -22,16 +28,24 @@ npx create-agent-rig init --dry-run  # print the plan, write nothing
 ```
 
 `init` drops in the autonomy tiers, stop rules, workflow, and the enforcement
-hooks — **wired**, in a `.claude/settings.json` that names exactly the hooks it
-installed — plus a `CLAUDE.md` that describes that rig rather than the generated
-monorepo. It refuses to clobber an existing `CLAUDE.md`; if the repo already has
-a `.claude/settings.json`, it keeps it and prints the entries to merge, because a
-hook nothing calls is not enforcement.
+hooks — **wired** for both harnesses, in `.claude/settings.json` and
+`.codex/hooks.json`, each naming exactly the hooks it installed — plus matching
+`CLAUDE.md` and `AGENTS.md` maps that describe that rig rather than the generated
+monorepo. It refuses to clobber either existing map; if the repo already has a
+Claude or Codex hook config, it keeps it and prints the entries to merge,
+because a hook nothing calls is not enforcement.
 
 Two things it deliberately leaves to you, and says so in the installed
-`CLAUDE.md`: the Definition-of-Done gate has no `dod-checks.json` (it cannot know
+maps: the Definition-of-Done gate has no `dod-checks.json` (it cannot know
 your commands), and the elevated-path list names only what every repo has.
 
+After generation or upgrade, review the checked-in `.codex/hooks.json` in Codex's
+`/hooks` view and explicitly trust it if Codex presents a trust prompt. The
+[official Codex hooks documentation](https://learn.chatgpt.com/docs/hooks)
+records trust against the current hook hash, so a changed hook definition may
+require that review again; the adapter does not silently replace user-owned hook
+configuration.
+
 ## Upgrading a rig you already have
 
 A release changes files, and `init` only ever _adds_ — so bringing an existing
@@ -54,12 +68,22 @@ How it knows: `create` and `init` write `.claude/.rig-manifest.json` — the rig
 version plus a hash per installed file. **Commit it**; without it in the
 repository the command is blind on CI and on a colleague's machine. Rigs
 installed before 0.4.0 have no manifest, so the package also carries the hashes
-of every **tagged** release (0.3.0 onward — 0.1.0 and 0.2.0 shipped untagged,
-and a rig from those reports every file as yours) and recognises a file matching
-one of them.
-
-`.claude/settings.json` is never replaced — it is where your own hooks live, so
-the new wiring is printed for you to merge.
+of every release whose published commit is on record (0.2.0 onward — 0.1.0's
+published bytes are not recoverable, and a rig from it reports every file as
+yours) and recognises a file matching one of them. The record is
+`templates/release-ledger.json`, written at the release _after_ the one it
+describes, so the newest release is never in the table a rig installed from it
+carries — one more reason committing the manifest is the sentence in bold above
+and not an aside.
+
+`.claude/settings.json` is replaced only when the manifest's recorded hash
+proves the rig wrote those exact bytes and you have not touched them — the case
+where a release adds a hook and the wiring that calls it. Anything else, and it
+is where your own hooks live: the new wiring is printed for you to merge, never
+written. Unlike every other file, a match against the released hashes is not
+enough for this one, and a replacement that would stop calling a hook the
+current wiring names — while that hook's file is still in `.claude/hooks/` — is
+handed over instead.
 
 **A file you deleted stays deleted.** The rules invite you to delete the ones
 whose invariant your project does not have, so an upgrade that quietly restored
@@ -75,13 +99,26 @@ and `--dry-run` lists it before anything is written.
 **A system of boundaries, each held by tooling.** An agent (or a human using
 one) cannot talk its way past them — each guard is a pre-write scan that stops
 the normal path cold (review and tests back it; the claim is stated exactly,
-never inflated). The hooks live in `.claude/hooks/` and are wired in
-`.claude/settings.json`:
+never inflated). The hook implementations live once in `.claude/hooks/` and are
+wired by both `.claude/settings.json` and `.codex/hooks.json`:
 
 - **`guard-core-purity`** — refuses any edit that puts I/O, clock, randomness,
   environment access, or a non-allowlisted import into the pure domain core;
 - **`guard-web-boundary`** — refuses `db`/service imports from the frontend;
   the web talks to the backend over HTTP only;
+- **`guard-rulebook`** — in an unattended run (a flag file the `loop` skill
+  writes at claim time), refuses an edit to the rulebook — hooks, wiring,
+  `queue.json`, the queue adapters, the router, the gate sweep, the rules,
+  `CLAUDE.md` — outside the current item's allow-list; does nothing in an
+  attended session.
+- **`guard-secret-file`** — refuses an edit that writes a credential: either the
+  path names one (`jira.env`, `id_rsa`, anything under `secrets/`) or the text
+  carries a credential VALUE. Both arms read one vocabulary,
+  `.claude/scripts/lib/secrets.mjs`, and a refusal names the pattern and the line
+  and **never the matched value** — printing it would leak the secret in the act
+  of refusing it. Its four blind spots are in its own header, each naming the
+  test that pins it or saying plainly that none does — and those tests live in
+  this generator, not in the rig;
 - **`block-no-verify`** — refuses bypassing pre-commit checks (and knows the
   difference between using the `--no-verify`/`-n` flag and merely mentioning it
   in a message);
@@ -96,7 +133,9 @@ never inflated). The hooks live in `.claude/hooks/` and are wired in
   check is red; it fails open (a missing or corrupt config never makes the
   session unquittable) and never blocks twice in a row;
 - **`inject-rules`** — re-injects the autonomy rules at session start, so they
-  survive compaction and resumes.
+  survive compaction and resumes: the whole file, minus the regions the file
+  itself marks as reference. What is left out is a decision written in
+  `autonomy.md` on the line above it, not one this hook infers.
 
 **A brake that is a real file.** `touch ~/.claude/<project>-loop-STOP` and no
 merge lands until it is removed — enforced at the tool layer, so it holds even if
@@ -125,8 +164,8 @@ never), **stop rules** (three strikes, flaky ≠ retry, session staleness),
 `prose-reviewer`, and `cdk-diff-reviewer` on the AWS target), **skills** (`pr-ship` pre-merge gate;
 `loop` queue driver; `worktree-task` for concurrent sessions; `new-invariant`, a
 generator for the invariant→hook→test pattern; `post-deploy-verify` and
-`ro-debug` on the AWS target), and a one-page `CLAUDE.md` map a fresh session
-orients by.
+`ro-debug` on the AWS target), and matching one-page `CLAUDE.md` / `AGENTS.md`
+maps a fresh session orients by.
 
 **The hooks are examples, not laws.** `.claude/rules/invariants.md` states the
 pattern behind each one — a stated invariant, a mechanical check, a test for the
@@ -196,8 +235,8 @@ under test, because that is exactly where scaffolders break. A grep-test keeps
 the universal rules free of any provider mention; the hook-blocking behavior
 itself is under test; and a weekly lockfile-free run resolves each template's
 dependencies fresh to catch upstream breakage early. This repo dogfoods its own
-rulebook — `CLAUDE.md` and `.claude/` are composed from the templates, and
-drift fails the suite.
+rulebook — the Claude and Codex projections are composed from the templates,
+and drift fails the suite.
 
 **And the enforcement layer is adversarially reviewed, not just tested.** The
 Bash guard went through four review rounds with ten reviewers, who executed it

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-agent-rig",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "Scaffold a new project with an agent operating system (rules, gates, hooks) and a runnable code skeleton",
   "keywords": [
     "create",
@@ -10,6 +10,7 @@
     "template",
     "agent",
     "claude-code",
+    "codex",
     "agent-os",
     "aws-serverless",
     "node-service"

package/packages/cli/dist/commands/create.js

@@ -2,7 +2,7 @@ import { execFile } from 'node:child_process';
 import { mkdir, readFile, readdir, stat } from 'node:fs/promises';
 import path from 'node:path';
 import { promisify } from 'node:util';
-import { copyTree, listTree } from '../lib/copy-tree.js';
+import { copyTree, listTree, mapConcurrent } from '../lib/copy-tree.js';
 import { ALLOWED_OVERWRITES, detectCollisions } from '../lib/composition.js';
 import { agentOsLayerDirs } from '../lib/install-set.js';
 import { sha256, writeManifest } from '../lib/manifest.js';
@@ -82,8 +82,13 @@ export async function createProject(dirArg, options) {
 async function recordInstall(projectDir, agentOsLayers, transforms, ctx, target) {
     const files = {};
     for (const layer of agentOsLayers) {
-        for (const rel of await listTree(layer.dir, transforms)) {
-            files[rel] = sha256(await readFile(path.join(projectDir, ...rel.split('/')), 'utf8'));
+        const paths = await listTree(layer.dir, transforms);
+        const hashes = await mapConcurrent(paths, 16, async (rel) => ({
+            rel,
+            hash: sha256(await readFile(path.join(projectDir, ...rel.split('/')), 'utf8')),
+        }));
+        for (const { rel, hash } of hashes) {
+            files[rel] = hash;
         }
     }
     await writeManifest(projectDir, {