docs(remediation): bank D-37/D-38, pre-register RM-61 re-review, rebuild board for a cold read

D-38 — RM-61's terminal-green verifier certified the right RECORD for the wrong COMMIT. rev-974
mutated only #2188's commit field and the gate still exited 0. Confirmed by construction: at
e7b29219 the whole verifier had exactly one "commit" line (159), no expected-head parameter, no
comparison, no failure path. D-24 at the gate layer — a true answer to a different question.
The transferable half is the AC set, not the verifier: AC1-AC8 ALL PASSED and the PR was still
NO GO, because every registered check tested whether the signature discriminates and none tested
whether the evidence was bound to its subject (coverage-failure-mode-2, D-17 class). Mos ruled a
STANDING clause into RM-02 coverage: "does this gate bind its evidence to the subject under
review?" — every gate can fail this way and pass its own ACs.

D-37 — one shared .git/config silently re-identified EVERY worktree. extensions.worktreeConfig is
unset, so a worker's repo-local identity write rebinds all linked worktrees at once; the
orchestrator checkout and rev-974's review worktree both authored as coder-mos1. Distinct from
D-34, not an instance: MOSAIC_GIT_IDENTITY was exported and correct and still resolved wrong.
Sharp edge is gate-16 defeated in the artifact — the reviewer would author its pre-registered ACs
as the author of the code under review. No contamination occurred. Containment (explicit -c, no
shared-config rewrites mid-flight) is the standing order; the real fix is authorised and owned by
Mos, sequenced at a quiet seam. #1024 is implicated: repo-local pinning is the colliding mechanism.

