---
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.