stack/agents/rocko/work/queue-as-data-adversarial-2026-09-26.md

Queue as data: adversarial plan review

VERDICT: revise

Rocko, 2026-09-26, for Sage / #1508. Read-only investigation; this report is the only file written for this assignment. No commits, issue writes, credentials read, live launches, or source changes. This is a design review, not a claim that unimplemented queue code has failed tests.

Reviewed Filbert's plan after the Q5–Q9 decisions and the final section-5 proposal/decision distinction were folded in:

• agents/filbert/work/queue-as-data-plan-2026-09-26.md, SHA-256 59d5a22f1f67426237761341b686c3a9dcf0dffb2d353bab8dd2f9741bcc1fdb.
• Brief docs/plans/2026-09-13_queue-as-data.md, SHA-256 12d8d39f95f40e7d1e93f3a4420390152bbf52d04a6596b48d443512ce559061.
• HEAD 21e3e908b6f64d3eba202480fede05e174799e1d plus current shared working files: AGENTS, QUEUE, scripts/mosaic, seat, control-board, ledger, launcher and Gitea helper sources. No packages/queue exists yet.

High means a credible loss of state, authority bypass, or false acceptance; medium means a material workflow or evidence defect. Findings against decided items request reconsideration or clarification by Sage; they do not silently reverse those decisions. Q1–Q4 remain with Jason.

Findings

R1 — High: the two-file write has no crash/recovery contract

Where: plan 2.A and 3.A, atomic write under a lock; test kills only before rename.

Scenario: A reads revision 10, installs revision 11 of queue.json, then dies before QUEUE.md is rendered. JSON readers and humans now select different work. Separately, a standalone renderer can read revision 10 before B's write and replace the Markdown with revision 10 after B has installed revision 11. A timeout-based stale-lock remover can also admit B while a slow A is alive. Atomic rename prevents a torn individual file, not these outcomes.

Fix: specify one canonical lock identity across the checkout and its compatibility symlink; acquire it before reading, not merely before writing. All mutations and standalone render use it. Generate both outputs from one validated revision; record a durable transaction/revision and define recovery for every interruption point. Readers must detect an incomplete pair rather than treating it as current. Prefer kernel-released locking or provable stale owner detection; do not steal a lock because a deadline elapsed. Bound waits. Document fsync behavior if surviving a host crash is promised.

Acceptance: race add/add, move/note and render/write through both checkout paths; kill after each file replacement and before/after commit; inject disk errors and a dead lock holder. Recover one acknowledged operation exactly once, or refuse with a concrete recovery instruction. Never erase a completed neighbor's update.

R2 — High: Q3's path-limited commit still captures another author's work

Where: Q3; AGENTS invariant 8.

Scenario: someone has an uncommitted change to QUEUE.md's hand-written header or historical footer. git commit -- queue.json QUEUE.md includes that entire file, not just the generated table. A concurrent ordinary commit can also capture the queue between its write and auto-commit: it does not honor the queue lock. An index-lock or hook failure leaves already-mutated queue state without the promised commit, and an unsafe rollback could erase a later writer. Git's index lock is not a lock over the whole operation.

Fix: default auto-commit off until Q3 is settled. If authorized, require clean queue paths relative to the intended baseline, no conflicting staged versions, no merge/rebase, and the authorized branch; serialize all relevant commit writers through an agreed repository protocol. Freeze and validate the exact prospective file contents, check HEAD/revision before committing, and define retry/recovery without reset/checkout of others' changes. A queue lock alone cannot enforce cooperation by arbitrary host git commands.

The statement that a validator means invariant 8 holds is false: schema validation is not the applicable suites. Identify the required checks and bind their receipt to the actual prospective content/code version. Absence of a shell suite wrapper does not exempt existing Node package tests.

Acceptance: pre-dirty header, partially staged queue file, unrelated staged files, competing ordinary commit, hook failure, and changed HEAD. Verify both the committed tree and preservation of the other author's index and working changes. No push authority follows from any local commit.

R3 — High: single-writer checks validate appearance, not provenance

Where: 5.9, 3.A, migration and render --check.

Scenario: hand-edit a row from queued to done, run render, and both schema validation and render --check pass. A Markdown hand edit is silently erased by the next successful CLI mutation, before the suite ever checks it. A merge can produce valid JSON with illegal transitions or removed rows; two clones can independently allocate the same new id. A fresh clone has no local lock installation or uncommitted audit trail and cannot reconstruct the claimed writer from a matching table.

