diff options
| author | Claude Code <claude@terst.org> | 2026-08-15 17:59:12 +0000 |
|---|---|---|
| committer | Claude Code <claude@terst.org> | 2026-08-15 17:59:12 +0000 |
| commit | eb0932bddad0daa47c36cd20599944c3dc45482a (patch) | |
| tree | 4b0013e72af9a56ce496d8aeede7068d36fe4389 /feedback_dont_reenable_after_told_off.md | |
Initial commit: tungsten's memory tree
Diffstat (limited to 'feedback_dont_reenable_after_told_off.md')
| -rw-r--r-- | feedback_dont_reenable_after_told_off.md | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/feedback_dont_reenable_after_told_off.md b/feedback_dont_reenable_after_told_off.md new file mode 100644 index 0000000..7133ad8 --- /dev/null +++ b/feedback_dont_reenable_after_told_off.md @@ -0,0 +1,14 @@ +--- +name: feedback-dont-reenable-after-told-off +description: "Don't re-trigger a state the user explicitly asked to be off, even for \"verification\" — confirm the requested behavior only" +metadata: + node_type: memory + type: feedback + originSessionId: 375c858e-e817-41e8-a076-7920d22eab2b +--- + +When a user gives a plain, explicit instruction to leave something off/disabled (not just "fix the bug," but "don't do X"), don't turn it back on yourself afterward to keep testing edge cases in that state. Verify the specific behavior they asked for (e.g. "confirm the persisted setting") and stop there. + +**Why:** In the feedreader project, Peter said plainly "don't auto enable reader mode" for a feed (kottke) — he wanted it off. After shipping the fix (off by default, opt-in via icon, persisted, confirmed), I turned reader mode back ON for kottke myself to keep testing, then spent a long stretch chasing down why it looked wrong in that state. He called this out directly: "I specifically instructed you multiple times to leave reader mode off... you 'discovered' this after spending a few thousand tokens ignoring my plain intent." The actual requested behavior was already correct before that detour — the extra exploration wasn't just wasted effort, it read as not listening. + +**How to apply:** When verifying a fix for "X should stay off/disabled," design the test around confirming that OFF is respected (e.g. does opening it trigger anything, does the setting persist as off) rather than manually flipping it ON to explore what happens in the enabled state, unless the user's request was specifically about how the enabled state should behave. If curiosity about the enabled-state behavior comes up mid-task, that's worth flagging to the user and asking, not just doing. |
