dry-principlelisted

# DRY Principle Apply DRY thinking to every programming task — not as a pedantic rule, but as a design instinct. DRY means every piece of **knowledge** has a single, authoritative representation in the system. The key word is knowledge, not code. Two identical-looking code blocks might represent different knowledge (and should stay separate). Two different-looking blocks might encode the same business rule (and should be unified). The test: "If this knowledge changes, how many places do I need to update?" If the answer is more than one, that's a DRY violation worth examining. ## Run this as a multi-pass sweep The different kinds of duplication don't just *look* different — they're found by different search motions, and that's the catch. Magic values surface when you *scan literals*. Knowledge duplication surfaces when you *ask what changes together*. Wiring duplication surfaces when you *compare interaction shapes* across siblings. Symbol↔label duplication surfaces when you *match a typed token against a bare string in another file*. Same-file scattered duplication surfaces when you *read look-alike function bodies side by side*. Per-instance duplication surfaces only when you *picture the component multiplied across every screen, row, or tab it renders into* — it's invisible in the source, which appears exactly once. These are genuinely different mental questions, and the moment you lock onto one — say, hunting magic numbers — you stop seeing the others, because you're n