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]>
#1032 merged 58b971ab and #1019 closed, both verified by property. RM-03 is delivered to main. And the
guard that actually executes on this host is unchanged: installed 291 lines with ZERO occurrences of
ASSERTED_NOT_READY, main 482 lines with five. Differing SHA-256. Measured, not inferred — the installed
guard contains none of the tri-state logic.
This is the install-drift disease the postmortem indicts, caught in the act on the mission's own fix.
Every completion signal is green — merged PR, closed issue, terminal CI, merge-gate GO — and the defect
is still live in the thing that runs. D-23's origin was an assumed-propagated-but-didn't guard; this is
that origin reproduced by the delivery of its own remedy.
Merge is not delivery for tool changes. Rules banked from Mos: propagate only via the canonical path
(mosaic upgrade / deploy pipeline), never a hand-copy that could diverge while appearing to fix it; the
installed guard stays zero-information until re-sync, so every state=unknown exit 0 this mission logged
remains correctly uncited; and on re-sync VERIFY THE PROPERTY by running the installed guard against a
known-red pipeline to confirm it exits non-zero and blocks. Closing this by assuming the upgrade worked
would reproduce D-23 a third time.
Generalises: every framework/tool change this mission delivers has the same main-to-installed gap. It
belongs on the completion checklist for tool-affecting tasks and mechanically on RM-63 — the same
systemd-service architecture that mechanises rotation also mechanises propagation.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
RM-03 #1032 freshened onto post-RM-61 main and re-cleared at 868b9b87: review 74 APPROVED bound to the
exact head, CI 2199 9/9 including clone, mergeable true. The deliverable is proven against production
rather than asserted — rev-974 invoked the exact-head ci-queue-wait.sh itself against isolated provider
fixtures and got exit 3 with ASSERTED_NOT_READY on terminal failure, no-status, malformed payload and
an indeterminate neutral status, plus timeout 124 on pending. D-23 said the guard returns pass for
every possible input; that is now false at this head. Merge-gate assigned, Jason's approval standing.
My own spot-check went further than the range-diff I asked for: ci-queue-wait.sh and pr-merge.sh blobs
are byte-identical across the old approved head and this one, so no guard implementation moved in the
rebase — the only delta is commit 1's additive test enumeration, a union preserving both sides.
RM-02 round 4 dispatched to coder-mos2, a fresh dedicated identity at 0.5% context, so no D-41
manual-respawn problem. I asserted its capability differentially before dispatch per my own D-11b
addendum rather than accepting it on report: authenticated push True, unauthenticated False.
Its brief carries the two traps I found by reading the code, both binding, because the first is how
anyone would naturally build (d): emitting the unverifiable state as an observation exits 0, and
coverageBoundary.excluded is schema-validated but not enforced. The claim goes away rather than being
annotated, and the exclusion needs a must-fail control or it is a gate with no proven failure path.
It also carries the CORRECTED residual — no local git state is trustworthy because PR code executes
before the gate — not the D-48 wording three of us approved.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
D-50: #1032 carried review 66 APPROVED and a merge-gate GO both bound to 78ec47cd, and by the time
Jason approved the merge it reported mergeable=false. Verified from the provider: its head does not
contain current main f4fd5967. Two rules we already hold, neither wrong alone, combine badly — a
verdict is commit-bound and voids when the head moves, and main drifts while a PR is held, so resolving
the drift moves the head and voids the verdict that was waiting to be used. Holding it across the whole
#1033 saga is what did it.
The asymmetry worth noting: usually a head moves because the AUTHOR pushed, so the void follows from
their action. Here nobody touched the PR — unrelated progress invalidated it — which is why it is easy
to miss and needs a checklist line rather than vigilance. Mos's line: a GO has a shelf life, re-gate on
main-drift.
RM-63 files Jason's architecture as the mechanization of D-41/RM-50/RM-58/P-LIFECYCLE rather than a new
island: durably-named systemd agent services with lanes, where restart triggers a continuation and the
agent resumes its lane, combined with DB-centric task assignment on the PG spine for autonomous pickup.
That is the enforcement surface D-41 proved missing — a managed service can be watched (token budget,
which is D-49's mechanical ceiling monitor), restarted (rotation, retiring our manual respawns) and
continued (rehydrate from the DB). It closes the f10-coder ceiling gap directly: Jason confirmed that
ceiling was not mechanically flagged and must be.
#1032 freshening dispatched to coder-mos1 — it authored the queue guard, so that context is an asset,
and by D-49 it can still take a lane at 67%. Told to stop and flag on any SUBSTANCE conflict, because a
queue-guard semantic resolved quietly re-breaks the very thing RM-03 fixes.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
The derived boundary f4fd5967 equals an independently computed git merge-base HEAD
refs/remotes/origin/main. It is the same value f10-coder once set by hand: the value was never wrong,
the authority was. That is exactly why Mos insisted A6 be separated from A4 — asking only whether the
value was right would have closed this three rounds ago with the hole intact.
Empty-registry attack now fails in the precondition's own language. The both-directions bootstrap
statement is in the code with the residual bound to Builds 1-2, per D-19's third mandatory move.
Exact-head CI 2198: 10 children all success including clone and gate-verify; my machine check exits 0
bound to the head with anomalies 0, and a wrong-head negative control exits 1. exempted_steps is 0 this
run because ci-postgres succeeded, so the #1000 exemption was present but unneeded.
Review dispatched with A1 and P2 as the sharp checks: both ask whether this fix REMOVED the author's
control point or moved it again. refs/remotes/origin/main is a local ref, and the seven required gate
IDs are an anchor list. Five for five so far, every blocker on this PR came from outside the registered
set.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Registered at fbb61912 before any reviewer read the diff. I reproduced three things first so the review
does not re-spend on them: the derived boundary equals an independently computed git merge-base HEAD
origin/main (f4fd5967 — the same value f10-coder once set by hand, now derived rather than asserted);
emptying the registry populations fails with the precondition's own language; the both-directions
bootstrap statement is present with the Builds 1-2 residual.
A1 and P2 are the sharp ones and they ask the same question the last two rounds answered badly: did the
fix REMOVE the author's control point or MOVE it? A1 — refs/remotes/origin/main is a local ref; who
controls it where the gate runs, and can an author rewrite remote.origin.url or craft that ref in their
own clone? P2 — the seven required gate IDs are an anchor list; if the author can edit it, that is D-45
one level in. A4 asks about the natural failure mode of this fix, over-inclusion causing false reds.
P3 independently confirms the production fixture-profile bypass the author found and removed in their
own pre-commit review — self-disclosed, so it gets verified rather than credited.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
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]>
Second NO-GO on the keystone at 32b490a7. The pattern is the finding, not the three blockers.
D-45: round 1 the author set activationCommit as a field, so we derived it; round 2 the derivation
depends on WHEN the author introduces gates/gates.manifest.json. rev-974 committed a gate change before
adding the manifest — deriveHistoryBoundary picked that commit as activation, the prospective list held
only the later introduction, and verifyHistory returned no failures. The three registered seam controls
cannot catch it because they compare candidates against whatever introduction the author selected: they
validate the choice, not the choosing. You cannot fix "the author controls X" by deriving X from
something the author also controls. That is D-19/D-25 verbatim — the anchor must live outside the
audited party's authority — arriving a third time, now inside the keystone, and it is exactly why
Builds 1-2 are forced rather than preferred.
D-46: I reproduced it myself. Emptying criteria, gates, proseClaims and compatibilityScenarios — 17, 7,
8 and 2 entries — and pointing gateRoots at an empty directory yields EXIT 0, reporting "all registered
cases ran from this checkout" and "open behavior deltas: 0". "All registered cases ran" is vacuously
true over an empty set. The registry can be reduced to nothing and still report green.
D-45 and D-46 are the same defect at two levels: vacuity through emptiness. Empty the commit range or
empty the registry population — either way a universally-quantified check over an empty set passes.
seam=HEAD was the first instance and we fixed it AS an instance; the principle was never extracted, so
it came back one level up. Proposed general clause pending Mos: no universally-quantified registry
check may pass over an empty set — non-emptiness and anchoring are preconditions, not properties.
D-47: the new criteria are still instance-scoped. RM02-EVIDENCE-SUBJECT-BINDING covers only provider
evidence identity, not whether every registered gate binds evidence to its subject; RM02-TYPE-STRICT-
SCHEMA covers registry schema fields, not each gate's own discriminators. Do not relabel the
originating instances as the general clauses.
Dispatch PAUSED for the first time this session: the fix needs a non-author-controlled anchor, which
touches the provider/merge-base boundary and is adjacent to RM-60, which Mos and Jason own. Asked Mos
whether that anchoring is in scope for f10-coder here or crosses into RM-60, and whether the empty-set
principle becomes a general clause now.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
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 (0b4aa475); the misspelled outputPatern is rejected
as an unknown field by the recursive schema; the global cross-commit duplicate-pipeline check is
present. Three new criteria registered with bound cases.
Exact-head CI 2197 is the notable one: pipeline success with 10 children, 9 success and 1 genuine
FAILURE — ci-postgres, type service, exit_code 0, exact #1000 teardown signature. The RM-61 exemption
fired for real on a gate-ready decision for the first time. I ran the machine check myself (exit 0,
terminal-green, exempted_steps 1, correct exemption id) and a negative control on the same record with
a wrong expected head (exit 1, not-terminal-green, exempted_steps 0). Both halves of RM-61 — the
signature-scoped exemption and the subject binding — demonstrated in a single run.
The pre-registered ACs deliberately do not re-check what I reproduced; they attack the FIX, because
every round on this mission the remediation introduced the next hole. H1 asks whether the new
derivation's inputs are author-controlled, S1 whether the schema closure is a class or an enumeration,
C2 whether the new criteria are clauses or just their originating instances.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Registered at 32b490a7 before any reviewer read the diff. I verified three of the four attacks are dead
by re-running them myself: injecting activationCommit=HEAD now yields "author-controlled
activationCommit is forbidden; history boundary is derived from the registry introduction"; the
misspelled outputPatern is rejected as an unknown field by the recursive schema; the global
cross-commit duplicate check is present. The three criteria are registered with caseRefs 1/3/3.
So the AC set does not spend itself re-checking what I already reproduced. Every round on this mission
the remediation introduced the next hole — the commit-binding fix shipped a type confusion, the
type-strict fix was clean but the registry around it had four defeats — so the value is in whether the
NEW mechanism is defeatable.
Blocker 1's fix replaced an author-settable field with a derivation, and a derivation has inputs. H1
asks who controls them: can an author move the derived boundary by adding, renaming, deleting-and-
recreating or symlinking gates/gates.manifest.json, or by planting a second manifest earlier in
history? If so, blocker 1 is relocated rather than fixed. H2-H4 ask what first-parent traversal,
shallow clones, and path deletion do — fail closed or silently derive a wrong boundary.
S1 asks whether the schema closure is complete or merely enumerated: find a nested object the author
did not list and inject an unknown key there. C2 asks whether the new criteria express D-38 and D-40
generally or only their originating instances — a clause that covers only the instance that produced it
is not a clause.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
rev-974 NO-GO at 83d2ecb2. A4/A5/A6 confirmed and three further blockers found, two of them outside my
registered set. Each is a silent-defeat path of the registry itself: the activation seam inerts the
history audit (seam=HEAD gives 0 prospective commits and no failures — and HEAD's parent and the
introduction commit also pass, so forbidding equality with HEAD does not close it); a misspelled
outputPattern silently reduces an assertion to exit-code-only because the closed schema is not
recursive; two provider records sharing pipeline number 7 certify two different commits; and the D-38
and D-40 criteria are absent, with blocker 4 a live instance of the very D-38 clause that is missing.
The headline: all four passed CI, passed the canonical gate:verify, and passed 38/38 focused tests.
Greens discharged nothing. My own AC set was incomplete too — A3 corrects the prospective range to
eight commits, not the seven I wrote; I omitted the seam commit itself.
Mos ruled ALL FOUR in this PR, no trim, and sizing does not help: a registry that ships with a known
way to be silently defeated IS the inert gate it exists to detect. There is no core registry that is
integrity-complete without these — they are not hardening on top of the deliverable, they are the
deliverable. Theme: the registry's own checks must not be silently defeatable. Each fix carries a
red-first must-fail control proving the specific defeat is now caught, and that control set IS the
D-38/D-40 coverage work rather than being additive to it.
Blocker 1's fix keeps the value and replaces the mechanism: derive the seam from non-author-controlled
history (parent of the first first-parent commit introducing gates/gates.manifest.json) rather than
asserting it in an author-editable field, plus must-fail controls for HEAD, HEAD's parent, and the
introduction commit. If the work balloons past reviewability the only acceptable split is by
integrity-complete stage, never by deferring a blocker.
Method note banked as a positive: I could not reproduce "full verifier exit 0", traced my first attempt
to my own instrumentation artifact (json.dump reformatting the manifest), and stated the divergence
rather than wielding non-reproduction as a refutation. The vacuity itself reproduced and blocker 3 was
confirmed by construction. Non-reproduction is not refutation. Open thread: why my gate:verify exits 1
on checkout-preflight with outcome 42.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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 f4fd5967 is the correct value — and it plausibly is,
since a pre-registry commit cannot carry a registry manifest — the mechanism question is independent.
If the audited party can relax its own audit behind a tautological check, the value being right today
is irrelevant and the next value need not be right.
If confirmed: BLOCKING at D-40's standard, and the fix is NOT reverting the value. It is making the
field non-author-relaxable — activationCommit independently derivable, equal to the real pre-registry
seam by construction rather than assertion — plus a must-fail negative control that a HEAD-valued or
over-advanced seam is REJECTED. The registry must be able to fail on its own seam being gamed.
If refuted: bounded, value stands, hardening tracked as a registry clause, and the refutation is itself
a finding worth having.
f10-coder commended with the distinction stated: it verified identity before committing and disclosed
the non-mechanical change unprompted, which is the only reason this is visible at all. But disclosure
is not sufficiency — an honest author flagging a self-relaxing change still made one. Honesty surfaced
it; the mechanism must catch it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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 83d2ecb2.
Second application of D-43's rule today: delete-and-reference, never paraphrase-to-save-bytes.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Registered at head 83d2ecb2 before dispatch. Prior reviews 63/65 are superseded and this head carries
no live review of any kind, so the keystone gets a full independent review.
The crux is the one non-mechanical change, which f10-coder disclosed unprompted: activationCommit
advanced f65e9ea6 -> f4fd5967 so that the newly merged pre-registry RM-61 commit is no longer treated
as prospective. activationCommit sets the lower bound of the commit range required to carry own-tree
registry provenance, so advancing it SHRINKS that set. The value is plausibly correct — a pre-registry
commit cannot carry a registry manifest — but the change was made by the author to turn the author's
own gate from red to green, which is the self-verification shape the charter warns about.
Registered as A1-A6 without a verdict from me (D-39). A4 is the sharp one: the only validation on the
field is merge-base --is-ancestor activationCommit head, and a commit is its own ancestor, so setting
activationCommit = HEAD would empty the prospective range and the per-commit provenance loop would
iterate zero times. Whether that makes the history check pass VACUOUSLY is for rev-974 to determine and
report — an author-settable field that can inert the anti-inert-gate registry's own history check would
be the disease inside the cure again. A5 asks whether a must-fail negative control exists for it, since
RM-02's own founding rule is that a gate with no proven failure path manufactures evidence.
B1/B2 carry Mos's scope ruling that the D-38 bind-to-subject and D-40 type-strict clauses land in THIS
PR; B3 confirms D-42's clause is deliberately absent rather than forgotten.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
#1033 merged f4fd5967, verified by property: merged=true + merge commit, #1034 (delivery) CLOSED,
#1000 (retirement trigger) still OPEN. The exemption is on main and RM-02 is unblocked.
D-43 is mine. Compressing RM-02's board row to meet the 8KB budget, I turned "2 reviews clear" into
"2 live REQUEST_CHANGES" — an inversion. Provider truth: reviews 63 and 65 are at superseded heads and
live REQUEST_CHANGES at f9746b23 is empty. The real state is subtler than either wording: no live
blocker AND no live approval, because the head carries no review at all.
Caught only by re-deriving RM-02's state from the provider before dispatching, not by re-reading the
board. I was one message from briefing f10-coder to remediate two blocking reviews that do not exist.
The transferable part: this board carries a hard <8KB budget, it exceeded that budget four times in one
session, and each time I shaved prose to fit. Compression IS restatement, and this board's own rule is
"REFERENCE, do not restate" (D-26) because restatement is lossy every time. The budget therefore forces
the exact operation the board forbids, on its most load-bearing table. I flagged that as a risk earlier
in the session; it then materialised as an actual error.
Rule banked: meet a size budget by ROLLING content out to BOARD-LEDGER.md, never by rewording what
stays. Deleting a row and pointing at its authoritative home is safe; paraphrasing to save bytes is not.
Applied immediately — this commit rolls the Decisions-log narrative out verbatim rather than trimming
it, and the board is back under budget at 8096.
And the deeper one, onto RM-34: the orchestrator is the board's sole writer, so nothing external checks
the board against reality. Code has rev-974, gates have the merge-gate, CI has the JSON scan — the
control plane has no independent verifier. Handoff validation must include re-deriving the board's
claims from the provider, not merely confirming a successor can read the file.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
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 57cae04f, Closes#1034
present, Refs #1000 present, Closes#1000 ABSENT, review 70 still CURRENT with zero live
REQUEST_CHANGES, #1034 open. coder-mos1 stayed parked; nobody pushed.
Process gap ruled by Mos: every remediation delivery PR needs a delivery issue to Close, created at
OPEN-TIME rather than discovered at gate-time. #1032 already Closes#1019; #1033 had none.
Both provider writes went through the tea->API fallback — the same path that silently dropped #1033's
draft property at creation — so both were read back and verified by property, not by exit code.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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 57cae04f, pipeline 2194 terminal
success at that commit, 9 children all success including clone (a 9-of-9 scan, not the 8-of-9 D-33 was
banked for). Queue guard run for the push gate and NOT cited — state=unknown exit 0 on branch=main,
D-23 verbatim.
The redundant-clause question I handed rev-974 without a conclusion came back answered by mutation
testing, and I re-ran both mutations myself: deleting the bool clause alone leaves the 17-case harness
green (not load-bearing), deleting the exact-type clause alone fails it (load-bearing, mutation
killed). So the exact-type clause carries the protection and the bool clause is inert-but-defensive
against a future type()->isinstance() edit, which the true/false cases would catch. Removing it alone
cannot reopen D-40. Better answer than either of us had, obtained by asking rather than telling —
D-39 paid for itself on the first review after adoption.
Disclosed to Mos rather than absorbed: JSON `-0` decodes to Python integer zero and passes. rev-974
ruled it not a type confusion because it is a valid JSON integer numerically equal to zero. I agree on
the merits, but it is a reviewer judgement inside the exemption and belongs in front of the gate.
Gate steps 1-3 are satisfied. Steps 4 and 5 — merge-gate verdict and head-pinned merge — are Mos's.
Head frozen; coder-mos1 parked idle per ruling (c) and will not push; neither will I.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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]>
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 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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
KICKSTART resume now points at origin/remediation/state for the live board, per Mos's
cadence ruling: every tick is pushed to the rolling branch immediately (durable
per-tick, no per-tick main PR); main carries periodic snapshots only. Reading the
board from main would silently yield a stale tick, so the step warns explicitly.
D-9 hardened: comms/v1 must use file/stdin transport, never argv interpolation.
Standing interim rule until then — agent-send -f for any body with special
characters, never -m. Mandatory in every worker brief alongside the D-8 clause.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
agent-send.sh -m with backticks executes them as command substitution: the recipient
got a mangled body plus a shell error, and the send still reported success. Same class
as the known pr-create.sh backtick bug — two tools in the comms path treating a
message body as shell input.
The failure mode is the mission's own pattern: silent corruption with a success
receipt.
Requirement on RM-40/RM-42: comms/v1 must carry payloads verbatim with no shell
interpretation at any hop, with a byte-identical round-trip test (backticks, command
substitution, quotes, newlines) registered under RM-02 including a must-fail control.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
| **A1** | `targetRef` is the literal `refs/remotes/origin/main`. **Who controls that ref in the environment where the gate runs?** Can a PR author influence it — a `remote.origin.url` rewrite, a crafted `refs/remotes/origin/main` in their own clone, a push to a fork's `main`? If the gate trusts a locally-writable ref, the anchor moved from the manifest into git config. |
| **A2** | **Absent/stale target:** if `refs/remotes/origin/main` is missing, stale, or the fetch is shallow, does it fail CLOSED (line 57 suggests it does) or silently derive a narrower range? |
| **A3** | **Delayed introduction — the round-2 attack, re-run.** Commit a gate change BEFORE adding the manifest. Does it now stay in range and fail the own-tree read? |
| **A4** | **Branch from an old main:** branch from a point far behind `origin/main`, so merge-base is old. Does the range widen correctly (safe) or include unrelated main commits that cannot carry manifests (a new false-red)? Over-inclusion is the natural failure mode of this fix. |
| **A5** | Is the **bootstrap residual** recorded as a **tracked dependency on Builds 1–2**, not prose? (D-19's third mandatory move.) |
| **P1** | Does the precondition run **before** every quantified check, on **every** path — or only the ones the author enumerated? Find a quantified check that still runs before its precondition. |
| **P2** | **Seven required gate IDs anchored to canonical sources** — can that anchor list itself be emptied, shrunk, or pointed elsewhere? An anchor list the author edits is D-45 again, one level in. |
| **P3** | The author reports finding and REMOVING a **production CLI fixture-profile bypass** in their own pre-commit review. **Verify it is gone from the shipped CLI path**, that the remaining relaxation is test-support only and non-executable in production, and that the CLI rejection is tested. This was self-disclosed — confirm it independently. |
## Q — clauses quantified over the population (D-47)
| **Q1** | `gateRefs`**exactly spans** every registered gate. Can a gate be added WITHOUT a corresponding ref — i.e. does adding a gate to the population escape the clause? |
| **Q2** | Deleting `gateRefs`, or shrinking gates and refs **together**, must fail. Shrink-together is the D-46 shape; verify it is a genuine control and not a regression guard mislabelled. |
| **Q3** | Do the population controls **iterate all seven gates** and mutate evidence-subject and comparison-type **per gate**, or only a representative one? |
| **Q4** | Honest labelling: author claims delayed-introduction, empty-populations, fixture-profile bypass and removable gateRefs as **genuine red-first**, and shrink-together/exact-span as **regression guards**. Verify each claim against pre-fix code (D-8). |
| **H1** | `deriveHistoryBoundary` = parent of the first first-parent commit introducing `gates/gates.manifest.json`. **Are its inputs author-controlled?** Can a PR author influence the derived value by adding, moving, renaming, deleting-and-recreating, or symlinking that path — or by adding a SECOND manifest earlier in history? If the derivation is gameable, blocker 1 is not fixed, only relocated. |
| **H2** | **First-parent traversal:** what happens on a merge commit, an octopus merge, a squash, a rebase that reorders, or a branch where the introducing commit is not on the first-parent chain? Does the boundary silently move, or fail closed? |
| **H3** | **Shallow/partial clone:** the branch previously needed an unshallow fix (`e8959975` "unshallow gate replay history"). If history is shallow, does the derivation fail CLOSED or silently derive a wrong/empty boundary? |
| **H4** | **Path deletion:** if `gates/gates.manifest.json` is absent at HEAD, or was deleted and re-added, what is derived? Fail closed, or a boundary that excludes the deletion window? |
| **H5** | Are the **three registered seam controls (HEAD, HEAD^, introduction) genuinely RED-FIRST** — do they fail against the PRE-fix code for their own stated reason? A control that was always green is a regression guard, not a must-fail control (D-8). |
| **S1** | **Is closure COMPLETE or enumerated?** The author lists the objects they closed. Find one they did **not** — any nested object anywhere in the manifest — and inject an unknown key there. If it is accepted, the fix covers instances, not the class. |
| **S2** | **Wrong-type, not just unknown-key:**`outputPattern` as a number/array/object/null rather than misspelled. Does the closed schema type-check values, or only key names? |
| **S3** | **Empty/degenerate values:**`outputPattern: ""` — does an empty regex match everything and silently neuter the assertion the same way a typo did? The author claims an empty-pattern control; verify it is bound. |
| **S4** | Confirm the registered typo/wrong-type/empty-pattern controls are **genuine red-first** against pre-fix code, and that anything labelled a regression guard is honestly labelled as one. |
| **E1** | Global validation runs **before** per-commit filtering **on every path**, including the HEAD-only path the author calls out. Is there any code path that reaches per-commit assessment without it? |
| **E2** | **Duplicate identity by another key:** the fix makes pipeline NUMBER globally unique. Can two records still collide on a different identity dimension — same commit + different number, same URL, same step-id — and certify the wrong subject? |
| **E3** | "Exactly one gate-verify step per record" — what if a record has zero, or two with different outcomes? Fail closed? |
| **C1** | The three new criteria (`RM02-EVIDENCE-SUBJECT-BINDING`, `RM02-TYPE-STRICT-SCHEMA`, `RM02-HISTORY-BOUNDARY`) are **checked criteria with bidirectionally bound cases**, not prose. Orchestrator observed caseRefs 1 / 3 / 3 — verify the bindings actually run and can fail. |
| **C2** | **B1/B2 satisfied in substance:** does `RM02-EVIDENCE-SUBJECT-BINDING` express D-38 generally ("does this gate bind its evidence to its subject?") or only the one pipeline-number instance? Same for D-40 vs the one typo instance. **A clause that only covers its originating instance is not a clause.** |
| **C3** | **Nothing weakened:** diff `83d2ecb2` → `32b490a7` removes/relaxes no existing case, test, or assertion. |
| **C4** | Exact-head CI terminal-green, full `-f json`, counts stated **including `clone`**; machine-checked with `verify-terminal-green.py --expect-commit 32b490a712a5e8e77f13c40c60099b51feb38994`. |
| **C5** | `Closes #1029` still present (D-38c). |
## Reviewer instruction
Verdict bound to `32b490a712a5e8e77f13c40c60099b51feb38994`, evidence enumerated, posted durably under
your own identity. If a check is unrunnable, **say so** — never substitute a passing variant.
**H1 and S1 are the two I most want answered**, because they ask whether each fix closed a **class** or
an **instance**. Attack outside this set: four of the last five blockers on this PR came from mutating
something nobody had registered.
**Environment note:**`pnpm gate:verify` fails on `checkout-preflight` with outcome 42 (bubblewrap
class) in at least one worktree. If you hit it, report it as an environment limitation — do not treat it
as a finding, and do not let it mask one.
**No one dispatching this review may state a conclusion on an open check (D-39).**
| **A1** | **Is the advance JUSTIFIED?** Can a pre-registry commit on `main` (e.g. `f4fd5967`) satisfy the provenance requirement at all, or is requiring it impossible-by-construction? If impossible, is advancing the seam the _correct_ remedy, or does a correct remedy exist that does not move an author-controlled field? |
| **A2** | **Is the advance MINIMAL?** Was it advanced exactly to the new parent baseline, or beyond it? Does any commit that _should_ remain covered fall outside the new range? |
| **A3** | **Are all 7 branch commits still PROSPECTIVE under the new seam?** Enumerate them and show each is still required to carry provenance. The author claims "own-tree provenance over every registry-era branch commit" — verify the claim, do not accept it. |
| **A4** | ★★ **IS THE SEAM ITSELF CONSTRAINED?** The only validation found is `merge-base --is-ancestor activationCommit head` (`gate-history.mjs:288`). **A commit is its own ancestor.** Determine what `activationCommit = HEAD` does: is the prospective range empty, does the per-commit loop iterate zero times, and does the history check therefore PASS VACUOUSLY? If so, the anti-inert-gate registry contains an author-settable field that can inert its own history check. **Run it. Report the observed exit and whether any failure is raised.** |
| **A5** | **If A4 shows vacuity is reachable, is there a registered MUST-FAIL negative control for it?** RM-02's own founding rule is that a gate with no proven failure path manufactures evidence. Does the registry hold a case that goes RED when the seam is over-advanced? If not, that is a hole in the registry's coverage of itself. |
| **A6** | **Self-verification shape (charter / D-19 / D-39b):** the field was advanced by the change's own author to make the author's gate pass. Independent of whether the value is correct, determine whether the _mechanism_ permits an audited party to relax its own audit, and whether that needs a constraint, an owner, or an escalation. |
## Registry substance — the clauses this PR must now carry
| **B1** | **D-38 clause present and enforced:** the registry asks of every gate _"does this gate BIND its evidence to the subject under review?"_ Ruled in-scope for THIS PR by Mos. Verify it exists as a checked clause, not prose. |
| **B2** | **D-40 clause present and enforced:**_"discriminator and comparison inputs must be TYPE-STRICT."_ Also ruled in-scope for THIS PR. `== 0` matching `False`/`0.0` is the banked instance; the clause is the general form. |
| **B3** | **D-42's clause is CORRECTLY ABSENT** — provider-side negative control tracks separately (Mos: landing it now would give the registry a clause with nothing to satisfy it, going red on its own clause). Confirm its absence is deliberate and recorded, not forgotten. |
| **B4** | **The four founding clauses still hold** (`MISSION.md`): every check proven **right** (red for its own stated reason), the set **covers**, no two criteria **conflict**, and criterion evolution **retains original text + restatement + reason**. |
| **B5** | **Nothing was weakened, skipped, or deleted by the rebase.** Diff `f9746b23` → `83d2ecb2` and confirm no registered case, test, or assertion was removed or relaxed to make the rebase land. |
| **B6** | **`coverageBoundary.excluded[]` is honest in BOTH directions** (charter principle 4): what it does NOT cover is stated beside what it DOES, and the gap is tracked (`trackedBy: RM-54`) rather than implied-fixed. |
| **B7** | **The RM-02 execution boundary** (`gate-history.mjs`, DOES / DOES NOT, owner RM-60, xref RM-59) states its limits in both directions and names a tracked owner — not a documented gap with no owner. |
## Head + CI (re-run these; do not carry them forward from the author's report)
| **C1** | Head `83d2ecb2…` on **both** git and provider; `Closes #1029` present in the body (delivery-issue rule, D-38c). |
| **C2** | Exact-head CI terminal-green by **full `-f json` scan**, counts stated **including `clone`**. Note the count changed 9 → **10** (this PR adds `gate-verify`) — confirm the new step is real, not a miscount. |
| **C3** | **Machine-check it, do not assert it:**`verify-terminal-green.py --expect-commit 83d2ecb2243f1b0987ef2bc14de47f444285a684`. Report exit, `exempted_steps`, `commit == expected_commit`. |
| **C4** | `exempted_steps=0` is expected here — `ci-postgres` succeeded, so the #1000 exemption was **not needed**. Confirm the exemption is present-but-unused rather than silently inapplicable. |
## Reviewer instruction
Verdict bound to `83d2ecb2243f1b0987ef2bc14de47f444285a684`, evidence enumerated per check, posted
durably under your own identity. If a check is unrunnable, **say so** — never substitute a variant that
passes. Scan CI from `-f json`, never default text (D-33); state your counts.
**A4 is the check I most want an answer to and the one I have least confidence about.** Attack outside
this set as well: every blocker found on this mission so far came from mutating something nobody had
registered a check for.
**No one dispatching this review may state a conclusion on an open check (D-39).** Observations may be
relayed to you; verdicts may not. The ruling is yours.
| **R1** | ★ **THE GUARD CAN FAIL.** RM-03 exists because the queue guard is ZERO-INFORMATION (D-23) — it returns pass for every possible input. Prove the rebased head's guard **actually fails** on asserted non-readiness, not merely that its tests pass. This is the whole deliverable. |
| **R2** | ★ **NO QUEUE-GUARD SEMANTIC MOVED IN THE REBASE.** Confirm the range-diff equivalence independently. A queue-guard semantic resolved quietly re-breaks the thing this PR fixes. |
| **R3** | **Union is complete in BOTH directions:** no RM-03 suite lost to main's version, no main suite (esp. `test-terminal-green-contract.sh`) lost to RM-03's. Enumeration count reconciles. |
| **R4** | **Tri-state is real** (`verified` / `written-unverified` / `failed`) — P-WRAPPER-001. Verify an indeterminate result cannot present as a pass; that is the exact defect (`state=unknown exit 0`). |
| **R5** | The guard's **exit-asserting non-null-case** tests are genuine — each fails for its own stated reason against pre-fix code, not merely present (D-8). |
| **R6** | `test:framework-shell` is **runnable to completion in CI** (canonical env). Known: it exits 97 on some hosts via a Bash 5.2.15 `BASH_LINENO` assertion — if you hit that, report it as an environment limitation, do not treat it as a finding and do not let it mask one. |
| **R7** | Exact-head CI terminal-green, full `-f json`, counts stated incl. `clone`; machine-checked with `--expect-commit 868b9b871a5118762aa5b8aafecd2f0592f7ab5c`. |
| **R8** | `Closes #1019` present in the body (D-38c delivery-issue rule). |
| **R9** | Nothing weakened by the rebase: no test, case, or assertion removed or relaxed to make it land. |
## Reviewer instruction
Verdict bound to `868b9b871a5118762aa5b8aafecd2f0592f7ab5c`, evidence enumerated, posted durably under
your own identity. If a check is unrunnable, **say so**.
**R1 is the deliverable and R2 is the risk.** Attack outside this set. **Do not cite the queue guard's
own green as evidence of anything** — it remains inert until this very PR lands (D-23).
**No one dispatching this review may state a conclusion on an open check (D-39).**
| **RR1** | The full 12-case contract harness passes at the exact head: `bash test-terminal-green-contract.sh` | ⇒0, and states 12 cases |
| **RR2** | ★CRUX — the ORIGINAL ATTACK IS DEAD. Take the real `#2188` record, mutate ONLY `commit` to an unrelated 40-hex value, verify against the true expected head | ⇒1, `exempted_steps == 0`, anomaly naming expected vs actual |
| **RR3** | Missing `--expect-commit` cannot be defaulted, inferred, or skipped | ⇒2 (not 0, not 1) |
| **RR4** | Malformed expected commit (short SHA, non-hex, empty) is rejected — no silent normalisation into a pass | ⇒2 |
| **RR5** | A record with the `commit` key ABSENT (not merely different) is rejected — fail-closed on missing, not just on mismatch | ⇒1, `exempted_steps == 0` |
| **RR6** | The genuine artifact still passes when correctly bound: real `#2188` + its true head | ⇒0, `exempted_steps == 1`, exactly one `WP-K8S-1000-CI-POSTGRES-TEARDOWN` |
| **RR7** | ★RED-FIRST, PROVED RETROACTIVELY. The four new cases must FAIL against the OLD verifier at `e7b29219` — otherwise they do not test what they claim (D-8 class). Run the new cases against the previous implementation | new cases ⇒≠0 under `e7b29219` |
| **RR8** | AC2 OF THE PRIOR SET DID NOT REGRESS: both REAL controls stay terminal red — `#2189` (`ci-postgres` exit 1) and `#2191` (exit 137, `test` exit 61) | both ⇒1, `exempted_steps == 0` |
| **RR9** | Still NO fetch / trigger / retry / re-roll / sleep / network of any kind in the verifier or harness. The coin flip must remain removed, not codified (D-21) | grep ⇒ no such call sites |
| **RR10** | The doc/baseline changes REQUIRE the current provider PR head to be passed — they must not merely mention it. Check `merge-gate.md`, `CI-CD-PIPELINES.md`, `woodpecker/README.md` state it as a requirement a gate operator cannot satisfy by omission | reviewer judgement, quote the lines |
| **RR11** | Exemption remains bound to #1000 and retires with it; signature conjunction unchanged and not widened by this fix | diff-scoped, ⇒ no widening |
| **RR12** | Case-sensitivity: an uppercase-hex record commit against a lowercase expected head must NOT silently pass by accident of comparison. State which way it resolves and whether it fails closed | state the observed behaviour |
## Reviewer instruction
Report the verdict **bound to `033b2ffb46674b2c0bcc5197273c109b461f62d9`** and state each check's
observed result, including counts read from `pipeline-status.sh -f json` (never default text — it omits
`clone`, D-33). If any check is unrunnable, **say so** — never substitute a passing variant. Attack
outside this set and report anything it finds; RR7 and RR12 exist because the last blocker was found
| **TS1** | ★RED-FIRST. `exit_code: false` on the real #2188 record is **observed wrongly exempting at `033b2ffb`** (exit 0, `exempted_steps 1`), then blocks after the fix | pre-fix ⇒0/exempt 1 · post-fix ⇒1/exempt 0 |
| **TS2** | ★RED-FIRST. Same for `exit_code: 0.0` | pre-fix ⇒0/exempt 1 · post-fix ⇒1/exempt 0 |
| **TS3** | REGRESSION GUARD. `exit_code: "0"` blocked before AND after — state honestly that it was already green | both ⇒1, `exempted_steps 0` |
| **TS4** | REGRESSION GUARD. `exit_code: null` blocked before AND after | both ⇒1, `exempted_steps 0` |
| **TS5** | ★NOT OVER-TIGHTENED. The genuine artifact — real #2188, real integer `exit_code: 0`, correctly bound head — still passes | ⇒0, `exempted_steps 1`, exactly one `WP-K8S-1000-CI-POSTGRES-TEARDOWN` |
| **TS6** | The strictness sits on the value the EXEMPTION rests on, not on a cosmetic sibling. Show the guarded comparison is the one feeding `exemption_applies` | reviewer quotes the line |
| **TS7** | `bool` is excluded EXPLICITLY, not incidentally. A bare `isinstance(x, int)` still admits `True`/`False` — verify the `not isinstance(x, bool)` clause exists | ⇒ clause present; `true` also blocks |
| **TS8** | Negative control unaffected: a genuine failed step with a real integer non-zero exit still blocks | ⇒1, `exempted_steps 0` |
| **TS9** | NO REGRESSION ON THE PRIOR ROUND'S BINDING WORK: mutated record commit ⇒1; `--expect-commit` omitted ⇒2; record `commit` absent ⇒1 | ⇒1 / ⇒2 / ⇒1 |
| **TS10** | Signature conjunction NOT widened elsewhere by this fix — `POD_NOT_FOUND` / name / type / state untouched | diff-scoped ⇒ no widening |
| **TS11** | Still no fetch / trigger / retry / re-roll / sleep / network | grep ⇒ no call sites |
| **TS12** | Full harness passes at the new head; **state the case count** (12 previously, expected 16 — confirm the actual number rather than the expected one) | ⇒0, count stated |
## Reviewer instruction
Verdict bound to the NEW head, evidence enumerated per check, CI counts from `pipeline-status.sh -f json`
(never default text — it omits `clone`, D-33). If a check is unrunnable, **say so**; never substitute a
passing variant.
**Attack outside this set and report what you find.** Both blockers on this PR so far — the missing
commit binding, and this type confusion — were found outside the registered set, by mutating a field
nobody had registered a check for. That is now the expectation, not a bonus.
**Nobody dispatching this review may state a conclusion on an open check here (D-39).** If you are sent
an observation, it is an observation; the ruling is yours.
Correct for the CI container (runs as root), fatal for EVERY non-root local checkout: `EACCES` on `/root/.local/share/pnpm/store/v10/server/server.json`. A committed config that only works on one runtime is exactly the activation-skew class. Fix candidate: make store-dir env-overridable, not hardcoded.
<!-- board-roll: 2 entries rolled from BOARD.md -->
### **D-3 / P-FLEET-001 — the seats running this mission are UNMANAGED.** `mos-remediation`, `rev-974`,
`planner-opus`, `planner-sol` appear in NO roster (`~/.config/mosaic/fleet/roster.yaml`, `agents/`). Planners run on socket `default`; the roster declares `mosaic-fleet`. This is the exact "one roster-owned socket/host + quarantine unmanaged + stale GC" failure P-FLEET-001 indicts — observed on the remediation mission's own fleet. Prerequisite for INBOX identity-addressing.
### **D-2 / hygiene — husky `prepare` fails `EPERM` copying into root-owned `.husky/_/`.** Repo working
tree has root-owned dirs (`.husky/`, repo root) under a non-root agent. Worked around with the intended `HUSKY=0` escape hatch (does NOT disable the existing pre-commit/pre-push hooks).
<!-- board-roll: 2 entries rolled from BOARD.md -->
### **D-5 / P-QUEUE-001 + P-CONFORMANCE-001 — KEYSTONE: an inert gate that erased its own evidence.**
Merged PR #868 (`b79336a8`) shipped a file that FAILS `pnpm format:check` ⇒ the CI format gate did not block. An unrelated later PR (#872) then reformatted that file via its own `lint-staged`, so `main` went green again and nobody learned the gate had failed to fire. Verified blob-level under the repo's own config. **Detection must be per-merge-commit against that commit's own tree** — a "is main green today" check reports all-clear on this exact defect. Binding on RM-02/RM-55. Full chain in `TASKS.md` §1a. NOT quiet-patched, by Mos's ruling: patching the symptom destroys the signal.
### **D-4 / P-LIFECYCLE + hygiene — a dispatched agent silently IGNORED an in-message context reset.**
planner-sol was at 64.3%/372k; the brief asked it to reset first; it began work on dirty context anyway. Only an out-of-band `/new` driven by the orchestrator guaranteed clean state. Confirms the postmortem thesis: **instructions are not enforcement.** Reset must be a mechanical pre-dispatch step, not a request.
<!-- board-roll: 2 entries rolled from BOARD.md -->
### **D-7 / P-FLEET-001 — stale-GC-on-disk: shared 30G /tmp hit 100% ENOSPC, degrading two seats.**
~5.2G was session scratch dead 8-9 days (this session's own footprint: 88K). Same missing capability as orphaned-tmux-session GC, applied to disk — not a quota or discipline problem. Resolved manually by Mos (lead coordinator) after independent verification; `/tmp` now 79%. **The gap IS the finding:** the authority to reap exists, the deterministic reaper does not. Folded into RM-50 with explicit requirements (mechanical liveness, age threshold, dry-run, audit event per reap — never a heuristic sweep). Refusing to unilaterally delete another session's scratch was correct doctrine; the fix is a reaper, not braver agents.
### **D-6 / P-QUEUE-001 — the mandated queue guard returned PASS on an UNKNOWN state, live, today.**
Running the required `ci-queue-wait.sh --purpose push` before pushing produced `state=unknown ... exit 0` — the exact defect at `ci-queue-wait.sh:282-288` that PR #1023 is parked on. It also evaluated `branch=main` rather than the branch being pushed. The mission's own required pre-push gate passed me on an indeterminate result. Third independent live instance of the class.
<!-- board-roll: 1 entry rolled from BOARD.md -->
### **D-8 / P-CONFORMANCE-001 — a PRE-REGISTERED acceptance check that was not runnable as written.**
PR #1025 AC2's fixture `mkdir -p apps/*/venv/lib` creates a literal `apps/*/venv/lib` dir when the glob is unmatched — it did not test what it claimed. rev-974 ran it exactly as written, caught it, re-ran the intended assertion at an explicit path, and **disclosed** rather than silently substituting a working fixture and reporting PASS. **Pre-registration protects a check from being retrofitted to the implementation; it does not make the check correct.** An unverified gate appeared inside the mechanism built to catch unverified gates. Hard requirement on RM-02: the registry must self-verify that every registered case runs AND can fail — presence is not evidence.
<!-- board-roll: Decisions-log narrative rolled from BOARD.md 2026-08-01 (D-43: meet the
byte budget by ROLLING OUT, never by rewording what stays) -->
### Decisions log — full record in [`TASKS.md`](./TASKS.md)
All 44 findings (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-43 + D-38c in `TASKS.md`) and every ruling with its
rationale live there. **Not duplicated here** — a second copy is a second thing to go stale, which this
board had done three times in one night (gate list, capability registry, DECISION-1 status), and three
more times by the next rotation seam (RM-61 "building", "nothing implemented yet", DECISION-1/2/3
"must be ruled"). The rulings a fresh seat needs are items 4–7 above; they are **not** repeated here,
because that repetition is what went stale.
<!-- board-roll: Sequencing section rolled verbatim from BOARD.md 2026-08-01 (D-43: meet the
byte budget by ROLLING OUT, never by rewording what stays). Canonical: MISSION.md + TASKS.md §5 -->
### Sequencing — see [`MISSION.md`](./MISSION.md)
Builds 1-5, the cross-cutting retirements, and DECISION-1's corrected wire-in target are stated once in
the charter and `TASKS.md` §5. **Not repeated here** — the previous copy of DECISION-1's status on this
board is one of the six stale restatements below.
<!-- board-roll: capability/seat-identity bullets rolled verbatim from BOARD.md 2026-08-01
(D-43: roll out, never reword). Authoritative home: TASKS.md D-11 / D-11a / D-11b. -->
- Capability is **per-path** (D-11b → **superseded in part by D-13/D-15**): a token file is **necessary,
not sufficient**. Three layers — token file (raw-API), `tea` login (tea paths), **repository permission**
(writes). Before dispatch, assert `permissions.push == true`**as that seat**, not token existence and
not a 200 on a read. Mos owns provisioning; escalate missing pairs.
- Seat identity (D-11a): token identity AND `git config user.name`/`user.email` must BOTH be set and
agree. Exporting `MOSAIC_GIT_IDENTITY` alone does NOT fix commit authorship.
| RM-03 queue guard | Jason (re-sync) | ✅ **MERGED**`58b971ab` (#1032), #1019 closed. ⚠ **NOT DELIVERED**: installed guard still the broken one (291 lines / 0 `ASSERTED_NOT_READY` vs main 482 / 5). Re-sync via `mosaic upgrade`, then **prove it blocks a KNOWN-RED pipeline** — **D-51** |
| RM-02 registry ★key | **coder-mos2** | Round 4 @ `fbb61912`. Blocker 2 hit **RM-60 again (D-52, CWE-353)** — seat stopped, both orchestrator AND coordinator had authored the error. Ruled **(b) honest narrowing**; blocker 3 + (d)-strict unchanged. **2 anchors now need RM-60** |
| RM-61 CI exemption | — | ✅ **MERGED**`f4fd5967` (#1033). #1034 closed; **#1000 stays OPEN** (retirement trigger). Exemption is on `main` |
# Adversarial Decomposition — Pragmatic / Shortest-Path Side
**Planner:**`planner-sol`
**Bias:** make one real fleet task pass through one enforced path as early as possible; reuse before building.
**Scope source:**`MISSION.md`, `MACP-WIRING-SCOUT.md`, `BOARD.md`, existing `@mosaicstack/macp`, `packages/coord`, PG/Valkey, Tess durable inbox/outbox, and the Mission Control PRD.
## Executive position
The first useful milestone is **not** “complete Builds 1 and 2.” It is this narrow vertical slice:
> A DB-backed mission task is atomically claimed by `packages/coord`, executed by one Node `@mosaicstack/macp` TaskExecutor, gated, and terminally recorded with identity-bound events and a tri-state mutation result. No `docs/TASKS.md`, `mission.json`, `tasks.json`, Python gate loop, or NDJSON ledger participates.
That slice is **SOL-03 → SOL-04 → SOL-05 → SOL-06 → SOL-07 → SOL-08**, estimated at **72K tokens**, mostly Codex. PG polling is acceptable for this first proof. Redis acceleration follows only after correctness is observable. This is the shortest path that is both dogfoodable and not throwaway work.
- First live choke-point dogfood: ~72K on the hard path; SOL-01 and SOL-02 can run beside it.
- Opus is not justified for planned implementation. Escalate only if an independent security review finds an unresolved architecture-level authority flaw.
- Every row is one PR. Estimates include implementation, focused tests, docs affected by that PR, and one remediation pass—not orchestration/reviewer overhead.
## Gates and critical path
| gate | opens when | proof required before downstream work |
### SOL-02 — Make queue guard fail-safe with exit-asserting tests
- **build:** 1
- **depends_on:** —
- **acceptance criteria (diff-blind testable):**
1. Fixture responses `pending`, `success`, `failure`, no-status, malformed JSON, provider error, and unknown status produce explicitly asserted process exits.
2. Only terminal success/no-active-queue returns 0; unknown, malformed, and transport failure return non-zero with actionable output.
3. A payload larger than 150 KiB is consumed without argv expansion or truncation.
4. At least one mutant changes unknown→success and is killed by the test suite.
### SOL-03 — Complete the canonical MACP contract, not another protocol
- **build:** 1
- **depends_on:** —
- **acceptance criteria (diff-blind testable):**
1.`@mosaicstack/macp` validates typed Task, TaskResult, lifecycle Event, state Claim, and `verified | written-unverified | failed` mutation outcome records.
2. Claims require source, confidence, issued-at, TTL/expiry, refresh instruction, and HMAC integrity; tamper/expiry returns a typed refusal, never partial data.
3. Lifecycle events include launch, mission generation, checkpoint, rotation, recovery, inbox receipt, and terminal disposition while preserving existing task events.
4.`MOSAIC_AGENT_NAME` is required for mutating execution and appears in credential/actor binding; missing identity fails closed.
5. Target metadata requires repository identity, task/record ID, and head or generation where applicable.
- **dogfood seed:** rev-974 identity drift plus the three observed write outcomes.
- **est. tokens:** 8K
- **suggested runtime tier:** codex
### SOL-04 — Add the narrow PG orchestration spine schema
- **build:** 2
- **depends_on:** SOL-03
- **acceptance criteria (diff-blind testable):**
1. Migration up creates mission, task, dependency, task-claim, MACP event, typed state-claim, session-generation, and dispatch-outbox records with tenant/mission keys and uniqueness constraints.
2. The database rejects a task without a mission, a dependency outside its mission, duplicate idempotency keys, and terminal→running regression.
3. Event and claim records reference canonical mission/task/generation identities; claims store integrity metadata.
4. Migration rollback on an empty test DB succeeds; rerunning migration is safe.
5. No comms-specific “universal message” schema is invented here; Build 4 reuses/extends existing interaction inbox/outbox tables.
- **dogfood seed:** mission convention existed but a lane could act with no mechanically valid mission/task.
1. Two concurrent claimers for one runnable task yield exactly one lease owner.
2. Dependencies are evaluated transactionally; an unmet dependency can never be claimed.
3. Claim, state transition, MACP event, and dispatch-outbox append commit atomically or all roll back.
4. Expired leases are reclaimable with a higher fencing generation; stale owners cannot complete or mutate.
5. Querying mission status is derived solely from PG and returns the next runnable task deterministically.
- **dogfood seed:** model-maintained live board and stale claims surviving session changes.
- **est. tokens:** 12K
- **suggested runtime tier:** codex
### SOL-06 — Build the one production Node MACP TaskExecutor
- **build:** 1
- **depends_on:** SOL-03, SOL-05
- **acceptance criteria (diff-blind testable):**
1. A public Node executor accepts only a claimed canonical MACP Task, resolves credentials/identity, runs the worker, runs structured gates, and persists terminal result/events through SOL-05.
2. Worker exit 0 plus a failed gate cannot produce `completed`; worker failure cannot skip terminal ledger emission.
3. Claude, Codex, and Pi fixture backends emit the same runtime-neutral lifecycle sequence.
4. Every mutation returns one mandatory tri-state outcome; callers cannot compile while discarding it.
5. Crash after worker success but before terminal commit leaves a recoverable fenced claim and no false completion.
- **dogfood seed:** stranded MACP, gate-6 inert completion, and `written-unverified` being treated as success.
- **est. tokens:** 16K
- **suggested runtime tier:** sonnet
### SOL-07 — Provide one-shot flat-file import and cutover readiness audit
- **build:** 2
- **depends_on:** SOL-05
- **acceptance criteria (diff-blind testable):**
1. A dry-run parses existing mission/TASKS artifacts, reports unsupported/ambiguous rows, and performs zero writes.
2. Apply is idempotent and records source digests; repeated apply creates no duplicates.
3. Unknown status, dangling dependency, duplicate task ID, and malformed table block import with row-level diagnostics.
4. Readiness reports “cutover-ready” only when imported PG projections exactly match source counts/dependencies/statuses.
5. This command is migration-only; it exposes no dual-write or ongoing sync mode.
- **dogfood seed:** current remediation board/TASKS state needs a clean DB landing without silently losing tasks.
- **est. tokens:** 8K
- **suggested runtime tier:** codex
### SOL-08 — Hard-cut `packages/coord` to PG and dogfood one live task
- **build:** 1
- **depends_on:** SOL-06, SOL-07
- **acceptance criteria (diff-blind testable):**
1.`mosaic coord run/status/continue` reads and mutates PG only; absent/unmigrated DB state fails with the SOL-07 repair path.
2. No fallback reads/writes `docs/TASKS.md`, mission JSON, task JSON, state JSON, results JSON, or events NDJSON.
3. A live canary task assigned to a fleet seat travels PG claim → TaskExecutor → worker → gate → terminal PG result/event and closes only after gate success.
4. Killing the coordinator after claim and restarting it neither duplicates execution nor allows the stale lease to close the task.
5. Evidence query shows actor seat, mission/task, target metadata, gate results, and tri-state outcome.
- **dogfood seed:** this remediation mission itself; reproduce a gate-6-style non-null task and identity-bound write.
- **est. tokens:** 16K
- **suggested runtime tier:** sonnet
> **G1 FIRST-DOGFOOD:** stop and validate here before broadening. If SOL-08 cannot carry a real task, do not build Redis, rotation, comms, or UI.
### SOL-09 — Route Forge and OpenClaw/MACP producers through TaskExecutor
- **build:** 1
- **depends_on:** SOL-08
- **acceptance criteria (diff-blind testable):**
1. Forge and the OpenClaw MACP runtime submit the canonical Task type to SOL-06; neither executes a worker or gate itself.
2. Their success callbacks are derived from canonical terminal results, not local/stub completion.
3. A failed canonical gate is observed identically from Coord, Forge, and OpenClaw fixtures.
4. Repository search plus an executable import boundary test finds no production-local redefinition of Task/TaskResult/GateResult on these paths.
- **dogfood seed:** Forge’s immediate empty-gate completion and the plugin’s redefined MACP-shaped result.
- **est. tokens:** 10K
- **suggested runtime tier:** codex
### SOL-10 — Retire flat-file orchestration and the disabled duplicate rail
- **build:** 1
- **depends_on:** SOL-09
- **acceptance criteria (diff-blind testable):**
1. The Python controller execution/gate/event path, `tasks_md_sync`, plugin-local protocol types, orphaned context loader, and production flat-file orchestration writers/readers are absent from shipped assets.
2. Framework guides/templates/startup context point to DB mission commands, not `docs/TASKS.md` as orchestration SoR.
3. A regression scan fails CI if production code reintroduces `events.ndjson`, `tasks.json`, `mission.json`, or `docs/TASKS.md` orchestration mutation.
1. With Redis/broker unavailable, a diagnostic/bootstrap command can inspect PG mission state, repair broker configuration, and resume without traversing the broker gate.
2. Normal recovery remains broker-gated and is labeled as such.
3. Break-glass requires explicit scope and expiry, emits a durable event, displays a loud banner, and auto-expires; permanent/silent bypass text or behavior is absent.
4. The Pi-brick fixture recovers the broker, then returns to normal gated operation without editing source/config by hand.
5. Orchestrator guidance removes “/compact and continue” only after the rotation command is available; ephemeral guidance remains explicit.
- **dogfood seed:** Pi brick and silent `MOSAIC BYPASS 2026-07-22`.
- **est. tokens:** 12K
- **suggested runtime tier:** sonnet
### SOL-17 — Converge each host on one roster-owned lifecycle domain
- **build:** 5 (hygiene; hard prerequisite for addressed comms)
- **depends_on:** SOL-16
- **acceptance criteria (diff-blind testable):**
1. Reconcile establishes exactly one roster-declared tmux socket/lifecycle domain per host.
2. Unknown sessions are reported and quarantined; they are never killed without positive unmanaged classification.
3. Max-age/max-context stale sessions invoke SOL-15 rotation for persistent seats or reap for ephemerals.
4. Seat identity survives respawn and equals the roster/MOSAIC_AGENT_NAME binding.
5. A fixture matching the current four unmanaged remediation seats converges them or produces explicit quarantine actions.
- **dogfood seed:** scout-bounce and BOARD D-3 seats split between default and `mosaic-fleet` sockets.
- **est. tokens:** 14K
- **suggested runtime tier:** codex
### SOL-18 — Publish authenticated `comms/v1` envelope and compatibility rules
2. Current and immediately previous supported protocol versions are accepted; unsupported versions are rejected loudly with supported range.
3. Framework/runtime version is diagnostic metadata and never the compatibility key.
4. Forged sender, changed recipient/payload, expired envelope, and replay with conflicting content fail closed.
- **dogfood seed:** wrong-socket bare tmux message with no authoritative sender/recipient receipt.
- **est. tokens:** 8K
- **suggested runtime tier:** codex
### SOL-19 — Build the logical PG-first comms service with tmux adapter
- **build:** 4
- **depends_on:** SOL-18
- **acceptance criteria (diff-blind testable):**
1. Sending commits envelope/payload and PENDING state in PG before adapter delivery.
2. State machine enforces PENDING → RECEIVED → CONSUMED or DEAD-LETTER; illegal regressions are rejected.
3. Recipient-filtered claims and append/coalesce policy are deterministic by message class.
4. tmux is a dumb adapter: delivery failure changes no PG authority state and is retryable.
5. Existing Tess durable repository/state-machine patterns are extended or generalized; no new deployable microservice or second inbox framework appears.
- **dogfood seed:** MACP scout bounce that was discovered only by manual liveness check.
- **est. tokens:** 16K
- **suggested runtime tier:** sonnet
### SOL-20 — Make `agent-send` use the sole path and prove stale-message handling
- **build:** 4
- **depends_on:** SOL-19
- **acceptance criteria (diff-blind testable):**
1. Normal `agent-send` creates a comms/v1 record and observes RECEIVED/CONSUMED; it cannot directly invoke tmux.
2. A wrong/missing socket leaves PENDING with retry diagnostics, then reaches RECEIVED after roster repair without resending.
3. A stale coalescible message arriving after a newer terminal message is marked superseded/consumed and is not surfaced as live work.
4. Duplicate identical send is idempotent; same ID with changed content is rejected.
1. Operator docs give exact DB import/cutover, rollback-before-cutover, recovery, break-glass expiry, rotation, comms, quarantine, and conformance commands.
2. Link/command checks find no orchestrator instruction to mutate flat-file mission/tasks, use silent bypass, direct-tmux normal comms, or “compact and continue” a persistent seat.
3. A clean non-root install activates one coherent version and runs the conformance smoke subset.
4. Release evidence maps all 15 decisions and every live seed to a passing check or an explicit deferred item below.
- **dogfood seed:** activation skew plus the tendency to leave built fixes unwired or undocumented.
- **est. tokens:** 6K
- **suggested runtime tier:** codex
## Explicit DEFER list (10)
These are not rejected; they are **past first dogfood** and should not delay G1/G2. Each is gold-plating unless a live failure makes it necessary.
1.**DEFER — Mission dashboard/TUI views.** CLI/DB queries are enough to operate and prove the spine.
2.**DEFER — PRD-to-board automatic decomposition.** This is LLM/judgment-heavy and unrelated to enforcing already-decided tasks.
3.**DEFER — General heuristic churn scoring.** Implement token threshold + compaction sensor first; repeated-tool-loop inference can follow measured need.
4.**DEFER — Discord comms adapter.** Existing plugin reach remains; migrate only after tmux+Matrix prove the service contract.
5.**DEFER — Slack comms adapter.** No current dogfood dependency.
6.**DEFER — Telegram comms adapter.** No current dogfood dependency.
7.**DEFER — Public MCP comms surface.**`agent-send` and service API are sufficient for the mission proof.
8.**DEFER — Protocol-v2 features/general negotiation framework.** Ship v1 with a bounded current/previous acceptance window; do not predict v2.
9.**DEFER — Multi-region/HA PG or Redis.** Existing in-stack PG+Redis and rebuildability satisfy current failure classes.
10.**DEFER — Event analytics/search UI and long-term warehouse.** Indexed PG evidence plus CLI queries is enough for audit/conformance.
| Canonical Node `TaskExecutor` | **JUSTIFIED:** explicitly required single choke point; wraps existing MACP functions rather than replacing them. |
| PG repository methods | **JUSTIFIED but narrow:** ordinary adapters around existing Drizzle/DB patterns, not a new “state platform.” |
| Rotation daemon | **JUSTIFIED:** finishes `packages/coord`; do not revive `apps/coordinator` or create another service. |
| Comms service | **JUSTIFIED only as a logical in-process boundary:** reuse Tess durable inbox/outbox and existing connectors; no new deployable microservice this cycle. |
| Universal queue/broker abstraction | **SUSPECT / DO NOT BUILD:** reuse `packages/queue`, PG outbox, and Redis Streams/BullMQ configuration already present. |
| Universal envelope/state framework | **SUSPECT / DO NOT BUILD:** MACP Task/Claim/Event and comms/v1 have different bounded purposes. |
| Generic compatibility-negotiation engine | **SUSPECT / DEFER:** a small supported-version check meets v1 needs. |
## Dissent (7)
1.**Do not wire new production behavior into `mosaic_orchestrator.py::run_single_task`.** The scout correctly identified the duplicated block, but BOARD’s later ruling says the disabled Python rail is residue and must be retired. Building a Node bridge only to delete it is throwaway. Put the Node TaskExecutor in `@mosaicstack/macp`, route the live Coord path to it at SOL-08, migrate remaining producers at SOL-09, then delete the Python block at SOL-10.
2.**Redis is not on the first-dogfood critical path.** PG claim/polling is sufficient for one real task and exposes correctness earlier. Add Redis only after G1; otherwise queue debugging obscures whether the choke point works.
3.**“One choke-point service” does not justify a new deployable service.** An exported executor plus Coord daemon is enough. A new Nest app, RPC protocol, deployment, auth layer, and health plane would be greenfield.
4.**The Mission Control PRD’s file-first and board-regeneration assumptions are superseded.** Keep its mission/rotation semantics, but obey the accepted hard DB cutover; do not implement its file-first milestones or PRD-to-board generator now.
5.**Do not gate every interactive runtime launch as if it were a mission task.** Enforce every tracked task/data mutation at the executor/DB authority boundary. Ephemeral interactive shells may launch, but receive no task mutation authority unless attached to a valid claim.
6.**Do not implement broad “churn intelligence.”** Token threshold and compaction-detected are deterministic sensors. Repeated-loop semantic detection is expensive, noisy, and premature until telemetry demonstrates a gap.
7.**The 100-rotation test is a final conformance bar, not an early unit-test tax.** First prove one rotation, then fault cases, then 100 repetitions in SOL-24. Requiring 100 before G3 would delay feedback without changing the design.
## Orchestrator reconciliation notes
- Pre-register each task’s acceptance checks from this document before showing implementation diffs to its reviewer. Author and reviewer remain different seats.
- SOL-07 permits a one-time import, **not** an interim store: no shadow writes, dual reads, or sync daemon.
- G1 is the budget escape hatch. If the 72K hard-path slice does not work, stop and remediate instead of spending the remaining ~222K.
- Docs belong in each behavior-changing PR where required; SOL-25 is cross-link/cutover validation, not permission to postpone essential docs.
**Scope:**`/src/mosaic-stack` inspected at HEAD `b79336a8c11e2a4646a47ff8d295a226e0c71404`; read-only. Existing dirty/untracked state was not touched.
## Verdict
**(c) STRANDED.** `packages/macp` is exported, unit-tested, and registered as a CLI command group, but no production dispatch/execution code invokes its credential resolver, gate runner, or event emitter.
A separate MACP-named OpenClaw/orchestrator rail exists, but it redefines task/result types and gate/event logic instead of importing `@mosaicstack/macp`; direct `mosaic yolo|claude|codex|opencode|pi` also bypasses it.
| Unified CLI | `packages/mosaic/src/cli.ts:8,385` | Imports and registers `registerMacpCommand`; no task/gate/event execution. |
| Forge | `packages/forge/src/types.ts:1,17,68,79` | **Type-only** imports of `GateEntry` and `TaskResult`. Pipeline calls an injected abstract executor at `packages/forge/src/pipeline-runner.ts:189-190,299-300`, not MACP. |
| Agent | No match under production `packages/agent/src/**` | No MACP import/call. |
| Coord | No match under production `packages/coord/src/**`; dependency list is only `@mosaicstack/types` at `packages/coord/package.json:25-27` | No MACP import/call. |
| Plugins | No `@mosaicstack/macp` import under `plugins/**` | No package use; the MACP-named plugin is an independent implementation (below). |
**Repository-wide production call-site search result:** excluding `packages/macp/**`, tests, worktrees, and build output, there are **zero** calls to `runGate`, `runGates`, `emitEvent`, `appendEvent`, or `resolveCredentials`.
### `packages/macp` implementation is internally connected only
- Public exports: `packages/macp/src/index.ts:1-48` exports Task/GateEntry/MACPEvent/TaskResult, credential resolution, `runGate(s)`, risk-floor, and event emission.
- Gate runner calls its own event emitter: `packages/macp/src/gate-runner.ts:187-236`.
- Event persistence implementation appends NDJSON to a caller-supplied path: `packages/macp/src/event-emitter.ts:11-27`.
- There is **no exported programmatic `submit` implementation** in `packages/macp/src/index.ts:1-48`; only the CLI placeholder named `submit`.
- Runtime commands dispatch directly to harness launch: `packages/mosaic/src/commands/launch.ts:730-801`.
- Claude/Pi go through the lease broker, then spawn the runtime: `packages/mosaic/src/commands/launch.ts:817-843`.
- Commander wiring sends `mosaic yolo <runtime>` and direct runtime commands to `launchRuntime`: `packages/mosaic/src/commands/launch.ts:1102-1157,1165-1167`.
- None of those ranges imports/calls `@mosaicstack/macp`, `runGates`, or `emitEvent`.
**Result:** a direct `mosaic yolo`, `mosaic claude/codex/opencode/pi`, or underlying exec does not create a typed MACP Task, run the package gate-runner, or append a package MACPEvent.
### Coord bypasses MACP
- Coord reads/updates `docs/TASKS.md`: `packages/coord/src/runner.ts:6,306-386`; parser/writer is `packages/coord/src/tasks-file.ts:326-377`.
- Coord launches a child process directly: `packages/coord/src/runner.ts:397-427`.
- Mission state is its own `.mosaic/orchestrator/mission.json`/`next-task.json`: `packages/coord/src/mission.ts:8-12`; `packages/coord/src/runner.ts:15-16,355-384`.
**Result:** Coord task execution has no MACP Task validation, package gate runner, or event append.
### Forge bypasses MACP execution
- Forge defines its own `ForgeTask` and abstract `TaskExecutor`: `packages/forge/src/types.ts:48-80`.
- The production CLI injects a **stub executor** that immediately reports completion with empty gates: `packages/forge/src/cli.ts:13-31,167,185`.
**Result:** even `mosaic forge run` does not execute MACP gates or persist MACP events.
### Separate MACP-named rail is not `packages/macp`
- OpenClaw plugin registers an ACP backend named `macp`: `plugins/macp/src/index.ts:1-18,72-102`.
- It locally redefines `OrchestratorTask`, `TaskResult`, and gate-result shapes instead of importing package types: `plugins/macp/src/macp-runtime.ts:43-77`.
- It appends directly to `.mosaic/orchestrator/tasks.json`, triggers an external controller, and polls `results/<task>.json`: `plugins/macp/src/macp-runtime.ts:290-329,437-483`.
- The controller independently implements `append_event`, `emit_event`, shell execution, gate execution, and results: `packages/mosaic/framework/tools/orchestrator-matrix/controller/mosaic_orchestrator.py:29-91,126-276`.
- Its gate loop runs raw string gates after worker success: `mosaic_orchestrator.py:213-235`; it does not support the package's structured `GateEntry`/AI-review behavior.
- Current checkout disables this controller: `.mosaic/orchestrator/config.json:2` (`"enabled": false`).
- Plugin references `tools/macp/dispatcher/pi_runner.ts` at `plugins/macp/src/macp-runtime.ts:85-91`, but `tools/macp/` does not exist in this checkout.
**Result:** there is a parallel, optionally enabled MACP-shaped rail, not package integration. It cannot make `packages/macp` the enforced path.
## 3. Event ledger status
- Package persistence exists only as a library primitive: `packages/macp/src/event-emitter.ts:11-27` appends JSON lines to an arbitrary `eventsPath`.
- Package event emission is reached only from package `runGates`: `packages/macp/src/gate-runner.ts:204-236`.
- No production caller invokes package `runGates/emitEvent/appendEvent`; therefore no runtime destination path is configured for the package ledger.
- Test-only ledgers use temp paths: `packages/macp/__tests__/event-emitter.test.ts:35-133`; gate tests use temp `events.ndjson`: `packages/macp/__tests__/gate-runner.test.ts:171-242`.
- The separate Python controller writes `.mosaic/orchestrator/events.ndjson`: `mosaic_orchestrator.py:129-133,159-161,219-235`; the Mosaic Framework plugin only **reads** that file for context at `plugins/mosaic-framework/src/index.ts:279-316,430-438`.
- In this checkout, `.mosaic/orchestrator/events.ndjson` is absent and the controller is disabled (`.mosaic/orchestrator/config.json:2`).
**Conclusion:**`MACPEvent` from `packages/macp` is defined/tested but not emitted or persisted by live production call sites. The similarly shaped Python ledger is a duplicate island.
## 4. Coord link
-`packages/coord` has no `@mosaicstack/macp` dependency/import: `packages/coord/package.json:25-27`; no matches in `packages/coord/src/**`.
- Coord's task model is Markdown `docs/TASKS.md` plus mission/session JSON: `packages/coord/src/tasks-file.ts:1-10,257-377`; `packages/coord/src/mission.ts:8-12`; `packages/coord/src/runner.ts:306-427`.
- It does not consume `.mosaic/orchestrator/events.ndjson`, MACP Task, MACPEvent, GateEntry, or TaskResult.
**Conclusion:** Coord and `packages/macp` are disconnected islands.
## Shortest wiring gap
**Single integration point:** replace the duplicated execution/gate/event block in `mosaic_orchestrator.py::run_single_task` (`:126-276`) with one production Node `TaskExecutor` backed by `@mosaicstack/macp` (typed Task validation + `resolveCredentials` + `runGates` + `emitEvent`), and make Coord/Forge/OpenClaw submit through that executor. This queue/controller choke point is where `yolo|acp|exec` worker outcomes can be gated and journaled before completion is recorded.
- MACP wiring scout (verdict c=STRANDED): [`MACP-WIRING-SCOUT.md`](./MACP-WIRING-SCOUT.md) (copied into this dir; TODO discharged). Its findings are sound; its _recommended wire-in point_ is superseded by DECISION-1.
## The plan — 15 proposals collapse to 4 builds + hygiene
| **1. One choke-point service** (mechanical enforcer) | MISSION, STATE, AUDIT, WRAPPER, QUEUE | Deterministic program every task/data mutation flows through. **Wire the stranded `@mosaicstack/macp`** — typed tasks, gate-runner, event ledger, credential binding, tri-state write outcomes. ⚠ **Target CORRECTED 2026-07-31 (DECISION-1, Mos):** a new production Node `TaskExecutor` on the **live** dispatch path (`packages/mosaic` launch + `packages/coord`), which Coord/Forge/live-dispatch submit through. **NOT**`mosaic_orchestrator.py::run_single_task` — that controller is `"enabled": false` and references a dispatcher absent from this checkout; wiring it would strand the executor, reproducing this mission's own disease. The Python rail is **deleted**, not ported. Both planners reached this independently. |
| **2. One durable spine + hot path** | (storage under everything) | **PG system-of-record + Redis hot queue** (transactional-outbox). Mission/tasks/state-claims/audit-ledger/comms-inbox all land here. |
| **3. Rotation lifecycle** (finish the Mission Control Plane) | LIFECYCLE, CONTRACT, GUIDE, RECOVERY | Coordinator daemon: contract-hash binding, compaction-detected → rotate-not-compact, checkpoint→fresh-session→rehydrate, broker-independent recovery. Deterministic, not an LLM. Reuse `packages/coord`; existing PRD at `docs/mission-control/`. |
| **4. Comms service** | AUTHORITY, INBOX (+ versioning roadmap) | Envelope (comms/v1) → sole-path service → PG/Redis → pluggable adapters (tmux→Matrix/Discord/Slack/Telegram). Version the protocol, not participants. |
| **+ Hygiene & proof** | FLEET, WORKFLOW, CONFORMANCE | One roster-owned socket/host + stale GC; allowlist auto-sync; the conformance harness that fault-injects the failure classes and proves builds 1–4 hold. |
## Why Builds 1–2 are necessary — two independent impossibility proofs
**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 that needed it — and both times the only resolution was an authority _outside_ the audited
party's control, which is precisely what Builds 1–2 provide.
| | the audited party controls… | so what fails | found as |
8.**P-WRAPPER-001** accept — identity derives from seat name + survives respawn; tri-state write outcomes MANDATORY; name safe target metadata.
9.**P-CONTRACT-001** accept — bind session to contract hash; re-anchor on policy-change OR compaction-detected; stale generation loses authority MECHANICALLY.
10.**P-INBOX-001** MODIFY — sole-path comms SERVICE; PG durable SoR + Redis hot queue (outbox, reconciliation sweeper); pluggable adapters; protocol-first, PG-first-then-Redis.
12.**P-GUIDE-001** accept — delete `/compact and continue` from orchestrator path (keep for ephemeral); removal = substitution (wire rotation trigger).
13.**P-FLEET-001** accept — one roster-owned socket/host; quarantine unmanaged; stale-session GC; prerequisite for INBOX identity-addressing.
14.**P-WORKFLOW-001** accept — auto-sync ALLOWLIST not denylist; worktree/lease isolation for agent docs/source; DB-tracking obviates the flat-file-sweep criterion.
15.**P-CONFORMANCE-001** accept — fleet lifecycle harness on REAL runtime artifacts + fault injection; the 100-rotations-lossless bar is a test; target the DB substrate.
## Fleet operating model
- **Project orchestrator** `mos-remediation` (this seat) owns the mission; coordinates under Mos (lead).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
mos-dt-0andMos