---
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.