## ADDED Requirements

### Requirement: Serial OpenSpec Queue
The repository SHALL maintain a serial OpenSpec queue that identifies the current guard, the next change to create or implement, the affected roots, and the verification gate for each item.

#### Scenario: Fresh chat needs the next item
- **WHEN** a contributor opens a fresh chat to continue the architecture stream
- **THEN** the queue identifies the single next OpenSpec action and the files that must be read first

#### Scenario: Queue has stale completed work
- **WHEN** an OpenSpec change is marked complete by `openspec list`
- **THEN** the queue no longer lists that change as active

### Requirement: Next Change Pointer
The repository SHALL maintain a next-change pointer document that contains the current guard condition, next change name, creation prompt, implementation prompt, and stop condition for the next fresh chat.

#### Scenario: Generator chat starts
- **WHEN** the next-change pointer says the next action is to create a change
- **THEN** the chat creates exactly one OpenSpec change, validates its artifacts, updates the pointer, and stops

#### Scenario: Implementation chat starts
- **WHEN** the next-change pointer says the next action is to implement a change
- **THEN** the chat implements only that change and does not start the next queue item unless the user explicitly asks

### Requirement: Active Guard Before Advancement
The queue SHALL block creation of a new concrete OpenSpec while an existing active change has unchecked required tasks or missing verification evidence.

#### Scenario: Frontend walkthrough evidence is missing
- **WHEN** `fix-env-profile-settings` still has an unchecked browser walkthrough task
- **THEN** the queue requires closing or explicitly blocking that task before generating the next concrete OpenSpec

#### Scenario: User explicitly reprioritizes
- **WHEN** the user asks to skip or reprioritize the active guard
- **THEN** the queue records the reason and updates the pointer before creating a different next OpenSpec

### Requirement: Proof-Oriented Backlog
The queue SHALL prioritize proof-oriented changes that verify real game server management behavior before adding broad new product scope.

#### Scenario: User says the project feels like a demo
- **WHEN** the next concrete OpenSpec is generated after current guards are closed
- **THEN** the first generated change focuses on end-to-end baseline verification across platform, run, frontend, and game management plugins

#### Scenario: A proof change finds missing behavior
- **WHEN** a proof-oriented change discovers a required flow is demo-only or broken
- **THEN** the queue records the follow-up implementation OpenSpec needed to close that gap

### Requirement: Channel and Scope Boundaries
Every queued OpenSpec SHALL preserve the platform channel boundaries and product scope boundaries from `AGENTS.md`.

#### Scenario: Plugin needs to operate files or configs
- **WHEN** a game management plugin needs file, config, log, or run operation capability
- **THEN** the OpenSpec routes the capability through platform-mediated contracts instead of direct browser/plugin access to run

#### Scenario: Logs and artifacts are both active
- **WHEN** a queued change touches log ingest or artifact transfer
- **THEN** the OpenSpec includes verification that file/artifact transfer does not block log ingest, control heartbeat, job ack, or job result delivery

#### Scenario: Unrelated SaaS scope appears
- **WHEN** a queued change introduces billing, cloud host sales, agent-provider workflows, or unrelated marketplace behavior
- **THEN** the change is considered out of scope unless a future user-approved OpenSpec explicitly requires it

### Requirement: Interface Satisfaction Handoff
The queue SHALL include a dedicated path for interface dissatisfaction that turns subjective UI feedback into a concrete interaction-design OpenSpec.

#### Scenario: User dislikes an interface
- **WHEN** the user says a page or flow is unsatisfactory
- **THEN** the queue uses a design-change prompt that asks for target workflows, pain points, reference interactions, and browser acceptance criteria before implementation

#### Scenario: Interface work is implemented
- **WHEN** a UI or interaction change touches `platform_web`
- **THEN** browser walkthrough evidence is required before the tasks can be marked complete