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

# Queue as data — adversarial review, round 3

VERDICT: revise

Rocko for Sage, 2026-09-26. The requested plan hash was verified **before
reading section 8**:
`cfdaa3fe4fa3fa6ef339f834a9814eb4a472ceac7c832c19bf955b61351ff21f`.
This review applies to that section plus Sage's explicit assignment rulings:
one JSON file with embedded log, complete-record link lock, canonical root in
genesis, 12-call E budget, 8.15 defaults and explicit per-seat credentials.
The superseded separate-journal alternative and unresolved-Q4 prose are not
treated as active choices.

During review the shared plan changed to
`1666f74b615c72a3b1f9f7bc306d3e1baed920d7eb3a19968bfa7727137aca46`.
Sage was notified. That intermediate revision is not separately reviewed;
the requested section was already read in full before the change. At Sage's
subsequent direction, the final revision is reviewed in the delta below.

The architecture is substantially simpler and the complete-record lock is
sound under its cooperative, single-host assumptions. Remaining blockers are
specific: durability versus visibility, out-of-protocol git rollback, the
requesting/uncertain lifecycle, the shared git index, and acceptance evidence.
No separate journal, repair engine, distributed locking or new identity
service is recommended.

## Direct answers to Sage's four questions

1. **Rename removes partial in-place JSON updates, not every torn system
   state.** After rename but before directory fsync, the new name is visible
   but not yet durably committed. JSON and Markdown are still two separate
   replacements. Ordinary git ignores the lock and can overwrite the entire
   internally valid log. See T1/T2.
2. **The link lock plus exclusive unlock gate is a reasonable design.**
   Complete owner publication and manual-only reclaim address the earlier
   races. Same-host boot/start mismatch may authorize unlinking the stale
   record; foreign host or unreadable identity must remain unknown. Apply
   the same rules to cleanup of a stale unlock gate. See T3.
3. **No resend on uncertain outcome is the right rule, but requesting must
   be unresolved too.** A kill or failed outcome write leaves no uncertain
   record. The human not-posted resolution also cannot be based solely on
   not seeing a comment. See T4.
4. **The Gate G link is checkable as cooperative evidence.** Pi records
   tool-call IDs, command arguments and corresponding tool results. An op-id
   substring anywhere in a call is insufficient; inspect the actual command,
   result, session branch and matching log transition. See T6.

## Findings

### T1 — High: visibility is being called durable commitment too early

**Where:** 8.0, 8.5 steps 4–6, unlocked reads in 8.4.

**Scenario:** the temp file is fsynced and renamed; the process is killed
before directory fsync, or that fsync returns an I/O error. A reader can
already observe the new revision. A host crash can then lose the rename's
durability: the design must not promise which pre-fsync namespace state
survives. On first creation it cannot even assume a prior queue exists.
This differs from a mere process kill while the host continues running.

The single-file design does avoid a half-appended log **when the complete
validated temp file is fsynced and only then renamed on the same filesystem**.
It does not establish the stronger statement “an operation after step 4
stands” when step 4 was interrupted before its durability barrier. Nor does
the word rename imply that every invalid file could only have been written
by an outsider; failed I/O or an implementation fault also need diagnosis.

**Required revision:** distinguish the visibility/linearization point
(rename), durable completion (successful directory fsync), and acknowledgement
(receipt). On failed fsync, report an uncertain local outcome with op id,
do not print success and do not undo by overwriting another version. Reads
may expose visible state, but must not authorize an external POST from an
intent whose durable write failed. The originating request path proceeds
to network I/O only after its own successful persistence barrier.

Define startup/retry behavior after this uncertainty without automatic
repair: inspect/verify and, if needed, explicitly establish durability of
the observed operation before claiming it durable. A plain read or replay
does not itself perform a durability barrier. State filesystem/platform
assumptions and handle short writes before rename.

**Acceptance:** distinguish process kill from host-crash reasoning; inject
file-fsync, rename and directory-fsync failures separately. Check that no
receipt or POST follows failed persistence, and no unsafe rollback occurs.
Do not claim power-loss behavior was tested merely by SIGKILLing a child.

### T2 — High: a valid git rollback erases both data and deduplication evidence

**Where:** 8.2 replay, 8.5 manual recovery, 8.12 integration.

