to-invariants

Take the current conversation context and codebase understanding and produce a set of invariants: properties that must ALWAYS hold for the system to be correct. Do NOT interview the user — synthesize what you already know. Two audiences, two sections: design-level system invariants and enforceable invariants that map to a concrete check.

An invariant is not a feature, a requirement, or a nice-to-have. It is a condition whose violation means the system is broken. "Users can reset their password" is a feature. "A session token is never valid after logout" is an invariant.

Process

1. Explore (if needed)

If you have not already, skim the code in the area under discussion to ground the invariants in the real data structures, state machines, and boundaries. Use the project's own vocabulary. An invariant you cannot point at a place in the code for is a guess — mark it as one.

2. Discover invariants

Sweep the design through these lenses — each tends to surface a different class of invariant. Aim for coverage, not volume; skip lenses that don't apply.