codinglisted

# Coding ## Making Changes **Note:** These rules are defaults; deviate only when you can state what following the rule would cost here. - **DRY**: a string, a threshold, a supported-values list has one authoritative home, easy to change/update/extend. - **Do not overfit**: Avoid overfitting solutions to problems in this chat. Think bigger. - **Separation of Concerns & Extendable Components**: Insist on separation of concerns. - **Duplication over the wrong abstraction governs structure**: tolerate two similar blocks until the shared concept is obvious (rule of three); a helper/component that needs a `mode` flag to serve both callers is the wrong abstraction. - **Extend along the promised axis**: at three cases the axis is promised (rule of three); shape code to make the fourth easy to add, without overfitting to just today's use-cases. - **Don't name a general structure after its first occupant**: once something is a shared slot or grouping, name it for the axis it opens — not for today's only member. Specificity belongs on the leaves. - **Tidy/Refactor separate from feature work**: an opportunistic refactor is in its own commit. Each stays reviewable. ## Code Comments Guiding Principles: 1. **Write for the stranger who understands the purpose of the project**: a comment must hold for a reader with only the file (and its project); with no access to this conversation, no contextual awareness of how the project evolved, no memory of the task that produced it. A