---
name: claudomator-sequential-orchestration-gap
description: "Retro conclusion from the tasks-board build (2026-07-06/08): claudomator has no native mode for sequential build-review-fix task chains; StoryOrchestrator's Builder->4-Evaluators->Arbitration shape doesn't fit it. Five-item synthesis + two concrete bugs found while building it."
metadata: 
  node_type: memory
  type: project
  originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390
---

Building claudomator's own "unified Tasks board" web feature via an adapted
subagent-driven-development (implementer = claudomator `submit_task`,
reviewer = local Claude Code subagent, hand-orchestrated by the controller)
surfaced a retro with five items, synthesized into one conclusion: **claudomator
has no native way to drive a multi-step plan through review-gated
implementation.** That role was played by the controller (Claude Code), by
hand, all session — dispatching, reading diffs, reviewing, re-dispatching,
tracking state in a scratch ledger file.

**Why the existing pipeline doesn't cover this:** `internal/scheduler.StoryOrchestrator`
already automates Builder → 4 parallel Evaluators → Arbitration → REVIEW_READY,
but that shape is "one deliverable, multi-angle critique." The tasks-board build
needed "N sequential tasks, single-evaluator gate per link, fix-and-advance
before moving on" — a different orchestration shape entirely. Forcing the
existing pipeline to fit would mean either faking 4 evaluators per task
(wasteful) or only getting eyes on the work after all N tasks are done (too
late — see the Task 4 near-miss below).

**Five retro items, synthesized:**
1. No `create_story`-shaped chatbot MCP tool — stated multi-task intent stays
   a loose chain of unlinked `submit_task` calls, never becomes a first-class
   Story. Whatever tool fills this gap needs to be complete and make it clear
   to agents how the lower-level primitives (`submit_task`, `spawn_subtask`
   with role, `answer_question`) compose underneath it — not a black box.
2. Needs a genuinely new orchestration mode (sequential task-chain, single
   evaluator per link) — not a reuse of the existing 4-evaluator Story
   pipeline.
3. The local-subagent-for-review / claudomator-for-implementation split this
   session used was practical, not principled — dissolves once (2) exists,
   since "reviewer" just becomes a native evaluator-role task type.
4. Want an orchestrator that resumes intelligently after session/model
   failures — deliberately held for later, tempered by (5): only tractable
   once state is DB/event-backed instead of a local ledger + conversation
   context.
5. **The governing constraint on how to build all of this:** wherever a
   lesson can become a mechanical/code-enforced check, make it one — not a
   prompt reminder a controller has to remember to retype into every
   dispatch. Two concrete bugs from this exact session prove why:
   - The plan document for the tasks-board build was never `git commit`ed.
     Every claudomator container that cloned the repo during that build never
     had the file its dispatch instructions told it to read. 4+ tasks of
     review churn got misattributed to "the implementer didn't follow
     instructions" before this was noticed — days later, by accident. A
     pre-flight "does this referenced file exist in a fresh clone" check
     would have caught it in seconds.
   - `ContainerRunner.buildInnerCmd` (`internal/executor/container.go`) never
     read `t.Agent.Model` when building the `claude -p ...` command — model
     selection was silently a no-op for every task, the entire session,
     masked because every request happened to ask for "sonnet" (the CLI's
     own default). Found only while discussing item 4. Fixed same session
     (commit `2d9ae7e`) — also fixed a real command-injection vector this
     surfaced (`Agent.Model` was unescaped free text concatenated into a
     `sh -c` string; now validated against `^[A-Za-z0-9._-]+$` in
     `task.Validate`, commit `0cedb90`).

**How to apply:** before proposing more hand-orchestrated multi-task claudomator
work, check whether the sequential-task-chain orchestration mode (item 2) has
been built yet — if so, use it instead of re-deriving this whole hand-driven
pattern again. If designing it, lean toward code-enforced checks over prompt
reminders per item 5, and don't build item 4 (resumability) before item 5's
discipline is in place — resumability depends on durable state, not on a
smarter controller.

Full retro discussion, spec, and implementation plan: see
`docs/superpowers/specs/` and `docs/superpowers/plans/` in
`/workspace/claudomator` for whatever this becomes.