# ProductPhase {X.Y} — Architecture Story for {project}

## 1. Intent and Context

Explain why **{project}** exists in this ProductPhase.

- Problem framing
- Goals
- Constraints (technical, organizational, regulatory)

## 2. Architecture Drivers (ASRs)

Summarize the key ASRs that define the architecture for this ProductPhase.
Link each to its file under `docs/asr/` (e.g. `docs/asr/0001-short-title.md`).

For each ASR, briefly describe:

- What requirement or invariant it encodes
- Why it matters for this phase's architecture

## 3. Architectural Decisions (ADRs)

Describe the major ADRs that implement, refine, or amend the ASRs for this phase.
Link each to `docs/adr/`.

For each ADR, explain:

- The decision
- How it satisfies or adjusts specific ASRs
- Notable consequences for implementation

## 4. Specs — Behavior in this ProductPhase (optional)

If the project uses Specs, outline the main feature-level Specs in scope for
this phase. Specs are optional in A2C; when present, they must follow A2C
conventions (see `templates/spec/` and governing ADRs).

For each Spec:

- Summarize key functional and non-functional requirements for this phase
- Explain how the Spec realizes relevant ASRs/ADRs

## 5. Contracts — Interfaces and ABIs (optional)

If the project uses Contracts, describe the main interface/ABI definitions for
this phase. Contracts are optional in A2C; when present, they must follow A2C
conventions.

For each Contract:

- Describe its role
- Note versioning or ProductPhase-specific aspects

## 6. A2C and planning flow in this phase

Explain how A2C and planning artifacts were used:

- How intent became ASRs and ADRs
- How Specs/Contracts (if any) were derived
- How Epics/Tasks mapped to delivery
- How implementation feedback led to amended or superseded ADRs/ASRs (if any)

## 7. Summary of the architecture for this phase

Short narrative tying everything together:

- Key constraints and decisions that define this phase
- Behaviors and interfaces delivered
- Positioning for future ProductPhases