lamina-invariants

# Invariants Rules the product must never violate. Design so illegal states are unrepresentable — not merely error-handled after the fact. ## Verify Each `invariants[]` id gets a probe in `/lamina-verify` — attempt violation on live product; UI must prevent or recover per linked `scenarios[]`. **Invariants vs dependencies:** Invariants are predicates that must hold in valid states. Dependencies are reachability edges — what must exist before a workflow can succeed. Do not collapse them; use [Dependencies](../lamina-dependencies/SKILL.md) for cross-feature setup. ## Decision frameworks - **Invariant**: A predicate that must hold for every valid system state (one hall ticket per student per exam; venue capacity not exceeded; cancelled tickets cannot be downloaded). - When to use: Any entity with uniqueness, capacity, lifecycle, or permission constraints. - How: Write in user language in the transactional graph `domain`; link scenarios to violation attempts. - **Define errors out of existence**: Redesign flows so invalid actions are unavailable, not allowed-then-rejected (disable download when unpaid; hide regenerate when exam completed). - When to use: High-frequency violations that produce support load. - How: Match UI affordances to legal states only. - **Illegal transitions**: State machine edges that must never occur (confirmed → draft without admin audit; issued → unissued without void record). - When to use: Lifecycle entities (orders, tickets, bookings)...