From 344ba52bf9977f5e087938a51196dfd7a75d2fe2 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 24 Sep 2026 08:57:59 +0000 Subject: 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 --- feedback_user_does_not_read_code.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 feedback_user_does_not_read_code.md (limited to 'feedback_user_does_not_read_code.md') diff --git a/feedback_user_does_not_read_code.md b/feedback_user_does_not_read_code.md new file mode 100644 index 0000000..14792be --- /dev/null +++ b/feedback_user_does_not_read_code.md @@ -0,0 +1,35 @@ +--- +name: feedback-user-does-not-read-code +description: "Peter does not read the code, diffs, or commit messages on his projects — he only experiences the running app, so explanations must be behavioral and correctness is entirely on me" +metadata: + node_type: memory + type: feedback + originSessionId: dc4bccb0-7454-412c-9fcd-f9e336f62a74 + modified: 2026-09-03T07:44:32.910Z +--- + +Peter stated plainly (2026-09-03, doot): **"I don't look at your commits though, the +code is entirely yours."** He experiences these projects only as a user of the +running app — not through diffs, commit messages, file paths, or symbol names. + +**Why:** I had answered "do I need a new APK?" by showing `git log` output for +`android/` and comparing commit timestamps. That's evidence he has no use for; the +answer was just "no." Worse, it implicitly treats commits as a shared artifact when +they're write-only from his side. + +**How to apply:** +- Answer in terms of *observable behavior* ("the widget picks this up on its own", + "you'll see it after a refresh"), never "see commit abc123" or "the diff in + `native_tasks.go`". Detailed rationale still belongs in commit messages and code + comments — that's their real audience: future me, not him. +- Don't cite code or commits as proof to *him*. If something needs proving, prove + it against live behavior/data and report the result. +- **Correctness is entirely mine.** He will not catch a bad change by reviewing it, + so "he'll spot it if I'm wrong" is never a valid fallback — verify against real + data before saying something works (see + [[feedback_verify_before_asserting_root_cause]]). +- I own tracking what changed and what that implies for him (e.g. whether a rebuild + or reinstall is needed) — he shouldn't have to derive it. +- Pairs with [[feedback_terse_manager_updates]]: that one says report at a higher + altitude; this one says the altitude is *user-visible behavior*, not a simplified + summary of the code. -- cgit v1.2.3