72 lines
4.3 KiB
Markdown
72 lines
4.3 KiB
Markdown
## 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
|