Fix: check for unexpected drift before mutating or rendering, refuse ambiguous markers and refuse to overwrite unexplained manual changes. Define a reviewed genesis/migration and validate each subsequent operation against its parent revision, including immutable IDs, deletions and authority rules. Use a committed operation history or another explicitly authorized receipt scheme, with merge reconciliation and fresh-clone validation. Keep a high water mark/tombstones for retired IDs, including removed row 7. If multiple clone writers are out of scope, refuse their integration until reconciled; a per-checkout lock does not solve that problem.

Be honest about the boundary: code running as the same host user cannot prevent that user from rewriting both data and receipts. Without an enforced integration boundary, this is a cooperative writer with drift detection, not tamper-proof authority. Hooks alone would not fix fresh clones and are outside Piece A's brief anyway.

Acceptance: valid-but-illegal hand-edited JSON with regenerated Markdown, deleted highest id, duplicate-id branch additions, conflicting merge, fresh clone, missing/duplicate render markers, and preexisting Markdown drift.

R4 — High: identity attribution is still being used as authorization

Where: Q5, 3.A authority tests, 5.3 and 5.8; brief iron-clad point 5.

Scenario: a seat runs --by jason or sets MOSAIC_AGENT_NAME=sage and moves a protected row. If assign lacks the move permission check, it can instead assign another seat's row to itself and then move it. Even without spoofing, the proposed rule only restricts clearing required, while the brief says only Jason moves required rows. These are different rules.

Fix: separate claimed attribution from verified authority. Q5 can map the new lead's queue role, but does not turn an environment variable into proof or grant managed-worker policy authority. Specify the permitted actor for every mutating verb/field, including assign, dependencies, required, gate ownership, notes and terminal rows. Either retain an explicit reviewed human gate for protected mutations or have Jason accept the limited cooperative trust model; weekly reporting is detection after the fact, not enforcement. Reconcile the exact required-row exception before building.

