8fe14d8e1adda96118e2983ba9def0338e3cdcf7
766
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 mos-dt-0andClaude Opus 5
|
8fe14d8e1a |
docs(remediation): RM-02 round-4 narrowing in review at e910a45a; D-48's failure mode now has a control
The wording ruling holds: the required sentence is verbatim in the baseline and its control, and every remaining use of "protected" refers to RM-60's external boundary rather than the local baseline. The history claim reads "structurally incapable of asserting history provenance". I verified the negative control by making the overclaim myself: clean exits 0, and injecting "protected, independently anchored" into the baseline purpose exits 84 with INVENTORY_CLAIM_OVERSTATED. D-48 was an overstated boundary claim that three of us approved; that exact failure mode is now caught mechanically rather than by attention. Review dispatched with N2 as the sharpest check: the overclaim control is itself PR-controlled, so can it be weakened or reworded so an overstatement passes? This PR's history is that every fix relocates the defect one level down, so the reviewer is asked to assume it did again. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
dde38717dd |
docs(remediation): pre-register RM-02 narrowing review — N2 asks if the honesty control is itself honest
Registered at
|
||
|
mos-dt-0andClaude Opus 5
|
d9207d4c1a |
docs(remediation): bank D-52 — the fifth arrival defeated both the orchestrator and the coordinator
coder-mos2 built blocker 2's "protected/base artifact" fix, ran independent code AND security review on its own fix, and returned HIGH CWE-353 against its own work: the baseline is not protected because verifier, manifest, baseline, tests and lifecycle code are all PR-controlled, so rewriting them consistently self-certifies. It stopped rather than invent a fourth local anchor. Both of us authored the error in the same turn. I dispatched blocker 2 as "must come from a protected/base artifact"; Mos ruled blockers 2+3 fixable in-PR; and the same brief told the seat that blocker 1 had no local fix because PR code executes before the gate. My own pre-registered P2 had already named it — the seven required gate IDs are an anchor list, and if the author can edit it that is D-45 one level in. I registered the check, rev-974 confirmed it as a blocker, and I dispatched a remediation reproducing it one level down. That is the strongest evidence the principle is real: it defeats the people who wrote it, every time, until the anchor is external. Knowing the rule does not protect you from it. Ruled (b) honest narrowing, and the sibling distinction is what makes it correct rather than a climbdown. Blocker 1's local check can be vacuously passed — seam=HEAD certifies over nothing — so the claim is REMOVED. Blocker 2's baseline genuinely detects accidental drift and fails only against an adversary rewriting baseline, manifest and verifier consistently, so the claim is NARROWED and the check kept. Accidental drift is most real-world drift. The wording is the whole ruling, because this is D-48 territory and neither seat may repeat it: no "protected" or "independently anchored" over a same-checkout baseline, positive claim and adversarial gap in the same breath, plus a negative control that goes RED if the check ever claims protection it does not have. Increment trajectory surfaced to Jason: two RM-02 anchors now require RM-60 and each thins the (d)-strict increment. If a third needs the same boundary the increment may thin past worth. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
33caf78744 |
docs(remediation): bank D-51 — merged, closed, and the running tool is still broken
#1032 merged
|
||
|
mos-dt-0andClaude Opus 5
|
1aedf32523 |
docs(remediation): RM-03 gate-ready, RM-02 round 4 to coder-mos2
RM-03 #1032 freshened onto post-RM-61 main and re-cleared at
|
||
|
mos-dt-0andClaude Opus 5
|
0d5aae2c84 |
docs(remediation): pre-register RM-03 #1032 re-review at the freshened head 868b9b87
Registered before the reviewer read the diff. Review 66 and the merge-gate GO are void at the new head per D-50; Jason's approval is standing and executes once this re-gates. Verified independently first so the review does not re-spend on it: range-diff shows commits 2-5 patch-equivalent with only commit 1 differing, and that difference is the test:framework-shell chain resolved as a union preserving main's terminal-green contract harness AND all four RM-03 suites plus the pre-existing branch-absent test. Nothing dropped either way. CI 2199 is 9/9 including clone, the machine check is bound and clean, and mergeable is now true. R1 is the deliverable: the guard must actually FAIL on asserted non-readiness. RM-03 exists because the queue guard is zero-information — it returns pass for every possible input — so proving its tests pass is not the same as proving the guard can fail. R2 is the risk: confirm no queue-guard semantic moved in the rebase, because one resolved quietly re-breaks exactly what this fixes. R4 checks the tri-state can represent an indeterminate result without presenting it as a pass, which is the defect verbatim (state=unknown exit 0). Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
08f706b675 |
docs(remediation): bank D-50 (a GO has a shelf life) and file RM-63 (systemd-managed fleet)
D-50: #1032 carried review 66 APPROVED and a merge-gate GO both bound to |
||
|
mos-dt-0andClaude Opus 5
|
eae62a598a |
docs(remediation): bank D-48 (a boundary statement that was wrong) and D-49 (idle is not available)
D-48 is Mos's error, banked in Mos's words at Mos's request, and renumbered from the D-46 he suggested because that number is already the empty-registry finding — the ledger is the primary product and a duplicated number corrupts it. Three seats shipped and approved "sound against an author who cannot rewrite main; residual = compromised main; owner Builds 1-2". A1 does not rewrite main; it repoints a local remote-tracking ref with one unprivileged git update-ref, which I reproduced in seconds. So the documented residual described an exotic threat while the real one is trivial. Stating a boundary is not the same as stating it correctly, and an understated residual is worse than none because it reads as rigorous. Everyone checked a both-directions statement EXISTED; nobody checked it was TRUE. That is D-19's own move 2 performed with wrong content, and the third distinct way the render/verify principles have failed inside their own enforcers. And the correct answer was already written down. f10-coder's handoff holds the wrong claim at line 21 and, at line 29, the suspicion that overturns it — that provider-target ref selection may be influenced by CI checkout/fetch configuration, marked honestly as unverified. rev-974 then found exactly that. Had anyone run the suspicion down, D-48 would not have shipped. Requirement banked on RM-02/RM-34: a labelled suspicion that contradicts a shipped claim must BLOCK that claim until falsified. Suspicions are currently recorded and ignored, which makes honest labelling free of consequence — where one targets a boundary or integrity claim it is a pre-registered check nobody ran. D-49 refines the parking rule and supersedes the rationale of the coder-mos1 (c) ruling: the threshold is not "is the seat idle" but "can it still take the next lane". f10-coder was idle with work pushed and frozen, which reads as safe, but at 97.4% could not have taken the remediation the pending verdict was about to require. Rotating on that asymmetry was the only clean boundary available. The detection was discipline, not a mechanism — I was not watching seat context in real time and Mos caught it on a manual sweep. Requirement on RM-58/P-LIFECYCLE/the coordinator daemon: the coordinator watches token budget across seats and pre-empts at threshold, so a keystone seat's ceiling is never found by a failed round or a lucky sweep. Interim we both sweep; the mechanism retires the sweep. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
267b58deb3 |
docs(remediation): RM-02 round-3 review dispatched at fbb61912 — anchor verified against ground truth
The derived boundary
|
||
|
mos-dt-0andClaude Opus 5
|
e2058d4e84 |
docs(remediation): pre-register RM-02 anchor-round review — A1/P2 ask if the control point moved again
Registered at |
||
|
mos-dt-0andClaude Opus 5
|
4430e60d84 |
docs(remediation): RM-02 round 3 dispatched — board de-staled, under budget
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
4520d2f672 |
docs(remediation): promote two first-class principles to the charter; dispatch RM-02 round 3
Mos ruled both open questions and promoted the pattern to the charter. PRINCIPLE 1 — the anchor must live outside the audited party's authority. You cannot fix "the author controls X" by deriving X from something the author also controls; deriving only MOVES the control point. Third independent arrival of one conclusion, each reached while shipping something else and each from a different direction: the manifest certifying its own tree (D-19), the sandbox evaluating code that enters before the boundary exists (D-25), and now the registry seam derived from a path the author also places (D-45). Three impossibility-derivations of the same conclusion is the strongest architectural evidence this mission has produced, and it is what forces Builds 1-2 rather than making them a preference. PRINCIPLE 2 — no universally-quantified check may pass over an empty set. "All registered cases ran" is vacuously true when there are none. Non-emptiness and anchoring are preconditions asserted before the quantified check runs, not properties hoped for after. The identical vacuity appeared twice at two levels — seam=HEAD emptied the commit range, an emptied manifest emptied the registry population — and the first was fixed as an instance, so it returned one level up. Corollary, same disease: a clause written for the instance that produced it is not a clause. Q1 ruled: the merge-base anchor IS in scope for f10-coder in this PR. It is git-computable against main, which the author does not control, so reordering or splitting within the branch cannot move it — an existing non-author-controlled reference, no new infrastructure. RM-60's execution boundary is a sibling under the same principle but a different mechanism (where gate-verify runs, not what the anchor is) and stays with Mos and Jason. Honesty required in both directions: the merge-base anchors to main, whose integrity rests on the merge discipline this registry enforces — a bootstrap, sound against an author who cannot rewrite main and NOT sound against an attacker who can, with that residual bound to the Builds 1-2 dependency rather than implied. Q2 ruled: state the empty-set principle as a general clause now, and generalize the D-38/D-40 criteria the same way — quantify over the population instead of relabeling the originating instances. Round 3 dispatched to f10-coder: merge-base anchor plus delayed-introduction must-fail; empty-set precondition as a general clause with an emptied-registry must-fail; generalized clauses bound across the gate inventory; each red-first. Number.isInteger accepting zero/negative/unsafe pipeline numbers banked as a non-blocking follow-up. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
09875143c0 |
docs(remediation): roll D-11 capability/identity bullets to the ledger (D-43: roll out, never reword)
Third application of D-43's rule today. Those two bullets restated D-11/D-11a/D-11b, which live authoritatively in TASKS.md, so they were a second copy waiting to go stale. Rolled verbatim; the board keeps a pointer plus the one operational line that is not a restatement — assert the differential as that seat, because a single endpoint can be true for anyone or 403 for an unrelated scope. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
08cb73fde3 |
docs(remediation): bank D-45/D-46/D-47 — the fix moved the author's control point instead of removing it
Second NO-GO on the keystone at
|
||
|
mos-dt-0andClaude Opus 5
|
24a7915633 |
docs(remediation): stop item 1 restating the In-flight table — it went stale 3x by duplicating it
Item 1 has now gone stale three separate times in one session, every time for the same reason: it restated lane state that the In-flight table already owns. That is D-26's class (restatement is lossy every time) and D-43's mechanism (a second copy is a second thing to go stale). Fixing the wording a fourth time would just buy another few hours. So it no longer carries lane state at all — it points at the table and keeps only the two things that are NOT restatements: read the table, and re-derive any board claim from the provider before load-bearing use, because the board is sole-written and has no independent verifier. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
e1a3806292 |
docs(remediation): RM-02 re-review dispatched at 32b490a7; RM-61 exemption load-bearing for the first time
All four D-44 silent-defeat paths remediated in one hardening pass. I re-ran three of the four attacks
myself and they are dead: activationCommit injection is rejected as an author-controlled field with the
boundary now derived from the registry introduction (
|
||
|
mos-dt-0andClaude Opus 5
|
72b577eb85 |
docs(remediation): pre-register the RM-02 hardening re-review — attack the FIX, not the original bug
Registered at
|
||
|
mos-dt-0andClaude Opus 5
|
52114dd4eb |
docs(remediation): bank D-44 — the anti-inert-gate registry was inert-able four distinct ways
rev-974 NO-GO at
|
||
|
mos-dt-0andClaude Opus 5
|
8f70b1bc63 |
docs(remediation): pre-position the RM-02 activation-seam disposition so it survives a rotation
Mos ruled the disposition BEFORE the verdict, contingent on rev-974's independent A4/A5/A6. Recorded
here — not in the frozen AC file, which would be retrofitting, and not relayed to the reviewer, who
must reach A4 themselves or refute it.
The concern: activationCommit is the lower bound of the range required to carry own-tree registry
provenance, advancing it shrinks the audited set, the author advanced it to turn the author's own gate
green, and the only validation is --is-ancestor, which a commit satisfies against itself. The registry
built to detect gates that silently stopped enforcing may contain a field by which its own author can
make it stop enforcing, validated by a tautology.
A6 is the crux and stands alone from A4: even if
|
||
|
mos-dt-0andClaude Opus 5
|
32384dab02 |
docs(remediation): board under budget by ROLLING OUT (D-43), not rewording; item 1 de-staled
Sequencing section rolled verbatim to BOARD-LEDGER — it was a pointer to a pointer, and MISSION.md
plus TASKS.md 5 remain canonical. Item 1 said RM-02 'needs rebase+CI+review'; rebase and CI are done
and it is in review at
|
||
|
mos-dt-0andClaude Opus 5
|
777a8f7f5b |
docs(remediation): RM-02 in review at 83d2ecb2; crux is the activation-seam question (A4)
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
995f8b6a24 |
docs(remediation): pre-register RM-02 keystone review ACs before the reviewer reads the diff
Registered at head |
||
|
mos-dt-0andClaude Opus 5
|
d0a510d28d |
docs(remediation): scope rulings banked; D-43 elevated onto RM-34 — the control plane has no verifier
SCOPE (Mos): D-38 (bind evidence to subject) and D-40 (type-strict discriminator inputs) land IN the RM-02 PR — cheap registry-coverage clauses, satisfiable now, and RM-02 literally IS the registry, so codifying what its own delivery learned about how gates fail is the coherent move. D-42 splits, and the reason is sharper than "needs experimentation": landing its clause in-PR today would give the registry a clause with NOTHING to satisfy it, so the registry would go red on its own clause and couple the keystone's landing to infra work. Wrong coupling. So (a) the infra experiment proving the pin enforces via the negative case, in Mos's D-37/D-41/D-42 cluster; (b) the registry clause "provider-side enforcement requires an OBSERVED negative control", in a follow-up RM-02 increment once (a) gives it something to check. Named owner, not a vacuous check and not a silent omission. D-43 point 3 elevated to the PRIMARY requirement on RM-34, with the table that makes it plain: code has rev-974, gates have the merge-gate, CI has the JSON scan, and the control plane has NOTHING. Every other layer earned a verifier from a live failure; the board never did, and it is the artifact every other decision is staged from. "Validate the checkpoint" must mean re-derive the board's claims from ground truth — not that the file parses or that a successor can read it. It belongs to the coordinator-daemon deliverable: the control plane needs its own verifier the way every other layer got one. Today's catch was discipline, not mechanism. Interim rule binding on BOTH seats until that mechanism exists, and Mos adopted it against himself: re-derive a board claim from ground truth before any load-bearing use. The orchestrator does it before dispatch; the coordinator does it before acting on or relaying a board claim that gates a decision. D-11b addendum: the false-NEGATIVE twin. /user returns 403 on a least-privilege seat token (no read:user) and reads exactly like an unprovisioned seat. The real assertion is the DIFFERENTIAL — authenticated push=true vs unauthenticated push=false proves the token caused the difference. A single endpoint can be true for anyone or refused for an unrelated scope reason. Would have escalated a working seat as unprovisioned and stalled the keystone on a phantom. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
8cef39f924 |
docs(remediation): RM-61 MERGED; bank D-43 — I inverted a board fact while compressing to fit the budget
#1033 merged |
||
|
mos-dt-0andClaude Opus 5
|
f3c100f814 |
docs(remediation): bank D-42 — the head-pin's negative control has never been observed
merge-gate.md says it outright: a successful merge is NOT evidence the pin worked, only the negative case is. On mosaicstack Gitea a merge against a WRONG head_commit_id has never been attempted, so every head-pinned merge to date is equally consistent with the pin working and with the pin being ignored. That is D-23's class — the queue guard "ran" and returned pass for every possible input; the pin "holds" on every merge that would have succeeded anyway. By the mission's own standard (every gate-introducing task carries a registered must-fail negative control; a gate with no proven failure path manufactures evidence) the head-pin is unregistered in substance however it reads in the runbook. Not blocking #1033: that head is coordinator-frozen with both the orchestrator and coder-mos1 holding, so there is no concurrent pusher for the pin to defend against — its protection is only load-bearing on a contested head. Raised by Mos while assigning the merge; Mos owns it and has filed it as an infra task in the D-37/D-41 cluster, to be proven before any contested-head merge. Requirement on RM-02: the negative-control clause must cover provider-side enforcement mechanisms, not only in-repo checks. "The API accepted our parameter" is not evidence the API honours it — the same true-answer-to-a-different-question shape as D-24 and D-38. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
2750cc4842 |
docs(remediation): D-38c — PR metadata failed a THIRD time on #1033; delivery-issue gap ruled
Merge-gate NO-GO with every code and CI gate verified, including the --expect-commit machine-check it
was told to exercise (9/9 JSON, exempted_steps 0, expected_commit == commit). The blocker was the body:
only "Refs #1000", no "Closes #N", and Mosaic completion requires a linked issue closed.
Third distinct metadata failure on one PR — missing commit binding, then a stale DO-NOT-MERGE body
describing a dead head, now an incomplete link. Each time the code was fine and the metadata was
unbound, stale, or incomplete. Nothing re-binds PR metadata to the head or checks it for completeness
until a gate does, and by then it costs a round trip.
The subtlety that makes it a real ruling: #1033 must NOT Closes #1000. The teardown defect stays open,
and #1000 is the exemption's own retirement trigger — auto-closing it would delete the retirement
trigger for the workaround being merged, turning a bounded exemption into a permanent one by side
effect. Hence a delivery issue distinct from the defect issue: #1034, with Closes #1034 added and
Refs #1000 kept.
Metadata-only, head never moved: verified by read-back that head is still
|
||
|
mos-dt-0andClaude Opus 5
|
553474e4c8 |
docs(remediation): RM-61 GATE-READY at 57cae04f — review 70 APPROVED, CI 2194 9/9, D-40 closed
rev-974 approved at the exact head with no blocking and no non-blocking findings. Verified by me from
the provider rather than relayed: head unmoved, review 70 bound to
|
||
|
mos-dt-0andClaude Opus 5
|
0de8ccb52c |
docs(remediation): RM-62 — fleet management is a PREREQUISITE, and the rotation claim is corrected
Mos ruled (c): coder-mos1 stays idle/parked, not manually rotated. It holds no in-flight work, so there is nothing to rotate FOR, and a manual in-pane restart would dress a missing mechanism as a lifecycle operation — the D-41 overclaim itself. It stays AVAILABLE through RM-61's re-review in case that review needs its context; the next NEW lane goes to a fresh seat, not to a seat at 67%. RM-62 filed, because a dependency stated as prose with no owner becomes the permanent gap the charter warns about. Bringing the execution fleet under roster/systemd management BLOCKS RM-50, RM-58 and P-LIFECYCLE-001 — each is unsatisfiable against its real population until it lands. Banked explicitly that both would FAIL against their real target today: RM-50 applied now quarantines the seat implementing RM-50, and RM-58 has no mechanical reset path for any seat that needs one. RM-50 and RM-58 now carry RM-62 as a hard depends_on edge, and RM-50 carries the requirement that acceptance be proved against the unmanaged execution fleet rather than the roster-managed canaries. RECORD CORRECTION, initiated by Mos and banked here: this session's opening rotation validated the checkpoint+rehydration DESIGN losslessly — the residency attestation genuinely passed from the files — but the MECHANISM was a manual pane respawn. "The handoff rehydrated losslessly" is earned; "rotation worked" overclaims a mechanism that does not exist, and that overclaim is D-41. Same distinction as D-23's inert guard: the step ran, one property was observed, the mechanism was not. Board header now says so rather than implying a lifecycle rotation occurred. D-37 and D-41 are one cluster — the execution fleet lacks both its shared-infrastructure and its lifecycle management. Mos owns both, sequenced at a seam, never mid-lane. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
37402e9770 |
docs(remediation): bank D-41 — the whole execution fleet is UNMANAGED, so RM-50/RM-58 have no surface
Went to rotate coder-mos1 mechanically; `mosaic fleet restart` cannot reach it. Every seat executing this mission is systemd inactive/disabled and flagged UNMANAGED — coder-mos1, rev-974, f10-coder, merge-gate, the pm-scouts, rev-3107b, ultron-3107, and mos-remediation itself. The roster-managed population is a different set of seats from the ones doing the work. RM-50 applied today would quarantine the entire remediation fleet including the seat implementing it. RM-58's mechanical out-of-band reset cannot be performed at all, so the only rotation available is what D-4 says does not count: asking the agent, or killing a pane by hand. Requirement banked on both: their acceptance must be demonstrated against the UNMANAGED execution population, because a criterion proved only on roster-managed canaries is tested on the wrong population — D-17's coverage class one layer up. Today's rotation is therefore labelled honestly as a manual pane restart with a hand-verified handoff, not as a lifecycle operation. The step ran; the property was not observed (cf. D-23). Did not run fleet restart against a disabled unit while the live pane held RM-61 and RM-03 state. Disposition escalated to Mos. Also records the handoff artifact as the positive control: typed state, and it surfaced D-12 recurring live (PR #1033's draft property silently dropped by a wrapper fallback), an unrunnable check declared rather than substituted, and suspicions labelled as suspicions. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
01831814b6 |
docs(remediation): board — D-40 ruled BLOCKING, RM-61 rebuilding, TS1-TS12 pre-registered
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> |
||
|
mos-dt-0andClaude Opus 5
|
86cd1a0f46 |
docs(remediation): D-40 RULED BLOCKING; pre-register type-strict ACs before the fix is pushed
Mos ruled BLOCKING on the exit_code type confusion. Both of us had leaned non-blocking on the
unreachability argument and neither shipped it. The two decisive grounds: the direction is
wrong-ACCEPT (false and 0.0 GRANT the exemption), which is this mission's disqualifying direction and
exactly why RR12 was tolerable; and "Woodpecker is Go with an int type" is structurally the same
incidental-correlate argument RM-61 itself forbade for the signature — you cannot certify the
discriminator against infra-shift and then defend a hole in it with an infra-stability assumption.
Generalised into an RM-02 standing clause, which is the real prize: discriminator and comparison
inputs must be TYPE-STRICT. A comparison that accepts a type it should not is a wrong-ACCEPT hole by
construction; `== 0` matching False and 0.0 is one instance of a class. D-40 is the instance, the
clause is the fix. It sits alongside the D-38 clause (does this gate bind its evidence to its subject).
D-39b banks the roles-swapped half: the author does not adjudicate its own PR's blocker status and
does not move the head to enforce it. Symmetric with D-39 — a seat with a stake in the answer does not
settle the question, and a conservative motive exempts neither direction.
ACs are registered NOW, before coder-mos1 pushes and before any reviewer reads a diff; at registration
the fix exists only as an unpushed local commit I have not read, so there is no diff to retrofit to.
They also state explicitly which cases are genuine RED-FIRST (false, 0.0 — currently wrongly exempting)
and which are only regression guards ("0", null — already blocking), because demanding an impossible
red for the latter two invites weakening something real to manufacture it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
||
|
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
|
||
|
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 @ |
||
|
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 |
||
|
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]> |
||
|
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]> |
||
|
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]>
|
||
|
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 |
||
|
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]> |
||
|
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
|
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |