browser/openspec/changes/architecture-delivery-stream/specs/architecture-delivery-workflow/spec.md

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