ConceptScaffoldGen

Scaffold a concept spec for $ARGUMENTS with annotations, state declarations (groups, enums, records), typed action signatures, capabilities, and a register() action.

When to use: Use when creating a new concept specification from scratch. Generates a .concept file with annotations (@version, @category, @visibility, @gate), purpose, state (with groups, enum types, record types), actions with typed variants, invariants, capabilities block, and a register() action following Jackson's methodology.

Design Principles

• Singularity: Each concept serves exactly one purpose — if the purpose has 'and', it's two concepts.
• Independence: A concept never references another concept's types or calls another concept's actions. Use type parameters and syncs.
• Sufficiency & Necessity: Every state field is needed by at least one action. Every action serves the concept's purpose. No dead state.
• Invariant Completeness: Use all six invariant constructs comprehensively: example (named tests), forall (quantified properties), always (state predicates), never (safety), eventually (liveness), action requires/ensures (contracts). Cover core purpose, error paths, constraints, state transitions, and boundary conditions. Aim for 2-5 invariants per concept.
• Success is ok: The happy-path variant must always be named ok. Do not use domain-specific success names like created, configured, registered, updated. Domain context belongs in the output fields. Exception: actions with multiple distinct success outcomes that syncs need to distinguish (e.g., ok/miss for cache lookup, clean/conflicts for merge).