From eb0932bddad0daa47c36cd20599944c3dc45482a Mon Sep 17 00:00:00 2001 From: Claude Code Date: Sat, 15 Aug 2026 17:59:12 +0000 Subject: Initial commit: tungsten's memory tree --- feedback_investigate_the_actual_claim.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 feedback_investigate_the_actual_claim.md (limited to 'feedback_investigate_the_actual_claim.md') diff --git a/feedback_investigate_the_actual_claim.md b/feedback_investigate_the_actual_claim.md new file mode 100644 index 0000000..0e96ad8 --- /dev/null +++ b/feedback_investigate_the_actual_claim.md @@ -0,0 +1,18 @@ +--- +name: feedback-investigate-the-actual-claim +description: "When the user hands over a specific, precisely-worded lead or hypothesis, investigate THAT claim directly -- don't paraphrase it into a different, easier-to-check claim and reject the paraphrase" +metadata: + node_type: memory + type: feedback + originSessionId: 2607e018-d4ad-4ec6-bb68-5f1d0f9a3906 +--- + +**When the user gives a specific lead, check that lead, in their words, before substituting your own reading of it.** Don't translate their claim into an adjacent claim that's more convenient to verify, then confidently reject the adjacent claim as if that settles their original point. + +**Why:** 2026-08-06, doot widget APK size investigation. User asked: "dex *packing* issue with minsdk - what's the highest sdk we can target without bloat? give me options." That's a specific, correctly-aimed technical claim -- "packing" points at packaging/compression, tied explicitly to the minSdk change. Instead of checking packaging/compression, the response was reframed internally as "does minSdk cause bloat via back-compat shims" -- a different, easier-to-check question -- and answered with `apkanalyzer dex packages`, a metric that measures reachable class-tree size, not packaged/compressed byte size. That metric showed ~11MB in both the small and large builds, which was presented as evidence minSdk "isn't the lever." It was already the correct diagnosis, misread and then wrongly rejected. Only a later, separate user question ("what caused the jump") triggered the real investigation (rebuild with only minSdk changed, check `classes.dex` compression via `unzip -v`), which confirmed EXACTLY what the user had said at the start. Net effect: the user's original, correct lead got dismissed with false confidence, then "rediscovered" later and presented as a finding -- wasted their patience for zero net progress over just believing them the first time. + +**How to apply:** +- When a claim/lead is handed over with specific technical vocabulary ("packing," "leak," "race," "timeout," etc.), treat that vocabulary as a hypothesis to test directly, not as loose color to paraphrase away. +- Before picking which tool/metric to use to check a claim, ask: does this tool actually measure what the claim is about? (`apkanalyzer dex packages` measures class reachability, not zip compression -- a mismatch that should have been obvious before running it, not after.) +- If a lead turns out to be right, that's a normal, good outcome of investigation -- not a "discovery" to present as new insight. Say plainly "you were right, here's the confirmation," not "I looked into it and found X" when X is exactly what they told you to look for. +- Related: [[feedback-verify-before-asserting-root-cause]] -- same underlying failure mode (asserting before checking against real data), this time compounded by not even checking the right thing. -- cgit v1.2.3