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

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