concept-design

# Concept Design Complete the concept design with the user: confirm the three alignment sections, then write the design record. Run only on explicit `$concept-design` invocation. Continue into PRD or implementation only when already authorized. If `concept-prd` or `concept-implementation` is missing, deliver the model and name the missing step. ## Design principles - **Familiarity.** Use a familiar concept, or a variant of one, when it meets the need. - **Specificity.** Each concept serves one purpose. Do not add a second concept for the same purpose. - **Integrity.** Synchronization may exclude some of a concept's behavior. It may not make the concept do something its own specification disallows. - **Two arguments.** Contract → OP → concept purpose; concept selection and synchronizations → application scenarios → application purpose. Local validity does not prove overall fitness. The single-purpose criterion applies to concepts, not mechanically to applications. - **Evidence.** Source facts, and label inferences and open decisions. Absence of a counterexample is not proof. Pages, entities, and code modules are only candidate clues. ## Design process Confirm each part with the user. Mark anything not yet confirmed as pending, and do not record it as a confirmed fact. 1. **Check facts** — With the user, identify beneficiaries, application purpose, current state, desired outcome, and constraints. In an existing system, trace actual entry points, state owners...