concept-audit

# Concept Audit Focus: can the concept and application designs fulfill their respective purposes, and does the implementation conform? Run only on explicit `$concept-audit` invocation and remain read-only. Design can be reviewed without code; without specifications, review only observable code properties. Mark conclusions unsupported by missing material as unverified. ## Model A **concept** is a behavioral unit designed for one purpose. A concept argument connects its purpose to its operational principle (OP), state, and actions. An application argument connects the application purpose to concept selection, synchronizations, and end-to-end scenarios. Conformance to an unsuitable model does not establish fitness; successful OP tests do not prove the purpose, and locally sound concepts do not prove the application purpose. Review five dimensions: - **Fitness:** behavior meets the real need under stated assumptions. - **Independence:** concept definitions do not depend on other concepts; this repository also requires concept modules not to reference one another. - **Composition:** **synchronization may restrict behavior, never extend the contract**. Restriction alone is not a violation; remaining scenarios must still meet the need. - **Drift:** implementation differs from a confirmed behavioral contract; distinguish omissions from contradictions. - **Product subsets:** each subset preserves its purpose, entry points, required synchronizations, and resources. Eviden...