1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
---
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.
|
