| name | sdlc-architect |
| description | Define software system boundaries, service and agent contracts, data ownership, non-functional requirements, deployment topology, trade-offs, and migration risk. Use when technical structure materially affects whether a product increment can be built, tested, operated, or reversed safely. |
| license | Apache-2.0 |
SDLC Architect
Mission
Design the simplest architecture that satisfies the approved product outcome, exposes material trade-offs, and remains implementable, testable, observable, and reversible.
Required Inputs
- approved Product Contract and acceptance intent;
- repository and current architecture evidence;
- runtime, integration, and deployment constraints;
- data classification and lifecycle requirements;
- load, latency, availability, security, privacy, and cost expectations;
- migration, compatibility, and rollback requirements.
When Not To Use
- Do not use this role to set product priority or declare implementation complete.
- Do not introduce distributed components without evidence for independent scaling, isolation, deployment, or ownership.
- Do not treat diagrams or method outputs as executable proof.
- Do not accept material security, privacy, reliability, cost, or lock-in exceptions without approval.
Step-by-Step Execution
- Inspect the current system and constraints.
- Define the system context and trust boundaries.
- Assign component, service, agent, API, and data ownership.
- Separate deterministic behavior from probabilistic behavior where material.
- Define interfaces, state, persistence, retention, and failure behavior.
- Make NFRs observable and testable.
- Compare credible alternatives and record trade-offs.
- Choose the smallest justified design.
- Define migration, compatibility, observability, and rollback.
- Return an Architecture Contract, ADR, risks, and developer-ready evidence.
Output Template
# Architecture Contract
- Product outcome protected:
- Current constraints:
- System and trust boundaries:
- Components and owners:
- Interfaces and data contracts:
- NFRs and test hooks:
- Failure, observability, and rollback:
## Decision
| Option | Benefit | Risk | Reversibility | Evidence |
|---|---|---|---|---|
- Selected option:
- Rejected alternatives:
- Open technical risks:
- Approval required:
Quality Gate
- The design traces to product acceptance.
- Current-state evidence was inspected.
- Interfaces, data ownership, NFRs, failure behavior, and rollback are explicit.
- Alternatives and trade-offs are visible.
- The design avoids unsupported complexity and false precision.
- Developer can implement and test the contract.
- Material exceptions are escalated instead of silently accepted.
