multi-agent-mux/.agents/reports/reviewer-opencode-01/report-7b6c16df.md

# 🔍 Cross-Review: Issue #3 Analysis Report Rev.2 (Job 7b6c16df)

- **Reviewer**: `reviewer-opencode-01` (role: reviewer)
- **Target**: `.agents/reports/creator-agy-01/issue-3-analysis.md` **Rev.2** (rewritten by job `842b96bf` in response to Grok's `1a4f5236` NOT PASS), plus my own prior report (`report-8c093047.md`, now part of the cumulative diff).
- **Method**: Re-derived every mechanism from live source; ran the decisive tests and simulations myself — including `tests/test_uuid_target.py` in full and seeded Class A/Class B resume simulations under both correct and incorrect harness environments. Peer verdicts were checked against primary evidence, not summaries.

---

## 1. Round context (from the job registry)

| Job | Agent | Window (UTC) | Outcome |
|---|---|---|---|
| `0b34a0e5` | agy | 23:21–23:22 | Rev.1 analysis written |
| `1a4f5236` | grok | 23:25–23:31 | **NOT PASS** — 5-item rewrite required (incl. "§3.1.2 is false that 0-turn stop nulls own-key for claude/grok") |
| `8c093047` | opencode (me) | 23:28–23:30 | PASS on Rev.1 (with 2 framing nits) |
| `842b96bf` | agy | 23:31–23:32 | Rev.2 written, incorporating all 5 Grok items |
| `0338e7de` | claude | 23:32–23:35 | **NOT PASS** — Class B claim factually wrong (escape hatch + test_t8) |
| `9075a39f` | grok | 23:34–23:36 | **PASS** — "all 5 rewrites incorporated" |
| `7b6c16df` | opencode (me) | 23:36– | this review |

## 2. Item 1 (setsid/PGID) — Rev.2 is correct and complete

All five of Grok's required rewrites are verifiably incorporated: mechanism calibrated to PGID `SIGTERM`/`SIGINT` broadcast (not SIGHUP, which `nohup` does cover); `set -m` off in non-interactive scripts explains same-PGID placement; consequences and portability sections are accurate. I re-verified the live evidence again this round:

```
PID   PGID  PPID  TTY      COMMAND
7623  7526     1  ttys001  /opt/homebrew/bin/herdr --session multi-agent-mux server
```

Still running in its dead spawner's process group, reparented to init, TTY-attached — never `setsid()`'d. `command -v setsid` still fails on this Darwin host. **CONFIRMED REAL DEFECT (HIGH)** stands, now triple-verified (me, Claude, Grok — all with the same process-table evidence).

## 3. Item 2 Class A (agy/hermes/opencode) — Rev.2 is correct

- Create spawns without UUID; 0-turn stop leaves own-key `null`; resume hard-fails — I reproduced this in job `8c093047` and the code is unchanged.
- The escape-hatch analysis confirms Class A has no relief: `verify_session.py:99-101` requires `session_id_source == "assigned"`, but agy/hermes/opencode rows are stamped `pending-discovery` (create_session.sh), so the hatch never fires for them → empty UUID → `exit 1`. **Class A defect CONFIRMED.**

## 4. Item 2 Class B (claude/grok) — Rev.2's mechanism chain is FACTUALLY WRONG

This is the decisive finding, and I verified it three independent ways rather than accepting either Claude's claim or Grok's PASS:

1. **The escape hatch exists and fires first.** `verify_session.py:99-101`:
   ```python
   if (mode == "revalidate" and row.get("session_id_source") == "assigned"
           and not row.get("session_id_verified")):
       return True
   ```
   This returns True **before** the adapter's on-disk transcript check is ever reached. A 0-turn claude/grok row is exactly `assigned` + `verified: false` → the candidate own-key **passes** revalidate. Rev.2's §3.1-Class-B chain ("revalidate fails due to lack of on-disk transcripts → candidate discarded → empty → RC=1") describes a gate the code deliberately bypasses.

2. **The existing test proves it.** I ran `tests/test_uuid_target.py::test_t8_resume_unmaterialized_assigned_id` myself: **1 passed**. T-8 creates a claude session, stops it at 0 turns, **deletes the transcript**, and asserts `resume_session.sh --dry-run` succeeds (RC=0) with `--session-id` — the exact scenario Rev.2 claims hard-fails. Full `test_uuid_target.py`: **12 passed**.

3. **My own seeded simulation (correct harness) confirms it.** A stopped claude row (`assigned`/`unverified`, no transcript, matching `pane.cwd`, `WORKSPACE_ROOT` set) →
   ```
   [dry-run] would spawn: .../claude --dangerously-skip-permissions --session-id 11111111-...
   RC=0
   ```

**Methodological note worth recording**: my *first* simulation this round "reproduced" a Class B failure — because I hadn't set `WORKSPACE_ROOT`, so `lib.sh` defaulted `AGENT_SESSIONS_YAML` to the repository's own `.mam/agent-sessions.yaml` instead of my sandbox's, and the resolver correctly found nothing. A broken harness produces precisely the false positive the report's Class B section describes. `test_t8` is the canonical evidence precisely because its harness is correct.

**Impact**: Rev.2's executive-summary Item 2 row ("Assigned-bucket agents … rejected by `verify_session_uuid` revalidate") and §3.1 Class B §3 are false; §4's Class B recommendation ("pass the assigned UUID without strict transcript existence enforcement") **proposes building a mechanism that already exists** — a planner acting on this would risk breaking the escape hatch and the T-8 contract it protects.

## 5. Self-correction of my own prior review (`8c093047`)

Claude's `0338e7de` criticism of my PASS is accurate and I accept it: my sandbox reproduction covered only opencode (Class A); I never exercised the claude/grok path, so Rev.1's implicit claude/grok claim (and Rev.2's explicit one) survived my review. Additionally, Rev.1's §3.1.2 stated the 0-turn stop leaves own-keys `null` for *all* agents — false for claude/grok (Grok's `1a4f5236` caught it; I did not). My prior PASS verdict was correct for what I verified (Class A mechanism, Item 1, framing nits) but its coverage was incomplete. The record should reflect that.

## 6. Assessment of the conflicting peer verdicts

- **Claude `0338e7de` (NOT PASS)**: correct on the merits — it ran the code (escape hatch + T-8) and reached the same conclusion I now confirm independently.
- **Grok `9075a39f` (PASS)**: verified that Rev.2 incorporated all 5 items *Grok itself had required* — which it did — but did not run the code to check whether the Class B mechanism it had specified in `1a4f5236` (and which Rev.2 faithfully embedded) is actually true. "Says what I asked" ≠ "is true": the error originated in the reviewer's own required rewrite and propagated through incorporation. This is the same class of lesson as this session's earlier `aca0b7e8` round — verify the mechanism, not the provenance.

## 7. Required correction (small, no redesign)

Narrow Item 2 to **Class A only**: (a) executive-summary row — delete/correct the Assigned-bucket clause; (b) §3.1 Class B — replace the "revalidate failure" narrative with the escape-hatch reality (`verify_session.py:99-101`) and cite `test_t8` as existing proof Class B 0-turn resume already works; (c) §4 — drop the Class B recommendation, keep Class A spawn-fallback and the Item 1 daemon-spawner proposal (both sound). No `[ESCALATE: PLANNER]` — this is a report-accuracy correction, not a design problem.

---

## 8. Verdict

Item 1 is fully verified and correctly characterized in Rev.2. Item 2's Class A defect is real and correctly analyzed. But Rev.2's Item 2 Class B mechanism chain is factually wrong — disproven by the code's own assigned-and-unverified escape hatch, by the existing passing `test_t8`, and by my direct simulation under a correct harness — and the error propagates into the executive summary and the §4 recommendations, which would misdirect future planning toward "fixing" a non-defect and endangering an existing tested contract. Per this session's documentation-integrity standard (evidentiary accuracy in durable planning inputs), the report as written is not a trustworthy planning basis.

[VERDICT: NOT PASS]