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

diff --git a/doot_future_task_scheduling_ideas.md b/doot_future_task_scheduling_ideas.md
new file mode 100644
index 0000000..bbb2e58
--- /dev/null
+++ b/doot_future_task_scheduling_ideas.md
@@ -0,0 +1,45 @@
+---
+name: doot-future-task-scheduling-ideas
+description: "Design-origin doc for doot's chains/buckets/labels/projects features (all four now built, as of this session) — kept for the rationale behind current shape, not as a backlog"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 61c70ef2-1b1b-456c-9cbd-ad1f76ea2401
+  modified: 2026-08-15T18:04:22.781Z
+---
+
+**Superseded 2026-08-14: all four ideas below are now built** ([[reference_doot_marine_codemap]], [[project_doot_isallday_midnight_bug]] and this session's work used chains/buckets/projects/labels directly against live doot). Originally captured 2026-07-15 on titanium as backlog "thoughts for the future," refined through a 24-question interview the same day, and had no spec yet at time of writing. Keeping this file for the *rationale* behind why chains are strict WIP-1, why buckets auto-select by staleness+priority, why labels and projects are two separate concepts, etc. — treat the content below as "why it works this way," not as a to-do list.
+
+## 1. Task budgets / availability times
+- Availability is **both**: a manual recurring weekly pattern (e.g. "2hr weekday evenings, 4hr Saturday") as a baseline, further reduced by actual Google Calendar events.
+- Budget is **both**: per-task duration estimates that roll up into and draw down a weekly/period pool.
+- Behavior: **just surface fit/overflow** — no auto-scheduling into slots; user still picks what to work on.
+- Scope: **opt-in per project/label** (depends on item 2 existing first) — not a global always-on constraint.
+- Overflow handling: **just flag it** (a warning/indicator), no auto-reprioritization or auto-push.
+- Estimate source: **user-entered, plus learned from history** (infer typical duration from past completions of similar tasks — needs completion-time tracking that doesn't exist yet).
+
+## 2. Task labels/projects
+- **Two separate concepts**: one project (hierarchy/grouping, exactly one per task) + many cross-cutting labels (tags).
+- Data model: reuse the `Task.Labels []string` field for tags; a separate lightweight Projects concept alongside it.
+- Color coding: **yes**, user-assignable colors per label/project, matching the existing `sourceColor()` convention.
+- Widget visibility: widget shows a color mark on the time grid; full label/project display and editing happens in the task-detail popup.
+- Recurrence interaction: project/labels are **series-level metadata** — every new recurring occurrence inherits them automatically.
+- Cardinality: **exactly one project per task**; labels handle the many-to-many cross-cutting need.
+
+## 3. Recurring maintenance buckets (pick N from a list every M days/weeks)
+- Architecture: a new recurrence variant layered onto the existing recurrence system, not a parallel/separate feature.
+- Selection mechanism: **system auto-selects N items** each cycle — not a user-chosen pool.
+- Deferral: deferring a selected item **puts it back into the pool**, eligible again next cycle (not pushed further out specifically).
+- Selection algorithm: **weighted/scored** — combining priority, staleness, and label/availability match.
+- Item timing: **no fixed due dates on individual items** — the M-day/week cycle length is the only timing concept.
+- Bucket membership: **exactly one bucket per item** (not multi-bucket).
+
+## 4. Linear task chains with WIP limits
+- WIP limit: **exactly 1** active task per chain at a time (strict, not configurable).
+- Structure: **strictly linear**, fixed order, no branching or reordering.
+- Visibility of future (locked) tasks: **hidden from timelines**, but **visible in the tasks list**.
+- Looping: **always terminates** — no loop-back-to-start option.
+- Project tie-in: **yes, one project per chain** — a chain is effectively a project with strict sequential unlocking.
+- Abandonment: **yes**, a chain can be paused/abandoned partway through without completing every task.
+
+**How to apply:** if a future feature request sounds like it's asking to change one of these four's fundamental shape (e.g. "let buckets have more than 1 item active," "let chains branch"), that's a deliberate departure from this original design, not a bug — confirm intent before assuming it's wrong.