first commit

openspec/changes/verify-current-platform-e2e-baseline/specs/current-platform-e2e-baseline/spec.md

@@ -0,0 +1,64 @@
+## 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