first commit
This commit is contained in:
npc0-hue
@@ -0,0 +1,67 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Local debug workspace starts the real stack
|
||||
The repository SHALL provide a local debug workflow that starts platform, run worker, platform_web, and one local game management plugin path using explicit local configuration.
|
||||
|
||||
#### Scenario: Developer starts local debug services
|
||||
- **WHEN** a developer follows the local debug workflow
|
||||
- **THEN** the workflow MUST provide concrete commands or scripts for platform, run worker, and platform_web with explicit local ports, data directories, log directories, run workspace root, run spool root, frontend API proxy, and Vite API base URL
|
||||
|
||||
#### Scenario: Local debug uses API-backed frontend
|
||||
- **WHEN** platform_web is started by the local debug workflow
|
||||
- **THEN** it MUST use platform-owned API routes through the configured proxy and MUST NOT require platform_web to connect directly to run or plugin-owned transports
|
||||
|
||||
### Requirement: Local debug workspace can be reset safely
|
||||
The repository SHALL provide reset or cleanup steps that remove only local debug workspace state and leave unrelated user files, repository source files, and non-debug service data untouched.
|
||||
|
||||
#### Scenario: Developer resets local debug state
|
||||
- **WHEN** a developer runs the documented reset path
|
||||
- **THEN** platform metadata, platform log bodies, run workspace files, run spool files, local fixture state, and local service logs for the debug workspace MUST be removed or reinitialized only within the documented local debug root
|
||||
|
||||
#### Scenario: Reset scope is auditable
|
||||
- **WHEN** a contributor inspects the reset command or script
|
||||
- **THEN** the command MUST show the exact local debug paths it removes and MUST NOT remove broad directories such as the repository root, home directory, `/Users`, `/private`, `/tmp`, or unrelated service data
|
||||
|
||||
### Requirement: Local debug workflow seeds a safe game plugin lifecycle fixture
|
||||
The local debug workflow SHALL seed or document a safe local game plugin fixture that can create and manage at least one server instance through platform-mediated lifecycle APIs.
|
||||
|
||||
#### Scenario: Developer prepares lifecycle fixture
|
||||
- **WHEN** the local debug setup creates plugin/server lifecycle data
|
||||
- **THEN** it MUST register or reuse a local game plugin manifest, install the plugin through platform data, create at least one logical server instance, and use scoped run workspace lifecycle templates with harmless commands
|
||||
|
||||
#### Scenario: Fixture preserves safety boundaries
|
||||
- **WHEN** plugin lifecycle data is visible through platform APIs or platform_web
|
||||
- **THEN** responses MUST NOT expose raw host paths, raw credentials, run session tokens, direct sockets, raw AI provider keys, shell launchers, or plugin-owned transport details
|
||||
|
||||
### Requirement: Local debug workflow includes smoke verification
|
||||
The local debug workflow SHALL include concrete smoke commands that prove the stack is healthy and API-backed before browser acceptance is claimed.
|
||||
|
||||
#### Scenario: Smoke commands verify backend state
|
||||
- **WHEN** smoke verification runs
|
||||
- **THEN** it MUST check platform health, run endpoint registration or heartbeat, plugin registration/installation, server instance lifecycle state, queued or completed lifecycle jobs, and safe log/artifact references through platform APIs
|
||||
|
||||
#### Scenario: Smoke commands reject demo-only fallback
|
||||
- **WHEN** smoke verification inspects frontend or API state
|
||||
- **THEN** it MUST prove platform_web is using the configured platform API and MUST flag local/demo fallback data as a failed smoke condition
|
||||
|
||||
### Requirement: Browser walkthrough verifies first-party areas and safety
|
||||
The local debug workflow SHALL include a browser walkthrough that verifies the API-backed console across required first-party areas and one plugin lifecycle path.
|
||||
|
||||
#### Scenario: Browser walkthrough opens first-party areas
|
||||
- **WHEN** the browser walkthrough runs
|
||||
- **THEN** it MUST open 首页、服务器管理、插件市场、用户管理、AI 提供商管理 with an API-backed user session and confirm the pages are not local fallback views
|
||||
|
||||
#### Scenario: Browser walkthrough verifies plugin lifecycle path
|
||||
- **WHEN** the browser walkthrough operates a local debug server instance
|
||||
- **THEN** it MUST use platform_web to inspect plugin/server details, trigger or verify a platform-mediated lifecycle action, observe operation history or job state, and confirm sibling/log/artifact references remain safe
|
||||
|
||||
#### Scenario: Browser walkthrough scans visible sensitive fragments
|
||||
- **WHEN** the browser walkthrough inspects visible page content
|
||||
- **THEN** it MUST fail if `/Users/`, `/private/`, `unix://`, `tcp://`, `Bearer `, `sk-`, `password=`, `apiKeyRef`, `rawApiKey`, run session tokens, direct run URLs, or plugin-owned transport details are visible
|
||||
|
||||
### Requirement: Local debug workflow is documented and verified
|
||||
The change SHALL include documentation, tests or smoke checks, and final verification commands proving the local debug workflow is reproducible.
|
||||
|
||||
#### Scenario: Verification commands run
|
||||
- **WHEN** the change is complete
|
||||
- **THEN** the documented test/build/smoke commands, `scripts/check-structure.sh`, and `openspec validate implement-local-debug-workspace --strict` MUST pass, and browser walkthrough evidence MUST be recorded if platform_web pages are touched or verified
|
||||
Reference in New Issue
Block a user