create-agent-rig 0.9.1 → 0.10.1

package/CHANGELOG.md

@@ -14,6 +14,466 @@ second recorded departure; its own entry states the direction and the reason,
 and this paragraph deliberately does not restate them — a numbering rule with
 two copies of its exceptions is the shape 0.8.0 exists to remove.
 
+## 0.10.1
+
+**A fixes-only patch on 0.10.0.** Every entry corrects existing behaviour or
+states a rule the rulebook already follows; nothing is added to what `create`,
+`init` or `upgrade` install beyond the corrected files, and no agent, skill,
+hook or routing row is new.
+
+### Fixed
+
+- **`upgrade` no longer crashes on a directory where a rig-owned file
+  belongs.** A tracked path that is a directory or another non-regular entry
+  is reported as a conflict with a reason and left untouched, in `--dry-run`
+  and `--yes` alike, instead of ending in an `EISDIR` stack trace (RP-189).
+- **`upgrade` re-checks a leftover `AGENTS.md.rig-new` before removing it.**
+  The file is removed only while it still holds exactly the rendered
+  `AGENTS.md` bytes, so one edited after the plan was shown is kept, one
+  removed in the meantime no longer crashes the run, and the closing notice
+  reports a removal only when one happened (RP-202).
+- **`upgrade --dry-run` exits 1 where the real run refuses** a non-file at
+  `AGENTS.md.rig-new`, instead of 0 (RP-202).
+- **The Stop gate's budget is measured on the monotonic clock.**
+  `gate-stop-dod` computed its shared deadline from the wall clock, so a clock
+  step lengthened or shortened it (RP-204).
+
+### Rulebook
+
+- `workflow.md` states the review-findings rule as a Core section of its own:
+  a blocking finding closes by a fix the reviewer reads again, or by evidence
+  the reviewer can re-check that its premise is false — with or without the
+  opt-in workflow layer (RP-194).
+- `check-premises` treats a claim about an external API, CLI or library as a
+  premise: backed by a four-part record (version, authoritative source, date,
+  quote or pointer), it holds or is `PREMISE FALSE`; without one it stays
+  `UNVERIFIABLE` (RP-194).
+
+### Generator repository (not a rig-facing change)
+
+- `packages/cli/src/commands/integrations.ts` is a declared elevated path.
+- `scripts/memory-conformance.mjs` names why a rig spawn failed — exit code or
+  signal plus the child's error code — instead of a bare "exit 1" (RP-188).
+- `docs/decisions/agent-roles-1.0.md` records the 1.0 agent-role targets; it
+  is repository-local and not shipped.
+
+## 0.10.0
+
+Platforms: the packed release candidate is accepted on Linux, Windows and
+macOS on Apple silicon (`scripts/release-acceptance.mjs`, dispatched on the
+exact release commit; `e2e.yml` gains a `macos-e2e` job for it). Every CI job
+now runs on a GitHub-hosted image; `e2e.yml` no longer has a runner switch.
+On Windows, Spec Kit 1.0.8 rewrites `.claude/settings.json` and `.codex/config.toml` with CRLF line endings, so
+`doctor` reports `rig-owned-files` as `warn` after Spec Kit setup there.
+Ownership hashes cover exact bytes (`docs/decisions/raw-byte-ownership.md`), so
+where a Codex MCP provider is also wired, `doctor` reports that wiring as
+`drift` and a later `setup` change to a Codex MCP provider refuses with the
+managed fragment for a manual merge instead of overwriting the file.
+
+`doctor [--json]` aggregates Rig file integrity, installed guards, optional
+workflow mechanisms, MCP wiring, pinned offline Spec Kit status and the
+machine's custom Memory diagnosis. It preserves the existing versioned
+`ok`/`warn`/`fail` contract and keeps connectivity and trust unobserved.
+
+A new project gets an `implementation-agent` for the Green step of TDD, pinned
+like the other roles (`claude-sonnet-5` / `gpt-5.6-terra`, `high`) in
+`.claude/agents/` and `.codex/agents/`. Ordinary implementation no longer falls
+to the unnamed general-purpose subagent, which remains for ad-hoc work.
+
+Basic Memory is available as an optional, wiring-only MCP preview for Claude Code
+and Codex. Rig records only its project MCP wiring; it never installs, updates,
+inspects, synchronizes, or removes Basic Memory data. `uvx` remains a launcher
+observation rather than a runtime, connectivity, or trust verification.
+
+`setup` now offers a provider/harness wizard and delegates Spec Kit setup to
+the pinned official CLI after an explicit plan and consent. Existing external
+installations use `setup add spec-kit --adopt`; updates and removal use the
+official integration lifecycle without destructive force. Spec Kit retains
+its files and manifests; Rig records intent after authoritative status succeeds.
+
+`setup apply` and `setup remove` manage explicitly selected Figma and Atlassian
+MCP configuration through Claude Code's documented project config. Dry-run and
+consent apply before changes; existing user entries are preserved. Ownership
+hashes live alongside provider selection in `.rig/integrations.json`.
+Authorization stays with the provider and harness. Codex uses whole-file
+rendering from the installed release baseline and a rolling intent hash; a
+manual edit refuses rather than being merged or overwritten.
+
+**`AGENTS.md` is now the canonical rulebook; `CLAUDE.md` is a short
+compatibility shim.** A new project gets the full rulebook text in
+`AGENTS.md` and a `CLAUDE.md` that is just an `@AGENTS.md` import (Claude
+Code's own import syntax) plus Claude-Code-specific notes — never a second
+copy of the rulebook. This is not a claim that Claude Code always reads
+`AGENTS.md` on its own: that support is version- and configuration-dependent,
+and the shim exists precisely for the sessions where it is not active (see
+`docs/decisions/agents-md-canonical.md` for what is verified and what is
+not). Provider-specific wiring (`.claude/settings.json`, `.claude/agents/`,
+`.codex/hooks.json`, `.codex/config.toml`) is unaffected.
+
+Migrating an existing rig: `upgrade` treats both files as the ordinary
+manifest-tracked paths they always were, with one deliberate coupling. An
+untouched pair is replaced with the new shim/canonical split. A `CLAUDE.md`
+or `AGENTS.md` the user edited is reported as a conflict and kept exactly as
+edited, never force-shimmed or overwritten — and if the kept CLAUDE.md is not
+already the `@AGENTS.md` shim, the reason also says it **shadows AGENTS.md**
+(by Claude Code's own default, a `CLAUDE.md` is read _instead of_ `AGENTS.md`,
+not alongside it) and names the fix. A file the user deleted stays deleted.
+**Security fix, content-based since round 5:** CLAUDE.md is held back —
+kept as its old, still-readable content, never replaced with the shim —
+only when the on-disk AGENTS.md genuinely cannot serve as the rulebook:
+absent, or present but carrying no non-empty `elevated-paths` block. A
+CUSTOMISED AGENTS.md that still carries a readable block lets the shim
+through — the shim then imports the user's own rulebook, which is the whole
+point of it — and AGENTS.md itself stays a perfectly ordinary, quiet
+conflict, because a customised `elevated-paths` block is this project's own
+designed steady state, not a broken rulebook (an earlier version of this
+rule keyed on AGENTS.md's verdict alone, which could not tell the two
+apart). Without the hold at all, an unreadable AGENTS.md combined with an
+untouched CLAUDE.md would silently install a shim over a rulebook that may
+carry no `elevated-paths` declaration at all. Holding CLAUDE.md back
+re-vouches it for its own current bytes — the same mechanism that lets a
+later `upgrade` resolve cleanly — which means a later `uninstall` reads it
+as rig-owned and unedited and **removes it**, not "leaves it in place" the
+way an ordinary, never-vouched conflict does; the decision record's
+uninstall column and a dedicated test cover this.
+
+The one always-reachable remedy for a genuinely unreadable AGENTS.md:
+`upgrade` WRITES the already-rendered content to a real sibling file,
+`AGENTS.md.rig-new` (never recorded in the manifest, and appearing ONLY in
+the genuinely held-back state — never for an ordinary, readable conflict),
+instead of printing it to stdout for a verbatim paste — measured (gate cycle
+3, round 3's own remedy) not to survive a real copy-paste byte-for-byte. Its
+status (`would-write` / `identical` / `differs` / `unsafe`) is decided
+entirely at plan time, so a dry run and a real run agree, and a symlink or
+directory at the path is refused BEFORE anything else is written. `mv
+AGENTS.md.rig-new AGENTS.md` is printed only for bytes this run wrote or
+verified — for a pre-existing, differing rescue file the remedy is `rm` (or
+restoring AGENTS.md some other way), never `mv`, since that file is not this
+run's bytes. The instruction is the short, delimited, LAST thing the run
+prints, not buried between the plan and the consent prompt. Once AGENTS.md
+resolves and the rig is no longer held back, a leftover matching rescue file
+is cleaned up and the run says so; unrelated clutter at the path (a stray
+directory or symlink) on an otherwise healthy rig is never touched and never
+mentioned. **Round 4, security disclosure:** `uninstall` removing CLAUDE.md
+or AGENTS.md while the other of the pair is not a clean removal now says so,
+naming which file stays and as what — a bare `- CLAUDE.md` line previously
+did not. See `docs/decisions/agents-md-canonical.md`, "The remedy that
+actually works", for what was measured and what did not work.
+
+Pinned by `packages/cli/test/upgrade.test.ts`'s describe block "RP-186:
+AGENTS.md becomes canonical, CLAUDE.md becomes its shim" (untouched pair,
+edited/deleted each side, the shadow-note cases, the held-back cases, the
+rescue-file state machine, the held-back uninstall case, and the re-derived
+4×3 pristine/edited-with-block/edited-without-block/deleted grid across both
+files), `packages/cli/test/uninstall.test.ts`'s pair-disclosure and
+rescue-file tests, `packages/cli/test/cli-report.test.ts`'s CLI-boundary
+tests for the rescue file (an independent oracle, never `plan.contents`) and
+for the quiet, customised-AGENTS.md conflict, and
+`test/e2e/agents-md-migration.test.ts` (the same migration, including the
+rescue-file remedy end to end and the customised-rulebook case, against a
+rig built from the actual pre-RP-186 payload).
+
+**Breaking: the application skeletons are removed, exactly as 0.9.0
+announced.** `create <dir>` no longer takes `--target` and no longer
+scaffolds `aws-serverless` or `node-service` — there is one payload, the same
+one `init` installs, and `create` is now a thin wrapper: `mkdir` → `git init`
+→ that install → the pristine baseline commit. The product is a package
+manager for repository-scoped Claude Code and Codex configuration, never an
+application generator (owner ruling, 2026-09-13). The universal layer's
+create-only "architecture group" (`.claude/rules/architecture.md`,
+`guard-core-purity`, `guard-web-boundary`, and the monorepo-shaped
+`CLAUDE.md`/`AGENTS.md` map) is retired along with it — it was an
+application-shape promise a harness configurator has no business making.
+`templates/agent-os/stack/*` (the node-ts and aws-cdk overlays) and
+`templates/agent-os/init/*` (the override layer `init` used to shadow
+`universal` with) are deleted; the init flavour's map and process-only scope
+_is_ the universal layer now.
+
+Migration for a repository this tool already generated: nothing breaks.
+`upgrade` still recognises your rig, still refreshes the files it installed
+and you did not touch, and still leaves your application code alone — it was
+never part of any install set, before or after this release. A path from a
+retired layer (an aws-cdk or node-ts rule, an architecture hook) gets a new
+verdict, `retired`: never written, never deleted, dropped from the manifest,
+and reported as no longer shipped — it is yours now. `upgrade`'s `--dry-run`
+output and its summary line both show a `retired` count when there is one.
+The full pre-0.10 migration path is pinned in `test/e2e/upgrade.test.ts` ›
+"retires the deleted stack overlay, and preserves the application and the
+process layer".
+
+**Fixed: Codex rejected the `SessionStart` rules refresh.** `inject-rules`
+printed plain text opening with `[agent-os]`, and Codex 0.154.0 was measured
+failing the hook with `hook returned invalid session start JSON output`, so
+that session started without the autonomy rules. The hook now prints one JSON object —
+`hookSpecificOutput.additionalContext`, the shape both harnesses document —
+carrying the same text, character for character, that Claude Code received
+before. It also waits for that write to finish instead of exiting over it,
+and a stdout failure other than an abandoned reader is reported on stderr
+with a non-zero exit rather than looking like a healthy session
+(`docs/decisions/session-start-wire-format.md`). That decision record now
+ships with the hook that cites it — the process layer's manifest
+(`layers.json`) had omitted it, so a generated rig received the hook's
+citation but not the file it pointed at.
+
+**Breaking: the workflow layer (queue/loop/pr-ship/run-state/journal/
+revalidation/claim-records/PR-lifecycle helpers) is now an experimental,
+opt-in install (RP-180).** A default `init`/`create` installs Lean Core only
+— rules, gates, stop rules, the review-gate agents and their hooks — and
+never the autonomous, cooperative multi-session machinery on top of it. Pass
+`--layer workflow` to `init` or to `create-agent-rig <dir>` to install it too;
+a rig that already has it keeps it on a plain re-run of `init` with no flag.
+`RigManifest` gains a `layers` field recording the choice, and `upgrade`
+refreshes only the layer(s) a rig recorded. Migration for an existing rig:
+nothing breaks and nothing is deleted — a manifest written before this field
+existed carries no `layers` key, and that absence is read as "every layer,"
+exactly what every release before this one installed, so `upgrade` keeps
+managing the workflow files a rig already has. Revalidation and claim-records
+keep their existing behavior unchanged (RP-53's freeze through the RP-26 gate
+on 2026-10-27) — this release only relocates their install-time layer.
+`uninstall` (RP-181) needs no layer awareness of its own: it walks
+`manifest.files` and `manifest.kept` directly, and those two records already
+reflect exactly what a given install wrote, by construction — a Core-only
+rig's manifest simply has no workflow-layer entries in `files` for
+`uninstall` to find, and an inherited pre-0.10 rig's workflow files are
+recorded in `files` exactly as every other installed path is (its manifest
+carries no `layers` key, read as "every layer" the same way `upgrade` reads
+it), so `uninstall` removes them under the same byte-hash check as anything
+else it owns. Nothing about the layer split widens or narrows what
+`uninstall` was already willing to remove.
+
+**This repository's own node-ts conventions move out of the shipped
+package**, into `scripts/dogfood/` — a repo-local overlay `sync-agent-os.mjs`
+composes into this repository's own rulebook, same as before, just no longer
+a template any generated rig receives.
+
+### Added
+
+- **Setup MCP ownership (RP-22)** uses one schema-v1
+  `.rig/integrations.json` for intent and Claude entry hashes. The
+  `list | add | apply | remove` commands replace the intermediate receipt
+  and `setup verify` surface. See `docs/command-contract.md`,
+  "setup integrations", and the command-level regressions in
+  `packages/cli/test/integrations-intent.test.ts`. The published
+  `setup --memory-root` interface remains compatible.
+- **`uninstall [dir] [--dry-run] [--yes] [--json]`** removes what a rig
+  installed, file by file, against the evidence `.claude/.rig-manifest.json`
+  carries and nothing else: a path is removed only when its bytes on disk
+  still match the recorded hash exactly (compared as raw bytes, never a
+  UTF-8-decoded string — ADR-RP-003), the path is a plain file the whole way
+  down from the repository root (never a symlinked ancestor or a symlink
+  itself), and the path is itself one of the EXACT paths this release
+  actually installs — a boundary drawn at a top-level directory would let a
+  manifest pair almost any path under `.claude/`, `.rig/`, `docs/` or
+  `journal/` with its true hash and have it removed. Anything under `.git` is
+  refused outright, for the whole run, for any segment that NORMALISES to
+  `.git` (case folded, a Windows alternate-data-stream suffix stripped,
+  trailing dots and spaces stripped) at any depth — not only a literal
+  top-level `.git` — regardless of the hash a manifest pairs it with; the same
+  refusal covers a manifest that lists one path under both `files` and
+  `kept`, which this tool's own writer never produces. An edited,
+  already-deleted, foreign, `init`-kept, or otherwise unrecognised file is
+  reported and left in place, and so is modified hook wiring
+  (`.claude/settings.json`, `.codex/hooks.json`), which names the hooks still
+  referenced — and so is a hook file such wiring still calls, even when that
+  hook file's own bytes are pristine, naming the wiring file that holds it, so
+  a kept settings file is never left pointing at a hook `uninstall` just
+  deleted. The manifest itself is read, and later removed, through the same
+  symlink-safe per-segment check every other manifest-owned path gets, never
+  a plain lexical one. It prints the plan, then asks before removing anything
+  — `--yes` up front, a prompt on a terminal, an outright refusal off one, and
+  always required with `--json`, which never prompts, never deletes
+  unattended, and reports an unplanned filesystem error (not only its own
+  refusals) as the same one JSON object rather than a bare stack trace. The
+  manifest is deleted last, and only once nothing was preserved: a CRLF
+  checkout, an edit, or any other conflict keeps the manifest even after
+  every removal that WAS planned succeeded, because the rig still owns bytes
+  it did not remove and the manifest is the only record naming them. A run
+  interrupted partway also keeps it and reports what finished and what a
+  re-run still owes — including the manifest itself, whenever a clean re-run
+  really would go on to delete it — so a repeat run is safe, and a repeat run
+  that finds no manifest at all is a no-op, exit 0. `.rig/` itself is never
+  removed, empty or not; the one manifest-owned file the rig installs
+  directly inside it is removed like any other file when it is pristine.
+  `--json` prints one JSON object and nothing else on stdout — `removed` is
+  always what was actually deleted, and `planned` carries the plan's own
+  answer regardless of outcome — documented next to the other command
+  contracts in `docs/command-contract.md` ("## uninstall (RP-181)"). A
+  successful removal names its own next step (`git add -A` and a commit) —
+  `uninstall` never touches git history itself. Selected MCP wiring and
+  delegated Spec Kit removal have their own lifecycle, `setup remove`;
+  `uninstall` touches only files the Rig manifest names (RP-181).
+- **`uninstall` re-verifies bytes twice more, and gains `--detach`.** A plan
+  can go stale in the window a confirmation prompt sits in: each `remove`
+  action now carries the plan's own recorded hash, re-read and compared
+  immediately before that one file's removal — a mismatch skips that file
+  (reported `preserved`, reason "changed since planning"), never aborts the
+  run, and never deletes it. The manifest's own bytes are checked the same
+  way at two points: once before the first removal (a mismatch refuses the
+  whole apply, nothing removed) and once immediately before the manifest's
+  own deletion (a mismatch keeps the manifest and reports an honest partial
+  result — what finished, and that the manifest is what a re-run still owes).
+  `--json`'s payload now names which of three outcomes a completed,
+  non-dry-run reached — `uninstalled`, `partial`, `detached`; a `--dry-run`
+  preview names none of them, since it has no end state to name — and folds
+  any
+  changed-since-planning path into `preserved` rather than a separate,
+  easy-to-miss list. **`--detach`** performs the identical safe cleanup and
+  then removes the manifest anyway, leaving every preserved (or
+  changed-since-planning) path for the user and printing the complete
+  handover list — it never forces away a conflicting or modified file, and
+  there is no `--force`. A hook file a wiring file still calls survives even
+  when that protection is only discoverable at apply time — a symlinked
+  wiring file (whose referenced hooks cannot be safely read, so every owned
+  hook is protected instead of a guessed subset) or one edited inside the
+  confirmation-prompt window, re-checked immediately before the first hook
+  removal, since hook files sort ahead of the wiring that references them.
+  **Protection also now follows a hook's own imports to a fixed point**: a
+  wired hook is not self-contained (`guard-bash.mjs` imports
+  `.claude/hooks/lib/hook-input.mjs`, `.claude/scripts/stop-flag.mjs`,
+  `.claude/scripts/lib/shell-tools.mjs`, …), and protecting only the
+  directly-named hook while deleting what it imports left every one of
+  those dying at module resolution with exit 1 — silently inert, since a
+  `PreToolUse` hook that exits non-2 is non-blocking. Every REAL read this
+  walk performs is gated by the same symlink-safe check every other read in
+  this command gets, not the purely lexical containment alone: a hook file
+  swapped for a symlink to an unbounded or blocking special file — reachable
+  from nothing worse than `git clone`ing a hostile branch, before consent —
+  no longer makes the walk's own read hang or exhaust the heap; the file
+  stays protected regardless, since that is recorded before the read is
+  attempted. A `kept` wiring file (a pre-existing `.claude/settings.json`
+  `init` never took ownership of — the ordinary "starts from an existing
+  repository" path) now protects its hooks too: it used to protect NONE of
+  them, silently, because the pass that decides this read only `files`'
+  hashes and a `kept` path has none. **The reason a protected hook reports
+  now names WHY its wiring file survives, not only THAT it does** — a `kept`
+  wiring file's hook used to say "which was preserved as edited" too, which
+  is false (nobody edited it; the rig never wrote it), and told a
+  contradictory story two lines apart from `.claude/settings.json`'s own
+  "user-owned (kept by init)" verdict in the same report. It now reads
+  "which init found already in place and never took ownership of"; a hook
+  whose wiring file could not be safely read at all (itself a symlink) now
+  says so ("which could not be safely read…") instead of "edited" too. A
+  file reached only through another protected file's own import, rather
+  than named by the wiring file directly, now gets its own reason wording
+  naming the immediate importer, since the wiring file itself may never
+  mention it at all. **A hook file that cannot itself be safely read (a
+  symlink) now protects the conservative superset of every owned `.mjs`
+  path, not only itself.** Two dependencies in the shipped tree have exactly
+  ONE hook that imports them — `.claude/scripts/lib/secrets.mjs` (only
+  `guard-secret-file.mjs`) and `.claude/scripts/unattended-flag.mjs` (only
+  `guard-rulebook.mjs`) — so symlinking that one seeder used to drop the
+  dependency's protection entirely: measured end to end through a real
+  `git commit` and a fresh `git clone`, the credential guard went from
+  blocking a credential write (exit 2) to dying at module resolution (exit 1,
+  non-blocking for `PreToolUse`) once its own import was gone, wiring still
+  in place and still claiming to enforce it. **The sweep that protects a
+  dependency it could not trace now says so, instead of claiming it as a
+  confirmed reference.** Reusing the "still referenced by … which was
+  preserved as edited" wording for a swept-in path made the sentence that
+  sounds most certain describe the files the command was least sure about:
+  in one reproduced run, of 84 owned paths under one preserved wiring file,
+  only ~7 were genuinely referenced by it, and ~30 were swept in by caution
+  alone — including a test fixture no hook could ever import — all reported
+  with the identical, fully-confident wording. A fifth reason string now
+  names the file whose own unreadability triggered the sweep instead
+  ("protected because `<file>` could not be read…"), and the plain-text
+  summary adds a one-line roll-up — how many `preserved` paths were
+  genuinely traced versus kept only as a precaution — once any are.
+  Which wording a hook gets does not depend on where the unreadable file
+  sits in the wiring file's own order: a hook the wiring names, or one a
+  readable file imports, is reported as referenced or imported whether the
+  precaution sweep ran before or after the command reached it. The sweep
+  itself is also
+  now narrower: it fires on a file that could not be SAFELY READ, never on one that is simply gone. Sweeping on absence bought
+  nothing (an absent file has no imports that can fail to resolve, because
+  the module that would make them is itself gone) and cost a real one: an
+  ordinary "I turned this hook off by hand" deletion, with the wiring still
+  naming it, used to turn 83 planned removals into 40 planned / 43
+  preserved on a repository that had done nothing hostile at all. Two other
+  apply-time-only fixes in the same area: the removal loop now re-reads a
+  wiring file's bytes fresh, immediately before that file's own removal,
+  instead of reusing a copy `protectedHooksFor` read before the loop even
+  started (an edit landing in that window was previously missed); and a
+  filesystem error surfacing from the new apply-time hook-protection re-check
+  itself is now caught the same way `planUninstall`'s own errors are, so
+  `--json` still gets its one promised object rather than a bare stack trace.
+  A manifest key with more path segments than any real path this release ever
+  installs no longer reaches the native path-join call that segment count
+  could otherwise overflow — reported the same honest, per-path `preserved`
+  way any other unowned path is (deeper than any path this release could ever
+  own), rather than aborting the whole run, `--dry-run` included, through a
+  message that used to claim the path "resolves outside" the repository,
+  which was simply false for one that never left it lexically at all; the
+  genuine `..`/absolute escape check is unweakened and still aborts the whole
+  run exactly as before.
+  Every ancestor check now makes two independent tests per segment, not one:
+  the existing symlink/type classification, and a separate `realpath`
+  containment check that does not read that classification at all — the
+  second is what makes the containment guarantee hold for a Windows
+  directory junction (or any future reparse-point kind) by construction,
+  rather than resting on `isSymbolicLink()` reporting it correctly, which is
+  the one part of this that a Windows-only test in the `windows-e2e` lane
+  (`packages/cli/test/uninstall.test.ts`, gated by `onlyOnWindows`) actually
+  measures — this repository's own development environment cannot build a
+  junction to verify it directly. Also: a manifest segment with a very long
+  run of trailing dots or spaces no longer costs quadratic time to
+  normalise (a hostile committed manifest could otherwise hang
+  `uninstall --dry-run`); `rigOwnedPaths` reads the bare install-manifest
+  list rather than rendering every template's content just to learn which
+  paths exist.
+
+### Generator (not a rig-facing change)
+
+**Generator-only (RP-178): nothing a newly scaffolded project receives changes.**
+No file under `templates/` moved. This entry records what changed inside the
+generator's own repository, ahead of 0.10.0.
+
+- **The speculative policy-declaration library and its benchmark are gone.**
+  `packages/cli/src/policy/` (a declaration schema, registry, decision-record
+  format and per-harness adapters, RP-36/RP-76) and
+  `scripts/policy-benchmark*.mjs` (the child-process benchmark that measured
+  it) shipped nothing a CLI command, an installed hook, or the sync scripts
+  ever called — its own module header said so. Removed as dead code, along
+  with `contracts/session-messaging/` (its sole remaining consumer) and the
+  vitest `benchmark` project. RP-157, RP-160 and RP-161 are closed by
+  deletion rather than by fix, since all three findings were against this
+  unreachable surface; the consumer graph behind each deletion is on pull
+  request #227.
+- **`docs/compatibility.md`** replaces the removed framework's claim to be a
+  compatibility check: a Claude Code × Codex × capability matrix — every
+  wired hook, the Windows command strings, skills/agents delivery, and the
+  optional external-subsystem contract — with one status vocabulary for the
+  matrix (SUPPORTED, DEGRADED, UNSUPPORTED, NOT-APPLICABLE, UNVERIFIED).
+  `test/template/compatibility-matrix.test.ts` refuses a status outside it,
+  a measured status without a test pointer, and a pointer whose test file is
+  gone or no longer contains the quoted test name. Windows is stated as
+  measured: the Claude Code wiring and most Codex `commandWindows` scripts
+  are UNVERIFIED there.
+- **`test/template/guard-acceptance.test.ts`** invokes the retained
+  `PreToolUse` guards through the real `.claude/settings.json` /
+  `.codex/hooks.json` wiring strings on POSIX, with one allowed and one
+  denied fixture per guard for each harness that wires it, in the payload
+  shape that harness sends (Codex edits arrive as `apply_patch`); the denied
+  one must exit exactly 2 and name its reason. It is the wiring a generated
+  project actually runs, not a parallel path. The guard list is derived from
+  the two wiring files, so a newly wired guard with no fixture and no
+  reasoned exception fails the suite, and so does one without a
+  `docs/compatibility.md` row. `guard-subagent-model` is Claude-only and
+  runs through the Claude Code wiring alone.
+- **Meta-tests that pinned shape instead of behaviour were removed or cut
+  down to the assertion that survives review as real**, each with its own
+  reason recorded in the pull request: a citation count nothing rereads
+  (RP-82, `generator-neutrality.test.ts`), an exact skip-site count that
+  named the deleted benchmark files, and the project-count/ordering
+  assertions that named the deleted `benchmark` vitest project.
+- **RP-110: the CI spawn-baseline diagnostic is removed** from the
+  `windows-smoke` job. It measured bare `node` startup, which stayed flat
+  across a red run and its green rerun while their wall clocks differed by
+  roughly half, so it read "healthy" on the run it was built to diagnose — a
+  diagnostic that argues against the correct conclusion is worse than none.
+  No replacement baseline was added, per the ticket's own accepted
+  resolution.
+
 ## 0.9.1
 
 **A patch, numbered by the owner.** Every entry corrects existing behaviour;
@@ -150,9 +610,8 @@ and the two template checks on Linux and `windows-smoke` (the CLI's unit
 project) on Windows; in `e2e.yml`, the Linux `e2e` job — the full suite with
 the e2e installs and the benchmark — when the pull request touches the CLI,
 the templates, the e2e harness or that workflow. The full suite on Windows
-runs in `e2e.yml` on master, nightly and by dispatch only, and a
-`runner_mode` switch there selects a self-hosted fallback that no pull
-request can reach (`docs/runners.md`).
+runs in `e2e.yml` on master, nightly and by dispatch only
+(`docs/runners.md`).
 
 ## 0.8.0