Commit Graph
735 Commits
Author SHA1 Message Date
mos-dt-0andClaude Opus 5 249335e515 docs(remediation): bank D-39/D-40 — gate-ready reached, then withdrawn on a finding I disclosed
D-39: I contaminated an open independent review. RR12 was an open registered check and I sent rev-974
my CONCLUSION, not just my observation. rev-974 then downgraded an automated Codex review that had
flagged RR12 as a blocker, in line with my framing. The bias sat in my instrument, not the reviewer's
diligence — a subordinate is agreeable by construction, and the divergence instruction I attached
cannot undo having named the answer first. Mos adopted the rule fleet-wide: a dispatcher may relay
observations and reproductions into an open review, never its own verdict on an open check.
Re-adjudicated by a mechanically fresh seat with no access to my framing: NON-BLOCKING, independently,
on stronger evidence than either prior pass (accept-set matrix proving the accepted set is a strict
subset of a correct case-insensitive comparison's, so it cannot false-certify; exploit path hunted and
ruled out; all 0x110000 codepoints scanned for a fold that could smuggle non-hex onto a valid SHA).
So contamination did not change the answer, and the finding stands anyway — a correct answer reached
by a contaminated process still corrupts the process.

D-40: that same fresh seat looked outside its question and found a type confusion inside the exact
conjunction the exemption rests on. `step.get("exit_code") == 0` is True for JSON false, and
coder-mos1 added the float case. Verified by me on the real #2188 record: false and 0.0 both yield
exit 0 with exempted_steps 1 — the exemption GRANTED; "0" and null correctly block. Two of four
near-miss types satisfy a conjunction whose whole justification is that it is exactly scoped.

Consequence: I reported #1033 gate-ready at 033b2ffb (RR1-RR12 pass, review 69 APPROVED, CI #2193
success 9/9) and then had to hand Mos a finding that may disqualify what I had just certified. Better
that than defending the report. Disposition is Mos's; coder-mos1 escalated it to blocker unilaterally
and moved to push — held, because the author does not adjudicate their own PR and does not void a live
APPROVED review plus terminal-green CI by pushing. Head frozen, fix prepared and unpushed, ACKed.

Board doctrine now carries both rules: never relay a conclusion into an open review, and the author
never adjudicates their own blocker status.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 09:20:15 -05:00
mos-dt-0andClaude Opus 5 d9ab6026c8 docs(remediation): RM-61 tick — twelve checks pass, blocker moved to metadata, head never moved
rev-974 review 68 @ 033b2ffb: RR1-RR12 all PASS. RR7 is the strong one — all four binding predicates
proved RED against the old e7b29219 verifier, and the original attack under the old interface returned
exit 0 with exempted_steps=1, proving the PRIOR DEFECT rather than merely unsupported syntax.

The remaining blocker was metadata, not code: the live PR body still said "DO NOT MERGE" and "the
exemption will not be implemented", describing an earlier head. Verified independently — the controls
were injected in 3931b0e2/9455cd6a/25ac5971/ef9d23ab and the final delta does not touch
.woodpecker/ci.yml at all. The body was true when written and went stale as the branch evolved. That
is D-38 one layer out: the PR that binds evidence to its subject shipped a description that was not
bound to its subject, and D-36's staleness class on provider metadata rather than a repo file.

Fixed as metadata only. Head confirmed unmoved at 033b2ffb from both provider and git, body SHA-256
b0198d98 matched the author's reported digest byte-for-byte, both stale strings absent. Because the
commit never moved, the twelve results stand and no third review round is owed — only the discharge
of the finding by the reviewer who raised it.

Exact-head CI #2193: success, 9 children, 9/9 success including clone, read from -f json (D-33).

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 09:10:32 -05:00
mos-dt-0andClaude Opus 5 50c0340add 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]>
2026-08-01 08:59:40 -05:00
mos-dt-0andClaude Opus 5 345d152790 docs(remediation): RM-61 result — kill criterion NOT triggered, signature discriminates structurally
coder-mos1 ran two real ci-postgres failure controls; the orchestrator verified the JSON
records independently. #2189 (startup failure) exit 1 and #2191 (post-readiness crash,
log proves ready then postmaster killed) exit 137 both take the workflow and the test
step down — terminal red. #2188, the genuine artifact, carries exit_code 0 under a
SUCCESSFUL workflow.

So the discriminator is structural — a failed service step with exit 0 under a successful
workflow — not the message string and not an incidental correlate like node or timestamp,
which were explicitly forbidden because they pass today and mask a real failure the moment
infrastructure shifts.

Verifier: exit 0 with one named exemption on the artifact; exit 1 with exempted_steps 0 on
BOTH real controls. No fetch, trigger, retry or re-roll — the coin flip is removed, not
codified.

PR #1033 dispatched to rev-974 with eight acceptance checks pre-registered before the diff
was read; AC2 (both real failures must NOT be exempted) is the crux and a REJECT if it fails.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 08:44:46 -05:00
mos-dt-0andClaude Opus 5 f11f257368 docs(remediation): bank D-36 — rotation-seam audit found three stale restatements on the board
Preparing the checkpoint for a cold read surfaced three stale sections, each a copy of
text owned elsewhere, each of which would have misled the incoming orchestrator: a
delivery-gate list still omitting the merge-gate step (D-26's own defect, still on the
board after MISSION.md was fixed); a capability rule superseded by D-13/D-15; and
DECISION-1 still marked CONTESTED hours after it was ruled.

None were wrong when written. All three drifted because they were copies — D-14 three
times in one artifact. The failure is not that someone forgot to update three lines; it
is that three lines existed to forget.

The rotation seam is what surfaced it. A familiar section is skimmed for the line you
came for; preparing state to be read cold by a stranger is a different act from
maintaining it, and catches a class ordinary use cannot.

RM-34: a handoff must VALIDATE the checkpoint, not merely write it. RM-02 registers the
general form with a must-fail on divergence. Interim: audit the board against its
sources at every rotation seam.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 08:14:04 -05:00
mos-dt-0andClaude Opus 5 6c779595e1 docs(remediation): rotation checkpoint — board rebuilt for a cold read, three stale restatements removed
Orchestrator rotating at ~803k tokens (~4x threshold). A mission built on
rotation-not-compaction should not run its own coordinator past it.

