Software Concept Architect · Build — Turn Models into Independent Modules

Turn Models into Independent Modules

Software Concept Architect · Build

Map a confirmed concept model to verifiable, composable implementation. Run only on explicit $software-concept-architect-build invocation; deliver a plan or code as requested. Continue confirmed portions and route model gaps affecting implementation back to software-concept-architect-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, invariants, effects, and result cases. A false precondition does not automatically imply an error output; specify rejection results. Where queries cannot replace atomic checks at the write.
• Rule execution: use WYSIWID completion → binding → invocation semantics. When conjunctively matches named inputs/outputs; omitted fields are wildcards and empty patterns do not imply success. Where queries, filters, or computes zero/many binding sets; zero fires nothing, each set invokes then. Then uses constants or bound values; its calls have no implicit order. Subsequent outputs require new completion matches. State changes alone do not automatically trigger rules.
• Correlation and boundaries: WYSIWID matches completions within one runtime flow and propagates that correlation. Batch actions also require object bindings; documentation groups are not runtime identities. Cross-concept policy belongs in syncs, public actions/queries respect confirmed permissions, and composition owns no business state but may retain execution records. Repository convention: connect rules through concept actions rather than hiding causality in direct sync-to-sync calls.
• Failure and recovery: handle no-match, rejection, and faults according to entry contracts; required responses must not be missing, crossed, or duplicated. Match errors and negative results by their respective cases. Define response, retry, compensation, or intentional ignoring and state consequences. Later failure does not erase completed actions; compensation need not restore state. Where recovery is required, persist rules, completions, bindings/invocations, and causal links; deduplicate by matched occurrence. External effects need separate idempotency guarantees.
• Atomicity and progress: implementations must realize abstract action atomicity; a database transaction alone does not make external effects atomic. Cross-concept transactions are optional, requiring contract permission, participating storage, and isolated external effects. Publish completions after commit or through a consistent outbox; failures still require results. Reachable cycles need termination, retry budgets, or controlled continuation with observable limit outcomes.

Implementation

1. Verify specifications: read the specification contract, application purpose, concept model, both argument layers' assumptions, and project conventions. Trace actions, persistence, failures, and tests in existing code. Route model defects to design, transcription errors to PRD, and code violations here; update specifications before implementing confirmed new behavior.
2. Map boundaries: give each concept a verifiable module; choose packages, classes, and storage for the project. Queries preserve relations and zero/many bindings without accumulating getters for composition. Encapsulate protocols in Requesting or edge adapters; use ports/adapters and composition roots when needed, without imposing layers on every concept.
3. Implement rules: preserve policy boundaries and cross-entry reuse with named functions/rule objects. Simple compositions may use a mediator; consider an engine when conjunctive matching, independent rule evolution, or tracing makes handwritten scheduling complex. Both preserve the constraints above. Ordinary listeners do not automatically provide conjunction, historical correlation, or recovery. Flow indexes and causal records explain complete chains.
4. Colocate and verify: place CONCEPT with its module and SYNCS with its composition package; migrate staged specifications and update the PRD index. Test OPs/invariants inside concepts, matching/bindings/branches per rule, and application purpose, concurrency isolation, and applicable failure recovery across rules. CI checks concept independence and read/write boundaries. Conformance does not establish purpose fitness; route counterexamples to the model. Delivery requires matching specifications/code, attributable executions, excluded actions neither called nor exposed, and no invented unresolved assumptions. Product subsets also require dependency closure, entries, remaining rules, resources, and build flags to be checked.

Read Rust, Spring Modulith, or TypeScript as needed; read scaling only for observed navigation, build, or collaboration pain. Modular-monolith scope, rule code organization, and reliability mechanisms include repository choices; see sources for verified versions and limits.