rule-ramificationslisted

# Ramifications These are not general best practices. They are the eight failure classes that actually shipped, measured across 3,127 `fix` commits in three production repos (see [`docs/failure-evidence.md`](../../../../docs/failure-evidence.md)). The thing they share is why QA keeps catching them and tooling does not: > "this is invisible in a diff and cannot be caught by testing the component > alone — the bug lives in WHO owns the mount" > — *Project B, fix commit* Typecheck passes. The build is green. The console is clean. The component renders. It is still wrong. **A clean verification run is not evidence against any of the eight below** — each one has to be checked deliberately. ## Before writing the code Answer these in one or two lines each. If a question does not apply, say so and move on — but do not skip reading it, because the ones that get skipped are the ones in the list. **1. Ordering and async (32–41% of all fixes — the single largest class)** What must happen before this runs? What if the user acts before it finishes, twice in a row, or navigates away mid-flight? Is anything awaited that could resolve after the component is gone? **2. Every state of the flow, not just the successful one** Enumerate them explicitly: first run · empty · loading · partial · error · offline · logged out · returning user with old data · the second time. Most "incomplete flow" fixes are one of these never having been considered at all. **3. Who else reads or writes this st