**Schedule A:** writer A holds the queue lock and has read revision 12.
Seat B runs checkout/restore/stash on queue.json, installing revision 9.
A then renames revision 13 computed from 12, silently overwriting B's
operation. If B runs last, revision 9 silently wins instead. Git does not
consult `.git/mosaic-queue.lock`.

**Schedule B:** after an acknowledged review POST, ordinary checkout or
stash restores an older JSON and matching Markdown pair. It is perfectly
canonical and replay-consistent, but the log no longer contains the POST's
op id. Reissuing the same op can now send again. Internal replay cannot
detect replacement of its entire trusted history by an earlier valid one.

**Required revision:** make preservation of queue history part of the
cooperative git protocol: no checkout/stash/restore/reset/branch switch
touching queue paths while they carry unintegrated operations or active
review requests; lead coordinates and verifies any exceptional restoration.
Check baseline file identity/hash immediately before replacement to catch
ordinary accidental interference, while stating that this cannot atomically
exclude uncooperative git. Pin the branch as well as canonical path.

Withdraw the generic instruction “restore with git” for invalid JSON. First
preserve the failed bytes and reconcile all acknowledged and outstanding
ops against receipts; restoring HEAD may delete work performed since the
last commit. A deliberate history reset requires explicit disposition of
external side effects and cannot retain the normal deduplication guarantee.
No same-user file format can make arbitrary rollback impossible. This is
a necessary trust-model limit, not a demand for a second authoritative log.

**Acceptance:** checkout/stash interleavings and a restored older valid pair
must be either refused by the cooperating workflow or explicitly diagnosed
as outside the guarantee. Do not label a passing replay as proof that no
history was lost. Preserve append-only *logical* history across normal writes.

### T3 — Medium: stale-gate cleanup needs the same identity rules as unlock

**What is fine:** the lock record is complete before `link()` publishes it.
EEXIST preserves exclusivity. The exclusive unlock gate prevents two
unlockers acting on old observations. A writer publishing after the gate
appears either sees it and releases or is classified live and retained.
I find no two-cooperating-writers schedule violating that argument, given
the specified post-publication gate check and identity validation.

**Remaining scenario:** the lock/gate was created on host A; it is later
seen on host B where the numeric PID is absent. The Discord helper's
`ownerState` checks PID death before other identity fields and knows no
host. Blindly adopting that order would classify the foreign record dead.
The queue specification correctly says foreign host is unknown: that test
must take precedence over local PID liveness. A stale gate's current hint,
“remove it by hand once that pid is gone,” omits host, boot and reuse.

**Required revision:** define queue classification explicitly: validate the
record, establish supported host/namespace scope, then evaluate boot/start
and PID evidence. Same-host known previous boot is a mismatch; foreign-host
record or missing evidence refuses, even if no such local PID exists.
Apply this to the unlock gate's manual cleanup too. A reused local PID may
be alive but cannot be the old owner if known start/boot differs; never
signal that unrelated process. Unknown remains unknown.

The release check should compare the full acquisition identity (and ideally
the acquired inode), not merely op+PID. This is a small defensive improvement,
not a replacement for the gate. `unlock` must use the gate protocol directly,
not first try to acquire the very lock it is supposed to remove. Validate
temp writes and use exclusive temp creation; other link errors must refuse.

**Acceptance:** PID reuse within a boot; same PID/start on a different boot;
foreign host with locally absent PID; unknown /proc; stale gate with reused
PID; both writer/unlocker orderings. No age-based reclaim. A renamed host
may require manual diagnosis: safe unavailability is acceptable here.

### T4 — High: requesting is an unresolved outcome, not permission to request again

**Where:** 8.9; op uniqueness in 8.2 and retry order in 8.5/8.6.

**Scenario:** durable intent is recorded, the lock is released, POST is
accepted, and the CLI dies before reacquiring the lock. The row remains
`requesting`, not `uncertain`. The current prohibition on further requests
only explicitly covers uncertain. A new op could open another request.
Failure to reacquire after the 30-second network call has the same result.
A timeout of the shell helper may also leave its curl child running; the
server outcome remains unknown regardless of client cleanup.

