feat(workflows): configurable task workflows driven by the daemon

[lapa2112]

What this adds

Today "process" in Warpforge is a single Orchestrator toggle: it appends a hardcoded prompt and hands an LLM three MCP tools. There are no roles, no review, no iteration limits, and nothing to configure — the process is whatever the model decides to do.

This branch makes the process declarative and deterministic. A workflow is a YAML file in the project's .warpforge/workflows/; the daemon — not an LLM — drives the task through it:

plan? → implement → review ⇄ fix → needs review

The workflow decides which agent and model runs each stage, what each stage is told, what the reviewers see, how many review rounds are allowed, and what happens when they run out. The existing Orchestrator chat is untouched; a workflow is a separate engine, and the two are mutually exclusive in the dialog.

How it works

• Templates. .warpforge/workflows/*.yaml, plus two built-ins shipped in the binary ("Implement + review loop", "Plan + implement + review loop"). A project file shadows a built-in with the same id; either built-in can be copied into the project in one click and edited. Invalid files stay listed with their parse error instead of silently disappearing.
• Engine. Every stage is a normal child task with its own agent session, so it shows up on the board and its chat can be opened. Reviewers run in parallel, may each be a different agent/model, and return a structured verdict; a repeat round continues in the same reviewer's session so it verifies its own findings rather than re-reviewing from scratch (review.reask: same_session | fresh, with an automatic fresh-session fallback when a session is gone).
• The parent task has no agent session of its own. Its transcript is a timeline of stages, each card listing the agents that ran it — click one to open that agent's session.
• It stops for you. A stage can ask a question mid-run; running out of review rounds asks whether to grant more, finish as is, or stop. Both surface in "Needs you" with a toast, and the parent's composer becomes the answer box.
• Pause/resume between stages, with an optional note that reaches the next stage as guidance.
• Restart-safe. Run state is snapshotted on every transition; barrier states resume as they were, and a run caught mid-stage parks at its last safe point (the re-run is told its predecessor was interrupted, so it inspects the partial diff).
• Never commits. A finished run lands in Needs review for a human to inspect.

Also here: the workspace config gains a preferred home at .warpforge/workspace.yaml next to .warpforge/workflows/. Existing root-level configs keep working; only newly generated ones move.

Review notes

Worth a close look, in rough order:

1. src/daemon/workflow.rs — the run state machine, prompt builders, and the two agent protocols (verdict / need_user_input). The prompts are the load-bearing part of whether this feels useful or annoying.
2. The workflow block at the end of src/daemon/actor.rs — actor glue. Methods take the run out of workflow_runs and must re-insert on every exit path; a dropped run means a parent stuck in "running".
3. src/workflow_config.rs — YAML schema and validation, including which knobs warn when they're inert.
4. desktop/src/hooks/useWorkflowSend.ts — the single place that routes composer input for a session-less parent. Anything that can point a composer at a task must go through it.

The branch went through a review pass across four dimensions (engine, config/protocol, desktop UX, prompt/product quality) plus a visual check of every UI state; a259b08 is that pass. The findings it fixed that are worth knowing about:

• a request_changes verdict with no parseable findings used to finish the run as a success — a silent rubber-stamp when a reviewer wrote its findings in prose
• one reviewer that couldn't produce a parseable verdict used to fail the whole pipeline; it now abstains
• AcpHandle::prompt is not a liveness check (its channel outlives the child), so the same-session and dead-session fallbacks were unreachable exactly when needed
• a stage whose session failed to start hung the parent forever
• a restart during a review round burned it ("round 3/2")
• the protocol JSON leaked into the user-facing timeline

Testing

• Rust: 176 tests. Unit coverage for config validation, prompt building, verdict/marker parsing, review merging, and diff formatting; plus end-to-end pipelines against a scripted mock ACP agent (tests/fixtures/mock-acp-workflow.mjs) covering the reject → fix → approve loop, question/reply, the limit decision, pause/resume, restart recovery, same-session reuse, dead-session fallback, and session cleanup (verified with pgrep — no agent process outlives a pipeline).
• Desktop: 345 tests, including the picker, composer routing per barrier, the controls, and the attention rule.
• cargo fmt, cargo clippy --all-targets -D warnings, bun run lint, bun run typecheck all clean.

Not verified: a real end-to-end run against live Claude Code / Codex sessions. Everything agent-facing is exercised through the mock, so the prompts themselves are the untested surface.

Deliberate limitations

Scoped out of this first iteration on purpose: no arbitrary stage DAG, no gate expressions, no finding ledger or dedup across rounds, no deterministic build/lint/test gates (agents run their own checks), no separate tester or final-acceptor role, no global ~/.warpforge/workflows/, no auto-commit. Pause is soft (at stage boundaries) rather than interrupting a turn mid-flight.

Known rough edges left as follow-ups: findings aren't deduplicated between reviewers or rounds; the diff is spliced into prompts without delimiters (mitigated by key-scoped protocol parsing); the workflow control bar lives inside the chat column, so a collapsed chat hides it; finished runs are never pruned from workflow_runs.