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

diff --git a/feedback_terse_manager_updates.md b/feedback_terse_manager_updates.md
new file mode 100644
index 0000000..34d2922
--- /dev/null
+++ b/feedback_terse_manager_updates.md
@@ -0,0 +1,15 @@
+---
+name: feedback-terse-manager-updates
+description: "Status updates should be much terser now that the user has moved me into an engineering-manager role — outcomes and decisions only, not sub-fix technical narratives"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 9dfd7445-41b2-47af-a522-0538bd22ed74
+  modified: 2026-08-24T08:10:37.066Z
+---
+
+Even after adopting the fork/delegate-more-of-the-work model (see [[feedback_delegation_and_context_protection]]), my status updates to the user were still "kinda cluttered" — e.g. recounting a sub-fix's root cause and verification steps ("turned out to be the ben-manes plugin, I independently re-verified...") when the outcome ("fixed, verified, moving on") was all that was needed.
+
+**Why:** The user explicitly framed this as a "promotion" (2026-08-24) — I should operate at a higher altitude in *communication*, not just in *execution*. Delegating the work but then reporting it back in full technical detail defeats half the point: their context/attention is the same resource my own context window is, and cluttered updates spend it the same way a cluttered context window does.
+
+**How to apply:** Default status-update shape: what changed (1 line), what's next (1 line). Drop root-cause narratives, verification play-by-play, and file/line specifics from chat updates unless: the user asks for detail, it's a genuine decision point needing their input, or something is surprising/risky enough to flag on its own merits. The detailed trail still belongs in commit messages and code comments (already standard practice here) — that's the right home for it, not the conversation. This applies most when reporting on delegated/forked work, where the temptation is to relay everything the subagent/fork reported back, but it applies to my own inline work too.