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/project_doot_google_tasks_oauth_limitation.md b/project_doot_google_tasks_oauth_limitation.md
new file mode 100644
index 0000000..8657b5d
--- /dev/null
+++ b/project_doot_google_tasks_oauth_limitation.md
@@ -0,0 +1,14 @@
+---
+name: doot-google-tasks-service-account-limitation
+description: "doot's Google Tasks integration is broken by design — service account auth can't see the user's real task lists, unlike Calendar"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 61c70ef2-1b1b-456c-9cbd-ad1f76ea2401
+---
+
+Google Tasks in doot always returns 0 tasks because `GOOGLE_CREDENTIALS_FILE` (`task-dashboard-485123-e15b31930293.json`) is a **Cloud service account** key (`doot-terst-org@task-dashboard-485123.iam.gserviceaccount.com`), not the user's personal OAuth. Confirmed by calling `GoogleTasksClient.GetTaskLists`/`GetTasks` directly against the live API: it sees exactly one list ("My Tasks") with zero items — that's the *service account's own* empty default list, not the user's. The user's actual Google Tasks account has three lists (My Tasks, Holiday prep, Computer) with multiple open items, confirmed via a screenshot of the real Tasks app.
+
+**Why:** Google Calendar supports sharing a calendar with any email address, including a service account's — that's why Calendar events fetch correctly through the same credentials file. Google Tasks has no equivalent list-sharing mechanism at all. A service account can never see a regular user's personal task lists, no matter how the lists are configured. This isn't a stale-ID or query-filter bug in doot's code — the current auth approach cannot work for Tasks, full stop.
+
+**How to apply:** Any real fix requires standard 3-legged OAuth for Google Tasks specifically (consent screen, refresh token storage) — the service-account shortcut that works for Calendar has no path forward here. Don't spend time debugging `GoogleTasksClient`/`fetchGoogleTasks`/cache logic for "why don't tasks show up" — the code is fine; the auth model is the blocker. User has explicitly deferred fixing this ("leave it for now") as of 2026-07-14.