Board rewritten as the rehydration artifact: in-flight state, a read-this-first block
for the incoming seat, and the live rulings it most needs. Under the 8KB cap.

AUDIT AT THE SEAM found THREE stale restatements on this board, each of which would have
misled the incoming orchestrator:
  1. the delivery-gate list still OMITTED the merge-gate verdict step (the D-26 defect
     itself, still sitting on the board after MISSION.md was corrected);
  2. capability described as 'token-file set = authoritative registry', superseded by
     D-13/D-15 (capability is per-path; assert permissions.push as that seat);
  3. Sequencing still said DECISION-1 was CONTESTED and 'do not treat it as settled'
     hours after it was RULED — an incoming seat would have re-litigated a closed decision.

All three were restatements of text owned elsewhere. Replaced with references, per the
mission's own render-not-restate principle: a second copy is a second thing to go stale,
and this board proved it three times in one night.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 08:13:12 -05:00
mos-dt-0andClaude Opus 5 cc097f36c5 docs(remediation): re-run failed; RM-02 blocked on RM-61, declared bound honoured
Pipeline #2188 at the same head: ci-postgres the sole failure, everything else success
including gate-verify. f10-coder independently confirmed and applied the pre-registered
rule itself.

RM-02 blocked. No ad-hoc exemption, no third roll. Recorded why: two failures against one
earlier clean run makes 'best of five' feel reasonable, and the point of declaring the
bound in advance is that it binds when the result is inconvenient. A third roll would
have been indistinguishable from diligence, including to the person doing it.

Data for RM-61: the artifact hit twice consecutively at f9746b23 while #2184 was clean at
38f1b249, so it may cluster rather than be uniformly random — which makes a one-shot
re-roll close to worthless and strengthens the ruling that it must not become policy.

And the illustration: the anti-inert-gate registry is blocked by an artifact that makes
gate evidence unreliable. The thesis demonstrating itself on its own keystone.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 01:34:20 -05:00
mos-dt-0andClaude Opus 5 56d8e8a3d5 docs(remediation): record the bounded re-trigger as a stopgap; mark the first end-to-end merge stack
The re-trigger guardrail, recorded so it cannot become practice: one bounded,
pre-declared attempt at the same head with the response to each outcome fixed before
triggering. Re-running until the desired answer appears is p-hacking the pipeline, and
silently nobody can tell it from diligence — including the person doing it. Per Mos: a
per-PR free re-roll would be D-21 normalisation wearing a new hat. RM-61 must make the
re-roll unnecessary, not codify it, and a clean re-run does not retire RM-61.

Milestone: RM-03/#1032 completed independent review -> CI terminal-green -> merge-gate GO
-> coordinator -> held for owner, the first time end-to-end. GO posted under the gate's
own minted identity by a seat that structurally cannot merge. Head verified unmoved after
the verdict, so the commit-bound GO stands.

The first delivery through the complete stack is also the last one gated by a check that
could not fail — RM-03 is that check's fix.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 01:22:32 -05:00
mos-dt-0andClaude Opus 5 4589659bc1 docs(remediation): board — RM-03 GATE-READY, merge-gate assigned, held for Jason
First genuine gate-ready of the mission. Head triple equal at 78ec47cd, latest review
APPROVED at the current head, CI 9/9 by JSON scan with two-observer agreement.

Recorded the shape worth remembering: the queue guard is still inert for this merge
because RM-03 is the fix — the last merge to pass through the broken gate is the one
that fixes it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 01:15:05 -05:00
mos-dt-0andClaude Opus 5 357a636a3a docs(remediation): promote redundant-observation to charter; bank D-35 (tool caught what attention could not)
Charter gains a fifth principle from D-33: two observers of the same evidence,
disagreeing, catch what neither catches alone — applied to evidence GATHERING, not just
judgement. A summary that resembles an enumeration is more dangerous than one that
obviously summarises; prefer the machine-readable record and state counts so divergence
is detectable.

D-35: while editing merge-gate.md to fix D-33, the coordinator recalled the mandate
string instead of reading it and the Edit tool's exact-match REJECTED it. Third instance
for that author, inside the turn fixing another instance of the same class — and the
only one that did not reach a document, because a mechanism caught it.

A rule that fails in its authors but is caught by a tool has told you where it belongs.
RM-02 should enforce verbatim citation by construction, as the Edit tool did by accident
of design.

Fix landed by annotating the source: merge-gate.md mandates 3 and 4 now require the
scan and count from the JSON record. The shared wrapper was deliberately NOT modified
mid-flight — three lanes are reading it; fix at a seam.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:53:27 -05:00
mos-dt-0andClaude Opus 5 9e205e8201 docs(remediation): bank D-34 — a context reset silently strips a seat's credential identity
rev-974 finished its RM-02 review and could not post it: pr-review.sh failed with
'Gitea token not found'. Verified — with MOSAIC_GIT_IDENTITY unset the token does not
resolve; with it set it resolves. The token file was correct throughout.

My own context reset wiped the seat's exported identity and my rehydration brief did not
re-establish it. git config mosaic.gitIdentity is persistent and per-worktree;
MOSAIC_GIT_IDENTITY is ephemeral and per-context. rev-974 works from ~/agent-work with no
git-config fallback, so it had no warning and the loss surfaced only when it next needed
a credential.

Intersection of two banked findings, created by acting on one: D-31 prescribes rotation,
D-11a requires identity coherence, and nothing said rotation is a credential-affecting
operation. The fix for one failure introduced another.

