concept-implementation

# Concept Implementation Map a confirmed concept model to verifiable, composable implementation. Run only on explicit `$concept-implementation` invocation; deliver a plan or code as requested. Continue confirmed portions and route model gaps affecting implementation back to concept-design. ## Concepts - **Concept module**: partitions actions and their state relations by purpose, not by entity. The same identity can participate in several concepts. Use type parameters/opaque IDs for external identities; concepts never reference, call, or query each other. Encapsulate storage while exposing abstract state and actions to composition. - **Synchronization rule**: a named causal rule outside concepts, expressing identifiable application policy that can be located, verified, and evolved independently. One entry can trigger several rules; one rule can serve several entries. Grouping preserves rule boundaries without requiring a file or package per rule. - **Actions and queries**: actions are observable occurrences in the contract and may read or update state. Queries only return binding sets and produce no action completions. A request can occur as a Requesting/Web action without the requested action following. ## Constraints - **Contracts and legibility**: composition produces only behavior permitted by each concept contract. Keep concept/action/parameter meanings aligned across specifications, code, and logs; map renames. Actions enforce preconditions, inva...