fsl-design-reviewlisted

# FSL Design Exploration — A Procedure for Translating Design Decisions into Contract-Conformance Checks The core is the following 5-step procedure. Design principles (SOLID etc.) are not the starting point of the procedure; they appear as judgment lenses at each step. This skill's job is to translate "is this design good?" into "does this design conform to the frozen contract?" and have fslc answer with counterexamples. **Prerequisite**: FSL syntax, the verification commands, and the repair protocol follow the fsl skill (SKILL.md + reference.md). This skill supplies only the procedure and the interpretation of results. If the user needs a new design-layer `.fsl` written before review, use `fsl-design` for authoring and return here for review/proposal judgment. Working examples: `specs/bank.fsl` + `bank_impl.fsl` + `bank_refines.fsl` (refinement), `seat_booking_*` (state-tag-dependent mappings), `specs/bank_system.fsl` (compose). ## Procedure ### Step 1 — Translate the design question into the language of contracts Design questions almost always fall into one of four shapes: comparing new design proposals / adding a variant or extension / reviewing a change to an existing design / judging substitutability. In every shape, what you identify is the same: - **The open part**: what may change (variants, extension points, the changed site) - **The closed part = the contract**: what must not break (invariants, guards, externally observable state) Lens — OCP: decide the "ra