Source
me-fuji session 150 (#1170 partial fix in PR #1173).
Observation
During implementation of the post-DP V-crossing detector, I scaffolded a second `_detect_gap_crossing_column` function for a case the issue body described — where one DP track is absent across a long coincidence stretch. Probe-investigation against the real af-75 chart then showed both DP tracks are continuous through the full plot with only short dash-gap-sized holes — there is no large single-track gap.
Two paths from there:
- Ship both detectors "in case it's useful later."
- Delete the gap detector; ship only the V-detector.
Picked (2): the gap detector would be 80 lines of code with zero test coverage on real data, ripe for future-maintainer toxicity. The YAGNI principle already covers "don't build for hypothetical future requirements," but this is a related case: you DID build it, then learned it's not needed. The temptation to keep it is sunk-cost adjacent.
Proposed template change
Add to `base/core/quality.md` near the YAGNI bullet:
Delete dead-code paths discovered during implementation. When probe-investigation against real data invalidates a code path you wrote earlier in the same session, delete it in the same commit. The "in case it's useful later" temptation is sunk-cost reasoning — what you've already written feels valuable. But code without a real test case to anchor it rots fast and confuses future maintainers about which path actually fires. If a future case appears that needs the deleted path, git history has it.
Distinct from YAGNI itself: YAGNI says don't build speculative code. This says: when you've built it and probing makes it speculative, retract.
Alternatives considered
- Fold into the existing YAGNI bullet as "(corollary: retract scaffolding made speculative by later probing)." Tighter but easier to miss.
- Add to `base/workflow/ai-workflow.md` "When to revert vs when to iterate" section. Fits there too — it's about recognizing when to revert vs. ship.
Preference: standalone bullet near YAGNI, since the principle is about the code's value (or lack thereof) regardless of who wrote it.
Source
me-fuji session 150 (#1170 partial fix in PR #1173).
Observation
During implementation of the post-DP V-crossing detector, I scaffolded a second `_detect_gap_crossing_column` function for a case the issue body described — where one DP track is absent across a long coincidence stretch. Probe-investigation against the real af-75 chart then showed both DP tracks are continuous through the full plot with only short dash-gap-sized holes — there is no large single-track gap.
Two paths from there:
Picked (2): the gap detector would be 80 lines of code with zero test coverage on real data, ripe for future-maintainer toxicity. The YAGNI principle already covers "don't build for hypothetical future requirements," but this is a related case: you DID build it, then learned it's not needed. The temptation to keep it is sunk-cost adjacent.
Proposed template change
Add to `base/core/quality.md` near the YAGNI bullet:
Distinct from YAGNI itself: YAGNI says don't build speculative code. This says: when you've built it and probing makes it speculative, retract.
Alternatives considered
Preference: standalone bullet near YAGNI, since the principle is about the code's value (or lack thereof) regardless of who wrote it.