state-combination-modelinglisted

# State Combination Modeling ## The problem, and when to invoke this skill When N independent boolean inputs drive one component, the state space is 2^N — but code written axis-by-axis silently models only the combinations its author pictured. The classic bug: an exclusive switch over "the status" deletes a state that two independent inputs can genuinely produce, and nobody notices until a user lands in it. Invoke this skill whenever a component or view is driven by two or more independent boolean inputs (feature flags, permissions, connection states, loading states). ## The minimum bar (MUST) 1. **Enumerate the full 2^N product** of the N independent boolean inputs — a literal table, not a mental sample. The table is cheap; the deleted state is not. 2. **Classify each combination real / impossible — and prove "impossible".** An `impossible` classification must cite a domain invariant or an explicit user/plan confirmation. **Unconfirmed → treat as real**: a unilateral "impossible" recreates the deleted-state bug one level up. 3. **Never collapse independent axes into one exclusive switch.** Orthogonal inputs drive *content* and *actions* separately — a permission flag may swap only the button, not the whole view. An exclusive switch over a synthetic "status" is the collapse in disguise. 4. **Tests cover every real combination.** The enumeration table doubles as the test matrix; a real combination without a test is an unmodeled state with extra steps. ## Anti-patterns -