Merge titanium's diverged memory tree into the shared historyHEADmain

Titanium and tungsten had grown two separate, unreconciled memory sets
for the same -workspace scope. Ports over 18 titanium-only entries
(12 claudomator files, the fork-scope-creep lesson, the doot Google
Tasks OAuth limitation, the default-subagent-driven-execution
preference, scout's Facebook priority, Hawaii GIS endpoints), merges
two true duplicates into their existing tungsten files rather than
keeping parallel copies (the migration-rename incident -- same
022->023 rename, same commit, titanium's version added the
confirmed-safe-to-patch-prod-directly carve-out tungsten's didn't
have; the APK build OOM note, folded into project_doot_widget_build.md
as a RAM-constrained-host fallback), and marks
doot_future_task_scheduling_ideas.md as historical now that all four
of its backlog items (budgets, labels/projects, buckets, chains) are
built.

1 files changed, 75 insertions, 0 deletions

diff --git a/project_claudomator_sequential_orchestration_gap.md b/project_claudomator_sequential_orchestration_gap.md
new file mode 100644
index 0000000..50d55ea
--- /dev/null
+++ b/project_claudomator_sequential_orchestration_gap.md
@@ -0,0 +1,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.