## ADDED Requirements

### Requirement: Baseline proof report classifies current behavior
The repository SHALL provide an evidence-based baseline proof report that classifies current functionality across platform, run, platform_web, and plugins as `real`, `partial`, `demo-only`, or `blocked`.

#### Scenario: Required flow is classified
- **WHEN** the baseline verification runs for a required first-party or channel flow
- **THEN** the report MUST record the classification, evidence source, command or browser step, and follow-up recommendation when the classification is not `real`

#### Scenario: Demo fallback is visible
- **WHEN** a frontend or plugin flow renders local seed data, local fallback data, or simulated completion without platform/run evidence
- **THEN** the report MUST classify that flow as `demo-only` or `partial` instead of `real`

#### Scenario: Verification is blocked
- **WHEN** a flow cannot be verified because a local service, browser, dependency, credential, or environment condition fails
- **THEN** the report MUST classify the flow as `blocked` and include the exact command or browser action and error that prevented verification

### Requirement: First-party frontend areas are browser verified
The baseline SHALL include a browser walkthrough for 首页、服务器管理、插件市场、用户管理、AI 提供商管理 and the personal/account navigation needed to identify authenticated workspace behavior.

#### Scenario: Browser walkthrough covers first-party pages
- **WHEN** the browser walkthrough is executed
- **THEN** it MUST visit every required first-party area and record whether each page is backed by platform APIs, local fallback data, or inaccessible state

#### Scenario: Browser walkthrough checks operational actions
- **WHEN** the walkthrough reaches server, plugin, user, AI provider, config, log, artifact, or plugin bridge actions
- **THEN** it MUST record whether the action uses platform-mediated APIs and whether unsafe raw host paths, run credentials, direct sockets, or raw AI keys are absent from visible UI state

### Requirement: Platform API and storage baseline is verified
The baseline SHALL verify that platform API behavior for authentication/session, server instances, users, plugins, AI providers, jobs, logs, artifacts, and file/config dispatch is backed by the current service and storage implementation.

#### Scenario: Platform API command evidence exists
- **WHEN** platform baseline verification runs
- **THEN** it MUST execute platform tests or smoke commands that cover the required API areas and record pass/fail evidence in the proof report

#### Scenario: Storage behavior is classified
- **WHEN** platform data is created, updated, queried, or restarted in the baseline
- **THEN** the report MUST classify whether that data is durable, in-memory only, seed data, or blocked from verification

### Requirement: Run-mediated lifecycle and channel behavior is verified
The baseline SHALL verify current run-mediated server lifecycle, job, log ingest, artifact transfer, and file dispatch behavior without exposing run internals to browsers or plugins.

#### Scenario: Lifecycle path is proven
- **WHEN** the baseline verifies server lifecycle behavior
- **THEN** it MUST exercise or cite executable evidence for create/install, start, stop, job claim/ack/result, and server state projection through platform-mediated contracts

#### Scenario: Log history is proven
- **WHEN** the baseline verifies log ingest
- **THEN** it MUST prove whether log history is durable and queryable after batch acknowledgement or classify the missing durability as `partial`, `demo-only`, or `blocked`

#### Scenario: Artifact and file channels are proven
- **WHEN** the baseline verifies artifact transfer and file/config dispatch
- **THEN** it MUST prove bounded chunk/checksum or dispatch behavior and record whether these operations remain separate from control heartbeat, job ack/result, and log ingest

### Requirement: Plugin capability boundaries are verified
The baseline SHALL verify game management plugin manifests, SDK bridge requests, plugin page execution, AI invocation requests, and file/config/log/run capabilities stay platform-mediated.

#### Scenario: Plugin boundary proof exists
- **WHEN** plugin baseline verification runs
- **THEN** it MUST execute plugin validation/type/test commands and record evidence that plugin code does not include platform auth storage, raw AI keys, direct run sockets, raw host paths, or direct run transport

#### Scenario: Plugin flow cannot operate real server behavior
- **WHEN** a plugin can render or request a capability but cannot complete a real platform/run-backed operation
- **THEN** the report MUST classify that plugin flow as `partial` or `demo-only` and recommend the follow-up OpenSpec needed to make it real