Acceptance: forged identity, reassignment bypass, dependency/gate edits by an ordinary seat, edits to done/parked rows, and every operation on a required row. No roles/*.json expansion is implied by this review.

R5 — High: Gate G can appear to pass with extra human help or no work

Where: Gate G setup and pass evidence; ledger.mjs messageKind (line 78) and readSessions (line 92); agent-host-dev.sh context and fresh handling.

Scenario: Jason supplies a correction through the board or a lead relays it. The ledger counts it as board/agent, leaving exactly one human message. --fresh creates a new conversation but preserves old session files and loads shared SOUL/USER/CONTEXT/skills; a task-specific hint there can make the demo pass without discovering the assignment. Another seat can move the row using the test seat's claimed identity. Reading the brief and moving the row alone is also not evidence of actually starting its work.

Observed read-only probe: messageKind returns human for the initial instruction, board for [dragon-lin:control-board -> dragon-lin:rocko] followed by a human correction, and agent for a similarly prefixed Sage relay. The new [from: sage (...) -> to: rocko (...) class=actionable] header is classified human. Table 2 aggregates a seat's sessions over the date range, not an identified Gate G session. It is unsuitable as the sole acceptance counter in either direction.

Fix: pin the exact fresh session id, initial context/brief/queue revisions, test interval and command output. Audit all input channels in that interval; distinguish the initial instruction from further human input regardless of routing. Preserve generic governance context but exclude task-specific pre-coaching. Require a concrete first authorized work action tied to the returned row and that session. Jason's observed pass/fail remains authoritative; do not infer it from the row or git author. Allow normal prerequisite reads instead of requiring the literal first filesystem read to be the brief. A commit is not necessary proof of G and must not bypass Q3 or suite requirements.

Acceptance: negative controls with a board correction, relayed hint, resumed session and row moved by a helper must fail. Use unit tests with competing eligible rows to test selection: the single-row demo cannot.

R6 — High: dependencies and next do not prevent unauthorized starts

Where: Q8, section 1, 3.A and 5.11.

Scenario: next skips a dependent row, but the seat directly runs move ID in-progress and bypasses the filter. Two sessions of the same seat both read next, then both start the same work; a state of in-progress does not distinguish resume by the owner session from a second claimant. An in-review row returned to its author may cause premature continuation; a reviewer can repeatedly receive a row it already reviewed if its receipt is not represented.

Fix: enforce prerequisite and authority predicates at transition time under the lock, not only in selection. Define atomic claiming or an explicit single-active-session assumption with detectable conflict. Return the action role (implement, resume, review, wait) and track review round/receipt so review dispatch has a stopping condition.

There are unresolved semantics: Q8's done-only dependencies cannot express the brief's row-6-blocked start exception. State-priority ordering differs from the existing first-eligible-row cadence. after alone cannot express every arbitrary owner priority, especially between active rows. Decide these once and update the brief/cadence together. Test that required work cannot be subordinated to ordinary queued work through dependencies.

R7 — High: posting then recording cannot promise exactly one review request

Where: 2.D, 3.D, 5.14; scripts/gitea-api.sh.

Scenario: Gitea accepts a comment but the response is lost, or the CLI dies before storing its id. The row remains unchanged and retry posts a second request. Conversely, a posted request survives a failed local commit. A repository lock cannot roll back the remote side effect. The existing helper supplies an ordinary POST, not an exactly-once transaction.

Fix: define a durable operation id containing row, revision, review round and candidate digest; persist intent before sending. Include the id in the request, reconcile uncertain outcomes by lookup/readback, and refuse blind retries if delivery cannot be determined. Specify outbox/recovery state and bounded lock behavior. An authorized token path also needs an expected account check; checking that the path differs from the default is not proof of the intended poster. Do not read or provision tokens before Q4.

Acceptance: accepted POST with dropped response, crash before receipt, duplicate retry, concurrent moves, stale candidate and local commit failure. Fake success/failure alone does not test these boundaries.

R8 — High: missing from the open list does not establish closed

Where: Q7 and 2.E.

Scenario: a row references a typo/nonexistent issue, a deleted issue, a PR number or an inaccessible item. It is absent from a complete open-issues response and the proposed algorithm declares it closed. Even a short page only shows that that response is short; it does not prove each referenced number is a known issue. A done row can therefore pass with no closure evidence.

Fix: retain the additional open-list call and full-page refusal, which are useful, but represent absent as unknown unless there is positive issue existence/type/state evidence. Fetch/cache positively identified referenced issues under a revised call budget, or report incomplete evidence instead of success. Bound cache age and detect changed scope. Specify --no-issues as unknown queue issue checks, not zero violations.

Acceptance: nonexistent/deleted/PR references, denied access, malformed responses, a full page and no-issues mode. This is a requested correction to decided Q7, not an instruction to silently implement another fetch policy.

R9 — High: the liveness exemption can turn missing evidence into green

Where: Q6, 2.E and 3.E; scan.mjs lines 272–307.

Scenario: remove a native seat's registration and it gets the same non-violation label as a T3 seat. loadRegistrations returns records plus errors; it does not check liveness and loads multiple layouts. Matching a seat name alone can select a fleet/other-workspace record. A dead or reused PID is not evidence of the intended active session. Corrupt records must not become the missing-registration exemption.

Fix: preserve Q6's prohibition on T3 probing, but distinguish explicitly unsupported runtime, missing expected registration, invalid record, stale record and live matched record. Match repository/layout/session identity. Propagate scanner errors. Show coverage/unknowns alongside violations and do not call E fully passed on zero violations when liveness was untested. Record the owner's explicit acceptance of a temporary reduced gate.

Acceptance: missing native registration, corrupt record, duplicate seat across layouts, wrong workspace, dead PID, unknown PID and an exempt T3 seat.

R10 — Medium: history needed for E is absent from the schema

Where: 5.3, 5.8 and 5.12; brief E's age and same-day remediation rules.

Scenario: queue note refreshes updatedAt every week, making a long-neglected required row appear young. A row is changed twice between ledger runs and updatedBy remembers only the last writer, so E cannot list every protected change as 5.8 promises. Removing a row and having no delete verb does not prove an id was never reused. A single latest timestamp also cannot prove each observed violation was remedied within the day.

Fix: define stable createdAt/requiredSince, operation history and audit retention, with explicit time zone and first-observed violation evidence. Do not depend on optional Q3 commits for mandatory checks. If a journal is chosen, make corrections new entries and place it in a dedicated directory; do not rewrite BUILD-LOG, SESSIONS or existing append-only runtime logs. Terminal required rows should not age forever as outstanding work.

R11 — High: some section-5 fixes change owner requirements, not details

Where: 5.6, 5.7, 5.10, 5.13 and 5.14; brief A/C/D and iron-clad point 3.

Scenario: the builder follows “settle in A's round” and makes brief optional, reopens parked rows, allows completion without Jason, or changes the issue/gate semantics. Those are externally visible requirements changes. The brief explicitly demands an existing brief for every row and says parked/done rows never change. A queued row can have an existing planning brief not yet accepted; a missing brief is not technically necessary to make queued reachable.

Fix: put each unresolved behavioral change in a disposition table: original rule, proposed rule, approving authority, acceptance change. Keep already-decided changes separate. Do not conflate source review approval with owner approval of altered gates. Decide the blanket any→blocked versus terminal immutability conflict and block→block semantics too.

The multi-row issue problem is real, but “open iff at least one row not done” is only sound if rows exhaust the issue's scope. Row 1/22 explicitly separates broader MVP acceptance from one targeted correction; row 6 has two issue phases. Model which row gates issue closure, or report mismatch for disposition without forcing automatic closure. A single reviewer field also loses row 6's independent Darkwing/Dewey reviews; use a review policy that can preserve both if that row is migrated intact.

R12 — Medium: immutable review candidate and receipt lifecycle are missing

Where: 5.14 and Piece D pass tests.

Scenario: a request posts /tmp/candidate.sha256; the file is replaced or disappears, so a later reviewer cannot identify what was approved. This takeover already found the historical #1511/#1512 /tmp snapshots absent. With issues: [int], “the piece's issue” also no longer selects an unambiguous posting target. Posting a request alone does not establish a full review round or preserve its verdict when the row loops through review again.

Fix: resolve and store the candidate content digest and durable commit or artifact reference, not just a path verbatim. Name the request issue, review round, required reviewers and receipt links; preserve prior rounds. Test request→changes requested→new candidate→approval against exact pins. Keep the brief's ban on new review files, but evaluate the stronger proposed ban separately: no-files-anywhere is not a substitute for durable receipts.

R13 — Medium: brief validation and migration are too shallow

Where: 3.A migration/C and 5.12; current QUEUE rows and parked table.

Scenario: a directory or symlink outside the repository “exists” as a brief, or an untracked local brief makes the author's tests pass but is absent in a fresh clone. A nonexistent section passes even though the fresh seat is instructed to open only the named brief section. Migration shortens a state cell and drops an acceptance/publication boundary that is not actually duplicated in CURRENT or an issue. A valid golden Markdown file proves none of those semantics.

Fix: require a readable repository-contained regular brief, a defined symlink policy, and tracked prospective content for publishable rows. Either validate section anchors or disallow them for actionable rows until resolved. Produce a reviewed row-by-row migration map preserving owners, review lanes, gates, required status, dependencies, historical IDs and each unresolved boundary. Map parked entries with no briefs explicitly rather than inventing authority from their free text. Preserve history through exact durable links or a reviewed archive; do not assume it was copied elsewhere.

R14 — Medium: package reuse and acceptance wiring need concrete decisions

Where: 2.E, 3.B, section 1; package.json and existing module layout.

Scenario: ledger imports @mosaic/queue but adding a sibling package.json does not install a workspace package. Root package.json declares no workspaces; a read-only import.meta.resolve('@mosaic/seat') probe returns ERR_MODULE_NOT_FOUND today. Moving the registration loader into seat also touches a package outside E's listed files and requires its regression tests.

Fix: use the existing relative-module convention or explicitly plan package linking and its installation/lockfile consequences; do not leave it implicit. Reuse the loader without silently expanding ownership, and specify liveness/error handling separately (R9). Name actual package test commands and affected suites. C also needs the promised two owner-accepted briefs, not just missing-path tests. D needs a full review round and E the dated ledger receipt/remediation evidence. B's --check verifies inputs exist, not that a running or fresh session received the new cadence; inspect the launch context and then perform G. Clarify the brief's “A to E in order” against the proposed C-with-A and D/E parallel delivery before dispatch.

What is fine

• Repository-local scripts/mosaic dispatch, keeping seat argv/env behavior, and tests for that behavior are appropriate. Q1 correctly remains an owner wording choice; no global CLI or fleet edits are needed.
• Queue data under docs/plans and code under packages/queue respect bootstrap-only root. An edit to the existing root AGENTS.md is permitted; a new root lock/journal/config file would not be. The plan proposes no contract, secret, run-record or managed-role changes.
• Required as a flag, an explicit review-to-work edge, strict unknown-field validation, dependency cycle checks, deterministic rendering and a non-mutating render check are good building blocks. They need the transaction/history/authority rules above to deliver the claimed result.
• Missing identity refusal, Q4 held for explicit credentials, no automatic push, no T3-backed product feature, and preservation of the old table log are sound boundaries. Historical log corrections must remain additions.
• Combining migration with the introduction of the authoritative data file avoids a deliberate two-master interval. A reviewed migration map still matters. Reusing one validator is correct once module resolution is explicit.

Recommended disposition

Revise the write/recovery/commit protocol (R1–R3), settle protected authority and requirement changes (R4/R11), strengthen Gate G evidence (R5), and specify transition claims and review delivery recovery (R6/R7) before implementation. Correct E's positive-evidence rules and audit model (R8–R10); complete the candidate, migration and packaging details (R12–R14). These are bounded plan changes, not authorization to build a new policy service or alter live state.

Validation for this review was source inspection and read-only in-process probes of the existing message classifier and module resolution. No queue implementation or fault-injection suite was run because none exists yet. This report records the session outcome in place of editing SESSIONS.md, as this assignment explicitly permits writes only to the report.