**Required revision:** requesting-without-terminal-outcome and uncertain
must both block a new request for that logical review. An explicit manual
resolve handles both. Keep the original op and candidate frozen through
all phases. No retransmission on replay, read, retry or a new op while the
prior attempt is unresolved. Define outcome finalization as a separate
logged event referencing the original op: log op IDs are unique, so intent
and outcome cannot both append entries with the same ID. State who may
resolve and how conflicting/late resolutions are rejected.

**Manual not-posted:** a human merely checking that a comment is absent
does not prove a timed-out request will never complete. Require positive
non-delivery evidence or leave it unresolved. If the lead explicitly
overrides uncertainty to permit a fresh attempt, record the accepted
duplicate risk; do not still claim at-most-one delivery for that case.
`posted:<id>` must refer to the expected issue, marker, round and candidate.
This is operational reconciliation, not a blind state setter.

The 4xx rule should be limited to actual trusted endpoint responses known
to mean non-acceptance; an arbitrary transport/proxy failure is uncertain.
The existing helper provides HTTP status in stderr and response JSON in
stdout: the wrapper must preserve that distinction without exposing tokens.
There is no timeout inside the helper; D must bound the process tree and
treat interrupted transport conservatively.

**Related gap:** 8.7 allows `move in-review` separately from `review request`,
but Piece D's brief requires the move itself to post the request. Define
that move as the request workflow (or explicitly change the brief); otherwise
a seat can enter review without a request/round. Also, 8.5 runs stale-view
checks before retry lookup: a recorded op followed by a view-write crash
does not get 8.6's promised recorded receipt until someone renders. Define
read-only lookup/receipt behavior before view freshness blocks new mutations.

**Acceptance:** kill before POST, after server acceptance, before outcome
write and during lock reacquisition; new-op request while requesting;
same-op retry after stale view; delayed first POST after attempted resolution;
late outcome after manual resolution; no second POST in any uncertain path.

### T5 — High: the shared-index commit procedure can sweep unreviewed files

**Where:** 8.12.

**Scenario:** another seat already staged source. Step 1 adds the queue pair,
step 2 checks it, and step 3's plain `git commit` commits the other seat's
source too. Or another seat changes the index after staged verification;
the commit is no longer the tested staged snapshot. Even reading
`git show :queue.json` and then `git show :QUEUE.md` can observe different
index generations. Neither is solved by keeping the queue write lock out
of the test path.

**Required revision:** Sage should choose an isolated index for the intended
commit, or an explicit cooperative exclusive staging/commit interval with
a clean/approved index. Freeze a prospective tree id once, verify the queue
pair from that tree, verify the complete intended path set and compare HEAD
before committing exactly that tree. Preserve others' index and working
changes. Do not use path commit as a substitute: it can select current
working bytes instead of the tested staged pair.

The sequence says `verify-commit ID COMMIT` runs before the source is
committed. Define a prospective-tree verification target or verify the
resulting local commit before treating it as approved integration. Also
ensure package tests exercise the proposed queue code, not unrelated dirty
working versions while claiming the staged code passed.

**Acceptance:** unrelated staged file; two-stage reads across an index
mutation; index mutation after verification; working queue changes during
integration; changed HEAD; manifest compared with the actual prospective
source tree. Commit authorization remains separate from this procedure.

### T6 — Medium: Gate G's evidence exists, but the checklist must follow execution

**Observed in the installed pinned Pi code:** session entries have `id` and
`parentId`; the header may carry `parentSession`. Assistant `toolCall`
blocks have `id`, `name` and `arguments`; a `toolResult` has `toolCallId`,
`toolName`, content and `isError`. Thus a direct bash command and its result
can be linked without inventing an incarnation variable.

**False pass:** a failed command, a dry-run/echo containing the op ID, or a
command on an abandoned session branch satisfies “op id appears in a tool
call.” Meanwhile a helper has moved the row. The checklist already concedes
helper spoofing is outside the cooperative proof, which is honest; it
should still reject these observable non-execution cases.

**Required revision:** pin session id/file hash at the evidence cutoff,
freshness/no-parent evidence, active entry ancestry and the test interval.
Inspect the actual `scripts/mosaic queue` invocation in canonical cwd,
its op/row/actor/arguments, the corresponding tool-result ID and receipt,
and the matching log entry/revision. A successful recorded retry is evidence
of lookup, not proof this session originated the move: check the original
timing and pre-test revision. If output was lost or truncated, preserve the
actual recoverable evidence or declare the link inconclusive.

