## 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