RM-34: rotation must re-establish AND verify seat identity before handing over work.
RM-50: prefer the durable binding (mosaic.gitIdentity in the seat's repo) so identity
survives a reset by construction. Interim: every rehydration brief re-exports identity.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:51:21 -05:00
mos-dt-0andClaude Opus 5 73a313301b docs(remediation): bank D-33 — the full-step-scan tool prunes a step in default output
coder-mos1 scanned pipeline #2186 with -f json and found 9/9 child steps; my scan of the
same pipeline in the wrapper's default text mode showed 8. Verified: text mode omits
clone (JSON shows the ci workflow entry, clone, and the 8 visible ones).

Every full step scan performed tonight enumerated 8 of 9 real child steps and reported
it as complete. clone succeeded throughout so no verdict changes — but the method was
incomplete and its user did not know.

The merge-gate mandate requires a FULL step scan and requires verdicts to enumerate the
step count. A verdict citing 8 where 9 exist is non-conforming evidence, and a gate using
this wrapper's default output would produce exactly that while believing it complied.

The shape is the session's thesis aimed at the detection tool: the doc says read the
artifact not the summary, and text mode IS a summary that looks like an artifact. Compare
D-24 — mergeable was a true answer to a different question; this is a true answer to a
smaller one.

Caught only because two observers' counts disagreed; neither alone would have found it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:49:01 -05:00
mos-dt-0andClaude Opus 5 eddf718a5c docs(remediation): board — RM-02 frozen at 38f1b249 with a fully clean 9/9 scan
First run on this branch where ci-postgres passed, so no exemption question arises.
Recorded that the artifact's intermittency is evidence FOR RM-61's negative-control
requirement: intermittent means delivery is a coin flip until the signature is proven to
discriminate from a real database failure.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:35:51 -05:00
mos-dt-0andClaude Opus 5 c83a3cd3e2 docs(remediation): bank D-32 — the repaired gate shipped with a documented switch to skip it
rev-974 blocked RM-03: pr-merge.sh still ships --skip-queue-guard at five sites
including a worked example. It proved this rather than reading it — stubbed the guard to
exit 99, ran a real fixture merge with the flag, and observed the guard never called,
provider payload created, 'merged successfully', exit 0.

Disqualifying because RM-03 repairs a mandatory gate that has never been able to fail;
shipping that repair with a documented bypass means the gate merely requires one flag
instead of zero, and every merge-side CANNOT_ASSERT/HOLD semantic is skipped. L0 bars
equivalent skip switches, and the merge-gate role doc names this exact hazard about
force_merge — adjacent to the field you came to edit, at the moment you are most
motivated to reach for it.

Generalizable: repairing a gate is incomplete while any supported path skips it. The
failure changes from 'cannot block' to 'can be told not to' — the same outcome one
keystroke later. Removing the bypass is part of the repair.

Everything else passed independently, including the 160 KiB stdin transport where #1023
regressed.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:33:18 -05:00
mos-dt-0andClaude Opus 5 bf8c6f4a89 docs(remediation): bank D-31 — seat ran past 100% context with 28 uncommitted files
coder-mos1 hit 102.5%/372k on RM-03 with 28 modified files uncommitted and its branch
still at base — a full context window spent with nothing durable. Caught by polling seat
state, not by any system signal. Nothing warned anyone: no threshold alert, no
pre-compaction hook.

The founding failure mode of this mission — compaction destroying in-flight work —
nearly hit the mission's own delivery twice in one night. RM-01 survived because it had
committed work when checkpointed; this one had none. Commit-then-rotate works;
rotate-without-commit loses everything.

RM-34: a context threshold is not enough — rotation must force a durable checkpoint and
refuse to rotate a seat with uncommitted work. RM-50: seat context is observable state
and must be monitored; relying on an orchestrator to poll is instructions-not-enforcement
applied to lifecycle. Brief doctrine: commit early, commit WIP.

Adjacent: the diff spans 5 guides and 11 templates against a brief scoped to one script.
Queried, not assumed — but a 28-file diff from a one-script brief is a scope signal
regardless of the answer.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:07:59 -05:00
mos-dt-0andClaude Opus 5 bdf8932328 docs(remediation): RM-61 terminal-green exemption ruled B, with sequencing correction
Condition 1 tested: the signature is stable — pods "wp-svc-<ULID>-ci-postgres" not
found across all five observed failures, an orchestration-layer lookup miss structurally
unlike a service-level failure.

But discrimination is UNPROVEN: every observation co-occurs with a demonstrably working
database, and we have never seen a real ci-postgres failure on this provider. If
PostgreSQL crashes and the pod is GC'd, the status query may also return pod-not-found —
the exemption would over-match and mask a real failure.

So conditions 1 and 2 are not independent: 2 is the evidence for 1. Build the negative
control first, prove a real failure produces a different signature, then adopt the
exemption. Kill criterion stated in advance: if an injected real failure also yields
pod-not-found, B is unsafe and we do A.

Filed as RM-61, unassigned — no free write-capable seat; flagged rather than stacked
onto a busy lane.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 00:04:32 -05:00
mos-dt-0andClaude Opus 5 16d11cd6cd docs(remediation): bank D-29 (syntactic criterion binding) and D-30 (false comparator, mine)
D-29: rev-974 moved two criterion bindings to an unrelated case, reformatted the
manifest, and gate:verify still exited 0. The registry verifies a criterion HAS a
binding, not that the bound case can fail for that criterion's stated reason —
RM02-REQ-03 unsatisfied. The keystone reproduced the defect it exists to eliminate, in
its own coverage check. Caught only by mutating and re-running; inspection would have
passed it.

D-30: my review brief claimed the ci-postgres FAIL appeared on #2167 — it did not
(#2167 is OK). My own banked D-21 says so explicitly; I restated from memory instead of
reading my record. D-26 recurring, in a reviewer brief, hours after promoting
render-not-restate to the charter.

The harm is not the inaccuracy but that I supplied a reviewer with fabricated supporting
evidence for my own reading. It refuted me — query-for-refutation paying for itself in
the same document that introduced it.

Requirement: briefs cite evidence from the record with identifiers, never from recall.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 23:59:25 -05:00
mos-dt-0andClaude Opus 5 8ce77fcb0d docs(remediation): board — RM-02 frozen at 9b4d4beb, CI green, review in flight
Head triple verified independently twice (orchestrator + f10-coder): local = origin =
PR #1030 = pipeline #2182. Full step scan rather than a tests-complete inference.
Queue guard not offered as evidence.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 23:41:52 -05:00
mos-dt-0andClaude Opus 5 cdd5568adb docs(remediation): promote query-for-refutation to charter doctrine
Per Mos. A subordinate asked to confirm a hypothesis will agree — the bias is induced by
the query, not by the answerer's diligence. 'The DB flaked, please confirm' and 'confirm
or refute, with the log line that proves it' are different instruments returning
different answers to the same question.

This matters most with agent subordinates, which are agreeable by construction, so the
discipline cannot rest on the answerer being rigorous — it must be built into how the
question is asked.

Origin: the orchestrator's ci-postgres hypothesis was refuted by the implementing seat
with log evidence and then settled by reproduction. Phrased for confirmation, it would
have returned agreement and D-21 would have been re-classified on a false premise,
silently corrupting a banked finding.

Operational form: state the hypothesis as yours, ask for evidence that kills it, say
what would change your mind, and reproduce when the answer is consequential. Added to
KICKSTART's standing invariants so it survives compaction.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 23:21:15 -05:00
mos-dt-0andClaude Opus 5 ff4b45b025 docs(remediation): RM-03 CANNOT_ASSERT semantics ruled (option B)
Resolves an ambiguity in the orchestrator's own brief, which required CANNOT_ASSERT to
neither silently pass nor permanently block without distinguishing push from merge.
coder-mos1 stopped and asked rather than inferring authorisation; Codex security
independently flagged CWE-693.

Ruled B: merge fails CLOSED (proceeding without exact-head CI evidence is D-23's
condition in a narrower costume), push degrades AUDITED (blocking during an outage
bricks delivery — the Pi-brick class we already banked). A temporary block pending
evidence is not a permanent block, and merge is separately gated by the merge-gate and
coordinator, so nothing is stranded.

Conditions: distinct exit code or the tri-state is destroyed; the audit record asserted
by a registered case, not assumed, or 'audited' is a claim dressed as a property;
retryable and self-clearing; cases observed RED first; no silent degraded merge path —
break-glass belongs to RM-05.

Option C rejected: it bricks push during an outage and defers the degraded path, which
in this codebase means a silent bypass appears under incident pressure. Three are
already on the books.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 23:17:01 -05:00
mos-dt-0andClaude Opus 5 f47cf45b0c docs(remediation): bank D-28 — a swallowed diagnostic destroyed a fail-closed check's evidence
RM-02 CI failed on four sandbox tests. Bubblewrap is installed by the gate step but not
the test step, so spawnSync returned ENOENT; replayCommit replaced the spawn diagnostic
with an empty string, so the classifier could not prove Bubblewrap provenance and
correctly refused to treat it as expected sandbox unavailability.

The refusal was right; the information loss was the bug. For a classifier, error text is
not decoration — it is the input. Widening acceptance to make the test pass would be a
finding, not a fix.

Linkages: D-16 again (local has bwrap, CI does not — local and CI disagree a third
time), and diagnostic-preservation registered as an RM-02 gate requirement with a
must-fail control proving a swallowed message is detected.

Process note: the orchestrator's hypothesis that the coincident ci-postgres FAIL caused
this was WRONG and was refuted with log evidence. D-21 stands unchanged as a teardown
artifact and is NOT upgraded — it was about to be re-classified on a false premise.
Asking the seat to confirm or refute rather than accept is what prevented that.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 23:10:53 -05:00
mos-dt-0andClaude Opus 5 e7c9160c7b docs(remediation): board — delivery-gate doctrine change recorded with render-vs-restate root cause
Per Mos's item 4. The gate definition was incomplete from setup because the gates were
restated from memory rather than referenced, and the omission propagated into every
worker brief since — then recurred inside the correction itself (D-26).

Board now carries the referenced sources, the gate order, freeze-after-GO, the
coordinator/orchestrator split, and the queue-guard zero-information field form.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 23:01:07 -05:00
mos-dt-0andClaude Opus 5 2d58779675 docs(remediation): bank D-27 — role file certifies the inert queue guard as enforced
rev-974 found this while loading the canonical gate sources, i.e. because we switched
from restating to reading. Verified in roles.local/merge-gate.md: mandate 3 requires
verifying 'CI queue guard clear', mandate 4 requires enumerating 'the queue-guard
outcome' in every durable verdict, the merge path annotates it 'real', and the control
table at :290 certifies it ' enforced … genuinely aborts'.

The document is correct about the WIRING and wrong about the CONTROL: set -euo pipefail
with an unguarded exit does abort, but the guard cannot produce a non-zero exit for any
input (D-23). A mechanism correctly wired to a sensor that never fires, certified as
enforced.

Compounding: the verdict format REQUIRES the queue-guard outcome as evidence, so a
conforming verdict must include a meaningless field — the role file instructs the gate
to manufacture evidence, in the mandate that exists to stop bare conclusions.

Interim: record the field labelled ZERO-INFORMATION (inert, owner RM-03) rather than
omitting it — omission makes the verdict non-conforming; silent citation is worse.

Escalated: operator-owned file, coordinator's to fix. Recommend annotation not deletion
— the requirement is correct once RM-03 lands.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 22:55:28 -05:00
mos-dt-0andClaude Opus 5 cbbe3e1ce2 docs(remediation): gate definition now REFERENCES canonical roles; bank D-26
The delivery-gate definition was incomplete from setup — the merge-gate verdict step
was missing because the gates were restated from memory rather than referenced, and the
omission propagated into every worker brief since.

Then it recurred inside the correction: the correcting message was itself a restatement
and dropped five things, including a security precondition (an unminted gate seat fails
open to the owner's admin account — the #3084 breach mechanism) and a citation to a file
that does not exist.

D-26 is the definitive case because every condition favoured success: attention maximal,
actor knew the rule best, subject was the rule itself. A rule its own enforcer cannot
follow while enforcing it is not a discipline — it is a requirement for a mechanism.

MISSION.md and KICKSTART.md now reference fleet/roles.local/merge-gate.md and
fleet/roles/validator.md and state only the gate ORDER. Every reference resolves; a
dangling pointer is worse than a restatement.

Precondition independently verified: merge-gate token is least-privilege,
pull=True push=False admin=False — structurally cannot merge.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 22:53:13 -05:00
mos-dt-0andClaude Opus 5 9a7ab73952 docs(remediation): charter — Builds 1-2 justified by two independent impossibility proofs; RM-60 option analysis
Per Mos. The choke-point executor and PG spine are not a design preference — they are
forced. Twice during the mission's own first deliveries, work stopped against a security
property that cannot exist at the layer needing it: D-19 (audited party controls the
manifest certifying it — artifact integrity) and D-25 (audited party controls the code
entering the sandbox — execution integrity). Both reduce to self-verification by the
audited party is not verification, and both resolve only via an authority outside its
control.

Neither proof was sought; both arrived while shipping something else, from different
directions, at different layers. An architecture forced by two independent impossibility
proofs is stronger evidence than one argued for.

RM-60 records Mos's sharper option analysis: A (unprivileged userns) does NOT fix the
vulnerability — it grants a capability and leaves the ORDERING defect untouched, so B is
required regardless; A without B is kernel exposure bought for nothing. B is the correct
primitive, generalises to RM-59 and the choke-point executor, and may not need A at all.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 22:09:38 -05:00
mos-dt-0andClaude Opus 5 2b85afe4ea docs(remediation): bank D-25, accept RM02-REQ-10 revision, open RM-60
RM-02's per-commit replay needs isolation; the privileged CI step was correctly refused
because PR-controlled code executes before Bubblewrap establishes any boundary — the
untrusted party would obtain the capability meant to contain it. Ordering defect, not a
hardening problem.

D-25 is D-19 one layer down: audited party controls the manifest (artifact integrity)
became audited party controls the code entering the sandbox (execution integrity). Both
reduce to self-verification by the audited party is not verification, and both resolve
via an authority outside its control — twice now this mission has derived Builds 1-2
from a security impossibility rather than design preference.

Option C ruled independently by the orchestrator and rev-974 before either saw the
other. rev-974 added the condition I missed and it matters most: post-merge replay is
DETECTION, not PREVENTION, with a defined quarantine/revert response, and must never be
presented as equivalent to a pre-merge gate.

RM02-REQ-10 revision formally recorded and accepted under RM-02's own clause 4 —
original text, restatement, reason — discharging rev-974's review-readiness condition.
RM-60 opened for the external pre-execution trust boundary, cross-referenced with RM-59.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 22:05:50 -05:00
mos-dt-0andClaude Opus 5 eabe04bc5e docs(remediation): bank D-24 — mergeable:true cited as merge-readiness; D-23 corrected backward
Mos verified #1023 before relaying and corrected my framing. Verified independently:
review id-58 REQUEST_CHANGES at f6334080, the current head — the block is live, and its
findings are that #1023's own fix is defective (unknown still exits 0, payload-as-argv
hits ARG_MAX, tests do not assert exits).

mergeable:true is git-mergeability, not readiness. The charter's first principle
committed by the orchestrator inside an escalation about proxies. Fifth instance of mine.

The mechanism, named because it will recur: mergeable is not a lie, it is a true answer
to a different question. A false field would have been caught; a true-but-adjacent field
passes every sniff test — which is why the discipline must be mechanical, not attentive.

D-23 corrected backward per D-14-as-amended, original framing quoted.

RM-02: readiness cases must assert the decision-relevant property — latest review state,
CI terminal status on the exact head, required approvals — never a structural proxy.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 20:50:46 -05:00
mos-dt-0andClaude Opus 5 36018be8d1 docs(remediation): bank D-23 — the mandatory queue guard has never worked, for any input
RM-02's registered fixtures found this before the registry was built. Worse than the
banked unknown=>exit 0: ci-queue-wait.sh:266 pipes the payload into a classifier
starting 'python3 - <<PY', so python reads its PROGRAM from stdin and json.load never
sees the JSON. Proven empirically — success, failure, pending and malformed all
classify as unknown, and unknown exits 0.

The mandatory pre-push/pre-merge guard therefore returns PASS for every possible input,
including a genuinely failing CI. The six observed meaningless greens were not an edge
case; they are the only output it can produce.

PR #1023 is exactly this fix, open and parked, and its body diagnoses it precisely.
Two aggravating details from that body: pr-ci-wait.sh:38 documented the bug and remedy
and it was never backported to the mandatory sibling (D-14 propagation with a
security-adjacent blast radius); and the fix was opened without re-verification.

Escalated for Jason's #1023 disposition. RM-02 records required-vs-actual with
DEFECT (owner: RM-03); no RM-03 lane opened, guard not edited.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 20:44:34 -05:00
mos-dt-0andClaude Opus 5 8c496993e4 docs(remediation): bank D-22 — the registry would have verified the wrong artifact
The gate that actually runs is the installed copy at ~/.config/mosaic/tools/git/;
a repo-scoped registry would test packages/mosaic/framework/tools/git/. Byte-identical
today (sha256 19cda2f7009c536e both) but nothing asserts it.

A registry that verifies the wrong artifact is worse than none — it manufactures
confidence, and the divergence would be invisible from every signal we have: registry
green, CI green, deployed gate arbitrarily different.

D-1/P-ACTIVATION applied to the enforcement mechanism itself rather than to config.

RM-02 gains: for every registered gate with a deployed counterpart, assert
repo-source == deployed-copy with a must-fail control; where none exists, record that
explicitly.

Found by design review before implementation — the only finding tonight not found by
execution, which is the design-first gate on keystone tasks paying for itself.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 20:14:13 -05:00
mos-dt-0andClaude Opus 5 e85a088f85 docs(remediation): bank D-21 — a FAIL that means nothing is a green that means nothing, sign-flipped
ci-postgres reports FAIL under an overall-success pipeline on #2170 and #2175 while all
eight functional steps pass. Most likely a service-pod teardown artifact; the test
step's pg_isready fail-fast guard passed, so the database was available during the run.

Low severity, but the pattern matters: a red that is routinely present and routinely
correct to ignore trains operators and agents to discount reds, and the discounting
generalises. Six instances of a meaningless green are already banked; a meaningless
FAIL is the same erosion with the sign flipped.

Recorded rather than normalised — the first time it is waved through without a note is
when it becomes background noise.

RM-55: treat a non-terminal-success sub-step under an overall-success pipeline as a
reportable anomaly, and make the CI contract state which steps may fail without failing
the pipeline. An implicit allowance is indistinguishable from a bug.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 20:08:34 -05:00
mos-dt-0andClaude Opus 5 8a795df0ce docs(remediation): D-14 amended by D-20 — propagation is bidirectional
ci/woodpecker/pr/ci Pipeline was successful
Both the orchestrator and the coordinator read D-14 as forward propagation only: a
ruling reaches the documents stating the new rule. D-20 proved that insufficient —
when D-19 superseded part of D-18, the consequence went forward into the charter and
the delivery conditions but never backward into D-18, which kept asserting a withdrawn
claim until a reviewer disproved it by experiment.

A supersession must update BOTH the documents rendering the new rule AND the finding it
retires, with the retired wording quoted rather than deleted. Interim rule updated
accordingly.

Applying D-14's own rule to D-14, in the same commit that records the amendment.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:53:36 -05:00
mos-dt-0andClaude Opus 5 f5a0566198 docs(remediation): board — RM-01 MERGED (f58b3699); RM-02 keystone is next
ci/woodpecker/pr/ci Pipeline was canceled
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:50:36 -05:00
mos-dt-0andClaude Opus 5 1e7a0701fd docs(remediation): fix D-18 overclaim (D-20) — reviewer empirically disproved my own documentation
rev-974 blocked #1027 a second time, and the defect was in this file, not the code.

D-18's AC2 restatement omitted the accidental/independent scope D-19 made mandatory,
and D-18 asserted the tampered-manifest control turns integrity 'from a claim into a
property'. It does not and cannot — that sentence predated D-19 and was never revised
when D-19 landed. rev-974 disproved it by experiment: a same-UID consistent
manifest+marker rewrite passed preflight.

Two banked findings firing on the orchestrator at once: the integrity-claim corollary
(I wrote a claim in the voice of a property, in the document defining the rule against
it), and D-14 propagation — I carried D-19's consequence forward into the charter and
the delivery conditions but never back into the finding it superseded. Backwards
propagation is the same defect as forwards and I did not audit for it.

Corrected in place with the original wording quoted and the disproof recorded, not
silently rewritten.

RM-02 fifth clause: documentation asserting a security or integrity property is itself
a claim requiring a negative control observed red. Prose is not exempt from the
mission's evidentiary standard, and governing prose least of all.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:48:00 -05:00
mos-dt-0andClaude Opus 5 43f69bf167 docs(remediation): promote D-19 to charter; bind residual risk to RM-59 as a tracked edge
Per Mos, with his two additions.

Charter gains a fourth first-class principle: when a property cannot exist at the layer
that specified it, three honest moves are mandatory — implement what the layer can
guarantee; state the boundary in BOTH directions (what it does not defend AND what it
does, since either alone misleads); and record the real guarantee as a TRACKED
DEPENDENCY, not prose. A written-down gap is acceptable engineering; an implied-fixed
gap is the mission's core failure in a new costume.

The residual risk is now RM-59 (depends_on RM-12, RM-21, RM-25) — a real backlog task
owned by the choke-point executor and spine, which verify from outside the worktree's
authority. Mos's point: 'record where the guarantee comes from' only holds if the record
is a live dependency someone must close; a documented gap with no owner becomes a
permanent gap that reads as intentional.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:23:15 -05:00
mos-dt-0andClaude Opus 5 f9435c2a03 docs(remediation): bank D-19 — an integrity property that cannot exist at its specified layer
Implementing the D-18 manifest hit CWE-345: manifest and marker share one same-UID
writable tree, so that actor can regenerate both and pass. No local construction fixes
self-authentication without a key outside its authority. The seat escalated rather than
calling it tamper-resistant — the charter corollary working on its first real test.

Ruling: Option A, scope AC2 to accidental/independent/stale mutation, retain the design.
The undefendable boundary is not the weak link (same-UID write already owns the source,
the tests, preflight.mjs and .husky); AC2 exists for the D-5 staleness class, against
which the design works; and a real anchor arrives with the choke-point executor and PG
spine, which verify outside the worktree's authority.

Acceptable only with honest labelling: threat model verbatim in code and PR, the words
tamper-proof/tamper-evident/secure barred there, scope carried in AC2's restatement,
residual risk named as backlog, all controls kept RED-first.

Generalizable: when a property cannot exist at the layer it was specified, implement
what the layer can guarantee, state the boundary precisely, and record where the real
guarantee comes from. A known gap written down is acceptable; a gap implied fixed is not.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:20:05 -05:00
mos-dt-0andClaude Opus 5 3b191b6b34 docs(remediation): promote the three-mode taxonomy and the integrity-claim corollary to the charter
Per Mos. Two first-class principles alongside observe-the-property:

1. Pre-registration prevents RETROFITTING and nothing else. A pre-registered check set
   can be WRONG (D-8), INCOMPLETE (D-17), or INTERNALLY INCONSISTENT (D-18). It confers
   neither correctness nor coverage nor consistency. All three modes were found on this
   mission's own first delivery, by the machinery applied to its own work. RM-02's four
   clauses are the enforceable form.

2. Never ship an integrity claim dressed as a property. A verification artifact
   writable by the actor whose behaviour it certifies certifies the attack. It must sit
   inside its integrity envelope, publish atomically, and carry a tamper negative
   control observed red. If it cannot be made tamper-evident, say so and reconsider —
   an honest 'this cannot be verified' is always available and always preferable to
   laundering foreign content as certified.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:14:06 -05:00
mos-dt-0andClaude Opus 5 85bdbe3383 docs(remediation): bank D-18 — pre-registered criteria AC2 and AC4 were mutually unsatisfiable
Implementing D-17's fix surfaced a conflict between criteria, not within one. AC2
(reject symlinked generated state) cannot hold alongside AC4 (canonical build
succeeds): verified independently that apps/web sets output:'standalone' and the built
tree carries 42 legitimate pnpm symlinks under .next/standalone. Only building the
tree reveals it.

Completes the chain: a pre-registered check set can be WRONG (D-8), INCOMPLETE (D-17),
or INTERNALLY INCONSISTENT (D-18).

Ruling: build-certified symlink manifest — .next itself still rejected; descendants
rejected unless exactly certified. Stronger than blanket rejection because it catches
retargeting. AC2 restated and RECORDED with provenance rather than absorbed, since
silently resolving a conflict between pre-registered criteria destroys the point of
registering them.

Hardening: the manifest is generated state, so a manifest writable by whoever plants a
rogue symlink certifies the attack. Must be inside the integrity envelope, published
atomically, with negative controls observed red first including manifest-tampered.

RM-02 fourth clause: the registry must detect conflicts between criteria, and retain
original text plus restatement plus reason when a criterion changes meaning.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:11:52 -05:00
mos-dt-0andClaude Opus 5 ae4baf145d docs(remediation): bank D-17 — pre-registration confers neither correctness nor coverage
rev-974 blocked PR #1027: AC2 was pre-registered and explicitly required rejecting
symlinked generated state; the implementation accepts it (ln -s into .next, preflight
exits 0 instead of 43) while the acceptance suite ran 21/21 green throughout.

Confirmed independently: preflight.mjs:82-92 rejects symlinks on the SOURCE path,
:28 merely skips symlinked dirs, and the generated-state path :141-163 checks uid but
never isSymbolicLink(). The suite's only symlink cases cover the turbo binary and a
source file.

Sharpens D-8 rather than repeating it. D-8: pre-registration does not confer
CORRECTNESS. D-17: it does not confer COVERAGE — a suite can be green with every
criterion appearing satisfied while a criterion's actual requirement is untested.

RM-02 third clause: the registry must bind each criterion to the specific case that
exercises it and prove that case red before trusting its green. Mutation testing
pointed at the criterion-to-case mapping, not just the gate.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 19:07:58 -05:00
mos-dt-0andClaude Opus 5 4512312b9f docs(remediation): D-16 ownership — #1024 is Jason-pending; CI is the authoritative gate for #1027
Propagating Mos's ruling in the same commit that records it, per D-14's interim rule.

The hermeticity fix IS PR #1024, which sits in Jason's parked delivery stack, so its
disposition is his — marked SUPERSEDED-PENDING-JASON alongside #1023. D-16 strengthens
urgency without transferring ownership; we do not open a third lane on a parked PR.

Class sharpened: a pre-push gate an operator cannot run locally is a gate only CI
enforces, so pointing .husky/pre-push at it misrepresents where the gate lives.
Non-hermetic gates make every green host-dependent.

#1027 proceeds on CI-green; the local exit-97 is a host-specific guard abort and is
not a merge consideration.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:43:25 -05:00
mos-dt-0andClaude Opus 5 e233f196b5 docs(remediation): bank D-16 — local and CI test gates disagree by environment
Ran down Mos's flag. Both hypotheses were wrong: CI runs exactly 'pnpm test' (same
command, path IS exercised) and is green, while this host exits 97 on an
environment-dependent BASH_LINENO guard (#973) that aborts on bash 5.2.15 and not in
CI's container. PR #1027 touches zero files under packages/mosaic, so the guard is
genuinely pre-existing — f10-coder's report was accurate in every particular, and main
is equally affected here.

Not 'merges step around a red' but something worse in one respect: the local gate and
the CI gate disagree about what passing means. No agent on this host can get a green
pnpm test on any branch. A gate only CI can run cannot be a pre-push gate.

Second defect found while establishing this: in the main checkout the same package
fails differently (exit 1) because a test scans the working tree and picks up
apps/coordinator/venv third-party site-packages. A test whose verdict depends on
untracked files is not hermetic — same contamination source that broke format:check,
one foreign tree breaking two independent gates.

Coordinate with #1007/#1024 rather than opening a third lane.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:40:53 -05:00
mos-dt-0andClaude Opus 5 3477e933df docs(remediation): bank D-15 — token scope is not repository permission
f10-coder holds gitea-mosaicstack-f10-coder.token with write:repository scope and was
verified at mint by 'repo access returns 200'. It cannot push: collaborator lookup
404s and its own token reports push:false, pull:true.

Capability has three independent layers — token file (raw-API auth), tea login (tea
path), repository permission (actual write authority) — and satisfying two proves
nothing about the third. Scope bounds what a token may ATTEMPT; repository permission
decides what the user may DO.

The charter principle failing on the check meant to confirm capability: a 200 on a
READ was accepted as evidence of WRITE. written-unverified treated as verified, by
both provisioner and orchestrator, one layer above D-12.

RM-50's pre-dispatch check must assert effective permission for the intended operation
(permissions.push == true as that seat), not token existence or a read returning 200.
A capability check that cannot fail on a seat lacking write permission is itself an
inert gate.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:32:27 -05:00
mos-dt-0andClaude Opus 5 d0ad6e942b docs(remediation): propagate DECISION-2 to charter — second un-propagated ruling, found by applying D-14
Applied D-14's own interim rule immediately instead of waiting to be bitten again, and
it caught a second instance within minutes: MISSION.md's standing directives still
stated the DB hard-cutover with no mention of Mos's binding qualification that the
spine must not be a single-point hard-stop (degraded mode + rollback artifact
required). A seat reading the charter would have designed toward an availability
posture the coordinator had explicitly rejected, with the superseded 'no DB means the
fleet stops' recommendation nowhere contradicted.

Two un-propagated rulings out of two that touched charter text. Without a mechanism,
propagation failure is the default outcome, not an oversight — which is the argument
for D-14 being a requirement rather than a discipline.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:12:16 -05:00
mos-dt-0andClaude Opus 5 7f686aaf6d docs(remediation): bank D-14 decision-propagation requirement; record D-13 reconciliation
D-14: DECISION-1 was ruled and applied to TASKS.md while MISSION.md — the charter a
cold-starting seat reads first — kept the superseded wire-in target for hours, flagged
CONTESTED on the board but never corrected in the source of truth. A resuming seat
would have read the rejected target as authoritative. Caught by hand during an
unrelated edit; nothing would have caught it otherwise.

P-MISSION-001 turned on ourselves: a decision that lives in a ruling and a board note
but not in the authoritative record has been AGREED, not MADE. Requirement: rulings
must propagate mechanically — decisions as records, documents rendering rather than
restating, and a must-fail check where duplication is unavoidable. Interim rule until
the DB cutover: the same commit that records a ruling updates every document stating it.

D-13 updated with Mos's reconciliation: 5 of 6 mosaicstack-provisioned seats have no
tea login — systemic, not a one-off. Supersedes D-11(b): the token-file set is
necessary but NOT sufficient; capability is per-path.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:11:01 -05:00
mos-dt-0andClaude Opus 5 f13222b76b docs(remediation): charter reflects DECISION-1 corrected wire-in target and current status
The charter's build-1 cell still named mosaic_orchestrator.py::run_single_task after
DECISION-1 ruled against it. Leaving the charter contradicting the ruled decision would
mislead any future reader who starts there — corrected in place with the rationale and
provenance, rather than only in TASKS.md.

Also: status PLANNING -> EXECUTING; scout TODO discharged (file is in-tree) with a note
that its findings stand but its recommended wire-in point is superseded.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:07:16 -05:00
mos-dt-0andClaude Opus 5 d1e7ba19ca docs(remediation): promote observe-the-property principle to charter; bank D-13 dual credential registries
Charter gains a first-class principle per Mos: no write is done until the requested
PROPERTY is observed; a success exit code is not evidence. Success output is designed
to be believed — that is why the inert-gate class exists and why the P-WRAPPER
tri-state is not optional. Recorded with its provenance: the orchestrator committed
this exact error (D-12), and three of the session's twelve instances were its own.

D-13: diagnosing D-12 found two parallel credential registries that can disagree.
gitea-mosaicstack-mos-dt-0.token EXISTS, but tea has no mosaicstack login for that
identity — so raw-API paths work while tea-dependent wrapper paths silently degrade.
tea is not stale; the login does not exist. Capability declared authoritative by the
token-file set does not govern the tea path.

RM-04 must reconcile the registries (or assert agreement at startup, with a must-fail
control). RM-50's pre-dispatch check must verify capability for the path actually used.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:06:18 -05:00
mos-dt-0andClaude Opus 5 0ffdcf14bd docs(remediation): bank D-12 — pr-create silently dropped --draft; I trusted exit 0 over observed state
PR #1027 was created with -d because it carries partial unproven work. tea auth was
stale, the wrapper fell back to the raw API which cannot set draft, warned on stderr,
and exited 0. The PR sat open and mergeable for ~25 minutes, protected only by the
word DRAFT in its title and body. I had reported it to the coordinator as a draft.

Three failures: a fallback silently degrading a SAFETY flag (nuisance for --labels,
dangerous for --draft); a correct warning nobody consumed; and my own failure to
verify the flag took effect — I checked the PR existed, not that it had the property
I required. That is written-unverified treated as verified, by me, on exactly the
class of tool this mission exists to distrust.

Fixed via the WIP: title prefix; draft:True verified after.

RM-02 gains a must-fail control: a wrapper that cannot honour a safety-relevant
argument must exit non-zero. RM-24 gains this as its canonical tri-state example.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:03:29 -05:00
mos-dt-0andClaude Opus 5 be10bdc828 docs(remediation): board tick — 2 PRs merged, RM-01 on rotated seat, dispatch doctrine
Board now carries the pre-dispatch capability check (token-file existence), the
token/authorship coherence rule, and the accreted worker-brief doctrine, so a
compacted or fresh seat inherits them mechanically rather than by recall.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 18:01:55 -05:00
mos-dt-0andClaude Opus 5 2201c30284 docs(remediation): correct D-11(a) mechanism — token identity and commit authorship are separate
Per Mos. MOSAIC_GIT_IDENTITY resolves the TOKEN; commit author comes from git config
user.name/user.email, a separate setting that fell back to the generic value. The
export could never have fixed authorship — my worker brief instructed only the export,
so the seat did what it was told and the commits were still mis-attributed. The error
was in the brief before it was in the finding.

Requirement is COHERENCE: token and authorship must agree; either half alone is drift.
Belongs in seat setup, verified by an exit-asserting test that commits and asserts the
author — not in prose a seat can follow correctly and still end up wrong.

Capability check mechanized: capability IS token-file existence. Before dispatching
seat X to provider Y, test gitea-<Y>-<X>.token exists. The token-file set is the
authoritative capability registry.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 17:59:06 -05:00
mos-dt-0andClaude Opus 5 75dfe2fa75 docs(remediation): bank D-11 — identity drift + seat capability opacity at dispatch
RM-01's seat was briefed to export MOSAIC_GIT_IDENTITY; its commits are authored as
the generic mosaic-coder fallback, so git history cannot say which seat did the work.
P-WRAPPER-001 reproduced on our own delivery.

Separately, nothing at dispatch time revealed the seat lacked a credential for the
target provider — discovered only when it failed mid-task after ~$9 and 69% context.
get_gitea_token behaved correctly by refusing to borrow another slot's token; the
dispatch-time information simply did not exist.

RM-50 gains per-seat capability declaration + pre-dispatch check; RM-04 gains
identity-binding verified by an exit-asserting test rather than assumed from an
export in a brief.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 17:56:34 -05:00
mos-dt-0andClaude Opus 5 409bf23e6a docs(remediation): bank D-10 — the queue guard's failure modes are inverted
Same required gate, both directions wrong: fails OPEN on state=unknown (5 meaningless
greens this session, wrong branch too), and fails CLOSED on credential resolution,
hard-blocking a worker's completed work. The identical command succeeded from that
worker's own worktree in another shell, so the checkout was fine.

A gate that waves through unchecked work and blocks ready work has its failure modes
backwards. Availability failures must degrade to a loud, audited CANNOT_ASSERT;
correctness failures must block. Also the Pi-brick shape: a gate whose unavailability
prevents recovery from it.

RM-03 extended to a third requirement: distinguish CANNOT_ASSERT from
ASSERTED_NOT_READY, both registered with must-fail controls, neither exiting 0 silently.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-07-31 17:52:42 -05:00