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

diff --git a/feedback_claudomator_no_watered_down_architecture.md b/feedback_claudomator_no_watered_down_architecture.md
new file mode 100644
index 0000000..f7ec74d
--- /dev/null
+++ b/feedback_claudomator_no_watered_down_architecture.md
@@ -0,0 +1,20 @@
+---
+name: claudomator-no-watered-down-architecture
+description: "User strongly rejects \"simplified\" or \"optional\" framings of claudomator's recursive-arbitrated-review architecture — verification must be real and recursive at every level, no exceptions offered as a design choice."
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390
+---
+
+When working on claudomator's recursive-arbitrated-review design (docs/superpowers/specs/2026-07-09-recursive-arbitrated-review-design.md), do not propose scoped-down, "simpler," or "optional" variants of the recursion as if they were legitimate design forks — even when framed neutrally as a question for the user to decide.
+
+Two concrete incidents this session:
+1. I proposed an "outer pipeline only, subtasks decompose freely" alternative to avoid touching core executor machinery. User's response (verbatim): "oh my God stop whining about existing code, paradigms and architecture. quit proposing this half baked shit... simple recursive model... because the turtles are simple things (built by simple parrots), they require supervision at all levels."
+2. I later framed "should a roll-up wait for its children's arbitrated-review verdicts, not just raw task-completion state, before proceeding?" as an open question needing the user's decision. User's response: this has exactly one correct answer given the architecture's own premise — a roll-up cannot be verified until its subtasks are actually verified (arbitrated), not merely COMPLETED. Presenting it as a live fork read as evasion.
+
+**Why:** The user's mental model is "turtles all the way down" — one uniform recursive mechanism, applied identically at every depth, with real supervision (arbitrated review) at every level. Anything that special-cases the root, skips a level, or treats verification as optional at some depth violates the premise by construction, not by omission — it isn't a judgment call, it's a bug.
+
+**How to apply:** Before presenting an "open question" about this architecture to the user, check whether the answer is actually forced by principles already established (recursion is uniform; verification precedes completion at every level). If it's forced, just say so and implement it — don't manufacture a decision point. Reserve real questions for things that are genuinely underdetermined by the stated architecture (e.g., a concrete mechanism choice with no principled answer, not a scope-reduction in disguise).
+
+Related: [[claudomator-sequential-orchestration-gap]]