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, 27 insertions, 0 deletions

diff --git a/project_claudomator_workflow_diagram_todo.md b/project_claudomator_workflow_diagram_todo.md
new file mode 100644
index 0000000..53c643e
--- /dev/null
+++ b/project_claudomator_workflow_diagram_todo.md
@@ -0,0 +1,27 @@
+---
+name: claudomator-workflow-diagram-todo
+description: "Claudomator story 11bd1cff, IN_PROGRESS — a diagram of claudomator's overall workflow, especially its entry points; live dogfooding run, first draft had real correctness issues, currently on a fresh fix-attempt"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390
+---
+
+User asked (2026-07-10, during the recursive-arbitrated-review retro) for a diagram of claudomator's workflow, with particular emphasis on **entry points** — the places work can originate in the system. Captured as claudomator story `11bd1cff-04db-45ff-98bd-8fe68677737b` (spec + acceptance criteria set via `POST /api/stories` directly — no chatbot MCP story-creation tool was exposed at first; see [[claudomator-stories-not-null-bug]] for a quirk hit while creating it). This became the **first real production run** of the finished recursive-arbitrated-review design, once the server was redeployed — and immediately surfaced a serious bug: see [[claudomator-arbitration-fail-open-incident]]. The original root task's diagram was incorrectly approved despite real factual errors an evaluator had found; that root task is now permanently `COMPLETED` (terminal state, can't be un-approved) with a fresh fix-attempt spawned against it after the fail-closed fix landed. As of this writing the fix-attempt is `RUNNING` (task `89dd315a...`); status not yet known.
+
+**Why:** After a session spent almost entirely inside `internal/scheduler`/`internal/executor` internals, the system's several distinct ways work gets created were scattered across REST handlers, MCP tool definitions, and orchestrator-internal spawn logic with no single picture tying them together.
+
+**How to apply:** Check `GET /api/stories/11bd1cff-04db-45ff-98bd-8fe68677737b` for current status before assuming this is still in-flight or done. If it's stuck again (`IN_PROGRESS` with no active/QUEUED/RUNNING task in its chain), see [[claudomator-arbitration-fail-open-incident]]'s note on why deleting a dead fix-attempt task alone isn't enough — the story's `status` must be explicitly reset to `NEEDS_FIX` again too.
+
+When building this diagram, the known entry points to cover (gathered from `CLAUDE.md`'s REST API table and this session's own code reading — verify each is still current before diagramming, don't trust this list blindly):
+- `POST /api/tasks` (direct task creation) + `POST /api/tasks/{id}/run` (submit PENDING → executor)
+- Chatbot MCP `submit_task` (`/chatbot/mcp`, human/chatbot-facing)
+- `POST /api/webhooks/github` (CI-failure-triggered task creation)
+- `POST /api/stories` (+ whatever story-level chatbot MCP tools exist — `create_story`/`list_stories`/`get_story`/`accept_story` came online mid-session after a server restart)
+- Agent-initiated `spawn_subtask` (both agent MCP `/mcp` and the native tool-use loop) — creates either a `ParentTaskID` subtask or a `DependsOn` DAG-sibling role-typed task depending on whether `role` is set
+- `StoryOrchestrator`'s own internal spawning — `ensureEvaluators`/`ensureArbitration`/`ensureFixAttempt`/`spawnNestedFixAttempt`/`processRetro`, all task-creating but never externally triggered
+- `Scheduler`'s retry/escalation resubmission of FAILED tasks, and `ask_user`-timeout escalation resuming a BLOCKED task
+- `claudomator run <file>` (CLI, bypasses the server entirely)
+- Planning-layer tools that aren't task creation but are adjacent entry points worth showing: `propose_epic`, `propose_role_config`
+
+Also worth showing on the same diagram (or a companion one): the task state machine (`PENDING → QUEUED → RUNNING → READY → COMPLETED`, plus `BLOCKED`/`FAILED`/etc.) and where the recursive arbitrated-review mechanism (pieces 1-5, finished 2026-07-10) sits relative to it — a builder-role task's `READY` no longer means "done," it means "awaiting arbitration," which is exactly the kind of subtlety a diagram would make obvious that `CLAUDE.md`'s prose historically didn't (now fixed, see [[claudomator-claude-md-staleness]]).