tungsten: memories from the Listen build session

Adds the feedback and project memories written while building Listen, podkit
and the devtools wrappers, and updates the FeeDreader entries. Uncommitted
since August; committing before merging Fedora's tree so neither side is lost.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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.