first commit
This commit is contained in:
npc0-hue
+68
@@ -0,0 +1,68 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Acceptance suite runs against the real local debug stack
|
||||
The repository SHALL provide an automated browser acceptance suite that verifies platform_web against the API-backed local debug stack and safe game plugin fixture.
|
||||
|
||||
#### Scenario: Suite prepares local debug fixture
|
||||
- **WHEN** the acceptance suite is run from a clean checkout with documented local debug prerequisites
|
||||
- **THEN** it MUST start or reuse platform, run worker, platform_web, and the dev game plugin fixture through documented local debug commands and MUST seed or verify `game.example`, `server-local-debug`, and `run-local-debug` before browser assertions begin
|
||||
|
||||
#### Scenario: Suite uses platform-owned browser API path
|
||||
- **WHEN** platform_web is exercised by the acceptance suite
|
||||
- **THEN** browser requests MUST go through the configured platform API proxy with `VITE_PLATFORM_API_BASE_URL=/api/v1` and MUST NOT require direct run URLs, run credentials, or plugin-owned transports in browser code or visible output
|
||||
|
||||
### Requirement: Acceptance suite verifies first-party console areas
|
||||
The browser acceptance suite SHALL verify the required first-party platform_web areas with an API-backed user session.
|
||||
|
||||
#### Scenario: Suite logs in with local debug user
|
||||
- **WHEN** the acceptance suite opens platform_web
|
||||
- **THEN** it MUST log in with the documented local debug operator account and confirm the session lands on an API-backed workspace rather than local fallback data
|
||||
|
||||
#### Scenario: Suite verifies required routes
|
||||
- **WHEN** browser acceptance route checks run
|
||||
- **THEN** they MUST open 首页、服务器管理、插件市场、用户管理、AI 提供商管理 and assert stable API-backed content for each route
|
||||
|
||||
#### Scenario: Suite rejects fallback content
|
||||
- **WHEN** any required route renders fallback, mock, demo-only, or local-auth fallback content
|
||||
- **THEN** the acceptance suite MUST fail and report the route, visible evidence, and failed assertion
|
||||
|
||||
### Requirement: Acceptance suite verifies plugin and server operation surfaces
|
||||
The browser acceptance suite SHALL verify core plugin/server operation surfaces that prove the console is connected to platform-mediated lifecycle and plugin data.
|
||||
|
||||
#### Scenario: Suite verifies server detail lifecycle surface
|
||||
- **WHEN** the suite opens the local debug server detail route
|
||||
- **THEN** it MUST assert that `Local Debug Example Server`, `server-local-debug`, `game.example`, `run-local-debug`, lifecycle controls, operation history, log entry points, and artifact or artifact-reference entry points are visible or otherwise represented through platform-owned UI state
|
||||
|
||||
#### Scenario: Suite verifies plugin marketplace data
|
||||
- **WHEN** the suite opens the plugin marketplace route or plugin detail surface
|
||||
- **THEN** it MUST assert that `game.example`, manifest reference metadata, installed state, platform-mediated permissions, bridge actions, and lifecycle capabilities are visible without exposing unsafe runtime transport details
|
||||
|
||||
#### Scenario: Suite verifies operation proof without direct run access
|
||||
- **WHEN** the suite triggers or inspects a lifecycle operation
|
||||
- **THEN** it MUST verify platform-owned job or operation-history evidence and MUST NOT rely on platform_web or plugin pages contacting run directly
|
||||
|
||||
### Requirement: Acceptance suite scans visible safety boundaries
|
||||
The browser acceptance suite SHALL scan accepted browser-visible content for fallback indicators and forbidden sensitive fragments.
|
||||
|
||||
#### Scenario: Suite scans each accepted route
|
||||
- **WHEN** a required route or plugin/server operation surface is accepted
|
||||
- **THEN** the suite MUST scan visible text for `/Users/`, `/private/`, `unix://`, `tcp://`, `Bearer `, `sk-`, `password=`, `apiKeyRef`, `rawApiKey`, run session tokens, direct run URLs, and plugin-owned transport details
|
||||
|
||||
#### Scenario: Suite fails on forbidden visible fragments
|
||||
- **WHEN** any forbidden sensitive fragment is visible on an accepted route
|
||||
- **THEN** the suite MUST fail and report the route, matched fragment class, and enough nearby evidence to debug the leak without printing raw credentials
|
||||
|
||||
### Requirement: Acceptance suite produces reproducible evidence
|
||||
The browser acceptance suite SHALL provide concrete commands and evidence outputs that can be used to close OpenSpec tasks.
|
||||
|
||||
#### Scenario: Suite command is documented
|
||||
- **WHEN** contributors read the change documentation or tasks
|
||||
- **THEN** they MUST find concrete commands for running local debug smoke, browser acceptance, frontend checks, structure checks, and strict OpenSpec validation
|
||||
|
||||
#### Scenario: Suite writes acceptance evidence
|
||||
- **WHEN** browser acceptance passes
|
||||
- **THEN** it MUST write or print evidence including stack URLs, seed evidence directory, routes checked, required assertions, fallback scan results, forbidden-fragment scan results, and plugin/server operation proof
|
||||
|
||||
#### Scenario: Suite cleans up self-started services
|
||||
- **WHEN** the suite starts local debug services itself
|
||||
- **THEN** it MUST stop or reset only the documented local debug root after completion or failure, using the same safe reset scope as the local debug workspace
|
||||
Reference in New Issue
Block a user