feat(opencode): add Phase 5.5 task-split review by @check

ppries' README mentioned "@check reviews task split for completeness
and coverage" as a workflow step but the gist's actual workflow.md
never implemented it, and neither did ours. Without a split-review
gate between Phase 5 and Phase 6, an over- or under-split task
surfaces only at Phase 8 final review — after expensive @test and
@make dispatches have already run on a broken split.

Adds Phase 5.5: a short, focused review of the task split as a set,
dispatched only to @check (split is structural / coverage, not
complexity, so @simplify is not involved). The dispatch passes the
absolute paths to plan.md and every task-N.md and asks @check to
evaluate the split against five questions: coverage, no overlap,
single-purpose, integration contracts, testable AC.

Loop limited to 2 cycles (less than the plan-review's 3), with a
BLOCK verdict routing back to Phase 4 when the plan itself does not
decompose cleanly. The phase is explicitly framed as "a quick gate,
not a deep review" — no line-by-line code feedback (there's no code
yet), no design re-litigation (that was Phase 4) — to keep it from
expanding into a second plan review.

No phase renumbering downstream — 5.5 fits between 5 and 6 without
disturbing existing cross-references.

config/opencode/commands/workflow.md

@@ -287,6 +287,37 @@ Apply **Dispatch Hygiene** to each task spec before dispatch in Phase 7.
 
 ---
 
+## Phase 5.5: Review Task Split
+
+A short, focused review of the task split as a set. Catches split errors (missed scope, overlap, multi-purpose tasks, missing integration contracts) when they're cheap to fix — *before* `@test` and `@make` dispatch on a broken split. Without this gate, the same errors surface only at Phase 8 final review, after expensive test/implementation work has already been done.
+
+**Dispatch only `@check`** for this phase — split review is structural / coverage, not complexity. `@simplify` is not involved. Apply **Dispatch Hygiene** to the prompt.
+
+The dispatch prompt names:
+- `$RUN_DIR/plan.md` (the plan being decomposed)
+- `$RUN_DIR/task-1.md` through `$RUN_DIR/task-N.md` (the split — list every task file)
+- The worktree path
+
+`@check` evaluates the split against five questions:
+
+1. **Coverage** — do the tasks together implement everything the plan promises? Any gaps?
+2. **No overlap** — do two tasks claim the same scope or modify the same lines?
+3. **Single-purpose** — does any task do more than one thing? (See Phase 5's Split Heuristic.)
+4. **Integration contracts** — where two tasks touch a shared interface, is the contract documented in both task files?
+5. **Testable acceptance criteria** — does every task have specific, falsifiable AC?
+
+**Review loop (max 2 cycles):**
+
+1. Dispatch `@check` against the plan + all task files.
+2. If `ACCEPTABLE` → proceed to Phase 6.
+3. If `NEEDS WORK` → edit the task files in place (split a task into two, merge two tasks, add integration contracts, sharpen AC). Re-apply Dispatch Hygiene to each updated file. Re-dispatch.
+4. If `BLOCK` → the plan itself does not decompose cleanly. Return to Phase 4 with `@check`'s finding instead of forcing the split.
+5. **Convergence detection:** same finding twice → stop loop, document the unresolved split issue in the run summary, proceed.
+
+**This is a quick gate, not a deep review.** No line-by-line code feedback (there's no code), no design re-litigation (that was Phase 4's job). The whole point is a fast structural check before downstream phases start churning.
+
+---
+
 ## Phase 6: Write Tests
 
 Apply **Dispatch Hygiene** to each `@test` prompt before sending.