1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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.
|
