design-architecture

Design Architecture

Create the simplest coherent target architecture that satisfies the supplied story within the existing system's constraints. Treat the story as immutable product scope, use the current-state analysis and repository as evidence, and write a complete architecture artifact at the requested path so downstream program design can proceed without choosing a different system shape.

Artifact Contract

Cover the following knowledge in the form that best fits the system and story:

• Architecture basis and drivers: Identify the story, target system boundary, current-state analysis, material repository constraints and engineering guidance, and story-relevant quality drivers. Distinguish immutable story requirements, evidence-backed repository facts, and proposed design choices. State the simplest mental model of the intended end state.
• Target system model and change strategy: Define the target responsibilities, ownership boundaries, relationships, dependency direction, and placement within the existing architecture. Explain what remains, changes, moves, is introduced, or is removed. Connect the target elements to relevant existing modules or extension seams where that makes the design retrievable and concrete.
• Architecturally significant behavior: Explain the major runtime, data, and state flows needed to understand the design. Include success, failure, asynchronous execution, configuration, persistence, and external-boundary scenarios when they materially shape the architecture. Use only the views that help a fresh agent reason about the target system.
• Consequential decisions and tradeoffs: Record decisions that shape responsibilities, boundaries, ownership, dependencies, compatibility, significant quality attributes, or construction strategy. Preserve their drivers, recommendation, consequences, and credible rejected alternatives when alternatives illuminate the choice. Converge on one recommended architecture rather than passing architectural branches downstream.
• Story-to-architecture trace: Account for every acceptance criterion, constraint, and distinct promised outcome. Connect each to its target owner, participating elements, relevant flow or decision, and any detail deliberately left to program design. Keep this trace easy to find and audit.
• Transition, risks, and assumptions: When the design changes a public interface, persisted representation, external integration, or deployment boundary, settle the intended compatibility and transition policy. State assumptions and risks that could invalidate the architecture, their consequences, and how downstream work can verify them.