diff options
Diffstat (limited to 'project_doot_bucket_followups.md')
| -rw-r--r-- | project_doot_bucket_followups.md | 48 |
1 files changed, 48 insertions, 0 deletions
diff --git a/project_doot_bucket_followups.md b/project_doot_bucket_followups.md new file mode 100644 index 0000000..608f3e3 --- /dev/null +++ b/project_doot_bucket_followups.md @@ -0,0 +1,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. |