Concept Implementation

Concept Implementation

Focus: how should confirmed concept behavior become verifiable, composable modules? Run only on explicit $concept-implementation invocation. Deliver a plan or code as requested. Continue confirmed portions and route model gaps that affect implementation back to concept-design.

A concept module encapsulates state, invariants, actions, and queries. Modules do not reference one another. Ports declare interfaces and adapters implement them; domain code depends on neither protocols nor other concepts. The synchronization layer coordinates public actions and owns cross-concept policy; the composition root wires implementations, while interface adapters translate DTOs and protocols into composition entry points.

Cross-concept coordination belongs in synchronizations, not the composition root. Concept actions atomically preserve their own invariants. A composition query cannot replace an action. Conformance tests do not establish model fitness.

Constraints

• Public interfaces, including queries, preserve confirmed coordination and authorization policy; one entry point may trigger multiple rules.
• The composition layer owns no domain state, but may persist provenance, retry, and idempotency records.
• Errors are matchable output cases with an explicit response, retry, compensation, or intentional-ignore strategy. Transactions do not replace failure semantics.
• Change the specification before implementing confirmed new behavior. Grouping exists only to solve navigation, build, or team pain.

Implement and Verify

1. Verify input — Read references/spec-format.md, application purpose, concept model, both argument layers, colocated or staged specifications, and project conventions. Trace actions, persistence, failure paths, and tests in existing code. Route model defects to design, transcription errors to PRD, and code violations here.
2. Map modules — Map each concept to one testable module. Prefer a separate package without requiring it. Keep physical state private, expose abstract state for composition queries, and expose actions as services. Preserve declared query bindings. Implement zero or more type parameters as generics or opaque IDs, never another concept's entity type.
3. Implement composition — Read references/composition-layer.md; default to a mediator and consider an engine only for evolving rules, multi-event matching, or tracing. Preserve completion events, bindings, concurrency, request correlation, and failure semantics. Interface adapters map requests or messages to explicit entry points; coordination produces required responses.
4. Colocate specifications — Place CONCEPT with its module and SYNCS with its composition package; migrate staged files and update the overall PRD index.
5. Verify behavior and seams — Read only the applicable language reference and add architectural guardrails to CI. Tie OP tests to concept purposes and end-to-end tests to application purpose and synchronizations, including their assumptions. Read references/scaling.md only when grouping or package splitting solves observed pain.

Completion requires no concept-module references, all cross-concept business policy in synchronizations, protected domain seams in CI, contract tests for OPs, application scenarios, invariants, bindings, match cardinality, failure, replay, and request isolation, observable completion semantics through transactions, colocated specifications matching code, excluded actions neither called nor exposed, and product subsets verified against dependency closure, entry points, remaining rules, resources, and build flags.

Language references: Rust references/rust.md; Spring Modulith references/java-spring.md; TypeScript references/typescript.md; engineering sources references/sources.md.