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

diff --git a/project_claudomator_chatbot_mcp.md b/project_claudomator_chatbot_mcp.md
new file mode 100644
index 0000000..3b80c3d
--- /dev/null
+++ b/project_claudomator_chatbot_mcp.md
@@ -0,0 +1,18 @@
+---
+name: claudomator-chatbot-mcp
+description: "How the claudomator chatbot MCP endpoint is wired up for remote control from Claude Code, and the gotcha that broke it"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: de223ab2-f071-4747-b262-6f21c923e759
+---
+
+Claudomator (`/workspace/claudomator`, a Go task-orchestration engine — see `.agent/mission.md`) runs as `claudomator@doot.terst.org.service` and exposes a chatbot-facing MCP endpoint at `https://doot.terst.org/claudomator/chatbot/mcp` (tools: `submit_task`, `list_tasks`, `get_task`, `get_events`, `answer_question`, `accept_task`, `reject_task`, `cancel_task` — see `internal/api/chatbotmcp.go`). This is "Option B" from 2026-07-05: driving claudomator remotely via a claude-code MCP client rather than SSH'ing in.
+
+The live bearer token lives in the deployed config `/site/doot.terst.org/claudomator.toml` (`api_token = "M3kA...JW"`) — that's the source of truth, not `~/.claude/settings.json`.
+
+**Gotcha:** a prior session had hand-written an `mcpServers` block directly into `~/.claude/settings.json`. That key is not read by the CLI for MCP registration — `settings.json` only reads as `permissions`/`theme`/`enabledPlugins`/etc. It also had a stale/wrong token (a leftover from an earlier token-generation attempt), which made the endpoint reply `"no server available"` (400) instead of a valid MCP `initialize` response.
+
+**Why:** MCP servers must be registered via `claude mcp add --transport http <name> <url> --header "Authorization: Bearer <token>"`, which writes to `~/.claude.json` (project-scoped under `/workspace` by default). Fixed 2026-07-05 — removed the dead block from settings.json and re-added correctly; `claude mcp list` now shows `claudomator ... Connected`.
+
+**How to apply:** If claudomator MCP tools ever go missing or show wrong-auth errors again, check `claude mcp list` first, and verify the token matches whatever's currently in `/site/doot.terst.org/claudomator.toml`'s `api_token` (it may get regenerated). Don't put `mcpServers` in settings.json — always use `claude mcp add`/`claude mcp remove`.