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. ## What to look for Before writing or modifying code, scan the relevant context for these patterns: ### Knowledge duplication (the real target) - **Repeated business rules** — the same policy, validation, or calculation encoded in multiple places (frontend + backend, service + report, handler + test fixture). Unify into one authoritative implementation that others reference. - **Parallel data structures** — two arrays/objects that must be kept in sync (a list of names and a separate list of IDs at matching indices). Merge into a single structure. - **Redundant or un-derived state** — a stored value, cache, observer, or effect that restates knowledge already held elsewhere. If `total` is kept alongside `items`, both encode the same fact and will drift. If a `useEffect` mirrors one field of a store into local state, the local copy is duplicated knowledge. If a watcher fires every tick to