57 lines
4.6 KiB
Markdown
57 lines
4.6 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Platform-mediated plugin lifecycle authority
|
|
The system SHALL route local game plugin lifecycle requests through platform-owned authorization, server instance records, and run job dispatch. Browser code and plugin code MUST NOT connect directly to run endpoints, raw sockets, raw host paths, or raw credentials.
|
|
|
|
#### Scenario: Plugin requests server creation through platform
|
|
- **WHEN** an authorized user invokes a declared plugin lifecycle action to create a server instance
|
|
- **THEN** the platform MUST validate the installed plugin, declared capability, user authorization, and request payload before creating the server instance and dispatching any run job
|
|
|
|
#### Scenario: Direct run access is rejected
|
|
- **WHEN** a plugin manifest, plugin page, SDK request, or browser-visible payload attempts to use a direct run URL, raw socket, host path, bearer credential, password, or undeclared transport detail
|
|
- **THEN** validation MUST reject the request or redact the unsafe field before it reaches platform_web or plugin code
|
|
|
|
### Requirement: One plugin manages multiple server instances
|
|
The system SHALL allow one installed local game management plugin to create and manage at least two independent server instances through platform-mediated lifecycle capabilities.
|
|
|
|
#### Scenario: Create two instances from one plugin
|
|
- **WHEN** an authorized user creates two server instances using the same installed local game management plugin
|
|
- **THEN** the platform MUST persist two distinct server instance records with independent IDs, names, lifecycle state, plugin association, and operation history
|
|
|
|
#### Scenario: Start and stop one instance independently
|
|
- **WHEN** the user starts one plugin-created server instance and leaves the second instance stopped
|
|
- **THEN** the run job result and platform state projection MUST show only the targeted instance as running while the other instance remains stopped
|
|
|
|
#### Scenario: Stop does not affect sibling instance
|
|
- **WHEN** the user stops one running plugin-created server instance while another sibling instance remains running
|
|
- **THEN** the platform MUST preserve the sibling instance state and MUST record the stop operation only against the targeted instance
|
|
|
|
### Requirement: Run lifecycle jobs provide observable proof
|
|
The run executor SHALL process plugin-mediated lifecycle jobs through the existing job channel and return acknowledgement, progress or result, and instance-specific state evidence to platform.
|
|
|
|
#### Scenario: Lifecycle job acknowledgement and result
|
|
- **WHEN** platform dispatches a plugin-mediated install, start, or stop lifecycle job to run
|
|
- **THEN** run MUST acknowledge the job and return a bounded result that platform can attach to the correct server instance operation history
|
|
|
|
#### Scenario: Instance-specific logs or artifacts
|
|
- **WHEN** a lifecycle operation produces logs or artifacts for a server instance
|
|
- **THEN** platform MUST expose only logical log/artifact references associated with that instance and MUST NOT expose raw run filesystem paths or transport credentials
|
|
|
|
### Requirement: Browser walkthrough proves real API-backed lifecycle behavior
|
|
The implementation SHALL include a browser walkthrough that proves the plugin lifecycle flow uses a real API-backed session and not local fallback or seed-only demo state.
|
|
|
|
#### Scenario: Browser creates and controls plugin instances
|
|
- **WHEN** the walkthrough logs in with an API-backed authorized user, opens the plugin/server management surface, creates two instances, starts one, stops it, and inspects operation history
|
|
- **THEN** the visible UI MUST show API-backed lifecycle state for each instance, distinct operation evidence, and no local fallback session indicator
|
|
|
|
#### Scenario: Browser unsafe-field inspection
|
|
- **WHEN** the walkthrough inspects plugin marketplace, server list, server detail, operation history, log, artifact, and plugin bridge visible states
|
|
- **THEN** the visible UI MUST NOT contain raw host paths, raw run credentials, direct run sockets, bearer tokens, raw AI keys, or plugin-owned transport details
|
|
|
|
### Requirement: Verification commands cover all roots
|
|
The change SHALL provide concrete verification commands for platform, run, platform_web, and plugins, plus strict OpenSpec validation and structure checks.
|
|
|
|
#### Scenario: Verification suite passes before completion
|
|
- **WHEN** implementation tasks are marked complete
|
|
- **THEN** the recorded evidence MUST include passing platform tests, run tests, plugin typecheck/tests/manifest validation, platform_web typecheck/tests/build, `scripts/check-structure.sh`, `openspec validate implement-real-game-plugin-lifecycle-proof --strict`, and the browser walkthrough commands/results
|