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

diff --git a/feedback_feedreader_alarm_vs_explicit_refresh.md b/feedback_feedreader_alarm_vs_explicit_refresh.md
new file mode 100644
index 0000000..9c5f72f
--- /dev/null
+++ b/feedback_feedreader_alarm_vs_explicit_refresh.md
@@ -0,0 +1,17 @@
+---
+name: feedback-feedreader-alarm-vs-explicit-refresh
+description: "feedreader refresh model is alarm + fetch-on-launch + explicit button, not alarm-vs-explicit-only"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: d248310c-6c0c-43d3-8ae2-1e765347624b
+  modified: 2026-08-22T22:42:36.554Z
+---
+
+When the user asked for "an explicit refresh button and only refresh on fresh open or explicit refresh," I removed the 5am morning alarm (MorningFetchReceiver) along with the hourly periodic WorkManager job. The user immediately corrected: they wanted the periodic job gone but the alarm kept — "I want the alarm... might want to know if there are new articles without screwing up the list ordering, but that's less important."
+
+**Why:** the user's phrasing wasn't a literal spec ("only these two triggers") — it was really about killing the noisy/unpredictable hourly polling, not the specific once-a-day alarm they'd deliberately asked for earlier in the same session. Don't over-apply a stated constraint to every mechanism that superficially fits the same category ("background trigger") when only one instance of it was actually the complaint.
+
+**How to apply:** feedreader's refresh model is now: fetch on cold launch, fetch via the explicit refresh button (Unread/Older top bar), and the 5am exact alarm — no periodic hourly job. If asked to touch refresh behavior again, keep the 5am alarm unless told otherwise.
+
+Also flagged, lower priority, not yet implemented: a background/alarm fetch arriving while the Unread list is open can reorder visible rows (new articles insert by publishedAt DESC). The existing "N new articles" snackbar already surfaces the count; the ask is to also avoid the reorder/jump, but the user called this less important than getting the alarm back.