tri-review: multiple blockers prevent actual model-diversity review

[5uck1ess]

Context

Ran /devkit:tri-review on PR #93 twice. First attempt was blocked entirely by a guard bug (fixed in #92 → v2.1.25). Second attempt (after rebase + local rebuild) exposed three further issues that combine to make tri-review non-functional even with the guard fix.

Issues discovered

1. codex:codex-rescue returns empty output

Dispatched twice — once via run_in_background: true, once foreground. Both completed in ~17s with zero retrievable verdict text. The background notification had no <result> field; the foreground call returned literally (Subagent completed but returned no output.).

Likely cause: the codex-companion adapter silently fails when the subagent's internal Bash invocation hits some error path. No error surfaced to the parent.

Repro:

Agent tool, subagent_type=codex:codex-rescue, any prompt → empty result

2. gemini:gemini-rescue — internal Bash blocked at subagent level

Parent dispatch of Agent(subagent_type=gemini:gemini-rescue, ...) succeeds now (thanks to the guard fix). But inside the rescue subagent, its contract is to shell out via Bash to gemini-companion.mjs — and that nested Bash call is still denied by the devkit PreToolUse hook. The subagent itself returned:

I'm blocked by the devkit workflow hook — this is a tri-review step expecting me to gather evidence via Read/Grep/Glob and call devkit_advance, not forward to a rescue subagent. Since my role per the system prompt is strictly to forward to gemini-companion task and the Bash call failed, I'll return nothing per my safety rules.

The guard fix allowed Agent/Task at prompt+hard steps but didn't cascade to Bash invocations within those subagents' sessions. Interestingly, codex:codex-rescue didn't hit this block — possibly because codex-companion Bash was separately allowed, or because Codex swallowed the block silently (see issue #1).

Fix direction: allow Bash to codex-companion.mjs / gemini-companion.mjs specifically — or whatever paths the rescue subagents call — on tri-review prompt+hard steps.

3. Cross-session workflow state persistence blocks unrelated tool calls

Root cause discovered by the user: .devkit/devkit.db (SQLite) in the repo root stores workflow state. The hook reads it on every tool call. When a previous session's tri-review is marked `running` and never cleaned up (e.g. session was killed mid-workflow, process crashed, CC restarted), the guard continues to enforce prompt-step rules on tool calls in future sessions — even unrelated ones.

Symptoms: Tool calls in a fresh session get blocked with `workflow step N/M is at a prompt step` even though the current user didn't start any workflow.

Workarounds:

# from the repo root:
~/.claude/plugins/cache/5uck1ess-plugins/devkit/<version>/bin/devkit-engine stop
# or nuke local state entirely:
rm .devkit/devkit.db .devkit/devkit.db-wal .devkit/devkit.db-shm

Fix direction: either (a) auto-mark abandoned workflows as `cancelled` when their session ends, (b) add a TTL so `running` workflows auto-expire after N minutes of no-activity, or (c) scope state to session-id so a new session doesn't inherit a dead one's state.

Also observed (not blockers, just notes)

• Haiku-backed fast-tier review via Agent(subagent_type=general-purpose, model=haiku) hallucinated 2 of 4 findings against a real Go diff (claimed `r.Reachable` never set — actually line 103; claimed `runners` / `cobra` imports unused — actually used throughout). Fast-tier on Go is unreliable; consider skipping fast-tier for Go PRs or flagging its output with a lower-confidence prefix.

Impact

With these three issues, tri-review currently cannot produce the model diversity it exists for. Users who want real three-way external-model review are stuck with single-tier (Claude-family) reviews from /pr-review-toolkit:review-pr, losing the whole point of tri-* skills.

Suggested priority

1. Issue Add Go CLI harness + fix all tri-* commands #3 (state persistence) — highest, because it silently blocks ALL subsequent tool use in affected repos, not just tri-review.
2. Issue Align Codex and Gemini to plugin-first with CLI fallback #2 (Gemini nested Bash block) — medium; documented workaround is "just use Codex" but that hits Add scrape command, Jina Reader integration, enhanced PR pipeline #1.
3. Issue Add scrape command, Jina Reader integration, enhanced PR pipeline #1 (Codex empty output) — medium; adapter-level bug, should surface errors instead of swallowing.

Encountered while reviewing PR #93.

[5uck1ess]

Addressed in #96:

• tri-review: multiple blockers prevent actual model-diversity review #95-3 (state persistence blocking unrelated sessions): fixed by adding cross-repo RepoRoot scoping to runPreToolGuard, mirroring the stop-guard fix from devkit-stop-guard fires across repos — hook is session-scoped, should be repo/branch-scoped #91.
• tri-review: multiple blockers prevent actual model-diversity review #95-2 (rescue subagent nested Bash): fixed by allowing Bash at prompt+hard when the command invokes codex-companion.mjs or gemini-companion.mjs.
• tri-review: multiple blockers prevent actual model-diversity review #95-1 (codex-rescue empty output): confirmed resolved upstream in openai-codex 1.0.3 — no devkit change required.

Closing now; #96 lands the devkit-side fixes.