project_doot_bucket_followups.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

---
name: project-doot-bucket-followups
description: "doot maintenance-bucket follow-ups requested 2026-09-07: a Home Maintenance bucket, on-demand pull from a bucket, plus an unreported bug where active bucket items never return to dormant"
metadata: 
  node_type: memory
  type: project
  originSessionId: dc4bccb0-7454-412c-9fcd-f9e336f62a74
  modified: 2026-09-07T07:08:00.017Z
---

Captured 2026-09-07 as explicit "note for later" items, none of them built yet.
Bucket mechanics live in `internal/store/buckets.go`; the pull model they plug
into is [[project_doot_pull_punch_list]].

**1. A "Home Maintenance" bucket.** Peter wants a second bucket alongside Yard
Work. Seed item he named: "fix ohana curtain holder" (this already exists as a
free-standing undated task — fold it in rather than duplicating). Contents beyond
that need asking; don't invent household chores for him the way the yard list was
gathered (he supplied every yard item himself).

**2. Pull from a bucket on demand.** Today a bucket only surfaces work on its
cycle (Yard Work: pick 2 every 4 days). He wants to be able to say "give me
something from Home Maintenance right now" without waiting for the cycle. Likely
shape: an action that activates the next-stalest pool item immediately —
`selectBucketCycle` already ranks by staleness, so this is close to a
one-item-now variant of it.

**3. Bug he has NOT reported — active items never go dormant.**
`selectBucketCycle` activates `pick_n` dormant items but nothing ever deactivates
an active one that simply wasn't done. An item leaves `active` only by being
completed or deferred, so actives accumulate: 7 were active on 2026-09-07 against
a `pick_n` of 2, including three left over from the old 14-day cycle. Left alone
this drains the pool back to "everything is always active", which is exactly the
condition populating the pool was meant to fix.

**Why this is a question, not a fix:** the obvious repair (uncompleted actives
return to dormant at the next cycle) mirrors his stated staleness rule for
recurring tasks — "if I don't get a weekly task done by the next iteration it's
just stale/abandoned" — but that's an inference about intent, and inferring intent
from a symptom is precisely what went wrong on the recurrence fix earlier in that
session. Ask before changing rotation semantics. See
[[feedback_investigate_the_actual_claim]].

**Also relevant:** a bucket cycle stamps every item it activates with a
byte-identical `due_date`, which is why two chores landed at the exact same
timeline slot. The rendering was fixed (86f1486, lanes now share width), but the
underlying modelling is still odd — nothing about "trim hedges" happens at
16:31:04. A date-only due date would be more honest.