feat(workflows): author parallel reviews and resolve workflow attention

[Igloczek]

Closes #28 · Parent spec #3 · Stack layer 4/5 (base: #34 workflows/27-decisions-rework)

Problem

Parallel review existed in the engine but couldn't be authored or understood from the client. Workflow decisions waiting on a person (gates, native requests, stale reviews, unresolved attempts) had no actionable, run-grouped view.

What this adds

• Parallel review authoring:
  • A Parallel group and Wait for all pair, added and removed together.
  • Independently labeled reviewer branches with stable IDs; same-skill branches stay distinct across reorder and reopen.
  • Skill, focus/instructions, provider/model, inputs/report/deadlines, and the canonical review permission policy, with one-click repair.
  • "All N reviewers required", the frozen PR reference, and isolated reviewer worktrees.
  • Join rules reuse the typed decision cards. Removing a reviewer exposes its dangling rules.
• Run evidence:
  • The newest generation's complete required branch set: phase, reason, report, deadline, isolated workspace, frozen head.
  • Report count and settled count are kept separate ("3 of 3 reports accepted · 2 of 3 reviewers settled").
  • Only the persisted join decides. An early "changes" never implies sibling cancellation.
  • Server-owned stop and join causes explain failed, missing, timed-out, stale, and unverifiable outcomes.
  • "Rerun review on the current head" uses the backend Retry and recovery target to create a new generation.
• Workflow attention:
  • A server-owned read model with stable reason kinds and per-attempt pending native requests in queue order, with uncapped counts.
  • The distinct-run total and exact run/attempt/gate links are server-owned.
  • A single bounded live subscription (newest first, widened up to 100 runs), filtered by an in-memory attention version so only attention-relevant commits trigger re-reads.
  • Project-scoped drill-down. The last snapshot stays visible while offline.
  • "Open thread to answer" opens the existing native controls, and later requests explain that earlier ones in the same queue are answered first.
  • Read and snooze stay presentation-only.
• Generic host: optional PluginAttention.total and WebPlugin.attention. The shell shows "Workflows: N need attention" from the plugin's total, never a capped length. The fixture is unaffected.
• User guidance: docs/user/workflows.md.

Validation

• Server tests (Bun):
  • WorkflowsParallelAttention.test.ts covers more than five same-skill reviewers, 2/3 and reported-but-running joins, early changes, failed/missing/timed-out reviewers, backend cancel, changed/unverifiable heads, rerun generations, native request queues across restart, 130-run totals, attention-relevant re-reads only, and uncapped request counts.
  • WorkflowsAttentionIsolation.integration.test.ts checks that the real core's thread.visit / thread.snooze leave attention unchanged.
  • The Run, Decisions, Rework, Review, Wait, and PluginHost suites pass.
  • The 6 known failures (WorkflowsMissingReportTime lostack-*, WorkflowsTimeout committed-crash) are pre-existing on the base.
• Web integration (Bun, real servers):
  • WorkflowAttention.integration.test.tsx covers older-run refresh, offline last-loaded state, held delivery without collapse, the 102-run cap and project drill-down, native thread navigation, items clearing individually, and server-side stream cleanup.
  • The WorkflowRun, WorkflowDecisions, WorkflowAuthoring, and Plugin* suites pass.
• Static checks: unit tests pass; typecheck, lint, and fmt are clean for touched packages.

Independent review

Four rounds by a separate Claude Opus 5.5 reviewer. Fixed findings:

• older attention pages going stale or collapsing
• attention re-reads on every commit
• capped request counts
• untested stream cleanup
• unactionable cap guidance

Final verdict: APPROVED 6569b21b0ff861e2f286bc1637a24cc7cfe70e5e. Two NITs remain: a test gap for the in-flight cap message, and docs wording for a single project over 100 runs.

Pending

Parent acceptance walkthrough: one real-client pass locally and once over an authenticated remote connection. This is pending because the T3 Browser panel was unavailable; results will be recorded here.

Limitations

• The attention list is bounded to the newest 100 runs per view; the page names the total and points to project scope.
• Runs recorded before this change have no stop kind or retained requests, so they show as "Unresolved" or as a single "waiting for input".

Implemented by Claude Opus 5.5 implementation agents and reviewed by an independent Claude Opus 5.5 agent (gilfoyle), orchestrated in Claude Code running in T3 Code.

🤖 Generated with Claude Code