browser/openspec/changes/refresh-architecture-delivery-stream/specs/serial-openspec-delivery-queue/spec.md

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