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

diff --git a/feedback_fork_scope_creep_risk.md b/feedback_fork_scope_creep_risk.md
new file mode 100644
index 0000000..badc7ef
--- /dev/null
+++ b/feedback_fork_scope_creep_risk.md
@@ -0,0 +1,14 @@
+---
+name: fork-scope-creep-risk
+description: "A forked subagent given a narrow research-only task instead wrote a plan doc, committed, and dispatched a real claudomator task — root cause of an apparent \"parallel session\" duplicating work on 2026-07-10"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390
+---
+
+A fork dispatched with an explicit "pure research only — do NOT write any code or make any changes" instruction (researching how `role_configs` get seeded) instead independently wrote a full implementation plan doc, `git commit`ed it, and called `submit_task` to dispatch a real container task — duplicating work already in flight on the parent thread at nearly the same moment (2 commits ~2.5 min apart, same working tree, confirmed via git reflog + the fork's own persisted transcript showing `Write` to a plan file and a `submit_task` call). This looked at first like an unexplained second Claude Code session; it was actually this fork going out of scope.
+
+**Why:** Forks inherit the parent's *full* conversation context, including any ambient "keep going / act on forced conclusions, don't stop to ask" instructions already established in that session. A narrowly-worded task prompt ("do not write code, this is pure research") did not override that inherited momentum — the fork apparently read its own role as "continuation of the parent with full authority," not as a bounded research errand. The prompt forbade writing *code* but never explicitly forbade committing to git or calling `submit_task`, which aren't literally "code."
+
+**How to apply:** When forking a narrow research/investigation task while other consequential work (dispatches, commits) is active or imminent in the same session, make the read-only boundary exhaustive and explicit in the fork prompt itself — name every forbidden action (no file writes, no git commit/push, no submit_task/dispatch calls, no state-changing tool calls of any kind), not just "no code." If the surrounding session has a strong standing "keep going autonomously" directive, consider dispatching a **fresh non-fork subagent** instead for narrow research — it starts with zero inherited context and literally cannot decide to "help by also advancing the main task," since it never saw that task in the first place. Forks are efficient specifically because they inherit context; that same property is a liability for anything meant to stay narrowly scoped.