first commit
This commit is contained in:
npc0-hue
+80
@@ -0,0 +1,80 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: First-party routes provide accepted interaction polish
|
||||
The platform_web console SHALL provide polished, scannable, API-backed interaction surfaces for the required first-party areas without changing product scope.
|
||||
|
||||
#### Scenario: Home route has clear operational hierarchy
|
||||
- **WHEN** an operator opens 首页
|
||||
- **THEN** the route MUST present loaded platform overview state, key resource/health signals, game/plugin counts or equivalent operational summaries, and a clear refresh or recovery affordance without visible overlap or clipped primary labels
|
||||
|
||||
#### Scenario: Server management route is action-oriented and scannable
|
||||
- **WHEN** an operator opens 服务器管理
|
||||
- **THEN** the route MUST make server identity, lifecycle state, run assignment, filtering, creation entry point, and drill-in affordance easy to scan without using a fixed left-list/right-detail master-detail layout
|
||||
|
||||
#### Scenario: Plugin marketplace route communicates trust and capability
|
||||
- **WHEN** an operator opens 插件市场
|
||||
- **THEN** the route MUST present plugin identity, installed state, manifest reference, lifecycle capabilities, platform-mediated permissions, bridge actions, and validation state in a readable structure without unsafe runtime transport details
|
||||
|
||||
#### Scenario: User management route supports account operations clearly
|
||||
- **WHEN** an operator opens 用户管理
|
||||
- **THEN** the route MUST present API-connected account data, roles/statuses, create/edit affordances, and empty/error/loading states with text labels and non-color-only status cues
|
||||
|
||||
#### Scenario: AI provider route keeps sensitive settings understandable
|
||||
- **WHEN** an operator opens AI 提供商管理
|
||||
- **THEN** the route MUST present provider identity, connection status, relay mode, model/default-model information, and redacted key references without exposing raw keys or making status dependent on color alone
|
||||
|
||||
### Requirement: Server detail workflows are polished without direct run access
|
||||
The platform_web server detail route SHALL provide polished workflow surfaces for lifecycle, logs, config, plugin controls, AI assistant, and operation history while preserving platform-mediated boundaries.
|
||||
|
||||
#### Scenario: Server detail header and tabs show stable context
|
||||
- **WHEN** an operator opens `#/servers/server-local-debug` or another server detail route
|
||||
- **THEN** the route MUST keep server name, server ID, plugin version, run node, lifecycle state, and tab navigation visible and readable across desktop and mobile widths
|
||||
|
||||
#### Scenario: Lifecycle commands have safe feedback
|
||||
- **WHEN** an operator views or triggers lifecycle controls
|
||||
- **THEN** start/stop or equivalent controls MUST have clear labels, enabled/disabled states, confirmation or progress feedback where appropriate, and operation-history visibility without browser or plugin pages contacting run directly
|
||||
|
||||
#### Scenario: Logs, config, artifacts, and operation history remain traceable
|
||||
- **WHEN** an operator uses detail tabs for logs, config, plugin controls, AI assistant, or operation history
|
||||
- **THEN** each surface MUST show meaningful loaded/empty/error states, logical IDs or safe references, readable timestamps/statuses, and no raw host paths, sockets, credentials, or plugin-owned transport details
|
||||
|
||||
### Requirement: Visual system contract is preserved during polish
|
||||
The platform_web polish SHALL preserve the existing game operations visual direction and shared theme architecture.
|
||||
|
||||
#### Scenario: Shared theme primitives drive surfaces
|
||||
- **WHEN** implementation changes route or component presentation
|
||||
- **THEN** it MUST reuse or extend shared tokens/classes in `theme/tokens.ts` and `theme/base.css` rather than introducing page-local opaque card systems, one-off dark dashboards, or unrelated visual languages
|
||||
|
||||
#### Scenario: Black mecha and magical-girl themes stay distinct
|
||||
- **WHEN** an operator uses the default black mecha theme or optional magical-girl theme
|
||||
- **THEN** both themes MUST keep their theme-specific materials, readable translucent surfaces, grouped large-entry navigation, and background visibility while sharing the same product workflows
|
||||
|
||||
#### Scenario: Global decorative effects remain centralized
|
||||
- **WHEN** implementation changes ambient or decorative effects
|
||||
- **THEN** full-workspace theme-aware effects MUST remain in `components/MagicalParticleLayer.tsx` and MUST NOT use page-local fixed decorative DOM/CSS elements
|
||||
|
||||
### Requirement: Responsive browser walkthrough proves polish acceptance
|
||||
The polish change SHALL require browser verification across required routes and representative viewport sizes before completion.
|
||||
|
||||
#### Scenario: Desktop and mobile walkthroughs cover required routes
|
||||
- **WHEN** implementation claims the polished UI is accepted
|
||||
- **THEN** browser walkthrough evidence MUST cover 首页、服务器管理、插件市场、用户管理、AI 提供商管理, server detail workflows, and representative desktop and mobile viewport widths
|
||||
|
||||
#### Scenario: Walkthrough rejects layout regressions
|
||||
- **WHEN** browser walkthroughs inspect accepted routes
|
||||
- **THEN** they MUST reject visible overlap, clipped primary text, unreachable primary controls, unreadable loaded/error/empty states, and navigation states that hide required first-party areas
|
||||
|
||||
#### Scenario: Automated acceptance remains compatible
|
||||
- **WHEN** polish implementation is complete
|
||||
- **THEN** `scripts/browser-acceptance.sh` with the documented local debug environment MUST still pass and MUST continue proving API-backed content, fallback rejection, forbidden-fragment scanning, and platform-mediated plugin/server operation proof
|
||||
|
||||
### Requirement: Polish verification commands are concrete
|
||||
The OpenSpec tasks SHALL list reproducible commands that prove implementation quality.
|
||||
|
||||
#### Scenario: Verification commands are available
|
||||
- **WHEN** contributors read implementation tasks
|
||||
- **THEN** they MUST find concrete commands for platform_web typecheck/tests/build, automated browser acceptance, structure checks, and strict OpenSpec validation
|
||||
|
||||
#### Scenario: Evidence is recorded before task completion
|
||||
- **WHEN** implementation tasks are marked complete
|
||||
- **THEN** task evidence MUST record the browser walkthrough coverage, automated acceptance command output or evidence path, platform_web verification, `scripts/check-structure.sh`, and `openspec validate polish-platform-interaction-design --strict`
|
||||
Reference in New Issue
Block a user