stack/agents/filbert/work/queue-as-data-plan-2026-09-26.md

Queue as data (#1508, QUEUE rows 9–13): build plan

Author: Filbert (T3 thread 9cb9731e), for Sage (lead). Planning only; no source edits. Written 2026-09-26 against HEAD 43d7574d plus the shared uncommitted tree. Brief: docs/plans/2026-09-13_queue-as-data.md.

Evidence was gathered read-only. Two read-only Gitea calls were made (GET user, GET issues/N for the issues the queue references).

Section 8 is the active specification (round 6). Where sections 0–7 differ from it, section 8 wins; sections 0–7 are kept as the record of how the design got here.

0. Status (updated 2026-09-26)

Round 6: Rocko's round 5 (agents/rocko/work/queue-as-data-adversarial-r5-2026-09-26.md, 3b031a70…177e) returned "revise" with two medium findings. G1: Gate G pinned session evidence that Pi hasn't written yet. G2: matching hook bytes don't prove the guard runs. Section 8 answers both (8.11, 8.12), and 8.19 maps them. No owner ruling was needed.

Round 5: Rocko's round 4 (agents/rocko/work/queue-as-data-adversarial-r4-2026-09-26.md, fcb8933d…efcff) returned "revise", with the lead choices accepted and five residuals, F1–F5. Section 8 answers them, and 8.18 maps each one. Jason's per-seat token ruling for D is in 8.9. No new owner ruling was needed.

Round 4: Rocko's round 3 (agents/rocko/work/queue-as-data-adversarial-r3-2026-09-26.md, 13a32804…a274) returned "revise", with findings T1–T8 and the architecture and rulings accepted. Section 8 now answers them, and 8.17 maps each one. Lead-level choices for Sage are listed at the end of 8.15. No new owner ruling was needed.

Round 3: Rocko's round 2 (agents/rocko/work/queue-as-data-adversarial-r2-2026-09-26.md, b3a2d72a…e70f4) returned "revise". Section 8 applies Sage's direction: fail closed, manual recovery verbs, one host, canonical checkout only. One departure is stated in 8.0: the log lives inside queue.json, so there is no journal file to tear. Sage, deciding as lead on Jason's instruction, has ruled on every open item, Q1–Q4 and J1–J9 (8.15). The round-2 text below about nine items, the journal file and incarnation is superseded.

Sage (lead) reviewed this plan and decided Q5–Q9 and the transition fixes in 5.3 and 5.4 (see section 4, "Decided"). Q1–Q4 are the open set. Sage is holding them for Jason until his next-phase target arrives, since that target may settle Q2.

Build assignment: not yet made. Rows 9–13 wait for row 6 to close and for Jason's target. When they open, the brief's split stands: Darkwing builds, Filbert reviews. Sage may move Filbert to author if Darkwing is still on row 6.

What each open question gates:

Open	Gates	Buildable before the ruling
Q1 Gate G wording	Gate G only	A, B, C, D, E
Q2 T3 identity and runtime	Gate G; next with no seat argument	A (refuse without identity), B, C, E
Q3 automatic commit	A's write path	A with no commit step (recommendation changed, section 7)
Q4 posting identity	D	A, B, C, E

Round 2 (2026-09-26): Rocko's adversarial review (agents/rocko/work/queue-as-data-adversarial-2026-09-26.md, SHA-256 df433f93…2cbf5c, reviewed this plan at 59d5a22f…) returned "revise" with 14 findings. Section 7 disposes of each. Sage amended Q6 (per R9) and Q7 (per R8). The Q3 recommendation has changed: no automatic commit. Section 7.2 lists nine further items that need Jason (J1–J9), plus the two Sage is already holding for him (reduced liveness gate, E before D).

1. Build order and dependencies

row 6 closes (Gate F or blocked)
  └─ A  queue record + CLI + render + migration      (row 9)
       ├─ C  brief template + `add` brief refusal     (row 11, ships inside A's round)
       ├─ B  AGENTS.md + CONTEXT.md point at the command (row 10)
       │     └─ Gate G demonstration (verifies A and B)
       ├─ D  review request posted by `move in-review` (row 12; needs identity ruling Q4)
       └─ E  ledger queue section                     (row 13; Q6, Q7 decided)

• A first. Every other piece reads or writes queue.json.
• C with A. The --brief must exist refusal is A's code. The template is one file. Shipping them separately would mean a second review round on the same CLI for one check.
• B after A, before Gate G. Gate G tells the seat the command directly, so it could technically pass without B. Running it after B also verifies B, which the brief says Gate G does.
• D and E are independent of each other in code. The brief says A to E ship in order, so E follows D unless Jason allows E first while Q4 holds D (R14, needs Jason). E's rulings (Q6, Q7, as amended) are decided.
• A is larger than the brief's "one commit-sized scope" after round 2: the journal, lock and verify (7, R1/R3) roughly double it. It may land as two commits under one row: A1 = journal, lock, CLI and verify; A2 = migration, render and dispatch. Sage's call.
• Migration is part of A. The 25 current rows and the parked table have to become queue.json in the same commit that makes QUEUE.md a rendered view. Otherwise there are two sources of truth.

2. Files and packages per piece (as the code stands today)

A (+ C)

New:

• packages/queue/package.json: same shape as packages/seat/package.json (type: module, engines.node >=24, test: node --test tests/, no deps).
• packages/queue/src/queue.mjs: schema validation, transition table, next, render, and the journal/lock/verify protocol in 7.1 (R1, R3). This replaces the earlier "atomic write under a lock file".
• docs/plans/queue.log.jsonl: the append-only operation journal (7.1).
• packages/queue/src/cli.mjs: list, next, add, move, assign, note, render, plus render --check (see 5.9). Exit codes follow seat: 0 ok, 1 operation failed, 2 invalid data/refused transition, 4 usage.
• packages/queue/tests/queue.test.mjs and tests/fixtures/.
• packages/queue/README.md.
• docs/plans/queue.json: the migrated rows.
• docs/plans/BRIEF-TEMPLATE.md (C).
• scripts/test-queue.sh: see 3.A. Package tests for seat, ledger, control-board and webui are in no suite script today. Nothing but a manual node --test covers them, so "commit only after suites are green" does not cover them either.

Changed:

• scripts/mosaic: today it is exec node packages/seat/src/cli.mjs "$@" with no dispatch. It needs queue) exec node packages/queue/src/cli.mjs and a fallthrough to seat. launch and seat task behavior must stay byte-identical, because every agents/*/launch.sh and scripts/test-{darkwing,rocko}-launch.mjs go through it.
• docs/plans/QUEUE.md: marker comments around the Pieces table. The hand-written header stays above the markers, minus the "Current owner priority" paragraph, which after replaces (Q8). The parked table's items become parked rows (Q9). The log of table changes stays below the markers, frozen as history (5.12).
• Row 7 (weekly ledger run) leaves the queue (Q9). A's scope excludes packages/ledger, so A leaves a one-line hand-written pointer to the weekly routine below the markers. E moves the routine into packages/ledger/README.md and removes the pointer.
• docs/TOOLS.md: usage lines. This file carries other owners' uncommitted changes; add a scoped patch the way #1511 did.

B

• AGENTS.md lines 112–117 (Cadence) and 190 (pointer).
• agents/{darkwing,dewey,filbert,rocko,sage}/CONTEXT.md: each has a line sending seats to docs/plans/CURRENT.md "to reconcile ownership and existing gates" (darkwing/dewey/filbert/sage line 18, rocko line 15). Researcher has no such line. The brief says agents/*/AGENTS.md, but no seat has one; the files are CONTEXT.md.
• Out of B's scope, noted for Sage: agents/filbert/SOUL.md and CONTEXT.md still name Darkwing as team lead.

D

• packages/queue/src/{queue,cli}.mjs: move ID in-review builds and posts the request comment, then records the comment id on the row.
• scripts/gitea-api.sh is unchanged if the identity comes from MOSAIC_GITEA_CREDENTIAL_FILE, which it already honors (see Q4).
• packages/queue/README.md, docs/TOOLS.md.

E

• packages/ledger/src/ledger.mjs (new queueChecks), src/cli.mjs (section above the weekly table, --json key), tests/ledger.test.mjs, README.md (counting rules for the new section, and the weekly routine that was row 7).
• One more Gitea call, state=open, one page; a full page fails as today (Q7). Referenced issues absent from that list count as closed.
• Reads docs/plans/queue.json through the queue validator by relative import (../../queue/src/queue.mjs). There are no workspaces, so a bare @mosaic/queue import would not resolve (R14).
• Reads registrations with loadRegistrations imported relatively from packages/control-board/src/scan.mjs, the way scan.mjs already imports ../../seat/src/seat.mjs. It is not moved, so no ownership expands. Liveness classification is E's own code (R9, 7.1).

3. Tests that prove each piece

A

• Schema: every field and type, id uniqueness, id never reused after deletion (the CLI never deletes a row; test that no verb can), blockedReason required iff blocked, unknown field refused, owner outside the allowed set refused, after naming a missing id or itself refused, a dependency cycle refused, required a boolean, state: "required" refused.
• Transitions: a table-driven test with one fixture per allowed edge and one per refused edge. Refusals must write nothing (file hash unchanged) and print exactly one stderr line with exit 2. Includes in-review→in-progress (allowed), and parking a row with required: true (refused).
• Authority: a seat moving another seat's row is refused. jason and sage may move any row (Q5). coordinator as an owner may move only its own rows. A missing identity (no MOSAIC_AGENT_NAME, no --by) is refused.
• next: picks in-progress, then in-review, then briefed, each by id, not file order (shuffle the fixture array); skips rows whose after dependencies are not done (Q8); never returns parked; prints nothing with exit 0; the reviewer case (5.11).
• Render: byte-stable (render twice, compare), idempotent over an unchanged file, | and newlines in text escaped. Only the marker region changes, so a hash of the header and footer bytes is unchanged.
• render --check: exits 2 when the table between the markers was edited by hand.
• Concurrency and recovery: superseded by 7, R1 and R3 acceptance lists (races through both checkout paths, kill at every step, dead lock holder, disk errors, hand-edited valid JSON, forks).
• Migration: a fixture of today's QUEUE.md table migrates to a valid queue.json. The rendered table matches a reviewed golden file.
• Dispatch: scripts/mosaic launch and seat task produce the same argv/env capture as before (reuse the capture pattern in scripts/test-darkwing-launch.mjs).
• C: add --brief missing/path.md refused, add --brief docs/plans/X.md#Section accepted when the file exists (the section is not verified; say so in the README).
• scripts/test-queue.sh runs the above plus render --check against the real docs/plans/queue.json, so the committed queue is validated by a suite.

B

• grep -n "CURRENT.md" agents/*/CONTEXT.md shows no "what now" pointer. AGENTS.md cadence names the command.
• agents/<seat>/launch.sh --check still passes for every seat, since context files feed the launch snapshot.

D

• A fake Gitea tool, injected the way readIssues(root, range, tool) already allows in ledger. move in-review posts exactly one comment, built from row fields and --candidate. A post failure leaves the row unchanged, exits 1 and prints one stderr line. No file is created under docs/plans/reviews/ or agents/*/work/.
• Identity: the comment is posted with the credential file the ruling names. The test asserts that the default ~/secrets/mosaic.gitea.json is refused.

E

• Fixtures: queue.json, an open-issue list and a registrations dir. One test per rule, both pass and fail, including a multi-row issue (5.10). A seat with no registration appears on its own labeled line and is not counted as a violation (Q6). A full page from the state=open call fails the run (Q7). Violations appear above the table in text and under a queue key in --json. Zero violations prints a "queue: 0 violations" line, not nothing, so an absent check is distinguishable from a clean one.

Gate G demonstration

Setup (Sage or Darkwing, before Jason watches):

1. One real row in briefed state, owned by the test seat, with an existing brief written from BRIEF-TEMPLATE, and no other row that seat owns in in-progress, in-review or briefed.
2. The seat starts with no prior session: agents/<seat>/launch.sh --fresh in its tmux pane. The Pi launcher exports MOSAIC_AGENT_NAME and writes the registration, so the board shows the seat. A T3 thread does neither (Q2).

Run: Jason sends exactly run \scripts/mosaic queue next` and do it` (Q1).

Pass evidence: superseded by 7, R5. The earlier version relied on the ledger's Table 2 count, the git log and "first file read is the brief". Rocko showed that all three can pass with extra human help or no work.

4. Questions

Open, for Jason (Q1–Q4; Sage is holding these until the next-phase target)

Q1. The mosaic name collides. On this host, mosaic on PATH is ~/.npm-global/bin/mosaic 0.0.50-next, the estate CLI. It already has a queue command group ("Manage Mosaic job queues": list, drain, pause, stats…), so mosaic queue next prints error: unknown command 'next' and mosaic queue list would run the estate's job-queue listing. The repo CLI is reachable only as scripts/mosaic (its own header says so). Recommend: Gate G's sentence becomes run `scripts/mosaic queue next` and do it. It needs no PATH change and does not touch ~/.mosaic or the npm-global install. Renaming the repo CLI is the alternative, but it is larger and gains nothing until the estate CLI is retired.

Q2. Which runtime runs Gate G? Development runs in T3 now. T3 threads set no MOSAIC_AGENT_NAME, write no registration, and are not on the board. This thread confirms it: the variable is absent. queue next with no seat argument therefore cannot know who is asking. Recommend: run Gate G on a Pi launcher (agents/<seat>/launch.sh --fresh), which sets identity and registers, so Jason can watch from the board as the brief says. Separately, decide whether T3 seats should export an identity. Until then, next with no seat and no env refuses rather than guessing.

Q3. Who commits queue.json? The brief says the file is committed, and the CLI writes it on every verb. In one shared checkout, an uncommitted queue.json gets swept into whichever seat commits next. That is the exact failure the brief cites. QUEUE.md is dirty in the tree right now. Recommendation changed in round 2 (R2): no automatic commit. The first version recommended git commit -- docs/plans/queue.json docs/plans/QUEUE.md after each write. It was withdrawn for three reasons:

• A path-limited commit takes the whole file, so another author's uncommitted edit to QUEUE.md's hand-written header goes into the queue's commit.
• An ordinary git commit -a from another seat does not honor the queue lock and can still take the queue files between a write and its commit.
• My claim that "the validator means invariant 8 holds" was false. Schema validation is not the applicable suite.

New recommendation: the CLI never commits. The lead commits the queue files (queue.json, queue.log.jsonl and the rendered table) at gate points, by explicit path, after scripts/test-queue.sh passes, as QUEUE.md is committed today. The journal (7.1) keeps every operation between commits, so no history depends on commit timing. If Jason still wants automatic commits, R2's preconditions are the minimum:

• the queue paths are clean against the last queue revision;
• nothing is staged on them;
• no merge or rebase is in progress;
• the branch is refactor;
• HEAD is unchanged since the read;
• test-queue.sh passes on the exact prospective content.

Even then, other seats' ordinary commits cannot be prevented. That option needs Jason's yes.

Q4. Whose Gitea identity posts review requests (Piece D)? scripts/gitea-api.sh defaults to ~/secrets/mosaic.gitea.json, which authenticates as jason.woltje (checked with GET user). Earlier rounds on #1507 and #1509 established "no Jason-default issue writes". Seat tokens live under ~/.mosaic/fleet/agents/<seat>/secrets/, the fleet tree being retired, and Jason's jarvis permission covers git, not issue comments by arbitrary seats. Recommend: D posts only with an explicit per-seat credential file passed through MOSAIC_GITEA_CREDENTIAL_FILE. Where that comes from is Jason's call (new repo-native seat tokens, or read-only use of the fleet token files). Until he rules, D refuses to post with the default file. D is blocked on this; A, B, C and E are not.

Decided by Sage as lead, 2026-09-26 (Q5–Q9)

Recorded from Sage's message to Filbert's T3 thread. Each question keeps its original reasoning, followed by the decision.

Q5. Who may move any row? The brief says coordinator and jason. coordinator was the Claude #1509 session. Sage has led since 2026-09-26. Decided: privileged identities are jason and sage. coordinator stays an owner label, for the #1509 rows, with no override authority.

Q6. Piece E's "live registration" check and T3 seats. Every seat now working in T3 has no registration, so the check would report every T3 row as a violation. Decided: "no registration" goes on its own labeled line and is not counted as a violation. No T3 liveness probe; the T3 guide forbids building Mosaic features on the T3 tools. Amended by Sage per R9 (2026-09-26): E keeps five states separate: explicitly unsupported runtime (T3), missing expected registration, invalid record, stale record, and live matched record. Only T3 gets the labeled exemption. E prints a coverage line. Zero violations with liveness untested is not a full pass. Accepting that reduced gate is Jason's call (7.2).

Q7. Piece E's dates and fetch rule. "First run Monday 2026-09-21" has passed. The ledger's one-call rule (issues updated since the start date, one page of 50) misses open issues that were not updated in range, such as #1503. Decided: the first run is the Monday after E is approved. E adds one more call (state=open, one page, a full page fails as today). Referenced issues absent from that list count as closed. Amended by Sage per R8 (2026-09-26): an issue absent from the open list is unknown, not closed. A done row needs positive closure evidence; without it, E reports incomplete evidence, never success. --no-issues makes the issue checks unknown, not zero violations.

Q8. The owner-priority override. QUEUE.md's header carries a "Current owner priority" paragraph that overrides row order. That is state in prose, which the brief exists to remove. Rows 9–13 also "start when row 6 is done", a dependency the schema cannot express. Decided: add after: [ids] to the schema. next skips a row until its dependencies are done, and orders in-progress, then in-review, then briefed, each by id. No free-text priority field.

Q9. Rows the schema cannot hold. Row 7 (weekly ledger run) is recurring: it is never done and must never change. The parked table's five items have no owner or issue. Decided: row 7 moves to packages/ledger/README.md as the weekly routine (sequenced across A and E; see 2.A). The parked items become rows with state parked, owner unassigned and issue null.

5. Where the brief contradicts the code or itself

Sage decided the fixes in items 3 and 4 (in-review→in-progress, required as a flag), and they are marked Decided. Items 1 and 2 are Q1 and Q2. After round 2 (R11), items 4 (remainder), 6, 7, 10 and 13 change owner requirements and are in 7.2 for Jason; they are not for A's round. Items 5, 9, 11, 12 and 14 are revised in section 7 and are builder detail.

1. mosaic queue next resolves to the wrong program (Q1). Verified on this host.
2. Gate G assumes a launcher identity that T3 seats lack (Q2). Verified: MOSAIC_AGENT_NAME is set only by scripts/agent.sh, scripts/agent-host-dev.sh, agents/rocko/launch.sh and the discord engine child.
3. required as a state loses information. Rule: required→in-progress only. After that move, nothing records that the row was required. E's "required row older than 14 days" can then only see rows never started, and "required rows cannot be parked" is enforced only by the absence of a path. Decided (Sage): required: true is a boolean on the row, alongside the normal state machine, and required is no longer a state. parked is refused while the flag is set. Proposed detail: only jason can clear it, following QUEUE.md's existing "only Jason moves" rule for required rows.
4. No way back from review. The listed chain queued→briefed→in-progress→in-review→waiting-on-jason→done has no in-review→in-progress edge. Every changes-requested round (#1511 R1→R2, #1512 R1 provenance) would need blocked. It also forces every piece through waiting-on-jason, while rows 14–20 closed without an owner step. Decided (Sage): add in-review→in-progress. Still proposed: in-review→done where the row's gate is not Jason's, made per-row with a gateOwner field or a waiting-on-jason requirement flag.
5. blocked→previous needs storage. Add blockedFrom, set on entry and cleared on exit.
6. queued is unreachable if add requires a brief. State queued means "no brief yet", but C makes add refuse a missing brief. Fix: --brief is optional on add, and must exist if given. queued→briefed requires an existing brief.
7. Parked rows "never change" vs "needs Jason to reopen" (QUEUE.md's parked table). Fix: parked→queued/briefed with --by jason only.
8. --by jason is a claim, not proof. The CLI cannot check who typed it. Every agent commits as the same git user. packages/seat handles taskSetBy the same way and says so ("authorizes nothing"). Iron-clad point 5 ("only Jason moves them") is not enforceable by the CLI. Fix: state this in the README, and have E list every change to a required or parked row, with its updatedBy, for Jason to confirm weekly. A real check needs a signed approval, which is out of this brief's scope.
9. Rendered view with hand edits. Nothing stops a hand edit between the markers, and the next write silently erases it. Fix: render --check in scripts/test-queue.sh fails on drift.
10. E's issue rules break on multi-row issues. "Every open issue with #N in a row has that row not done": #1509 is open (checked) and rows 14, 15, 17, 19 and 20 are done. That is five violations on day one, and the same shape exists for #1503 (rows 1, 22) and #1508 (rows 9–13). Fix: per issue, open ⇔ at least one row not done, and closed ⇒ all rows done.
11. Owner and issue fields hold one value; today's rows hold several. Examples: "dewey; filbert reviews", "#1511 code phase; #1512 pilot". Fix: add reviewer (seat or null) and issues: [int]. next for a reviewer returns rows in in-review where they are the reviewer. That is how Filbert's review work would reach Filbert through the command.
12. State cells are paragraphs. Rows 6, 15, 17 and 23–25 carry 375–775 characters of history in State; seven more rows exceed 150. The schema's note is one line. Fix: migration keeps a short note, and the history stays where it already is (CURRENT.md, issue comments). The journal is the change log, and its genesis entry keeps each original row verbatim (7, R13; this replaces "Q3's per-write commits"). The hand "Log of table changes" is frozen as history.
13. Piece D's pass criterion is already trivially met. Since 2026-09-13, review receipts have gone to agents/darkwing/work/*/r*-review.md, not docs/plans/reviews/ (161 entries, last change ea00ec66/11659cf2). The side channel moved; it did not close. Fix: the criterion counts new review files anywhere, including agents/*/work/.
14. The review request needs a candidate identity the row does not have. Current practice pins a frozen snapshot plus a SHA-256 manifest. Fix: move ID in-review --candidate <commit-or-manifest-path>, required, included verbatim in the comment.
15. Ownership text is stale. The brief names "Coordinator: the Claude session" and darkwing as builder. Sage leads now and has confirmed the brief's split for when the rows open (section 0).

6. Scope held

No source, record or queue edits were made for this plan, and nothing was committed or pushed. The only repository writes this session are one line appended to docs/SESSIONS.md (registration) and this file.

7. Disposition of Rocko's adversarial review (round 2)

Source: agents/rocko/work/queue-as-data-adversarial-2026-09-26.md, SHA-256 df433f932f6e8687fdb2ad6d707d133b633a245ac39293362ce6bde6942cbf5c, verified before reading. It reviewed this plan at 59d5a22f…1fdb.

I reproduced Rocko's two probes. messageKind classifies the T3 [from: sage (…) -> to: …] header as human, and import.meta.resolve("@mosaic/seat") throws ERR_MODULE_NOT_FOUND. I also checked R13's fresh-clone concern against today's rows. Five briefs the queue points at are untracked in git: relaunch-activity (row 6), task-attribution (row 6), internal-development-bootstrap (row 16), discord-board-row (row 18) and board-attention-status (row 22).

No finding is rejected. Ten are accepted as written and four (R1, R3, R6, R7) are accepted with a modification, each stated below. "Needs Jason" marks a change to an owner requirement or gate. The items are collected in 7.2.

7.1 Findings

R1 (High), two-file write without a crash contract: accept-modified. Rocko is right that an atomic rename protects each file, not the pair or the sequence. Plan change:

• Truth and views. The journal docs/plans/queue.log.jsonl is the record of operations, queue.json is the validated snapshot, and the rendered table is a view. list and next read only queue.json, and only after verify. No reader ever takes QUEUE.md as current.
• Revision stamps. Each snapshot carries revision and the SHA-256 of its journal tail. The rendered table's begin marker carries the same revision and hash, so anyone can see a stale view.
• Lock. The lock is a directory at $(git rev-parse --git-common-dir)/mosaic-queue.lock, realpath-resolved. The checkout and its symlink ~/src/mosaic-stack-dev-test therefore share one lock, and nothing new is added at the repository root. Every verb, including list, next and standalone render, takes the lock before reading.
• Stale locks. The owner file records the PID and its /proc/<pid>/stat start time. A lock is stale only when that PID is dead, or alive with a different start time. It is never stale because a deadline passed. Waits are bounded (10 s), then the verb refuses and prints the owner.
• Write order under the lock:
  1. Verify the current state (R3).
  2. Append the journal entry and fsync.
  3. Write the queue.json temp file, fsync, rename, fsync the directory.
  4. Render the table and rename it into place.
  5. Acknowledge on stdout.
• Recovery on entry, under the lock:
  • Journal tail present, snapshot equal to the tail's parent: roll forward by replaying the tail.
  • Snapshot current, view stale: re-render.
  • Anything else: refuse, and print the verify output with a recovery instruction.
• Retries. add refuses when an identical non-terminal row exists (same piece, owner and brief) and prints that row's id. A move to the state the row already holds reports the earlier journal entry and exits 0. A retry after an unacknowledged crash therefore applies at most once.
• Durability. The README states that only acknowledged operations survive a host crash, and only because of the fsyncs above. Modification: I use provable stale-owner detection and do not introduce a kernel flock, because Node has none built in, and spawning flock(1) would tie the lock to the bash wrapper and not to the CLI the tests call. Acceptance: Rocko's list as written (add/add, move/note and render/write races through both paths; a kill after each step; injected disk errors; a dead lock holder; a reused PID).

R2 (High), Q3's path-limited commit takes other authors' work: accept. This changes my Q3 recommendation to "no automatic commit" (see Q3). Plan change:

• A has no commit step, not even behind a flag.
• The lead commits queue files by explicit path after scripts/test-queue.sh passes on the exact content being committed.
• The invariant-8 claim is withdrawn. The checks that apply to a queue-data commit are scripts/test-queue.sh: node --test packages/queue/tests/, verify, and render --check. A commit that also changes code adds that code's suites.
• Package tests are not exempt because they lack a shell wrapper; test-queue.sh runs them. If Jason chooses automatic commits anyway, R2's preconditions and acceptance list apply as written.

R3 (High), checks validate appearance, not provenance: accept-modified. Plan change:

• queue verify replays the journal from its genesis entry (the reviewed migration, R13) and requires the replay to equal queue.json byte for byte. Each entry is checked against its parent for authority (R4), legal transitions, immutable ids and no deletions.
• The high-water id is the maximum id ever issued, and retired ids stay as tombstones. Row 7 is recorded as retired in genesis.
• Every mutation runs verify first and refuses to overwrite unexplained drift in queue.json or between the markers. Missing or duplicate markers are refused.
• A fork (two entries with the same parent, for example after a merge or from a second clone) blocks writes until the lead reconciles it with a new journal entry. A second-clone writer is out of scope and is detected, not supported.
• A fresh clone can run verify from committed files alone. Modification: the honest boundary goes into the README and the #1508 gate comment in Rocko's words: this is a cooperative writer with drift detection. Code running as the same host user cannot stop that user rewriting both the data and the journal. No hooks. Acceptance: Rocko's list as written.

R4 (High), identity attribution used as authorization: accept. Needs Jason (trust model and the required-row rule). Plan change: a permission matrix is added to A. "Claimed" means from --by or MOSAIC_AGENT_NAME, recorded in the journal as a claim.

Verb or field	Who (claimed)
add	any identified seat for its own rows; privileged (jason, sage) for any owner
move (ordinary)	row owner or privileged
assign, reviewers, after, gateOwner, issues	privileged only; after on a required row: jason only
required set	privileged; required clear: jason only
park / unpark	jason only, refused while required
note	owner, a reviewer of the row, or privileged; never on a done row
done rows	immutable; nothing changes them

Also: assign cannot be used by a seat on its own row to launder a move. A non-required row cannot be added to a required row's after (so required work cannot be subordinated, R6).

"Only Jason moves required rows" (brief point 5) conflicts with the brief's own "required→in-progress". I read "moves" as reorder or park, which matches QUEUE.md's header ("cannot be parked or reordered below queued rows; only Jason moves it"). Needs Jason: confirm that reading.

Needs Jason: on this host every seat runs as the same Unix user, and the default Gitea credential authenticates as jason.woltje. No human gate is available that the CLI could verify. Recommend: Jason accepts the cooperative trust model for #1508, with detection through the journal and E's weekly list of every protected change, as the brief's scope. Enforcement would need a separate credential or user boundary, which is outside #1508. No roles/*.json change is implied.

R5 (High), Gate G can pass with extra help or no work: accept. Plan change, replacing the old pass evidence:

• Pin before the run: the fresh session file path, the launch snapshot under .pi/state/<seat>/launches/ and its hash, the queue.json revision, the brief's hash, and the start time.
• Coaching audit: diff the launch snapshot against committed SOUL, CONTEXT and USER inputs. Any row- or task-specific text is a fail. Generic governance context is allowed.
• Input audit: after Jason's instruction, any further user-role entry in that session, in any format, fails the gate until Jason's pass or fail. That covers board replies, agent relays, the T3 header and tmux sends. The ledger's messageKind is not used for the count: it classifies the T3 header as human and a board-routed correction as board.
• Claim check: the journal entry moving the row to in-progress must carry the pinned launch's MOSAIC_LAUNCH_INCARNATION.
• First work action: at least one concrete action from the brief's "What ships" in that session (an edit or a command), not only reads. Normal prerequisite reads before the brief are allowed.
• Verdict: Jason's observed pass or fail stays authoritative. A commit is not required and not evidence.
• Checker: packages/queue/src/gate-g.mjs, a read-only evidence checker, with negative-control fixtures that must fail: a board correction, a relayed hint, a resumed session, a helper moving the row, and reads with no work action.
• Selection among competing eligible rows is tested in unit tests, not by the single-row demo. Follow-up outside #1508, for Sage: messageKind also counts the T3 header as human in the weekly Table 2 number (row 7). That is a ledger bug in its own right.

R6 (High), dependencies and next do not stop unauthorized starts: accept-modified. Needs Jason (the row-9 start condition, only as a brief wording check). Plan change:

• Predicates at transition time. move checks the after and authority predicates under the lock, the same predicates next uses. A seat that bypasses next is refused.
• Claims. Moving to in-progress records the claim: seat plus MOSAIC_LAUNCH_INCARNATION when present. in-progress→in-progress is refused. next reports a row claimed by another incarnation as resume (claimed by <incarnation>) and does not return it as fresh work.
• Action role. next returns an action with the row: implement, resume, review or wait. An author whose row is in-review gets wait. A reviewer gets review only when it has no receipt for the current round (R12).
• Dependency conditions. after entries carry a condition. The default is done, and settled means done or blocked. Row 9 is after: [{id: 6, when: "settled"}], which matches the brief's "Gate F or blocked". Sage decided after, so this is a refinement of that decision.
• Ordering. The in-progress > in-review > briefed ordering (Sage, Q8) differs from AGENTS.md's "first row you own in any of those states". B updates the cadence text in the same commit, so the two cannot disagree.
• Limitation. after cannot rank two rows that are both active. The README says so, and no priority field is added (Q8).

R7 (High), post-then-record cannot promise one review request: accept-modified. Plan change: no exactly-once promise is made, because a remote side effect cannot be rolled back. D promises at most one request per operation id, with reconciliation:

• The operation id is formed from row, revision, round and candidate digest.
• An intent entry is written to the journal and fsynced before the POST.
• The comment embeds <!-- mosaic-queue-op: <id> -->.
• On an uncertain outcome, D looks up the issue's comments for that marker before any retry. If the lookup fails, it refuses and prints the recovery step. No blind retry.
• After Q4, D compares GET user against the account expected for the seat before posting; a different path alone is not proof of identity.
• No token is read or provisioned before Q4.
• Local-commit failure no longer applies (R2). Acceptance: Rocko's list, with a fake transport that can accept a POST and then drop its response.

R8 (High), absent from the open list does not mean closed: accept (Sage amended Q7). Needs Jason (the call budget). Plan change:

• Absent means unknown.
• Positive evidence comes from GET issues/N for each referenced issue absent from the open list. That is currently 3 (#1504, #1505, #1506). The response must be an issue, not a PR, and must exist.
• The lookups are bounded at 20, then E reports incomplete.
• A done row without positive closed evidence is reported as incomplete.
• --no-issues prints queue issue checks: not run. The per-issue lookups break the ledger's one-call boundary from the #1506 brief. Needs Jason: allow the bounded extra lookups, or accept "incomplete" as the permanent result for done rows. Acceptance: Rocko's list as written.

R9 (High), the liveness exemption can turn missing evidence green: accept (Sage amended Q6). Needs Jason (the reduced gate; Sage is adding it to his list). Plan change:

• Five states: exempt-runtime (T3, declared per run with --unsupported-runtime SEAT and printed), missing, invalid, stale (dead PID, or a PID alive with a different start time) and live.
• Matching uses repository root, layout repo and seat, never seat name alone. Duplicates across layouts are reported.
• Errors. Scanner errors propagate as invalid.
• Coverage line: liveness: N live, N exempt, N missing, N invalid, N stale. With any exempt or untested seat, E says "reduced gate". Acceptance: Rocko's list as written.

R10 (Medium), history E needs is not in the schema: accept. Plan change:

• Rows gain createdAt and requiredSince (UTC).
• E ages required rows from requiredSince and only while non-terminal, so note no longer resets the age.
• The journal (R1) is the history. E lists every protected change from it, not from updatedBy.
• Violation first-observed evidence is the dated E run posted on #1508. Remediation is the journal entry's UTC timestamp on the same day.
• None of this depends on commits (R2). Corrections are new journal entries.
• The journal lives in docs/plans/, not in BUILD-LOG, SESSIONS or any runtime log.

R11 (High), some section-5 fixes change owner requirements: accept. Plan change:

• Section 5's intro no longer says "settle in A's round" for these items. They are listed in 7.2 with the original rule, the proposed rule, the authority and the acceptance change.
• 5.6: I take Rocko's reading. --brief stays required on add (the brief's rule is kept). queued means the brief exists but is not accepted, and briefed means accepted. That changes QUEUE.md's definition of queued ("no brief yet"), so it needs Jason.
• Blocking: any→blocked applies to non-terminal rows only. done and parked stay immutable, which keeps the brief's "never change". blocked→blocked is refused; the reason is updated with note. This is a reading, not a change.
• 5.10, issue closure: rows gain closesIssue: true on the row whose completion gates closure (for example row 22 targets #1503 while row 1 keeps broader MVP acceptance, so row 1 would carry it). Where rows and issue state disagree, E reports a mismatch for disposition. It does not demand closure. Needs Jason.
• Reviewers: the single reviewer field becomes reviewers: [seat] with per-reviewer receipts, so row 6's Darkwing and Dewey lanes migrate intact.

R12 (Medium), no immutable review candidate or receipt lifecycle: accept. Plan change:

• --candidate must be a commit SHA present in the repository, or a regular, repository-contained manifest file. /tmp and other out-of-repository paths are refused.
• The journal and the comment record the resolved content digest.
• The row gains reviewIssue (defaults to the first of issues, and is explicit when there are several) and review: {round, requests[], receipts[]}. Prior rounds are kept.
• Test: request, changes requested, new candidate, approval, with exact pins in each round.
• The brief's criterion (no new files under docs/plans/reviews/) stays as written. My stronger "no review files anywhere" (5.13) is a separate proposal for Jason, and it does not replace durable receipts. The receipts are the issue comments.

R13 (Medium), brief validation and migration too shallow: accept. Needs Jason (row 8 has no brief). Plan change:

• Briefs: a brief must be a regular file (symlinks refused) whose realpath is inside the repository and which is tracked by git (git ls-files --error-unmatch).
• Five current briefs are untracked (listed above). They must be committed before migration, or their rows cannot be migrated as briefed. That commit is Sage's to schedule.
• Anchors: path#Heading is validated. The heading must occur exactly once in the file.
• Migration map: a reviewed row-by-row map preserves owner, reviewer lanes, gate, required, dependencies, the historical id and every open boundary. It lives in agents/<author>/work/. The journal genesis entry keeps each original QUEUE.md row verbatim (legacy), so no history depends on having been copied elsewhere.
• Parked items map explicitly, and their "Where" references become briefs.
• Row 8 ("none yet") has no brief, which breaks iron-clad point 3. Needs Jason: accept a stub brief written by the lead, or keep row 8 out of the queue until it has one.

R14 (Medium), package reuse and acceptance wiring: accept. Plan change:

• Relative imports only (2.E updated). No workspaces and no lockfile change.
• Test commands: node --test packages/queue/tests/, node --test packages/ledger/tests/, scripts/test-queue.sh, and node scripts/test-darkwing-launch.mjs and node scripts/test-rocko-launch.mjs for the dispatch change.
• C acceptance adds two owner-accepted briefs, recorded on #1508.
• D acceptance is one full review round (R12). E acceptance is a dated ledger receipt with remediation evidence.
• B acceptance: inspect a fresh launch snapshot for the new cadence text, then Gate G.
• Order: C-with-A is the brief's own wording ("as part of Piece A's review round"). D/E parallel departs from "A to E in order", so section 1 now follows the brief. Needs Jason only if Q4 holds D and E is wanted first.

7.2 Needs Jason (in addition to Q1–Q4)

#	Original rule	Proposed rule	Acceptance change	From
J1	Iron-clad point 5: only Jason moves required rows	Confirm "moves" means reorder or park; seats may start and progress required rows they own	Permission matrix in R4	R4
J2	CLI enforces authority	Accept a cooperative trust model with journal detection and E's weekly list; enforcement needs a boundary outside #1508	README and gate comment state the boundary	R4, R3
J3	QUEUE.md: queued = "no brief yet"	queued = brief exists, not accepted; add always requires a brief	States text in QUEUE.md header	R11 (5.6)
J4	Brief: parked rows never change; QUEUE.md: Jason reopens	Unpark by jason only, refused while required	Transition table	R11 (5.7)
J5	Chain passes through waiting-on-jason	in-review→done allowed where gateOwner is not Jason	Transition table	R11 (5.4 remainder)
J6	E: open issue ⇒ its rows not done; done ⇒ closed	closesIssue row gates closure; disagreement is a mismatch for disposition	E rules and fixtures	R11 (5.10)
J7	D: no new files under docs/plans/reviews/	Optionally also no review files under agents/*/work/; receipts are issue comments	D pass criterion	R11, R12 (5.13)
J8	Ledger one-call boundary (#1506)	Bounded per-issue lookups (≤20) for positive closure evidence, else "incomplete"	E fetch budget	R8
J9	Every row has a brief that exists	Row 8: stub brief by the lead, or leave it out of the queue	Migration map	R13

Also held for Jason by Sage: the reduced liveness gate (R9), and E before D if Q4 holds D (R14).

Decided by Sage and not needing Jason:

• required as a flag. It alters the brief's schema text but keeps its semantics.
• in-review→in-progress.
• Q5–Q9 as amended.
• The settled dependency condition, a refinement of Q8 that matches the brief's own "Gate F or blocked".

8. The active specification (round 6)

Round 6 answers Rocko's round-5 report, agents/rocko/work/queue-as-data-adversarial-r5-2026-09-26.md, SHA-256 3b031a707555960dc69cc274fef6c39c0d8c0ebad539a5e8ae0c0c2545f4177e, verified before reading. It reviewed round 5 at 889f2566…ae3d3, found F2, F3 and F5 resolved, and raised two medium findings, G1 and G2. 8.19 maps them.

Round 5 answered Rocko's round-4 report, agents/rocko/work/queue-as-data-adversarial-r4-2026-09-26.md, SHA-256 fcb8933d515bcf98c509d17cb7c5bb384f2bce844b2b87eab6f83e67658efcff, verified before reading. It reviewed round 4 at 14dccfd0…e63f. He accepted the lead choices and raised five residuals, F1–F5. 8.18 maps each one. Round 5 also folds in Jason's credential ruling for D (8.9).

Round 4 answered Rocko's round-3 report, agents/rocko/work/queue-as-data-adversarial-r3-2026-09-26.md, SHA-256 13a328045fafc3195305b8ae44f0524620a13d5d06b9e86866c59b3956c6a274, verified before reading. It reviewed round 3 at cfdaa3fe…1ff21f, plus the delta to 124b6f9e…0d26. He accepted the architecture and Sage's rulings, and raised T1–T8. 8.17 maps each finding to the text that answers it.

Round 3 answered Rocko's round-2 report, agents/rocko/work/queue-as-data-adversarial-r2-2026-09-26.md, SHA-256 b3a2d72ae32775edc835ab6399f99dc870fe17a4833d76b6972a72e1da0e70f4, verified before reading. It reviewed this plan at 94922cc5…a27cc5.

Sage's direction for this round: this is a queue for one host and a handful of seats. It fails closed, and recovery happens only through explicit manual verbs, modelled on the Discord connector's run lock (#1509 reclaim-race rounds 3–5, packages/discord/src/journal.mjs). There is no automatic recovery.

This section is the specification. Where sections 1–7 differ from it, this section wins. They remain only as the record of how the design got here (S11). A builder reads the brief and this section, nothing else.

8.0 What round 3 removes, and one departure from Sage's direction

Removed:

• The separate journal file. The operation log moves inside queue.json (8.2).
• All automatic recovery: roll-forward, re-render, stale-lock reclaim.
• Worktree and clone support, and fork reconciliation (S6).
• MOSAIC_LAUNCH_INCARNATION, and any process-start comparison for registrations (S8).
• Retries matched by tuple equality (S4).
• The ban on a required row depending on a non-required row (S7).
• The optional stronger D criterion (J7, which Sage dropped).
• The Gate G checker package. Gate G now uses a checklist (8.11).
• The separate generated-table file idea. The brief's markers in QUEUE.md stay.

Departure, stated plainly. Sage directed queue repair for a torn journal tail (S2). I propose no journal file at all. Operations are recorded inside queue.json, which is written only by temp file, fsync and rename.

• A file replaced by rename cannot be torn. The partial-append case does not arise, so there is nothing for a repair verb to handle.
• It is also closer to the brief's "One file, docs/plans/queue.json … It is the queue."

Sage's other S2 rules carry over unchanged (8.5):

• invalid data refuses every verb;
• acknowledgement means a printed receipt;
• an op that was recorded but never acknowledged stands and is flagged.

Decided by Sage 2026-09-26: accepted. There is no journal file and no queue repair. An invalid queue.json refuses every verb. Recovery is a manual, reviewed procedure (8.5), not a plain git restore.

Round 4 (T1) narrows one round-3 claim. A rename makes a new version visible, but it isn't durable until the directory fsync succeeds, and it isn't acknowledged until the receipt prints. 8.5 now keeps those three points separate.

8.1 Files

• A, with C inside it.
  • packages/queue/: package.json, src/queue.mjs (data, checks, transitions, lock), src/cli.mjs, README.md, tests/.
  • scripts/mosaic dispatches queue to the queue CLI and passes everything else through unchanged.
  • scripts/test-queue.sh runs node --test packages/queue/tests/, then scripts/mosaic queue verify.
  • scripts/queue-commit.sh is the lead's commit procedure (8.12).
  • scripts/git-hooks/pre-commit is the queue guard, which queue-commit.sh --install-hook installs (8.12).
  • docs/plans/queue.json is created by genesis (8.2).
  • docs/plans/QUEUE.md: the table between the two markers becomes generated. The header stays hand-written and loses its priority paragraph (Q8).
  • docs/plans/BRIEF-TEMPLATE.md (C).
  • The lock's process-identity helpers are imported from packages/discord/src/journal.mjs by relative path: processStart, bootId, pidAlive, validStart, validBoot. The control board already imports that module the same way, and nothing in the discord package changes.
• B: the AGENTS.md cadence line, changed to name scripts/mosaic queue next (8.8). The context files that point at CURRENT.md for what to do next change as well: line 18 of agents/{dewey,filbert,darkwing,sage}/CONTEXT.md and line 15 of agents/rocko/CONTEXT.md ("Read docs/plans/CURRENT.md to reconcile ownership and existing gates"). Line 30 of agents/darkwing/CONTEXT.md describes what CURRENT.md records, not what to do next. It stays unless the review of B says otherwise. That makes one commit, which a fresh launch snapshot verifies (8.14).
• D: packages/queue/src/review.mjs and the review verbs. It posts only through scripts/gitea-api.sh with MOSAIC_GITEA_CREDENTIAL_FILE, set to the per-seat token file Jason ruled on (Q4, 8.9).
• E: packages/ledger/src/queue-checks.mjs and the ledger CLI hook. It imports ../../queue/src/queue.mjs and the control board's registration loader by relative path.

8.2 Data: one file, one log

docs/plans/queue.json holds {version, canonicalRoot, revision, rows, log}. The brief's "array of rows" becomes the rows member. This file is new, so no reader of the old shape exists.

Serialization is deterministic:

• UTF-8, \n line endings, one trailing newline;
• two-space indentation;
• keys in schema order;
• rows sorted by id, and log entries in the order they were appended.

The CLI refuses any file that does not re-serialize byte for byte, so a formatting-only hand edit is caught too.

Row fields:

Field	Meaning
id	never reused
piece	one line
owner	seat name, jason, coordinator or unassigned
issues	list of issue numbers
closes	the issues this row gates, a subset of issues
state, previousState	current state; the state blocked returns to
required, requiredSince	flag; ISO time or "unknown"
gate, gateOwner	the gate sentence and who holds it
brief	{path, anchor, blob}
after	list of {id, when: "done" | "settled"}
reviewers	list of seats
review	{issue, rounds: [...]} or null
claim	{seat, op} or null
note, blockedReason	text
createdAt, updatedAt, updatedBy	times are ISO; createdAt may be "unknown"

Log entry: {rev, op, verb, args, by, at, semantics, result, viewSha}.

• args is canonical.
• by is the claimed actor.
• semantics is the rule version this entry was checked under.
• viewSha is the SHA-256 of the table body rendered for that revision.

Genesis is log[0], and it is the only entry of its kind. It is created by queue genesis --op ID --root PATH --branch NAME --map PATH, which only a privileged actor may run. Genesis refuses if any of the following holds:

• docs/plans/queue.json exists in the working tree or in HEAD;
• the witness file exists (below);
• --root differs from the realpath of the toplevel, found as in 8.3;
• --branch differs from the branch HEAD currently names;
• the map is not a committed blob in HEAD.

Genesis is the only verb that runs before canonicalRoot exists, and these arguments are its reviewed input. It records:

• the QUEUE.md table rows and parked entries verbatim;
• the starting rows as normalized in the reviewed migration map, with that map's blob id (agents/<author>/work/queue-migration-map.md);
• row 7 retired, and the id high-water mark;
• canonicalRoot and branch (8.3).

Genesis writes through 8.5, so it is durable once the directory fsync succeeds and it has written the witness.

Genesis is committed before anything else happens (F3). Until HEAD contains docs/plans/queue.json, every mutating verb except genesis refuses with genesis not committed. The exceptions are sync and render, which log nothing. The first queue commit is therefore genesis alone (8.12).

Witness (T2). <canonicalRoot>/.git/mosaic-queue.head holds {revision, logDigest, fileSha, at} for the last write whose directory fsync succeeded. logDigest is the SHA-256 of the canonical serialization of log[0..revision]. The witness is a check value, not a second store: it holds no rows and no operations, and nothing can be rebuilt from it. It is there so that git replacing queue.json with an older valid file is detected. Replay alone cannot see that (Rocko's Schedule B). A missing witness refuses (8.5).

Legacy createdAt and requiredSince come from cited evidence or are "unknown". Migration time never stands in for them, and no approval is invented: legacy done rows carry no receipts.

Replay starts from genesis. It applies each entry under that entry's semantics version, checks the actor and transition against the state before it, and requires the result to equal rows.

• Replay never reads briefs, the roster or registrations. A row's brief identity is the blob recorded at write time.
• Whether today's briefs still hold is a separate check (verify --current, 8.13).
• There is no rotation or archive in #1508. At about 40 rows and a few hundred entries a year, the file stays small.

8.3 Canonical checkout only (S6)

Every verb, reads included, refuses unless all four of these hold:

• The realpath of git rev-parse --show-toplevel, run from the process's working directory, equals canonicalRoot.
• Every later git query runs as git -C <toplevel> rev-parse --path-format=absolute …, so paths never resolve against the wrong working directory (git 2.55 here). After realpath, --git-dir and --git-common-dir are the same path. A linked worktree fails this.
• git symbolic-ref -q HEAD names the genesis branch. A detached HEAD or another branch refuses. Moving the queue to another branch is a reviewed migration, like moving the root.
• The CLI's own file lies under canonicalRoot. The one exception is verify --snapshot (8.12), which reads only the bytes it is given.

The symlink ~/src/mosaic-stack-dev-test resolves to the root and works. A worktree, or a clone at any other path carrying the same committed queue.json, refuses. The tests cover a linked worktree and a second clone.

No configured canonical root exists today. config.json has only configVersion, environment, dataRoot and execution, and it is user-authored. So the root is recorded in the reviewed genesis entry, and no config change is needed. Moving the checkout later needs a reviewed migration. It is out of scope.

Only one host is supported. The lock records the host name and the boot id, and a lock from another host classifies as unknown (8.4).

8.4 Lock (S1, T3)

The lock is the file <canonicalRoot>/.git/mosaic-queue.lock. It is not committed, and it is not a root file.

Owner record: {pid, start, boot, host, op, verb, at}. start and boot use the same syntax and validation as the Discord connector. If this process's identity cannot be read from /proc, the CLI refuses to take the lock.

Acquire:

1. Create <canonicalRoot>/.git/mosaic-queue.lock.<pid>.<random>.tmp with O_CREAT|O_EXCL|O_WRONLY, mode 0600.

   • Write the whole record, looping on short writes and checking the total. Then fsync and close.
   • Read the file back and compare it with the record. Any mismatch or error removes the temp file and refuses.

2. link() the temp file to the lock path.

   • EEXIST means the lock is held. That is the same exclusivity as an O_EXCL open.
   • Any other link error refuses.
   • On success, stat the temp file and keep its (dev, ino). After a hard link, that is also the lock's inode.
   • Remove the temp file whatever the result.

   Sage accepted link() in place of a literal O_EXCL open (2026-09-26). An empty or unparsable lock file, which the CLI can't produce, counts as invalid.

3. If the unlock gate (below) exists, release the lock and refuse.

Classification (T3). The lock record and the gate record are classified the same way. The tests are taken in this order, and the first one that applies decides:

#	Test	State
1	Record missing, empty or unparsable, or start/boot fail validation	invalid
2	This process can't read its own /proc start or boot_id	unknown
3	host is not this host	unknown, whatever the local pid says
4	boot is not the current boot id	mismatch: a previous boot on this host, so the owner can't be running
5	Same boot, and the pid is not alive	dead
6	Same boot, pid alive, but its /proc start is unreadable	unknown
7	Same boot, pid alive, and its start differs	mismatch: the pid was reused, and the process holding it now is never signalled
8	Same boot, pid alive, and its start matches	live

This order differs from the Discord helper's ownerState, which looks at pid death before anything else and doesn't know about hosts. The queue imports only the low-level readers (processStart, bootId, pidAlive, validStart, validBoot). It does not import ownerState.

On EEXIST: retry every 100 ms for up to 10 s, then classify and refuse:

Owner state	Result
live	"held by <verb> <op> since <at>; retry the same op later"
dead or mismatch	"run scripts/mosaic queue unlock once nothing is running"
unknown	refuse; unlock refuses too; diagnose by hand
invalid	refuse; inspect by hand

Nothing is ever removed because of its age or because of an earlier inspection. If the host is renamed, locks from before the rename classify as unknown, so the queue stays unavailable until someone diagnoses it. That is accepted.

Release: the holder stats the lock path and reads the record. It unlinks only if the (dev, ino) and every record field equal what it acquired. Otherwise it leaves the file alone and reports it. Only unlock removes another process's lock, and unlock refuses a live owner.

queue unlock is manual, any actor may run it, and it never tries to take the lock itself.

1. Create the gate <canonicalRoot>/.git/mosaic-queue.unlock with the same temp-and-link() steps, using the unlocker's own identity record.
   • If the gate exists, refuse, classify the gate record, and print the result.
2. With the gate held, classify the lock.
   • live, unknown or invalid: refuse and remove the gate.
   • dead or mismatch: unlink the lock.
3. Remove the gate, and print the record that was removed.

Why two actors can't both win:

• A writer publishes its lock, then checks for the gate.
• If that check came before the gate existed, unlock classifies later, sees the writer's published live record, and refuses.
• If the check came after, the writer sees the gate and releases.
• unlock never acts on an inspection made before it held the gate, and two unlockers cannot both hold the gate.

A stale gate from a killed unlocker blocks writers with a message that names it. queue unlock --check-gate is read-only: it classifies the gate record by the table above and prints the state. A person removes the gate by hand, only after --check-gate says dead or mismatch, and only once no queue command is running. unknown and invalid gates are left for diagnosis.

Who takes the lock: every mutation, render, verify and sync (8.5). list, next and show read without the lock. A rename replaces each file whole, so each read sees one complete revision. Two files read one after the other are not an atomic pair, though (F2). Unlocked reads therefore follow this rule:

1. Order. Read the witness first, then queue.json. The writer publishes queue.json before the witness (8.5 steps 8 and 10). So a file read after the witness is never older than it unless history really was lost. A normal write in progress cannot make an unlocked reader see the file behind the witness.
2. Ahead. A file ahead of the witness prints rev N visible, not confirmed durable. An unlocked reader can't tell a writer that is still publishing from a crash leftover, so it calls it neither.
3. Adverse. Any other result takes the lock and repeats 8.5 steps 1–2 before it reports anything. That covers an invalid file, a file that doesn't extend the witness, and a missing witness. This includes accept-history, which writes the file before the witness. If the lock can't be taken, the read refuses as 8.4 does, naming the holder. An unlocked read never reports lost history on its own, and never suggests accept-history.

Only a locked caller reports an unconfirmed tail as something to fix, because under the lock no writer can still be publishing. Nothing holds the lock across network I/O (8.9) or across git (8.12).

Tests:

• a kill between the temp write and the link: no lock appears;
• a short or failed temp write: refused, no lock;
• a link error other than EEXIST: refused;
• a paused holder: others wait 10 s, then refuse live;
• two concurrent unlockers: one refuses on the gate;
• a writer publishing during an unlock, in both orders;
• a reused pid within one boot: mismatch, and the process is never signalled;
• the same pid and start on a different boot: mismatch;
• a foreign host with no such local pid: unknown, and unlock refuses;
• unreadable /proc: unknown;
• a stale gate whose pid is now reused: --check-gate says mismatch;
• a delayed release by a dead owner, after unlock and a new owner: the inode check keeps the new lock.

8.5 Write path, durability, acknowledgement and manual recovery (S2, S3, T1, T2)

Supported platform. Linux, with docs/plans/ and .git/ on a local ext4, xfs or btrfs filesystem (tmpfs is allowed for tests). The CLI checks fs.statfsSync(...).type and refuses anything else. This checkout is ext4. Temp files are created in the same directory as their target, so a rename never crosses filesystems. It is assumed that rename replaces the target atomically on these filesystems, and that fsync of a directory fd persists the renamed entry.

Three points, kept separate (T1):

Point	When	Meaning
visible	the rename returns	readers see the new revision
durable	the directory fsync succeeds and the witness is written	the revision survives a host crash, within the platform assumptions
acknowledged	the receipt prints	the caller may treat the op as done

A mutation runs these steps under the lock:

1. Checks. Run the canonical checks (8.3). Read queue.json, and keep its bytes and its stat result (dev, ino, size, mtime_ns). The file must parse, match the schema, re-serialize byte for byte and replay to rows. log[0] must be the only genesis entry, op ids must be unique and revision must equal the last rev. Any failure refuses.

2. Witness. Compare the file with the witness:

   • It matches (same revision and logDigest): continue.
   • It extends the witness, meaning the prefix up to the witness revision has the same logDigest and later entries follow: this is an unconfirmed tail. Some earlier op became visible but was never confirmed durable.
     • If this call is a retry of an op in that tail, or is queue sync: fsync queue.json, fsync docs/plans/, write the witness, then continue.
     • Otherwise refuse, and name the tail ops and queue sync.
   • It does not extend the witness (a lower revision, or a different prefix): history was lost or replaced. Refuse every verb except accept-history (below), and name the witness revision.
   • No witness: refuse, and name queue accept-history. The one exception is a file holding only genesis, which sync accepts.

3. Lookup (8.6). If the op id is in the log, print its recorded receipt and stop.

   • This happens before any view check, so a retry is answered even while the table is stale, with a one-line warning (T4).
   • Reads and lookups never fsync. A lookup reaches this step only after step 2 has confirmed durability.

4. View. Check that the QUEUE.md table is current. If it is stale or unknown, refuse the new op (see "Outcomes").

5. Compute. Compute the new rows and the log entry, and validate both.

6. Temp file. Create queue.json.<op>.tmp with O_EXCL, write all bytes (looping on short writes and checking the total), fsync, and close. On any failure, unlink the temp file and refuse. Nothing has changed.

7. Unchanged check. stat and hash queue.json again. They must equal step 1's values. If they don't, something wrote outside the lock, git most likely: unlink the temp file and refuse. A window remains between this check and the rename. A lock that git ignores cannot close it, and the README says so.

8. Rename. Rename the temp file over queue.json. The op is now visible. A rename failure unlinks the temp file and refuses.

9. Directory fsync. fsync docs/plans/. The op is now durable. If the fsync fails:

   • print uncertain <op> rev N: visible, durability not confirmed (<errno>) and exit 3;
   • print no receipt, and write neither the witness nor the view;
   • never write an older version back.

   The next call finds the unconfirmed tail at step 2.

10. Witness. Write the witness: temp file, fsync, rename, directory fsync. If that fails, print uncertain <op> rev N: durable, witness not updated, exit 3, and print no receipt.

11. View. Render the table body. Write QUEUE.md by temp file, fsync, rename and directory fsync, replacing only the bytes between the markers.

    • Everything outside the markers is copied from the bytes read at step 4.
    • If QUEUE.md has changed since step 4, refuse the view write. The op stays recorded, and the view is stale.
    • The same check-to-rename window as step 7 applies, and is stated.

12. Receipt. Release the lock and print ok <op> rev N row R <from>→<to>. Only now is the op acknowledged.

Recorded but not acknowledged:

• Killed between step 8 and step 10. The next call finds an unconfirmed tail and refuses new ops until queue sync runs or the op is retried. sync prints durable now, never acknowledged: <op> by <seat> at <time> for each tail op.
• Killed between step 10 and step 12. The op is durable, and the stale view flags it: "rev N (op X by S at T) is recorded but the table shows rev N−1; it may never have been acknowledged. Tell S, then run queue render."
• Killed after the view but before the receipt. Nothing flags it. The caller learns the outcome by retrying the same op id or by running queue show.
• Unlocked reads. They follow the order and recheck rule in 8.4. A read that sees a revision past the witness prints rev N visible, not confirmed durable.
• D. Its network step starts only after its own intent reached step 10 (8.9).

Outcomes:

Condition	Effect	Fix
All checks pass	proceed	—
queue.json invalid	every verb refuses, reads included	the manual recovery below
unconfirmed tail	new ops refuse; retries of tail ops and sync confirm durability first	queue sync, or retry the op
history lost (the file doesn't extend the witness)	every verb refuses except accept-history	the manual recovery below
view stale (the body matches the viewSha of an earlier log entry, a genuine older render)	new ops and verify refuse and name the unshown ops; retries answer; reads warn and work	a person looks, then runs queue render
view unknown (the body matches no logged render; markers missing, duplicated or out of order)	every verb that writes QUEUE.md refuses, render included	a person restores the table with git, or re-applies the edit as CLI ops, then runs render

Manual recovery for an invalid file or lost history (T2). No verb repairs anything. The steps, in order:

1. Copy the current queue.json bytes to agents/<lead>/work/queue-recovery-<date>/ before touching anything. Restoring HEAD would discard every op written since the last queue commit.

2. Find the lost ops. They are the entries after the last committed revision, taken from:

   • the preserved bytes;
   • git stash list and the reflog;
   • the receipts that seats hold;
   • issue comments carrying mosaic-queue-op markers.

3. Account for external effects. For every lost review request, check whether its comment exists. A lost op id is no longer deduplicated, and reusing it could post again.

4. Put a valid file in place: the restored version with the lost ops re-applied under new op ids, or a reviewed hand-built file.

5. Run queue accept-history --op ID --reason TEXT.

   • Only a privileged actor may run it.
   • It appends an entry recording the old witness (revision and logDigest, or "absent"), the new revision and the reason, then rewrites the witness.
   • It is the only verb allowed while history is lost, or while the witness is missing.
   • Before running, it prints the lost revision range and the warning "ops in that range are no longer deduplicated", and it needs --yes.

   A reset accepted this way does not keep the at-most-once guarantee for the lost range. The log entry says so.

The git side of the protocol (T2). This part is cooperative, stated in the README and in B's cadence text. While the working queue.json has ops that are not yet committed, or any review attempt is unresolved (8.9), no one runs checkout, stash, restore, reset or a branch switch that touches docs/plans/queue.json or QUEUE.md. Only the lead does such an exceptional restore, and only by the recovery steps above.

Commits follow the same cooperative rule (F1):

• Seats commit with plain git commit and never --no-verify, so the queue guard runs (8.12).
• Merge, rebase, cherry-pick, revert and am skip that guard. On the queue branch they are the lead's.
• Nobody disables, replaces or overrides the guard. That means no core.hooksPath in any scope and no -c core.hooksPath= on a command. It also means no environment that changes which config git reads (GIT_CONFIG_*), no edits to .git/hooks/pre-commit, and no change to its mode (G2).
• "Lead's" and "nobody" are protocol, not enforcement. The witness detects lost history afterwards; it can't prevent a same-user git write. That trust limit is accepted.

Step 7 catches ordinary interference. The witness catches rollback after the fact. Neither can stop an uncooperative git command, because git doesn't honour the lock. That limit comes with the trust model, and nothing here pretends otherwise. A passing replay shows the file is consistent with itself. It does not show that no history was lost. The witness is the only thing that speaks to that.

queue render takes the lock, runs steps 1–2, and rewrites the body only when the view is stale. When the view is current it does nothing. It never overwrites an unknown view.

queue sync --op ID takes the lock, runs steps 1–2 (which confirm any unconfirmed tail), prints what became durable, and logs nothing.

render --check and verify never write, and neither do list, next or show. Hand edits stay refused.

Tests. File operations go through an injectable layer, so each fault can be injected separately:

• a short write, ENOSPC, and a file fsync failure: nothing visible, temp file removed;
• a rename failure;
• a directory fsync failure: uncertain, exit 3, no receipt, witness and view untouched, and a later retry or sync confirms it;
• a witness write failure;
• a kill at each step boundary, using a child killed with SIGKILL:
  • before the rename, nothing is recorded;
  • after the rename, before the witness: the tail refuses new ops, and sync names the op;
  • after the witness, before the view: the stale refusal names the op;
  • after the view, before the receipt: a retry returns the receipt;
• a same-op retry while the view is stale: it answers;
• git interference:
  • git checkout -- docs/plans/queue.json between steps 1 and 7: step 7 refuses;
  • git stash of a valid newer pair, restoring an older valid pair: history lost, every verb refuses, and accept-history works only with --yes and a reason;
  • a deleted witness: refuses, after the locked recheck;
• unlocked reads racing a writer (F2):
  • a reader paused between the witness read and the file read while a writer completes steps 8–10: no lost-history report;
  • a test hook forcing the file-then-witness order: the locked recheck prevents a false report;
  • a writer paused before and after the witness rename;
  • a true rollback, reported only after the locked recheck;
  • an accept-history in progress;
• a hand edit to queue.json that is still valid JSON: replay mismatch;
• a formatting-only edit;
• a genuine stale view compared with an edited view that carries the same old marker;
• a current marker over a changed body;
• missing or duplicate markers;
• a header edit during a write;
• verify and render --check leave bytes and mtimes unchanged.

SIGKILL tests exercise process death only. Power loss is not tested. The host-crash claims rest on the platform assumptions above, and the README says so.

8.6 Operation ids (S4)

Every mutating verb requires --op ID, matching ^[a-z0-9][a-z0-9._-]{7,71}$, so at most 72 characters. Every op id in the log matches ^[a-z0-9][a-z0-9._-]{7,79}$. The 8 characters in between leave room for REQOP.outcome (8.9, F5). The CLI never makes one up. The caller chooses the id before the first attempt and passes the same id on every retry, for example --op dewey-row9-start-2026-09-26. Because the id is written into the caller's own command, a killed CLI cannot lose it.

Op id in the log?	Result
No	a new operation, checked against the current state
Yes, same verb and canonical arguments	no change; print the recorded receipt with "already recorded at rev N", exit 0, whatever has happened since
Yes, different verb or arguments	refuse, exit 2

Identity is the op id alone. No state or tuple is compared. The lookup runs at step 3 of 8.5, after the durability checks and before any view check. A retry is therefore answered even while the table is stale (T4). Op ids ending in .outcome are reserved for the outcome entries that D writes itself (8.9), and callers may not use them. Tests:

• a 72-character request op records its 80-character outcome;
• a 73-character caller op is refused;
• a caller op ending in .outcome is refused.
• A new operation asking for in-progress→in-progress is refused as an illegal transition. R1's "moving to the current state succeeds" is withdrawn.
• A retried add returns the id it first allocated, even after the row was reassigned or finished.

Tests:

• Rocko's S4 schedule: a lost result, then another writer changes the row, then the retry returns the recorded receipt and opens no second round;
• an add retried after reassignment and after done;
• a reused id with a different payload;
• a missing --op.

8.7 States, transitions, permissions: one matrix (S7, R4)

The states are the brief's. required is a flag (Sage). queued means a brief exists but has not been accepted, and briefed means it has been accepted (J3, Sage). Every add needs a brief, and it creates a queued row.

What add may set (T8).

• An ordinary seat adds only rows it owns, and owner is itself. It may set piece, brief (required, 8.13), issues and note.
• Defaults for everything else:
  • closes = issues;
  • gateOwner = jason, so the brief's route through waiting-on-jason applies unless a privileged actor changes it;
  • after = [];
  • reviewers = [];
  • required = false.
• A privileged actor may also set owner, gateOwner, after, reviewers and required on add.

"Privileged" means jason or sage (Q5). Actors are claimed through --by or MOSAIC_AGENT_NAME, and a verb with neither is refused. This is the cooperative trust model (J2).

Transition	Who	Condition
queued→briefed	privileged	—
briefed→in-progress	owner	every after entry satisfied; records claim
in-progress→briefed (release)	claimant, or privileged	clears claim
in-progress→in-review	claimant	once D is built, for a row with reviewers, this move is the review request, and it takes --candidate (8.9). Before D, or with no reviewers, it opens the round with request: none
in-review→in-progress	owner, or privileged	changes requested (Sage)
in-review→waiting-on-jason	owner, or privileged	with D built, on a comment round: refused while any attempt is unresolved, and it needs the approving receipts of every listed reviewer for that round, the same checks as in-review→done (8.9). Before D, or on a round with request: none: no condition
waiting-on-jason→done	jason; or sage with --evidence citing Jason's approval	the evidence reference is logged
in-review→done	the row's gateOwner, or privileged	refused when gateOwner is jason (that path runs through waiting-on-jason). --evidence must name the current round and its candidate digest: with D built, the approving receipts of every listed reviewer for that round (8.9); before D, a comment id together with the round's candidate digest, which must match. Logged (J5)
any non-terminal→blocked	owner, or privileged	reason required; records previousState; blocked→blocked refused (update the reason with note)
blocked→previousState	owner, or privileged	—
queued or briefed→parked	jason	refused while required
parked→queued (unpark)	jason	the brief is re-accepted through queued→briefed (J4)
done→anything	refused	—

Field edits, on add as well as afterwards:

Field	Who
owner	privileged. An ordinary seat may add only rows it owns.
gateOwner, after, reviewers	privileged
issues, brief	set on add by the adder; afterwards privileged only (a brief change is a re-pin, 8.13)
closes	set to issues at genesis and on add; privileged may narrow it only with --reason, which is logged (J6)
setting required	privileged; refused on a parked row
clearing required; changing after on a required row	jason
note	owner, a listed reviewer, or privileged; never on a done or parked row
review receipt	a listed reviewer, for the current round, citing that round's candidate (8.9)

Claim lifecycle (T8). Invariant: claim is null, or claim.seat equals owner.

Event	claim
briefed→in-progress	set to {seat: owner, op}
in-progress→in-review, in-review→in-progress, in-review→waiting-on-jason	kept
→blocked, and blocked→previousState	kept unchanged
release (in-progress→briefed)	cleared
assign by a privileged actor on a claimed row	owner and claim.seat both become the new seat, and claim.op becomes the assign op. The review round continues
→done, by any allowed actor	cleared
parked, unparked	never claimed: parking happens only from queued or briefed

Permission comes from this matrix alone. A claim adds no refusal of its own, so a gate owner who isn't the row's owner can complete it through the J5 edge. "Claimed by X" is only the wording of the refusal a non-owner gets when they attempt an owner transition.

Prerequisites. after holds owner-approved prerequisites of any shape, including a required row depending on a non-required one. Row 9 is after: [{id: 6, when: "settled"}], where settled means done or blocked. Prerequisites are checked only on the move into in-progress. Later transitions do not recheck them, so a parent that leaves blocked afterwards strands nothing.

Rulings in this matrix (Sage, 2026-09-26, 8.15):

• J1: owners progress their required rows. Reordering, parking and clearing required are Jason-only.
• J4: only jason unparks, and a parked row returns to queued.
• J5: in-review→done is allowed where gateOwner is not Jason.

8.8 next and claims (S8, R6)

A claim is the seat name and nothing more: claim: {seat, op}. No incarnation and no process identity are recorded. The claim lifecycle is in 8.7.

• If another seat attempts an owner transition, the CLI refuses with "claimed by X". X runs release, or a privileged actor reassigns the row.
• Two sessions of the same seat are one claimant. The queue cannot tell them apart and does not try. This limit is stated in the README.

next [SEAT]. SEAT defaults to MOSAIC_AGENT_NAME. With neither, the verb refuses (Q2). It returns one action, lowest id first within each class, in Q8's order:

1. resume: an in-progress row claimed by SEAT.
2. review: an in-review row where SEAT is a listed reviewer and has no receipt for the current round.
3. start: a briefed row owned by SEAT whose after is satisfied. If the working brief no longer matches the pinned blob (8.13), next still names the row, marked brief differs from pinned blob; ask the lead to re-pin, and start refuses.
4. wait: only when nothing above matches and SEAT owns an in-review row.
5. nothing.

The author's in-review rows are not actionable, so they give wait only when there is nothing else. That is how I apply Q8 to the author's side. queued, blocked, parked and done rows are never returned. B's cadence text is written to this list.

8.9 Review requests, Piece D (S9, S10, R7, R12, T4)

D posts only with an explicit per-seat credential file (MOSAIC_GITEA_CREDENTIAL_FILE) and refuses the default file (Q4).

Credentials (Jason, 2026-09-26, relayed by Sage). The live round reads each seat's own token in place, read-only, at ~/.mosaic/fleet/agents/<seat>/secrets/gitea-mosaicstack-<seat>.token (mode 0600). There are no copies and no writes under ~/.mosaic. The lead posts as jarvis under the same rule, reading ~/.mosaic/fleet/agents/jarvis/secrets/gitea-mosaicstack-jarvis.token in place (Sage, 2026-09-26). That is the Gitea API token. The push helper has its own route, and this plan doesn't change it.

• D never opens the file. gitea-api.sh reads it.
• D only stats it: it must be a regular file, owned by the user, mode 0600. The path must name the acting identity: the seat, or jarvis for the lead.
• Scopes as ruled: darkwing and dewey hold write:repository, and filbert and rocko hold write:issue.
• It is unverified whether write:repository alone lets a token post an issue comment. If it doesn't, the POST gets a 403, which is failed: a definite result with nothing posted. So it fails safe. Nobody spends a real post to check this beforehand (Sage, 2026-09-26). A 403 for darkwing or dewey in the first live round is an expected finding, not a defect in D. It is recorded with the round, and the scope question goes to Sage.

The tests use a fake transport and read no token.

Verbs:

• move ID in-review --op OP --candidate <commit|manifest>. Per the brief, this move posts the request. It opens round n and its first attempt.
• review request ID --op OP: another attempt in the current round, with the round's candidate. It is allowed only when every earlier attempt in the round is failed or abandoned.
• review resolve ID --op OP --attempt REQOP --posted <commentId>: the owner or a privileged actor.
• review abandon ID --op OP --attempt REQOP --reason TEXT --yes: privileged only.
• review record ID --op OP --verdict approve|changes --comment <id>.
• review verify-commit ID <commit|tree>, which is read-only.

Candidate. A candidate is one of:

• a commit reachable from a local branch or tag;
• a manifest listing repository paths and their SHA-256, in the form of today's CANDIDATE.sha256.

The candidate is frozen for the round. A new candidate needs a new round: in-review→in-progress, then move in-review again.

The manifest text goes into the comment and into the log. The queue does not keep the source bytes of an uncommitted candidate. verify-commit checks that every manifest path has the approved digest in the given commit or prospective tree (8.12). If the approved bytes have changed or are gone, integration is blocked, and the fix is a new round. A missing candidate is never quietly replaced by a new one. A commit candidate stays retrievable only while some ref keeps it, and the README says so.

Attempts. Each attempt is keyed by its request op and lives in round.attempts[]. The candidate digest and the op never change after the intent is written.

State	Meaning	New request on this row?
requesting	intent is durable; no outcome recorded yet	refused
posted	a comment id was confirmed, by the transport or by resolve	not needed
failed	definite non-acceptance (below)	allowed, with a new op
uncertain	the transport outcome is unknown	refused
abandoned	a privileged actor gave up on it, accepting the risk of a duplicate	allowed, with a new op
conflict	a late transport outcome disagrees with an earlier manual resolution	refused

Request steps:

1. Intent. Run the full 8.5 path under the lock. The entry, with op REQOP, moves the row or opens the attempt, recording the candidate digest, issue, round and requesting.

   • If any attempt on the row is requesting, uncertain or conflict, refuse.
   • If the write ends uncertain (exit 3), stop: nothing is sent. Only a write that reached 8.5 step 10 goes on to the network.

2. Pre-send checks, without the lock:

   • the credential file is set, is not the default, and passes the stat checks above;
   • GET user matches the expected login: the seat's own for a seat, and jarvis when the lead posts. The queue actor stays the lead; only the login is jarvis. It runs in its own process group under the same 30 s deadline as the POST, and a timeout here is a pre-send failure.

   A failure here means the POST was never started, so the outcome is failed.

3. POST. Run gitea-api.sh in its own process group. After 30 s, kill the whole group with SIGKILL. The helper has no timeout of its own, and killing its curl child does not undo a request the server has already received. The body carries <!-- mosaic-queue-op: REQOP -->, the round and the manifest. The helper prints the body on stdout and HTTP <code> on stderr, and it keeps the token off argv, stdout and stderr. D records only the status and the comment id.

   • HTTP 201 with a parseable comment id: posted.
   • HTTP 400, 401, 403, 404 or 422, meaning the endpoint answered and refused: failed.
   • Anything else is uncertain:
     • the helper's "request failed", because curl's exit does not say whether the body was sent;
     • a kill at the deadline;
     • a 5xx or any other code;
     • a 2xx without a comment id.

4. Outcome. Take the lock and run the 8.5 path. Append the entry REQOP.outcome, referencing the attempt.

   • If the attempt is still requesting, it takes the new state.
   • If a person already resolved it:
     • agreement (resolved posted X, transport posted X) is recorded as confirmation;
     • disagreement (for example, abandoned while the transport reports 201) sets conflict and records both.
   • If the lock can't be taken, print uncertain REQOP: transport said <x>, not recorded, and exit 3. The attempt stays requesting.

Nothing is resent automatically. Replay, verify, list, next, a retry of the same op and a new op all leave an unresolved attempt alone. The CLI may print the issue URL and the marker as a hint. It never decides.

Resolution by a person:

• --posted <id>. The CLI makes one GET for that comment, under the same 30 s process-group deadline. It checks the comment belongs to the row's issue, carries the marker for REQOP, and names the round's candidate digest. If everything matches, the attempt becomes posted. If anything differs, or the GET fails, the command refuses and the attempt is unchanged.
• There is no not-posted. A missing comment doesn't prove that a delayed request will never arrive. The only definite failures are the CLI's own pre-send failures and the listed 4xx codes.
• abandon. Privileged only, with a reason and --yes. It marks the attempt abandoned and the round duplicateRisk: true. For that round, the report makes no at-most-one claim.
• Terminal states. Resolving an attempt that is posted, failed or abandoned refuses. A conflict accepts one more resolution, by either verb.

Receipts. review record is accepted from a listed reviewer, for the current round, citing the comment id and the candidate digest that was approved. A mismatch refuses. Every round is kept in review.rounds[]. On a comment round, the receipts gate both moves out of in-review toward done: in-review→done, and in-review→waiting-on-jason, which is the route for a Jason-gated row. Each needs an approval from every listed reviewer and no unresolved attempt.

Tests use a fake transport:

• a kill:
  • before the POST;
  • after the server accepted it, before the outcome write;
  • while reacquiring the lock;
• posted; each listed 4xx; a 5xx; "request failed"; a timeout kill; a 201 without an id;
• a new-op request while an attempt is requesting or uncertain: refused;
• a same-op retry after a stale view: it answers, and nothing is sent;
• a late POST after abandon: conflict;
• a late outcome after resolve --posted with the same id and with a different id;
• resolve --posted with the wrong issue, marker, round or candidate;
• a pre-send GET user mismatch, and a GET user timeout;
• the lead: a fake-transport success with login jarvis and actor lead, and a refusal when the login is anything else, sage included;
• the credential stat checks: a wrong mode, another seat's path, the default file;
• request → changes → new candidate → approval, with exact pins at every round.

In no path does the fake transport see a second POST for one attempt.

8.10 Ledger queue checks, Piece E (R8, R9, S8, S10, J8)

The checks come from the brief:

• a row naming an open issue is not done;
• the owner of an in-progress or in-review row has a registration;
• the issues a done row closes are closed;
• a required row older than 14 days is listed.

How I read the one-call restriction. The rule is in the #1506 Piece 3 brief: 2026-09-12_control-board-mvp.md, Boundaries, "no network beyond the one Gitea call". It bounds the ledger's metric sources, and the ledger README calls the full-page refusal "the cost of the brief's one-call boundary". Piece E, which Jason approved under #1508, asks about "every open Gitea issue" the queue references. The metric call cannot answer that, because it returns issues updated in range, and an open issue nobody touched that week is absent. So E cannot exist inside one call. I read Jason's approval of E as adding a separate, bounded queue-check budget. The metric source is unchanged.

Budget, per run:

Calls	Purpose
1	Metrics, unchanged.
1	Queue checks: state=open, limit 50. A full page makes the queue issue checks "incomplete".
up to 10	Queue checks: GET issues/N for issues in some row's closes that are neither in the open list nor shown closed in the metric page. Issues beyond 10 are "unknown (budget)", and the run is incomplete.

That is at most 12 calls. --no-issues makes 0 calls and prints queue issue checks: not run.

• An issue absent from the open list is unknown. Closed needs positive evidence: a closed entry in the metric page, or a GET that returns a closed issue that is not a PR.
• Today the extra calls would be at most 3 (#1504, #1505, #1506; section 7, R8).

Closure (J6, decided by Sage). closes equals issues at genesis and on add, which is the brief's literal rule. An issue is expected closed once every row whose closes includes it is done. The lead may narrow closes only with a logged reason (8.7), for example so that row 22 does not close #1503 while row 1 remains. Other disagreements print for disposition.

Liveness (S8, R9, T7). A registration carries a pid and startedAt, which is the registration time. It holds no process-start identity, so nothing is ever reported as "live" or "verified".

Class	Meaning
exempt	declared on this run with --unsupported-runtime SEAT (T3); printed
missing	no registration for (canonical root, layout repo, seat)
invalid	fails validation, or the scan errors
pid-unknown	the registration is valid but its pid is null, missing or malformed
pid-gone	the recorded pid is not alive
pid-present	the recorded pid is alive, reported as "pid present (identity not verified)"; a reused pid looks the same

The coverage line reads: liveness: N pid-present (unverified), N exempt, N pid-unknown, N missing, N invalid, N pid-gone.

Age. A row's age runs from requiredSince. A legacy row marked "unknown" was required no later than genesis. So once genesis is more than 14 days old, the row is overdue for certain, and it is listed as "age ≥ N days (legacy lower bound)". Until then its age is undecidable.

Result (T7). E prints one of three results, and never a full pass:

• fail: any known violation that has not been remediated. That covers a missing, invalid or pid-gone owner, and any issue or age violation.
• incomplete: no known violation, but something couldn't be decided. That covers:
  • an issue check that was unknown (budget), hit a full page, or was not run;
  • a pid-unknown owner;
  • an undecidable legacy age.
• reduced pass: nothing known and nothing undecided. The liveness evidence is pid presence only, and it may include exempt seats.

A verified full pass would need process identity in registrations. That is out of scope for #1508, as Sage ruled that incarnation is dropped. Sage's acceptance of the reduced gate means a reduced pass meets E. It says nothing about verified liveness.

Remediation (S10). A violation's identity is (check, row, issue). "Moved within the day" means a second dated E run on the same UTC day no longer reports that identity, and both runs are posted on #1508. A row edit alone is not remediation. A note can never clear a registration finding, because that check reads registrations, not rows.

8.11 Gate G (S8, R5, T6)

A Pi seat is launched with --fresh through its launcher (Q2) while Jason watches the board. Jason's instruction is "run scripts/mosaic queue next and do it" (Q1). The check is manual. Sage posts this checklist on #1508, with evidence, and Jason's observation is the final gate.

1. Interval and pins.

   • The interval starts at Jason's instruction entry and ends at the first successful result of the concrete work action (item 4). Input after the interval ends, such as Jason's verdict or housekeeping, is outside the audit.

   • At the cutoff, pin:

     • the session file's path and SHA-256, and its session id;
     • the launch snapshot under .pi/state/<seat>/launches/;
     • the pre-test queue.json revision;
     • the brief blob.

   • Freshness (F4, G1). The header having no parentSession rules out a fork, but it doesn't rule out an ordinary resume. So freshness is proved from the launch itself.

     Pinned Pi writes no session file before the first assistant message. SessionManager._persist keeps the header, the setting entries and the instruction in memory, then writes them all at once with an exclusive create (wx) when the first assistant message arrives (dist/core/session-manager.js, around line 739; Rocko reproduced this in round 5). So the file cannot be pinned before the instruction. Nobody seeds it, and nobody sends a warm-up message to make it appear.

     Before the launch, Sage records:

     • the listings of .pi/state/<seat>/sessions/ and .pi/state/<seat>/launches/;
     • the exact launch command line, with --fresh;
     • the UTC start time.

     At the cutoff, Sage pins the session file and the new launch snapshot. They pass only if, retrospectively:

     • the session file is absent from the pre-launch listing;
     • the launch snapshot directory is the only new entry under launches/;
     • the header's timestamp falls after the recorded start time and before the instruction;
     • the header has no parentSession;
     • the entries before the instruction are only the launch's settings (model_change, thinking_level_change), with no message, compaction or branch summary.

     Pinning the file once it first appears is allowed, as long as the cutoff pin follows.

   • Linear file. The header is session identity, not a node in the entry chain. The first entry after the header has parentId null, and every later entry's parentId is the previous entry's id. A branched file fails the gate, so branching is excluded from the demonstration, and the audited chain is the whole file from the instruction to the cutoff. All 18 recorded session files under .pi/state/*/sessions/ have this shape today.

2. Context audit. Take the SHA-256 at the start and at the cutoff of every context source:

   • the launch snapshot;
   • the committed SOUL and CONTEXT files;
   • <dataRoot>/user/USER.md, whose hash is recorded privately and whose content never goes into git or the issue;
   • the loaded skills;
   • the brief.

   Any change fails the gate. An edit that is made and then reverted inside the interval is not visible to endpoint hashes. That is covered by the cooperative rule that nobody edits these files during the test, and the report states the bound.

   Row-specific text in these sources fails the gate, with one exception: the queue data and the row's brief, which the seat is meant to discover during the test.

3. Input audit. Any user-role entry anywhere in the file after the instruction and before the cutoff fails the gate, whatever its format.

4. Execution trace. The audited chain must show, in order, with ordinary reads between the steps allowed:

   • the next call: a toolCall running scripts/mosaic queue next with the canonical root as its working directory, and its toolResult (matched by toolCallId, isError false) naming the row;
   • the brief read: a successful read of the brief named in that result;
   • the start transition: a toolCall whose actual command is scripts/mosaic queue move <row> in-progress --op <OP> … in the canonical root, with a successful toolResult carrying the receipt. The op, row and actor in the command must equal the log entry that made the transition. That entry's revision must be the first one after the pinned pre-test revision to touch the row, and its time must fall inside the interval. A receipt from a retry ("already recorded") shows a lookup, not the origin, and fails this item. Echoing the op, a dry run, or a failed command fails it as well;
   • the work: a concrete action from the brief's "What ships" with a successful result or a visible effect. Proposing a tool call is not enough.

   If the output was lost or truncated, preserve whatever evidence can be recovered, and declare the link inconclusive. Inconclusive is not a pass.

5. Verdict. Jason's observation, in one sentence on #1508.

This is cooperative evidence. A helper that runs the same command outside the session isn't excluded. The checklist does rule out the observable non-execution cases.

Positive controls (G1). The audit must pass a genuinely fresh session before Gate G relies on it:

• a unit fixture built with the pinned SessionManager, with no model: a new session, then settings, the instruction and a synthetic assistant message. The freshness and linearity rules pass it;
• the recorded fresh session files under .pi/state/*/sessions/. The linearity and prefix rules pass them.

No pre-instruction model turn is needed for either.

Negative controls, reviewed by hand against recorded or constructed session files. Each one must fail item 4:

• an op that is only echoed;
• a start command with a nonzero or error result;
• a seat reusing an op a helper recorded earlier;
• a forked session (parentSession present);
• an ordinary resumed session: no parentSession, but it holds earlier messages or was already in the pre-launch listing;
• a session with a compaction entry before the instruction;
• a branched file, including one where the start sits on an abandoned branch;
• a file whose first entry after the header points at the header's id, or at any other entry;
• a brief that was never read;
• a work command that failed.

Selection among competing rows is covered by unit tests, not by this demonstration.

8.12 Committing the queue (S5, T5, F1, F3)

The CLI never commits (Q3). The lead runs scripts/queue-commit.sh -m MSG. It uses a temporary index, as Sage directed, and commits exactly the tested bytes. Nothing anyone else has staged is swept in. A pre-commit guard stops ordinary commits from reverting the queue.

The queue guard (F1). scripts/git-hooks/pre-commit is versioned. It refuses any git commit whose index entries for docs/plans/queue.json or docs/plans/QUEUE.md differ from HEAD's (git diff --cached --quiet HEAD -- <both paths>). Its message names the fix: git reset -q -- docs/plans/queue.json docs/plans/QUEUE.md. Only queue-commit.sh changes those paths in a commit, and it uses commit-tree, which runs no hooks.

• The guard is installed as <canonicalRoot>/.git/hooks/pre-commit by queue-commit.sh --install-hook, which is privileged.

  • It copies HEAD's blob, mode 0755.
  • It refuses if a different pre-commit hook exists or core.hooksPath is set.

• Active, not just present (G2). Matching bytes are not enough. With the same bytes but no executable bit, git skips the hook, and Rocko reproduced the revert from queue 12 to 10. A later core.hooksPath selects a different hook while the checked file stays the same. So on every invocation, queue-commit.sh checks all of these:

  • .git/hooks/pre-commit is a regular file, not a symlink, owned by the user and executable, and its bytes equal HEAD's scripts/git-hooks/pre-commit;

  • git config --show-scope --get-all core.hooksPath is empty in every scope;

  • the canary. Git itself runs the hook it would run for a commit. With a new temporary index read from H, git hook run pre-commit must exit 0. After one queue entry in that index is changed to a different blob, it must exit nonzero, and its stderr must carry the guard's own refusal line. A hook git can't find ("cannot find a hook named pre-commit") fails the clean run, so a missing, non-executable or redirected hook refuses.

    I checked this with git 2.55.0 in a scratch repository. An active hook gave a clean exit of 0 and a changed exit of 1. A non-executable hook and an alternate core.hooksPath each gave 1 on the clean run.

  The checks run at step 1, and again just before update-ref in step 7. If either run fails, the script refuses before publishing. They use the lead's normal git environment. A seat's per-command overrides aren't visible to them, which is why 8.5 forbids those overrides.

Why this closes Rocko's schedule. After update-ref publishes C, the shared index still holds H's queue entries, and those differ from C's.

• Any ordinary git commit is refused by the guard until step 8 reconciles those two entries.
• A commit whose guard ran before update-ref loses at its own HEAD update. git commit updates HEAD with the parent it read as the expected old value, so it fails with "cannot lock ref 'HEAD': is at C but expected H".
• The reverse order is safe too: if that commit lands first, the lead's update-ref fails.

I checked all three cases with git 2.55.0 in a scratch repository on 2026-09-26. So there is no window in which an ordinary commit can put the old queue on top of C.

If step 8 can't run, the guard is the maintenance hold Rocko asked for, as long as it stays active under 8.5's rule. Ordinary commits stay refused, each naming the fix, until someone reconciles. No queue lock is held across tests or git.

Sage's narrower proposal. Of its three parts, the pre-commit check is the one that closes F1, and it is adopted. The other two don't close it, and they are not adopted:

• The shared index empty of everything else. The check runs before update-ref, and a seat can stage and commit after it. Even with an otherwise clean index, the index's queue entries are H's, so any commit in the window would revert the queue.
• Under the queue lock. Ordinary committers never take the queue lock.

The existing guard in step 1, that no queue path is staged, stays.

Bootstrap (F3):

1. The queue implementation lands through normal, review-gated source integration: packages/queue, the scripts/mosaic dispatch, queue-commit.sh, the guard and test-queue.sh. HEAD then has the code and no queue.json.
2. queue-commit.sh --install-hook, which is privileged.
3. queue genesis (8.2) in the working tree.
4. queue-commit.sh --genesis -m MSG, the first queue commit.
   • It is allowed only when HEAD has no docs/plans/queue.json and the snapshot's log holds only the genesis entry. Genesis's canonicalRoot and branch must match 8.3, and its migration-map blob id must exist in HEAD.
   • --genesis with a base present refuses, and so does a missing base without --genesis.
   • No op can come in between, because every mutating verb refuses until genesis is committed (8.2).

Steps:

1. Guard.

   • Run the active-guard checks above: file, mode, bytes, core.hooksPath and the canary.
   • Refuse if the shared index has staged changes to either queue path (git diff --cached --quiet HEAD -- docs/plans/queue.json docs/plans/QUEUE.md). Seats never stage queue files.
   • The branch must be the genesis branch.
   • Record H=$(git rev-parse HEAD), and whether H:docs/plans/queue.json exists (git cat-file -e). Absent requires --genesis; present forbids it.

2. Snapshot. scripts/mosaic queue snapshot --out DIR takes the lock and runs 8.5 steps 1–2. It requires a confirmed tail and a current view, copies both files' bytes into DIR (a new mktemp -d outside the repository), and releases the lock. The two files come from one revision because they are read under the lock.

3. Base (F3). The script writes the base into DIR from the canonical object database. Unless --genesis is set, that is git -C <root> cat-file blob H:docs/plans/queue.json > DIR/base.json. It also writes DIR/base.id with H and H's tree id. The validator reads only files in DIR. It runs no git, and resolves nothing from its working directory.

4. Verify with HEAD's code. Unpack git -C <root> archive H into a new temp directory. There, run its node --test packages/queue/tests/ and its queue verify --snapshot DIR --base-file DIR/base.json, or --base-absent for genesis. It runs with GIT_CEILING_DIRECTORIES set, so no repository is found around it. Snapshot verify checks only this:

   • the given pair is valid and the table is its render;
   • the log extends the base's log, or is genesis alone when the base is absent.

   It does not certify live witness continuity (F2). That is canonical verify's job, under the lock. Dirty working copies of the queue code play no part.

5. Blobs. B1=$(git hash-object -w DIR/queue.json), and B2 the same for DIR/QUEUE.md.

6. Tree. In a temporary index at a path that doesn't exist yet:

   • export GIT_INDEX_FILE=$(mktemp -d)/index;
   • git read-tree $H, which creates it;
   • git update-index --add --cacheinfo 100644,$B1,docs/plans/queue.json --cacheinfo 100644,$B2,docs/plans/QUEUE.md;
   • T=$(git write-tree).

   Git 2.55 also accepts an empty file as an index, but the plan doesn't rely on that. Then check that git diff-tree -r --name-only $H $T lists only those two paths.

7. Commit.

   • C=$(git commit-tree $T -p $H -F msgfile).
   • Run the active-guard checks again. If they fail, refuse; nothing has been published.
   • git update-ref -m queue-commit refs/heads/<branch> $C $H. This fails if the branch has moved since step 1. If it does, nothing is lost: start again.
   • commit-tree runs no hooks, the guard included. There are no other hooks today.

8. Reconcile the shared index.

   • Check again that git rev-parse HEAD is C. If it isn't, which needs a bypass, stop, report, and don't touch the index.
   • Check that the shared index's two entries (git ls-files -s) still equal H's. For genesis, queue.json must be absent. If they differ, someone staged a queue path: stop and report.
   • Run git reset -q -- docs/plans/queue.json docs/plans/QUEUE.md. It points those two entries at C's blobs and touches nothing else.
   • If the index is locked by another git process, print that command and exit 3. The guard holds ordinary commits until it runs.

Why not something simpler: git commit --only -- <paths> also builds a temporary index, so it wouldn't sweep in other staged files either. But it commits the working-tree bytes as they are at commit time, which may no longer be the tested snapshot, and it runs hooks and the editor.

Review-gated source is integrated the same way. The prospective tree comes from H plus the blobs of the approved manifest paths.

• review verify-commit ID $T must pass on that tree before commit-tree.
• The suites run from git archive $T unpacked, not from the working tree.
• If the approved bytes are no longer on disk, integration refuses (8.9).

Ordinary source commits by seats go through the guard. The only way it refuses them is a queue path that is staged or not yet reconciled.

Committing still needs its own authorization. This procedure doesn't give it.

Tests, in a scratch repository:

• F1:
  • pause right after update-ref, then make an ordinary commit of unrelated staged source. The guard refuses it. After step 8 it commits, and the queue stays at C's revision;
  • a commit whose guard ran before update-ref: its HEAD update fails;
  • step 8 while index.lock is held: exit 3, and ordinary commits are refused until the printed command runs;
  • HEAD changed before update-ref: refuse;
  • a shared-index change during the procedure is not committed;
  • a queue path staged after update-ref: step 8 stops and touches nothing;
  • a missing or different hook: queue-commit.sh refuses;
  • a hook with the same bytes but no executable bit, a symlinked hook, and a newly set core.hooksPath in the local and the global scope. Each makes queue-commit.sh refuse before update-ref;
  • the guard deactivated between step 1 and step 7: refuse at the step-7 recheck;
• bootstrap (F3):
  • an implementation-only HEAD, then genesis, then the --genesis commit, then a later extending commit;
  • --genesis with a base present refuses;
  • an absent base without --genesis refuses;
  • an op after genesis but before the first commit refuses;
  • the archived validator, run in a directory outside any repository;
• general:
  • an unrelated staged file stays staged and uncommitted;
  • a queue write after the snapshot is not committed;
  • the committed blobs equal the snapshot bytes;
  • a snapshot whose log does not extend the base refuses;
  • verify-commit on a prospective tree with one changed manifest path fails.

8.13 Brief checks (S10, R13)

On add and on any brief change, the brief must be:

• a repo-relative path whose realpath is inside canonicalRoot;
• a regular file, not a symlink;
• present in HEAD's tree (git cat-file -e HEAD:<path>). A brief that is only staged is refused.

The anchor heading must occur exactly once in the HEAD blob. The row records the blob id.

verify --current rechecks the briefs of non-terminal rows against HEAD and reports drift. Replay never does this. The five untracked briefs (section 7, R13) must be committed before genesis.

The working brief (T8). A seat reads the brief from the working tree, not from HEAD. So start computes the git blob id of the working file's bytes in-process, as SHA-1 over blob <len>\0 plus the bytes, with no git write. It refuses if that differs from the pinned blob, and next flags the row (8.8). A re-pin is a privileged brief change. The new version has to be committed first, and the row then records the new blob.

8.14 Acceptance checklist

• A:

  • tests for every transition and refusal in 8.7;
  • the op-id rules in 8.6;
  • every lock schedule in 8.4 and write schedule in 8.5;
  • the canonical checks in 8.3, with worktree, second-clone, detached-HEAD and wrong-branch fixtures;
  • genesis refusals (8.2), witness, sync and accept-history (8.5);
  • the claim lifecycle, add defaults and J4/J5 cases (8.7);
  • the working-brief check (8.13);
  • the queue-commit.sh tests, including the guard and bootstrap (8.12);
  • the unlocked-read race tests (8.4, 8.5);
  • byte-stable render;
  • next ordering among competing rows.

  scripts/test-queue.sh passes. Genesis runs from the reviewed migration map. The README states:

  • the cooperative trust boundary and the git side of the protocol (8.5);
  • the platform assumptions and that power loss is untested;
  • the unacknowledged-op rule;
  • the same-seat claim limit;
  • the check-to-rename windows.

• C: BRIEF-TEMPLATE.md, plus two owner-accepted briefs recorded on #1508.

• B: the AGENTS.md cadence line and the five CONTEXT.md lines (8.1) name scripts/mosaic queue next. A fresh launch snapshot shows the new text. Then Gate G (8.11), including the negative controls.

• D: the 8.9 tests. Then one full live round on a real issue with the per-seat tokens read in place (8.9), with zero new files under docs/plans/reviews/.

• E: the 8.10 tests with a fake gitea-api.sh, covering each result level and the legacy age bound, and node --test packages/ledger/tests/ passing. One dated run with the coverage line and its result level is posted on #1508.

• Order: A with C, then B, then Gate G. D and E come after A, and E may go before D (Sage, 2026-09-26). D's live round uses the per-seat tokens Jason ruled on (8.9).

8.15 Decisions

Jason told Sage to decide as lead. Every item below is decided by Sage 2026-09-26; nothing in this plan waits on Jason except D's live posting round (Q4). Round 5: Jason ruled on D's credentials the same day (8.9), so nothing waits on him now.

Item	Decision	Where
Q1	Gate G's instruction is "run scripts/mosaic queue next and do it"	8.11
Q2	Gate G runs on a Pi launcher with --fresh; next without identity refuses	8.8, 8.11
Q3	the CLI never commits; the lead commits the queue files after test-queue.sh	8.12
Q4	D posts only with an explicit per-seat credential file (MOSAIC_GITEA_CREDENTIAL_FILE) and refuses the default file. Where seat tokens come from is Jason's; the live posting test waits for him, the build does not. Round 5: he ruled that each seat's token is read in place (8.9)	8.9, 8.14
J1	owners progress their required rows; reorder, park and clearing required are Jason-only	8.7
J2	cooperative trust model; claimed actors, detection through replay and E	8.7, README
J3	briefs mandatory; queued = brief exists, not accepted	8.7
J4	only jason unparks, to queued	8.7
J5	in-review→done allowed where gateOwner is not Jason, with logged evidence	8.7
J6	closes = issues; narrowing needs a logged reason	8.7, 8.10
J7	dropped	—
J8	12 calls at most, 0 with --no-issues, "unknown (budget)" past the limit	8.10
J9	Sage writes a parked stub brief for row 8, which keeps id 8	8.2
Reduced liveness gate	accepted, labelled reduced	8.10
E before D	allowed	8.14
8.0 single file	accepted; no journal, no queue repair; directory fsync on every write	8.0, 8.5
8.4 link()	accepted in place of a literal O_EXCL	8.4
8.3 root in genesis	accepted; no config key	8.3

Two points where I resolved Sage's wording:

• For J4 and J5, "as proposed in 7.2" replaced the 8.7 build defaults that referenced the brief (parked terminal; in-review→done refused). The 7.2 proposals are what the matrix now says.
• J4's return state is queued, not the pre-park state, so a possibly stale brief is re-accepted before work resumes.

Round 4: choices of mine for Sage to confirm. None of these needs a new owner ruling. Each is a lead-level specification choice made in answer to T1–T8:

• The witness file .git/mosaic-queue.head (8.2). It is a check value, not a second store. Without it, a rollback that loses ops can't be detected, which is what you asked for in T2.
• Pinning the branch alongside the root (8.3). Moving the queue to next or main later is a reviewed migration.
• accept-history is privileged, needs --yes and a reason, and gives up deduplication for the lost range (8.5).
• No not-posted resolution. A privileged abandon records the risk of a duplicate instead (8.9).
• The failed-4xx allowlist: 400, 401, 403, 404 and 422. Everything else is uncertain (8.9).
• add defaults: gateOwner is jason, and reviewers is empty (8.7).
• The op suffix .outcome is reserved (8.6).
• The filesystem allowlist: ext4, xfs, btrfs, and tmpfs for tests (8.5).
• E never prints a full pass. Its best result is reduced pass (8.10).
• queue-commit.sh uses commit-tree, which skips hooks. There are none today (8.12).

Sage confirmed all of the above on 2026-09-26.

Round 5: lead-level choices for Sage to confirm. None of these needs an owner ruling.

• The queue guard is a pre-commit hook in the canonical checkout (8.12). It runs on every seat's git commit, and refuses only when a queue path is staged or not yet reconciled. Of Sage's proposal, this part is adopted. The clean-index and queue-lock parts are not, because they don't close F1.
• Genesis is committed before any op (8.2), with a --genesis exception for an absent base (8.12).
• Unlocked reads read the witness first and recheck under the lock before any adverse report. There is no retry loop (8.4).
• Gate G requires a linear session file and proves freshness from the launch (8.11).
• Caller op ids are capped at 72 characters (8.6).
• "There are none today" (above) no longer holds once the guard is installed. commit-tree skips the guard on purpose, and 8.12 step 8 plus the guard cover that gap.
• D only stats the credential file, and never opens it. The lead's jarvis token follows the seat rule (8.9).

Sage confirmed the round-5 choices on 2026-09-26. She also set the jarvis Gitea token path, and ruled that a write:repository 403 in the first live round is an expected finding (8.9).

Round 6. No new lead-level choice. Two of Rocko's corrections:

• Gate G's pins are taken before the launch and at the cutoff, never on a session file before the instruction;
• the guard is checked for being active on every invocation.

8.16 Where each round-2 finding is resolved

Finding	Resolved in
S1 lock	8.4
S2 torn append	8.0 (one file, rename only), 8.5
S3 view drift and hand edits	8.5
S4 retry identity	8.6
S5 commit integration	8.12
S6 one history, genesis, replay	8.2, 8.3
S7 prerequisites, field permissions, closure	8.7, 8.10
S8 identity evidence	8.8, 8.10, 8.11
S9 at most one POST	8.9
S10 candidates, briefs, remediation	8.9, 8.13, 8.10
S11 contradictory body	this section is the specification (banner at the top)

The round-2 modifications:

• R1's lock is replaced by 8.4, which never reclaims automatically.
• R3's cooperative writer stays, restricted to the canonical checkout.
• R6's claims become seat names with no incarnation.
• R7 becomes 8.9's uncertain state, with no resend.

8.17 Where each round-3 finding is answered

Finding	Answered in
T1 visibility vs durability	8.0 note, and 8.5: the platform, the three points, steps 6–10, uncertain exit 3, sync, the fault-injection tests, and the statement that power loss is untested; D sends only after a durable intent (8.9 step 1)
T2 git rollback	8.2 witness; 8.5 step 7 unchanged check, "history lost" refusal, manual recovery replacing "restore with git", accept-history, and the git side of the protocol; 8.3 branch pin; 8.12 step 3 (committed history only grows)
T3 lock and gate classification	8.4: classification order with host before pid, --check-gate, release by inode and full record, unlock never takes the lock, O_EXCL temp with checked writes, other link errors refuse
T4 requesting and outcomes	8.9: the attempt states, where requesting blocks as uncertain does; REQOP.outcome entries; conflict; resolve --posted verified by GET; abandon in place of not-posted; the 4xx allowlist; process-group kill; move in-review as the request. 8.5 step 3 and 8.6: lookup before the view check
T5 shared-index commit	8.12: temporary index, blobs from the tested snapshot, commit-tree plus update-ref against the expected HEAD, tests from git archive, prospective-tree verify-commit
T6 Gate G execution	8.11: interval and pins, the ancestry chain, toolCall/toolResult matching, a first transition inside the interval, the work result, the context exception, hash bounds, the negative controls
T7 unverified liveness	8.10: pid-unknown; the results fail, incomplete and reduced pass, with no full pass; the legacy age lower bound
T8 internal consistency	8.7 add rules and claim lifecycle, with J5 precedence and settlement; 8.13 working-brief check; 8.2 genesis bootstrap; 8.3 git -C with absolute paths; 8.1 and 8.14 B's context files

8.18 Where each round-4 finding is answered

Finding	Answered in
F1 HEAD/shared-index gap	8.12: the queue guard, why it closes the schedule, step 8 reconciliation with its rechecks, the guard as maintenance hold, the tests. 8.5: the commit side of the cooperative protocol. 8.1: the hook file
F2 unlocked reads	8.4: witness-first order, and a locked recheck before any adverse report. 8.5: the unlocked-reads bullet and the race tests. 8.12 step 4: snapshot verify does not certify witness continuity
F3 bootstrap and base	8.2: genesis committed before any op. 8.12: the bootstrap sequence, --genesis, the base written from the object database, the validator isolated from any repository, the temporary index at a fresh path
F4 Gate G freshness	8.11: freshness proved from the launch, a linear file, input audited across the whole file, new negative controls
F5 op-id length	8.6: caller ids ≤ 72, log ids ≤ 80, boundary tests
Rocko's T3 note (quiescence)	8.4: gate removal only once no queue command is running
Rocko's T4 note (bounded GETs)	8.9: GET user and resolve --posted under the 30 s process-group deadline
Jason's credential ruling	8.9 credentials; 8.14 D

8.19 Where each round-5 finding is answered

Finding	Answered in
G1 Gate G pins evidence Pi hasn't written yet	8.11: pre-launch receipts (listings, command line, start time), the retrospective audit at the cutoff, the header exempt from the entry chain with the first entry's parentId null, positive controls with no pre-instruction model turn, and a new negative control
G2 matching bytes don't prove the guard runs	8.12: file, mode, bytes, every-scope core.hooksPath and the git hook run canary, at step 1 and before update-ref, with tests. 8.5: disabling or overriding the guard added to the forbidden bypasses, and the trust limit stated
Lead login (Rocko's note)	8.9: the expected login is jarvis for the lead, whose actor stays the lead, with a success and a wrong-login test

Log

• 2026-09-26: first version, sent to Sage.

• 2026-09-26: Sage's decisions folded in (Q5–Q9, fixes 5.3 and 5.4). Q1–Q4 marked as the open set for Jason. Section 0 added.

• 2026-09-26: round 2. Section 7 disposes of Rocko's R1–R14 (ten accept, four accept-modified, none rejected); 7.2 lists J1–J9 for Jason. Q3 recommendation changed to no automatic commit. Q6 and Q7 amended by Sage. Body edits in sections 0–5 point at section 7.

• 2026-09-26: round 3. Section 8 added as the active specification after Rocko's round 2 (revise, b3a2d72a…e70f4). It follows Sage's direction: manual recovery verbs, a lock with no automatic reclaim and an unlock gate, op ids as the only retry identity, canonical checkout only, no incarnation, at most one review POST. One departure: the log lives inside queue.json, so there is no journal file and no repair verb (8.0). The J8 budget and reading are in 8.10. Banner and section 0 note added; sections 1–7 are unchanged and superseded where they differ.

• 2026-09-26: Sage's round-3 rulings recorded (8.15): 8.0 single file, link() lock and genesis root accepted, J8 budget accepted, and Q1–Q4, J1, J2, J4, J5, J6, the reduced liveness gate and E before D decided by Sage as lead. 8.0, 8.4, 8.7, 8.10 and 8.14 updated to match. J4 and J5 follow 7.2's proposals rather than the earlier build defaults.

• 2026-09-26: round 4. Rocko's round 3 (revise, 13a32804…a274, T1–T8) answered in section 8: durability kept separate from visibility, a rollback witness with manual accept-history, host-first lock classification, attempt states for review requests with no not-posted, a temporary-index commit procedure, Gate G tied to its execution trace, E result levels with no full pass, and the add, claim, brief and genesis consistency fixes. 8.17 maps T1–T8. Lead-level choices are listed in 8.15.

• 2026-09-26: round 5. Rocko's round 4 (revise, fcb8933d…efcff, F1–F5) answered in section 8:

  • a pre-commit queue guard plus shared-index reconciliation (F1), checked in a scratch repository;
  • witness-first unlocked reads with a locked recheck (F2);
  • a genesis-first bootstrap and an isolated validator given its base (F3);
  • Gate G freshness proved from the launch, with a linear file (F4);
  • caller op ids capped at 72 characters (F5).

  Jason's per-seat credential ruling is folded into 8.9. 8.18 maps the findings.

• 2026-09-26: round 5 follow-up. Sage confirmed the round-5 choices. 8.9 now names the jarvis Gitea token path under the seat rule, and treats a write:repository 403 in the first live round as an expected finding.

• 2026-09-26: round 6. Rocko's round 5 (revise, 3b031a70…177e, G1, G2) answered in section 8:

  • Gate G freshness proved from pre-launch receipts and a retrospective audit, because Pi writes no session file before the first assistant message. The header is out of the entry chain (G1);
  • the guard checked as active on every invocation, including a git hook run canary (G2), checked in a scratch repository;
  • the lead's expected login is jarvis. 8.19 maps the findings.

• 2026-09-27: correction from Filbert's Piece D review round 1 (C1), ruled by Sage. The transition table let in-review→waiting-on-jason pass with no reviewer approvals, so a Jason-gated row could close without its reviewers. That move now carries the in-review→done checks on a comment round; the table and 8.9's receipts paragraph say so.