Require the trace `next output → named brief read → successful start
transition → concrete work`, with normal prerequisite reads allowed. The
work action needs its own successful result/effect, not merely a proposed
tool call. Define when input counting stops so later verdict/housekeeping
messages cannot retroactively fail the completed interval.

The literal “any row-specific text” context rule needs an exception for
the authorized brief/task data discovered during the test; otherwise the
task itself fails the audit. `git status` at two endpoints does not detect
an edit made and reverted between them. Record content hashes and bound
the no-coaching claim to the observed interval under the cooperative
no-external-edits rule. Jason's observation remains the final gate.

**Negative controls:** echo-only op id; nonzero command result; helper's
earlier op reused by the seat; resumed/forked session; wrong branch of the
session tree; brief never read; work command failed. Manual review suffices;
no checker package is required.

### T7 — Medium: unverified PIDs still qualify as a full liveness pass

**Where:** 8.10.

The display correctly says pid-present is unverified, but the full-pass
predicate allows every owner to be pid-present without any verified process
identity. A reused PID can therefore produce “full pass” although the
brief required a live owner registration. This recreates the acceptance
gap in more honest display wording.

**Required revision:** either call this a reduced registration/PID-presence
check and obtain the designated reduced-gate acceptance, or retain
incomplete liveness and do not issue a full pass. No start-time producer
or schema expansion is needed. Null/unknown PID needs a category and cannot
be converted to verified liveness. Keep the approved 12-call Gitea budget;
it is unrelated to this finding.

The age-unknown legacy case similarly needs incomplete coverage reporting
if it prevents deciding whether a required row is overdue. A report can
truthfully have zero known violations without meeting every full-pass gate.

### T8 — Medium: a few executable rules are still internally inconsistent

These are lead-level specification fixes, not new owner questions:

- **Ordinary add:** every add requires brief, but brief is privileged-only
  “on add as well as afterwards.” Define the allowed initial fields/defaults
  for an ordinary owner's add, or state that only privileged actors add.
- **Claim lifecycle:** specify claim creation/clearing for
  in-review→in-progress, blocked→previousState and reassignment. Otherwise
  “claimant” permissions can refer to the wrong owner or stale op.
- **Current briefs:** add validates a HEAD blob, but the fresh seat opens
  a working path. `next`/start should refuse or visibly flag a working brief
  that differs from the pinned blob; an optional verify --current against
  HEAD alone does not establish what the seat reads.
- **Genesis bootstrap:** canonicalRoot exists only inside the file genesis
  creates. Define the reviewed root input and special absence check for
  first creation, without guessing a root or allowing a second genesis.
  Resolve git-dir paths relative to the cwd actually used for the git call;
  simplest is to run those queries explicitly from the discovered toplevel.
- **B scope:** 8.1 now lists only AGENTS.md, whereas Piece B also requires
  seat context files that direct work to CURRENT.md to change. Keep those
  named context edits and their snapshot verification in the active scope.

## What is now closed or honestly limited

| Earlier concern | Round-3 disposition |
|---|---|
| S1 owner-publication/reclaim race | Complete-record hard link and manual gated unlock address the core race. T3 specifies remaining classification/cleanup details. |
| S2 partial journal append | Removed by one validated fsynced temp JSON file. T1 is the narrower durability distinction; no journal repair verb requested. |
| S3 unexplained table drift | Genuine old-render hash versus unknown body and manual-only render is a sound boundary. JSON/Markdown mismatch remains detectable and intentional. |
| S4 tuple retry matching | Explicit persistent op IDs close the core ABA/tuple problem. T4 addresses receipt lookup ordering and multi-phase request events. |
| S5 shared git integration | Still open; T5 gives an exact prospective-tree procedure. |
| S6 multiple histories/replay | Canonical-root genesis, linked-worktree refusal and versioned replay are suitable for this scope. External git rollback remains a cooperative boundary (T2). |
| S7 impossible required dependency | Fixed by owner-approved prerequisites of either required status. Remaining field/claim details are T8. |
| S8 unsupported identity | Same-seat sessions deliberately share a claimant: an honest bounded limitation under Sage's ruling. T6 makes Gate G checkable; T7 prevents unsupported liveness acceptance. |
| S9 uncertain POST | No automatic retry is correct. Requesting, outcome events and manual negative resolution remain open (T4). |
| S10 candidate/brief evidence | Embedded manifest plus exact integration digest check is useful. It explicitly does not preserve uncommitted source bytes: review can become unrecoverable if those bytes vanish; that must block integration, not silently downgrade to a fresh candidate. T5/T8 bind verification to the actual source/brief. |
| S11 conflicting active sections | Section 8's precedence banner resolves the old-section conflict. This review does not relitigate superseded alternatives or accepted defaults. |