Also pre-registers the twelve RM-61 re-review checks at exact head 033b2ffb BEFORE the reviewer
reads the diff, and rebuilds the board for a cold read — RM-61 "building", "nothing implemented
yet", and DECISION-1/2/3 "must be ruled" were all stale, the D-36 class again at the same seam.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This commit is contained in:
mos-dt-0
2026-08-01 08:59:40 -05:00
co-authored by Claude Opus 5
parent 345d152790
commit 50c0340add
3 changed files with 148 additions and 36 deletions
+75
View File
@@ -322,6 +322,81 @@ merges cannot perform them.
And the shape holds: **RM-03 is the fix for the queue guard, so this — the first delivery through the
complete stack — is also the last one gated by a check that could not fail.**
### D-38 — a gate that certified the right RECORD for the wrong COMMIT (and the AC set that could not see it)
**RM-61's terminal-green verifier reported the pipeline's commit and never bound it to the PR head.**
`rev-974` altered ONLY `#2188`'s `commit` field to an unrelated 40-hex value; the verifier still exited 0
with `exempted_steps=1`. So an older artifact pipeline could satisfy the detailed gate while
`pr-ci-wait.sh` was evaluating a different head. Confirmed by the orchestrator **by construction, not by
report**: at `e7b29219`, `grep -n commit` over the entire verifier returned exactly one line — 159,
`"commit": record.get("commit")` — no argparse parameter, no comparison, no failure path. The verifier
could not bind a scan to a head because it was never given one.
**Class: D-24 at the gate layer — a TRUE answer to a DIFFERENT question.** Not a lie, not a bug in the
signature (AC1AC8 all PASSED and the discrimination result stands); the gate answered "is this record
terminal-green" correctly while the question that mattered was "is THIS HEAD terminal-green".
**★ The transferable finding is the AC set, not the verifier.** Eight pre-registered checks all passed
and the PR was still NO GO. Every one tested whether the signature DISCRIMINATES; not one tested whether
the evidence was BOUND TO ITS SUBJECT. That is **coverage-failure-mode-2 — INCOMPLETE (the D-17 class):
green while a criterion's requirement goes untested.** It surfaced only because the reviewer went BEYOND
the registered set and mutated a field no registered check covered.
**The recursion is why this must be standing.** This mission's own anti-inert-gate work shipped a gate
that could certify the wrong subject — the disease one layer up, inside the cure, the same shape as
DECISION-1's stranded-executor risk.
> **REQUIREMENT ON RM-02 (ruled by Mos, 2026-08-01): a STANDING coverage clause in the registry —
> _"does this gate BIND its evidence to the subject under review?"_** Not per-gate discretion: every gate
> we ship can fail this way **and pass its own ACs**, so the registry must ask it of each one. This
> attaches to RM-02 clause (2) (coverage).
Remediated at `033b2ffb` (`--expect-commit`, exit 2 on missing/malformed, exit 1 on missing-or-mismatched
record commit, harness 9→12 cases). Orchestrator reproduced the reviewer's exact attack independently:
mutated ⇒ exit 1 / `exempted_steps 0` / explicit anomaly; correctly bound ⇒ exit 0 / `exempted_steps 1`;
omitted argument ⇒ exit 2. Re-review pre-registered at `AC-RM61-REREVIEW-033b2ffb.md`.
### D-37 — ONE shared `.git/config` silently re-identified EVERY worktree, including the reviewer's
Found during the post-rotation resume, before any orchestration action. `extensions.worktreeConfig` is
**unset** on this checkout, so all linked worktrees share `/src/mosaic-stack/.git/config`. A worker's
repo-local identity write therefore rebinds identity **for every seat at once**:
| observation | value |
| ---------------------------------------------------------------- | -------------------------------------------------------------- |
| `.git/config` mtime | 2026-08-01 08:37:49 — inside `coder-mos1`'s RM-61 build window |
| `user.name` / `user.email` / `mosaic.gitIdentity` | `coder-mos1` |
| `git var GIT_AUTHOR_IDENT` in `/src/mosaic-stack` (orchestrator) | **`coder-mos1`** — not `mos-dt-0` |
| same in `agent-work/rm-02`, `rm-03`, **`rev-974-pr1033`** | **`coder-mos1`** |
**This is a DISTINCT mechanism from D-34, not an instance of it.** `MOSAIC_GIT_IDENTITY=mos-dt-0` was
exported and correct throughout, and the identity **still** resolved wrong — D-34 is "the env var gets
stripped", this is "the env var is irrelevant because repo-local config outranks it."
**Sharp edge:** `rev-974`'s review worktree would author its **pre-registered acceptance checks as
`coder-mos1` — the author of the code under review.** Gate-16 (author ≠ reviewer) defeated _in the
artifact_, while the record reads clean. That is the charter's "integrity claim dressed as a property":
the pre-registration would certify the wrong identity and look correct doing it. No contamination
occurred — `rev-974-pr1033` was detached with zero commits of its own, and the RM-61 commits are
genuinely `coder-mos1`'s own work, correctly attributed.
**★ The #1024 collision (escalated to Jason by Mos).** PR #1024 is literally _"pin repo-local
`mosaic.gitIdentity` in five test suites"_ — **repo-local pinning IS the mechanism that just collided
across every worktree.** #1024's APPROACH is therefore implicated: repo-local pinning WITHOUT
`worktreeConfig` is the bug, not the fix. **#1024 must be re-scoped to worktree-scoped identity before
it merges.**
**Rulings (Mos, 2026-08-01):**
- **CONTAINMENT (in force now):** nobody rewrites the shared config while lanes are live — that
silently re-identifies live seats mid-flight, the same defect pointed the other way. Every seat commits
with explicit `git -c user.name=<seat> -c user.email=<seat>@…`.
- **REAL FIX AUTHORISED, owned by Mos, SEQUENCED AT A SEAM:** `extensions.worktreeConfig true` +
per-worktree identity + wrappers writing worktree-scoped rather than repo-local. Not while three lanes
are live.
- **Requirements attach to RM-50** (roster-owned socket/host + quarantine) **and RM-58** (mechanical
pre-dispatch reset) — both already own seat-identity mechanics.
### D-36 — a rotation-seam audit found THREE stale restatements on the live board
Checkpointing for the orchestrator rotation, the board was audited line by line before handing it to a