kiss-coherencelisted

# KISS — Coherence **One question, one answer.** For every core concept the system reasons about, exactly **one** canonical accessor derives it. Every other site delegates. This is the dimension that `kiss-modularity` cannot cover, and the two are **orthogonal**: | | asks | fails when | |---|---|---| | **modularity** | *Is each unit simple?* | one unit does too much (or too little) | | **coherence** | *Does the system have ONE answer?* | N units each derive the same concept differently | A codebase can score **perfectly** on size, cohesion, dead code and test coverage while N small, clean, single-responsibility functions independently derive the **same concept** from **different stores** and silently drift apart. Simplicity of the parts is **not** coherence of the whole. > **Splitting can HIDE this.** If all the duplicated logic sits in one ugly god-object, the contradictory > reads are adjacent and obvious. Dispersing the concept into tidy separate files removes the proximity > that would have exposed the drift. Aggressive modularization makes each answerer *easier to read* and > the *duplication harder to see*. ## The two failure modes | Failure | Looks like | Fix | |---|---|---| | **Divergent duplication** | N implementations of one concept, reading different stores, drifting | extract ONE canonical accessor; delegate the rest | | **Premature unification** | forcing genuinely different questions through one accessor because they look alike | keep them separate; docu