## Recommendation and evidence limits

Keep the ruled architecture. Before coding, close T1/T2/T4/T5 and make the
bounded checklist/matrix corrections in T3/T6/T7/T8. These are operational
and specification changes; they do not require Jason to choose a locking
algorithm or a new service. At the third review round, Sage should record
this remaining disposition explicitly rather than infer approval from the
absence of rejected earlier findings.

Investigation was read-only except this report. Failure schedules are
design analyses, not executed power-loss, git-interference or transport
tests against queue code (which does not exist yet). I inspected existing
process-identity helpers, API transport and local Pi transcript types; no
live session transcripts or credentials were read for this round.

Source pins: `packages/discord/src/journal.mjs`
`db33880f88dc2c7708015efecd0c6db604bc40387ea0dd6259d91f621a5b022c`;
`scripts/gitea-api.sh`
`033e6d5fdd4626fb0ca1c981b6d85eba961a4618a303faf2bb7b30ae024ed9a6`;
`scripts/agent-host-dev.sh`
`706f8e02fe0d8c18887d2e030f64f447a7db05badb3df3a20800c68ed5313687`.
Pi evidence: local `pi-coding-agent/dist/core/session-manager.d.ts` and
`pi-ai/dist/types.d.ts` under `node_modules/@earendil-works/`; bash tool
implementation under `pi-coding-agent/dist/core/tools/bash.js`.

## Delta: final specification 124b6f9e

Verified **before reading** the final section 8:
`124b6f9e250985d48654c6068ddfb0d82be6984f16da8700969281c4e06b0d26`.
Main review target remains
`cfdaa3fe4fa3fa6ef339f834a9814eb4a472ceac7c832c19bf955b61351ff21f`.

**Delta verdict: revise, for the same remaining technical findings.** The
recorded rulings are taken as authoritative for this review; no Q/J approval
is requested again. The only outstanding external input identified by the
final plan is seat tokens for D's live posting test.

- **J4:** Jason-only unpark to queued is explicit and appropriate: it
  requires renewed briefing before work can start. Refusing required=true
  on parked rows closes that conflicting state combination. Test unpark
  actor refusal, queued re-entry and claim/review state cleanup. No new
  authority finding against this ruling.
- **J5:** the new edge correctly refuses gateOwner=jason and requires
  logged approval evidence for the allowed gate-owner/privileged path.
  Define permission precedence against 8.8's blanket refusal for another
  seat moving a claimed row; otherwise a legitimate non-owner gateOwner
  could be rejected. Evidence must identify this candidate/round's approval,
  and completion must settle the claim. These are the existing T8 lifecycle
  details, not objections to delegated completion.
- **D:** fake-transport construction/testing reads no token; the live round
  waits for explicit per-seat credentials. This is a clean build/live split.
  It does not close T4: requesting can still outlive the CLI, and manual
  not-posted resolution still needs a defined uncertainty disposition.
- **No repair/journal:** the final removal matches Sage's accepted design.
  “Reviewed hand restore” improves recovery governance, but T1/T2 still
  require reconciliation of uncommitted/externally effective operations
  before a git restore discards their log. No repair verb is proposed here.
- **Other rulings:** accept the 12-call budget, root in genesis, link lock,
  cooperative claims, narrowed closes with a logged reason, and E-before-D.
  The reduced liveness gate is now explicitly accepted. T7 consequently
  needs **no further approval**: label unverified PID-only coverage reduced
  too, rather than full merely because no exempt seat exists. The accepted
  reduced gate resolves permission to report limited coverage, not evidence
  of verified liveness.

The final delta does not change the write/fsync sequence, shared-index
procedure or Gate G op-id test; T1/T2/T5/T6 remain applicable. T3's lock
classification and T8's ordinary-add, current-brief, genesis and B-context
details likewise remain. The core architecture is accepted as the target;
the revise verdict concerns these bounded implementation contracts.