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

# Queue as data — adversarial review, round 5

Verdict: **revise**. Rocko for Sage, 2026-09-26.

Plan hash verified before reading:
`889f25665b42f620a82051e916b017e26e2aeb5c5ef4a4549e327f796b1ae3d3`.
This supersedes 7d61f18d. Review target is active section 8, against round-4
report `fcb8933d515bcf98c509d17cb7c5bb384f2bce844b2b87eab6f83e67658efcff`.
Sage's choices and credential rulings are accepted. Two bounded fixes
remain; neither needs a new owner decision or architecture.

## Round-four disposition

| Finding | Assessment |
|---|---|
| F1 HEAD/shared-index gap | The installed, active pre-commit guard closes the ordinary-commit rollback schedule. Cooperative exclusions are explicit in 8.5. Its active status needs the additional validation in finding 2 below. |
| F2 incoherent reads | Resolved. Witness-first reading plus a locked recheck before adverse diagnosis avoids falsely declaring lost history during a normal publication. An ahead revision is only visible/unconfirmed. Snapshot verify explicitly does not certify live witness continuity. |
| F3 genesis/bootstrap | Resolved at plan level. Implementation-first commit, genesis-only first queue commit, base-absent exception, explicit base bytes from H and a nonexistent temporary-index path are concrete. |
| F4 freshness/branch coaching | The intended proof closes ordinary resume and abandoned-branch coaching, but the newly prescribed pre-instruction file pin cannot be obtained from pinned Pi. See finding 1. |
| F5 op-id length | Resolved. External maximum 72 plus reserved eight-character suffix fits internal maximum 80; boundaries have tests. |

## 1. Medium — Gate G requires evidence Pi has not written yet, and its first-parent rule rejects a fresh session

**Where:** 8.11 freshness and linear-file bullets.

The plan requires the new session file/header to be pinned before Jason's
instruction, containing only header and launch settings. Pinned Pi's
SessionManager creates these entries in memory but defers file creation
until an assistant message exists. Even appending the initial user message
does not create the file. The launcher does not pre-create it.

Separately, the session header has a session id, but is not the parent of
the first tree entry. That entry has parentId null. “Every entry's parentId
must be the previous entry's id” fails on a valid session immediately after
the header. Subsequent tree entries should form the requested linear chain.

**Executed evidence:** imported the repository's installed
`@earendil-works/pi-coding-agent/dist/core/session-manager.js`, created a
session in a temporary directory, appended model/thinking settings and a
user instruction, then a synthetic assistant message. Results:

- before instruction: session file absent;
- after instruction: session file absent;
- after assistant: file present;
- first nonheader entry parentId is null, not header.id.

Source: `_persist` at line 739 and `newSession` around line 650. This used
no model, live session or credentials; the temporary fixture was removed.

**Fix:** pin the pre-launch directory listing, launch snapshot, launch
arguments and start time before the instruction. Pin the completed session
file at cutoff (or once Pi first creates it, with a final cutoff pin).
Audit the resulting header timestamp, absence of parentSession and the
prefix before the instruction retrospectively against those pre-launch
receipts. Do not introduce a warm-up message or manually seed Pi's session
file. State that the first nonheader entry has parentId null and every
later tree entry points to its preceding tree entry. The header's id is
session identity, not an entry-chain node.

**Acceptance:** run the checklist on a real fresh session generated by the
pinned Pi; it must pass without a pre-instruction model turn. Retain the
ordinary-resume, prior-compaction and branching negative controls.

## 2. Medium — matching hook bytes does not prove the commit guard will run

**Where:** 8.12 installation and step-1 guard.

Installation writes mode 0755 and refuses core.hooksPath. Each subsequent
queue commit checks only that `.git/hooks/pre-commit` bytes match HEAD.
If the executable bit is lost during a hook copy/restore, the bytes still
match, but Git ignores the hook. Likewise a later core.hooksPath setting
can select a different location while the checked file remains unchanged.
No malicious edit or --no-verify flag is needed on the ordinary commit.

**Executed schedule in an isolated temporary repository:** HEAD/index
queue=10, unrelated source staged, private-index commit publishes queue=12
without reconciling the shared index. With the executable guard, plain
`git commit` refuses. Remove only the hook executable bit, preserving its
bytes; the same plain commit succeeds and HEAD queue becomes 10.

**Fix:** before publication, verify both expected bytes and that the hook
is executable and selected by the effective Git configuration/environment
used by ordinary committers. Recheck core.hooksPath at invocation, not only
installation. Refuse before publishing if the guard is inactive. Explicitly
include disabling/replacing hooks or overriding their selection among the
cooperative bypasses seats must not perform during integration. No software
check can prevent a deliberate later same-user bypass; that accepted trust
limit remains. Do not represent bytes alone as an active maintenance hold.

**Acceptance:** same-byte nonexecutable hook and a newly set alternate
hooksPath both make queue-commit refuse before update-ref. Keep the existing
ordinary-commit race tests with an active hook.

## What is fine, and the remaining bounds

The cooperative model is now stated honestly in 8.5: ordinary commits use
the guard; --no-verify is forbidden; merge, rebase, cherry-pick, revert and
am are lead operations because the guard does not protect them. These are
routine Git operations that bypass this protection, so the lead must apply
the recovery/integration discipline too. “Lead-only” is not an enforcement
mechanism. The witness detects lost history afterward; it cannot prevent
an uncooperative Git write. No stronger same-user security boundary is
requested here.

The private index, exact snapshot blobs and expected-old-HEAD publication
are sound for the intended ordinary source-commit workflow. commit-tree
intentionally skips hooks; its own prospective-tree checks and compare-and-
swap remain necessary. I independently reproduced the active guard refusing
an ordinary commit after publication. I did not rerun Filbert's claimed
full three-order race experiment; the remaining schedules were reviewed
from the specification.

Jarvis is an explicit authorized lead identity, not a fallback token. The
read-in-place rule does not authorize copies, token inspection by this
review, or credential changes. GET user must map the lead to expected login
jarvis, while preserving the queue actor as the lead; “seat's expected
login” in step 2 must be read with that exception. Include a fake-transport
lead success case and wrong-login refusal to prevent accidentally comparing
jarvis to sage. Stat ownership/mode and path checks are metadata checks;
the helper alone reads the token. A 403 is a recorded failed attempt under
the accepted endpoint assumption, never an automatic retry or scope upgrade.
The permission-scope question remains with Sage, as ruled.

No new defect was found in the uncertain-outcome protocol: durable intent
precedes network work, all three request types have bounded process groups,
and unresolved attempts are not resent. Abandonment explicitly withdraws
the at-most-one claim. Fake transport is appropriate for this build; it is
not evidence that a live token has comment permission.

Only this report was written in the repository. Scratch Git and Pi fixtures
were isolated and removed. No source/index edits, commit, live process
change, secret read or external request. The source fixes above are plan
clarifications for the builder; implementation acceptance remains necessary.