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

diff --git a/project_doot_pull_punch_list.md b/project_doot_pull_punch_list.md
new file mode 100644
index 0000000..a9f479b
--- /dev/null
+++ b/project_doot_pull_punch_list.md
@@ -0,0 +1,36 @@
+---
+name: project-doot-pull-punch-list
+description: "doot's pull-based punch list (committed_date) shipped 2026-09-03; carry-over is the open design question — ask Peter about it on/after ~2026-09-10 if he hasn't raised it"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: dc4bccb0-7454-412c-9fcd-f9e336f62a74
+  modified: 2026-09-03T07:47:34.540Z
+---
+
+Reworked doot's task model so the day's list can actually reach zero. `due_date`
+had meant both "real deadline" and "when I plan to do it"; chains stamped
+`due_date = now` on every unlock, so milestones arrived looking overdue. Split
+into `due_date` (deadlines only) + `committed_date` ("I chose this for today").
+The day = committed work + genuine deadlines; chain steps and bucket items reach
+it only via a "+ today" pull. Shipped and verified against production 2026-09-03.
+Full design and remaining gaps live in the repo at
+`docs/superpowers/specs/2026-09-02-pull-based-punch-list-design.md` — read that
+rather than restating it here.
+
+**Open question — carry-over.** A task committed today and not finished simply
+stops appearing tomorrow; it does not show as carried. The choice (auto-roll
+forward vs. make him re-choose it during a review) is about how Peter wants to
+work, not something to infer.
+
+**Why:** He explicitly said he'd report back after living with it, and: "I'll let
+you know about the carryover thing (or if it's been a week or so feel free to
+ask)."
+
+**How to apply:** If a doot session happens on or after roughly **2026-09-10** and
+he hasn't raised carry-over, ask him directly — a short question about which
+behavior he wants, not a proposal to build both. Don't build carry-over before
+that answer. Related: [[feedback_investigate_the_actual_claim]] and
+[[feedback_user_does_not_read_code]] — this is exactly the class of question to
+ask about *intent* rather than infer from symptoms, which is what went wrong
+mid-session on the recurrence fix.