68 lines
3.9 KiB
Markdown
68 lines
3.9 KiB
Markdown
## 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
|