multi-agent-mux/.agents/reports/reviewer-opencode-01/report-8c093047.md

🔍 Cross-Review: Issue #3 Technical Analysis Report (Job 8c093047)

• Reviewer: reviewer-opencode-01 (role: reviewer)
• Target: .agents/reports/creator-agy-01/issue-3-analysis.md (new, from job 0b34a0e5, creator-agy-01) — an analysis-only deliverable (no code changes permitted) determining whether the two tmpl/multi-agent-mux Issue #3 items are real structural defects.
• Method: Re-derived every claim from live source plus empirical runtime verification — process-table inspection of the actual live herdr server, a sandbox reproduction of the 0-turn resume cycle, and macOS portability checks. Not from the report's or Claude's/Grok's summaries.

---

1. Item 1 (setsid omission in daemon bootstrap) — CONFIRMED, and I verified it empirically

Source-level check: lib.sh:211 and the generated .mam/shim/herdr:59 both use nohup "$REAL_HERDR" --session ... server >/dev/null 2>&1 & + disown. The analysis's mechanism is textbook-correct: nohup only masks SIGHUP; disown only removes bash job-table tracking; neither changes PGID or SID. A PGID-targeted kill -- -PGID (SIGTERM/SIGINT) reaches the daemon and kills it, taking down every workspace/pane it manages — matching the reported symptom (total session reset).

Empirical confirmation from the live system (this is stronger than reading code):

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

The production MAM herdr server: (a) is reparented to PID 1 (its spawner subshell is dead — the exact lifecycle the issue describes surviving), (b) still carries the dead spawner's PGID 7526 rather than its own process group, and (c) is still attached to a TTY (ttys001), i.e. it never called setsid(). The structural claim is not hypothetical — the deployed daemon is currently running in exactly the vulnerable state the report describes.

Portability claim verified: command -v setsid fails on this macOS host — the report's macOS constraint is accurate, and the proposed subprocess.Popen(..., start_new_session=True) resolution is the correct portable idiom (os.setsid() in the child, both macOS and Linux; lib_py already depends on Python). This matters to me directly — my own session's herdr server is one of the processes exposed by this defect.

2. Item 2 (0-turn stopped session resume deadlock) — CONFIRMED, reproduced in sandbox

Source-level checks, all matching the analysis:

• create_session.sh:178-180: only claude/grok pre-allocate a UUID; agy/hermes/opencode spawn without one (verified against all adapters' spawn_spec).
• stop_session.sh: capture_conversation_id returns "" for a 0-turn session ("WARN: no conversation id resolved before stop (nothing on disk yet)"), and if captured and not purge: is skipped — so the row persists as status: stopped with a null own-id and no resumable flag.
• resume_session.sh:54-57: [ -z "$UUID" ] → exit 1 with "Use multi-agent-mux-create first."
• create_session.sh:96: --role is required (exit 2 if missing) — so the suggested fallback isn't callable with the arguments a resume caller holds. The handoff-friction claim is real.

Sandbox reproduction (my own run): seeded a status: stopped opencode row with no own-id, ran resume_session.sh --workspace ... --agent opencode --session test-0turn-creator-opencode →

ERROR: No saved session for /var/.../tmp.X (opencode). Use multi-agent-mux-create first.

Hard failure reproduced exactly as reported.

Agent-asymmetry reasoning verified: for agy/hermes/opencode the original spawn never had a UUID, so relaunching the base CMD_FULL restores the intended clean state — the proposed fallback is semantically valid; for claude/grok fresh-UUID allocation mirrors what create does. The existing test_tier3_integration.py:199 even asserts the current hard-fail behavior for a non-existent session — confirming the current design conflates "no session ever existed" with "0-turn stopped session exists," which is precisely the defect.

3. Precision points (minor, non-blocking)

1. "Reconcilers enter a permanent failure loop today" is slightly ahead of the evidence — the same nuance Claude (7e62abfd) found, which I independently re-verified: the only automated resume_session.sh call site (reconcile.sh:464 _pin_and_verify_resume) is invoked exclusively after a non-empty UUID has been discovered, so no current code path hits the null-UUID branch automatically. The script-level defect and the SKILL.md "Case 2: herdr alive but empty → manual recovery" gap are real; the automation-loop framing is a plausible future risk, not a today-observed failure. A one-line softening ("...and any automated caller that treats resume as the standard stopped→running transition would enter...") would make this exact.
2. Severity of Item 2: MEDIUM-HIGH is defensible given the lifecycle contract break; I'd note the practical blast radius today is manual/interactive flows (automation doesn't currently reach it), which arguably places it at the MEDIUM end — a judgment call, not an error.
3. The report's Item-1 line citation "lib.sh:211" is exact (verified); the quoted bootstrap block matches live source verbatim.

4. Process integrity

• Job 0b34a0e5 is real (registry-verified, completed 23:22:28Z); the analysis-only constraint was honored — git status shows the report file as the only change; zero code/test mutations (confirmed by direct inspection).
• Peer reviews: Claude 7e62abfd completed PASS (with the same nuance I found — convergent, independently derived). Grok 1a4f5236 was still running at my report time; not cited as evidence.
• The recommendations (§4) are appropriately scoped as subsequent-phase proposals, not smuggled implementation.

5. Verdict

Both defect determinations are correct and now carry three independent layers of verification: source-level reading, Claude's cross-check, and — decisively — my own empirical confirmations (live process-table evidence of the un-detached daemon state; sandbox reproduction of the 0-turn resume hard-fail; macOS setsid absence). The analysis is rigorous, the mechanisms are accurately described, the portability recommendation is sound, and the only imperfections are two minor framing-precision points that do not affect either verdict. As an analysis-and-determination deliverable, it fully meets its brief.

[VERDICT: PASS]