Summary
review-gh-pr is not safe to run under claude -p (single-shot, non-interactive) past the Step 3.5 review-core Workflow dispatch. Everything the orchestrator does after the Workflow returns — Step 3.6 (durable log), Step 4 (GitHub posting), and analysis-only rendering — can silently not happen. Today this is latent (nothing in the plugin runs the skill headlessly), but it is a real landmine for any future cron / CI / headless invocation.
Mechanism
The orchestrator is the main agent loop; it has no workflow() primitive, so it dispatches review-core.mjs via the Workflow tool, which runs in the background and delivers completion as a <task-notification> on a later turn.
- Interactive: the notification arrives as a fresh turn, the orchestrator resumes, Steps 3.6 / 4 run normally. ✅
claude -p: there is no "later turn". Once the model stops emitting, the -p process finalises and the background Workflow is torn down. workflow() never returns to the orchestrator, so Step 3.6 and Step 4 never execute.
Observed while running the panel-vs-classic A/B harness (which drives /review-gh-pr under claude -p) against a merged PR with analysis_only=true:
- Classic arm: orchestrator passively "waited for the completion notification" →
end_turn → process finalised at 871s mid-synthesis (review-core wf_*/journal.jsonl held only 6 specialist results, no synthesiser output). No log, no render.
- Panel arm: orchestrator instead polled the workflow journal (each poll = a new turn, keeping the process alive), reached synthesis (journal held the synth
{bodyText}), then hit the harness's 30-min timeout (exit 124). Still no Step 3.6 / Step 4.
Whether the model passively waits or polls is model-non-deterministic, so headless behaviour is unreliable by construction.
Impact
- Durable log (Step 3.6): low real-world impact today —
full_log is opt-in / default-OFF and only the A/B harness turns it on. See sibling issue on the durable-log-gate blind spot.
- Posting (Step 4): this is the sharp edge. If anything ever runs
/review-gh-pr under -p (scheduled review, CI gate, batch re-review), the review would complete all its expensive specialist work and then silently fail to post the verdict/comments — no error, no output. The bundle exists only as the Workflow's return value + journal entry; review-core writes nothing to disk itself (review-core.mjs ~489: "the host writes the log").
Options (not yet decided)
- Document the constraint:
/review-gh-pr is interactive-only; headless callers must use a wrapper that harvests the Workflow's sealed bundle directly (the A/B harness is getting exactly such a harvester — see the capture task).
- Make the orchestrator await review-core inline/synchronously when it detects a non-interactive (
-p) context, so Steps 3.6 / 4 run before turn-end.
- Provide a first-class headless entry point (e.g. a thin Workflow/script that dispatches review-core and does the post/render itself, no inter-turn hop).
Provenance
Surfaced 2026-07-12 during panel-vs-classic A/B arm-tell capture (spec #3, Follow-up B). Run dir tests/ab/runs/20260711T193814Z-orchestration-full.
Summary
review-gh-pris not safe to run underclaude -p(single-shot, non-interactive) past the Step 3.5 review-core Workflow dispatch. Everything the orchestrator does after the Workflow returns — Step 3.6 (durable log), Step 4 (GitHub posting), and analysis-only rendering — can silently not happen. Today this is latent (nothing in the plugin runs the skill headlessly), but it is a real landmine for any future cron / CI / headless invocation.Mechanism
The orchestrator is the main agent loop; it has no
workflow()primitive, so it dispatchesreview-core.mjsvia the Workflow tool, which runs in the background and delivers completion as a<task-notification>on a later turn.claude -p: there is no "later turn". Once the model stops emitting, the-pprocess finalises and the background Workflow is torn down.workflow()never returns to the orchestrator, so Step 3.6 and Step 4 never execute.Observed while running the panel-vs-classic A/B harness (which drives
/review-gh-prunderclaude -p) against a merged PR withanalysis_only=true:end_turn→ process finalised at 871s mid-synthesis (review-corewf_*/journal.jsonlheld only 6 specialist results, no synthesiser output). No log, no render.{bodyText}), then hit the harness's 30-min timeout (exit 124). Still no Step 3.6 / Step 4.Whether the model passively waits or polls is model-non-deterministic, so headless behaviour is unreliable by construction.
Impact
full_logis opt-in / default-OFF and only the A/B harness turns it on. See sibling issue on thedurable-log-gateblind spot./review-gh-prunder-p(scheduled review, CI gate, batch re-review), the review would complete all its expensive specialist work and then silently fail to post the verdict/comments — no error, no output. The bundle exists only as the Workflow's return value + journal entry; review-core writes nothing to disk itself (review-core.mjs~489: "the host writes the log").Options (not yet decided)
/review-gh-pris interactive-only; headless callers must use a wrapper that harvests the Workflow's sealed bundle directly (the A/B harness is getting exactly such a harvester — see the capture task).-p) context, so Steps 3.6 / 4 run before turn-end.Provenance
Surfaced 2026-07-12 during panel-vs-classic A/B arm-tell capture (spec #3, Follow-up B). Run dir
tests/ab/runs/20260711T193814Z-orchestration-full.