## ADDED Requirements

### Requirement: Ordered Architecture Backlog
The repository SHALL maintain an ordered architecture delivery backlog that maps each future OpenSpec change to its primary roots, purpose, dependencies, and verification expectations.

#### Scenario: Backlog lists the next architecture change
- **WHEN** a contributor needs the next implementation target
- **THEN** the backlog identifies the next change name, affected roots, and why it follows the previous change

#### Scenario: Backlog preserves bootstrap as baseline
- **WHEN** a follow-up change is planned
- **THEN** it references `bootstrap-game-server-platform-architecture` or archived baseline specs instead of redefining the product scope

### Requirement: Single Active Implementation Change
The delivery workflow SHALL keep only one concrete implementation OpenSpec active at a time unless the user explicitly requests a pause, reprioritization, or parallel track.

#### Scenario: Previous change is not closed
- **WHEN** the current implementation change has unchecked tasks or missing verification evidence
- **THEN** the next concrete implementation change is not started as active work

#### Scenario: User requests a reprioritization
- **WHEN** the user explicitly changes the implementation order
- **THEN** the backlog is updated or superseded before the new active change is implemented

### Requirement: Per-Change Handoff
Each concrete implementation OpenSpec SHALL include a handoff block suitable for a fresh chat, containing the change name, implementation objective, required context files, expected verification commands, and stopping conditions.

#### Scenario: New chat starts implementation
- **WHEN** the user opens a fresh chat for a concrete change
- **THEN** the handoff block gives enough context to implement that change without expanding scope to unrelated backlog items

#### Scenario: Handoff references verification
- **WHEN** the handoff is prepared
- **THEN** it includes `scripts/check-structure.sh`, `openspec validate <change> --strict`, and any change-specific build, test, or browser walkthrough commands

### Requirement: Closure Evidence
Implementation tasks SHALL remain unchecked until the implementing chat records verification evidence for the task or group of tasks.

#### Scenario: Task is completed
- **WHEN** a task checkbox is marked complete
- **THEN** the change records the command, walkthrough, file reference, or artifact that proves the task is complete

#### Scenario: Verification fails
- **WHEN** a required verification command fails
- **THEN** the implementation chat fixes the issue or records the blocker before the change is considered closed

### Requirement: Ownership Boundaries
Each concrete change SHALL name its affected project roots and preserve root ownership boundaries from `AGENTS.md`.

#### Scenario: Change touches multiple roots
- **WHEN** a change updates more than one of `platform/`, `run/`, `platform_web/`, and `plugins/`
- **THEN** the OpenSpec design explains the contract boundary and avoids casual cross-root imports

#### Scenario: Shared contracts are needed
- **WHEN** two roots need the same request, response, or protocol shape
- **THEN** the change uses an explicit contract file, generated artifact, or documented copy boundary rather than importing implementation code across roots

### Requirement: Progress Tracking
The delivery workflow SHALL maintain a progress record for the architecture stream that shows completed, active, pending, paused, and blocked changes.

#### Scenario: Active change completes
- **WHEN** a concrete implementation change is closed
- **THEN** the progress record marks it complete with verification evidence and identifies the next pending change

#### Scenario: Change is split
- **WHEN** a backlog item is too large for one implementation chat
- **THEN** the progress record replaces it with smaller ordered changes and records the reason for the split