first commit
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-07-08
|
||||
@@ -0,0 +1,80 @@
|
||||
## Context
|
||||
|
||||
The current architecture stream has package-level evidence for platform APIs, run channels, plugin manifests, SDK bridge envelopes, and the management frontend. The latest baseline still found a critical product gap: it could not prove that one local game management plugin can create and manage multiple real server instances through the intended platform-mediated path.
|
||||
|
||||
This proof spans all four product roots. `plugins/` must declare and request lifecycle capabilities without owning transport. `platform/` must authorize plugin lifecycle requests, create server records, dispatch bounded jobs, persist state, and expose safe API responses. `run/` must execute or simulate local lifecycle jobs through its channelized executor contract and return observable results. `platform_web/` must let an authorized user install/use the plugin and inspect separate server instances without showing raw host paths, credentials, sockets, or run transport details.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
|
||||
- Prove one installed local game management plugin can create at least two independent server instances.
|
||||
- Prove install/create/start/stop/status/log/artifact lifecycle operations are routed through platform APIs and run jobs, not direct browser/plugin access to run.
|
||||
- Prove each instance has independent identity, lifecycle state, operation history, logs/artifacts where applicable, and browser-visible controls.
|
||||
- Prove plugin manifest permissions and SDK bridge envelopes reject direct run URLs, host paths, raw credentials, raw AI keys, and undeclared lifecycle actions.
|
||||
- Provide repeatable API, run, plugin, frontend, and browser verification commands.
|
||||
|
||||
**Non-Goals:**
|
||||
|
||||
- No billing, cloud host sales, agent-provider/cloud-provider workflows, or unrelated marketplace behavior.
|
||||
- No production-grade game server hosting, cloud provisioning, external orchestrator, or remote game binary distribution.
|
||||
- No direct browser-to-run or plugin-to-run transport.
|
||||
- No new raw host path, raw socket, raw credential, or raw AI-key exposure.
|
||||
- No broad redesign of the magical crystal-moonlight frontend style.
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision 1: Use one first-party local proof plugin
|
||||
|
||||
The implementation will use the existing local example/dev game plugin as the proof target or evolve it into a clearly named local lifecycle proof plugin. The plugin declares lifecycle actions and platform-mediated capabilities in its manifest, and its SDK calls produce bounded platform bridge requests.
|
||||
|
||||
Alternative considered: introduce several plugins for different games. Rejected because the stream needs one focused proof that the lifecycle path is real before multiplying game-specific scope.
|
||||
|
||||
### Decision 2: Platform owns lifecycle authority and instance records
|
||||
|
||||
The platform remains the authority for plugin installation state, server instance records, lifecycle authorization, job creation, audit events, and safe response DTOs. Plugin requests name logical server/plugin/action identifiers; platform translates them into jobs for run and stores resulting state.
|
||||
|
||||
Alternative considered: allow plugin pages to call run endpoints directly for local development. Rejected because it violates the required channel boundaries and would make browser proof unsafe.
|
||||
|
||||
### Decision 3: Multi-instance proof requires independent state and evidence
|
||||
|
||||
The proof is not accepted unless the same installed plugin creates at least two server instances and can start/stop them independently. Evidence must include distinct IDs/names, operation history per instance, lifecycle state projection, and browser-visible separation.
|
||||
|
||||
Alternative considered: create one server and assume the code generalizes. Rejected because the baseline gap is specifically multi-instance real operation.
|
||||
|
||||
### Decision 4: Run proof can use bounded local lifecycle execution
|
||||
|
||||
The run-side executor may use a deterministic local fixture command or safe simulated local game process when no real game binary is available, but it must still travel through the run job channel and return job ack/result/state evidence. Any fixture must be explicit and must not expose raw host paths to plugins or platform_web.
|
||||
|
||||
Alternative considered: require a full real game server binary immediately. Rejected because the architecture proof is about platform-mediated lifecycle wiring and instance isolation, not a specific commercial game runtime.
|
||||
|
||||
### Decision 5: Browser acceptance must be API-backed
|
||||
|
||||
The browser walkthrough must use a real platform session and local stack. Local auth fallback, static seed-only data, and demo-only plugin controls cannot satisfy this proof. The walkthrough must record the stack commands, pages visited, actions taken, visible state, and unsafe-field checks.
|
||||
|
||||
Alternative considered: accept unit and integration tests only. Rejected because this stream requires browser evidence for frontend-facing behavior.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- [Risk] Local stack setup may remain brittle. Mitigation: tasks require exact commands, health checks, and explicit blocker recording if a service cannot bind or authenticate.
|
||||
- [Risk] A simulated local lifecycle fixture could be mistaken for production hosting. Mitigation: name it as a local proof fixture and require platform/run channel evidence rather than game-specific claims.
|
||||
- [Risk] Plugin bridge expansion could accidentally expose transport details. Mitigation: add negative tests for direct run URLs, host paths, raw credentials, sockets, and raw AI keys.
|
||||
- [Risk] Multi-instance state can collapse into shared mutable demo data. Mitigation: require two instances with independent IDs, operation histories, and state transitions.
|
||||
- [Risk] Browser proof can pass against fallback data. Mitigation: require API-backed login, platform responses, and no `本地会话`/demo fallback classification for accepted proof.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Extend the local proof plugin manifest and SDK/page code to declare lifecycle actions and platform-mediated capability envelopes.
|
||||
2. Add platform service/API support or repair existing endpoints for plugin-mediated multi-instance create/install/start/stop/status operations.
|
||||
3. Add run-side lifecycle handling needed to acknowledge jobs, execute bounded local fixture operations, and return instance-specific results.
|
||||
4. Update platform_web server/plugin flows to expose the proof actions and state without changing the visual system.
|
||||
5. Add automated tests across plugin, platform, run, and platform_web.
|
||||
6. Run the full local stack and browser walkthrough, recording exact evidence before marking tasks complete.
|
||||
|
||||
Rollback before acceptance is to remove the proof plugin lifecycle declarations, platform/run/frontend implementation changes, and any verification fixtures added by this change.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Whether the local lifecycle fixture should be a no-op process, a tiny managed process, or an existing example game command.
|
||||
- Whether the browser walkthrough should use docker-compose or separate local commands as the primary evidence path.
|
||||
- Whether the proof report should be a standalone artifact under this change or embedded only in `tasks.md` evidence.
|
||||
@@ -0,0 +1,29 @@
|
||||
## Why
|
||||
|
||||
The baseline proof showed substantial package-level platform/run/plugin evidence, but it did not prove that a real local game management plugin can create and manage multiple server instances end to end. This change turns that gap into one focused implementation proof before the stream adds more surface area.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Add a local game plugin lifecycle proof that creates and manages multiple server instances through platform-mediated contracts only.
|
||||
- Implement the missing platform/run/plugin/frontend wiring needed for one installed local plugin to request create/install/start/stop/status/log/artifact operations without direct run access.
|
||||
- Verify multiple server instances can be created from one game management plugin and tracked independently through platform storage, run jobs, operation status, and browser-visible state.
|
||||
- Add API, run, plugin SDK/manifest, and platform_web tests for lifecycle permissions, bridge envelopes, multi-instance isolation, and safe field redaction.
|
||||
- Require a browser walkthrough proving the lifecycle flow is real, API-backed, and free of raw host paths, raw credentials, direct sockets, raw AI keys, or plugin-owned run transport details.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `real-game-plugin-lifecycle-proof`: Proves a local game management plugin can create and manage multiple server instances only through platform-mediated platform/run capabilities.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- None.
|
||||
|
||||
## Impact
|
||||
|
||||
- Affects `plugins/` manifests, SDK/example plugin behavior, and manifest validation tests for lifecycle capability declarations.
|
||||
- Affects `platform/` plugin lifecycle APIs, server instance orchestration, job dispatch, audit/event evidence, and safe response DTOs.
|
||||
- Affects `run/` lifecycle execution handling, job acknowledgement/result projection, and instance-specific isolation evidence.
|
||||
- Affects `platform_web/` server management and plugin marketplace/detail surfaces needed to trigger and inspect the proof in a browser.
|
||||
- Does not add billing, cloud host sales, agent-provider/cloud-provider workflows, unrelated marketplace behavior, direct browser/plugin access to run, raw host path exposure, raw run credentials, direct sockets, or raw AI keys.
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
## 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
|
||||
@@ -0,0 +1,92 @@
|
||||
## 1. Plugin Lifecycle Contract
|
||||
|
||||
- [x] 1.1 Extend the local proof plugin manifest to declare platform-mediated lifecycle actions for create/install/start/stop/status/log/artifact operations.
|
||||
- [x] 1.2 Add plugin manifest validation tests that accept declared lifecycle capabilities and reject direct run URLs, raw sockets, host paths, bearer credentials, passwords, raw AI keys, and undeclared transport details.
|
||||
- [x] 1.3 Extend plugin SDK/example bridge envelopes so lifecycle requests carry only logical plugin, server, action, config, log, artifact, and AI capability references.
|
||||
- [x] 1.4 Run `cd plugins && npm run typecheck && npm run test && npm run validate:manifest` and record evidence.
|
||||
|
||||
## 2. Platform-Mediated Lifecycle API
|
||||
|
||||
- [x] 2.1 Add or repair platform DTOs, validators, domain types, repository/service methods, and API handlers for plugin-mediated multi-instance create/install/start/stop/status operations.
|
||||
- [x] 2.2 Ensure platform owns authorization, server instance persistence, plugin installation checks, lifecycle job creation, state projection, audit events, and safe response DTOs.
|
||||
- [x] 2.3 Add platform tests proving one installed plugin can create at least two server instances with distinct IDs, names, lifecycle states, plugin associations, and operation histories.
|
||||
- [x] 2.4 Add negative platform tests proving browser/plugin payloads cannot expose or submit raw host paths, direct run sockets, bearer tokens, passwords, raw AI keys, or undeclared lifecycle actions.
|
||||
- [x] 2.5 Run `cd platform && go test ./... -count=1` and record evidence.
|
||||
|
||||
## 3. Run Lifecycle Execution Proof
|
||||
|
||||
- [x] 3.1 Add or repair run-side lifecycle handling for plugin-mediated install/start/stop jobs using scoped logical templates under `RUN_WORKSPACE_ROOT`.
|
||||
- [x] 3.2 Ensure run acknowledges lifecycle jobs, reports bounded progress/result metadata, preserves per-instance isolation, and rejects unsafe command templates, absolute paths, parent traversal, shell launchers, credentials, and direct sockets.
|
||||
- [x] 3.3 Add run tests proving start/stop on one instance does not mutate sibling instance state or block job result submission.
|
||||
- [x] 3.4 Run `cd run && go test ./... -count=1` and record evidence.
|
||||
|
||||
## 4. Platform Web Proof Surface
|
||||
|
||||
- [x] 4.1 Update platform_web API types/client methods, schemas, route/page contracts, and components needed to trigger plugin-mediated lifecycle actions from server management or plugin detail surfaces.
|
||||
- [x] 4.2 Preserve the magical-girl crystal-moonlight console style and avoid generic opaque SaaS restyling while adding lifecycle controls and operation status.
|
||||
- [x] 4.3 Add frontend tests for API-backed plugin lifecycle controls, two-instance separation, operation history rendering, role access, and unsafe-field redaction.
|
||||
- [x] 4.4 Run `cd platform_web && npm run typecheck && npm test && npm run build` and record evidence.
|
||||
|
||||
## 5. Local Full-Stack Proof
|
||||
|
||||
- [x] 5.1 Start a local API-backed proof stack and record exact commands, including platform, run worker, and frontend commands such as `PLATFORM_ADDR=127.0.0.1:18080 PLATFORM_STORAGE_BACKEND=file PLATFORM_DATA_DIR=/private/tmp/browser-platform-lifecycle-proof PLATFORM_METADATA_PATH=/private/tmp/browser-platform-lifecycle-proof/metadata.json PLATFORM_LOG_BODY_BACKEND=file PLATFORM_LOG_DIR=/private/tmp/browser-platform-lifecycle-proof/logs go run ./cmd/platform`, `RUN_MODE=worker RUN_PLATFORM_URL=http://127.0.0.1:18080 RUN_WORKSPACE_ROOT=/private/tmp/browser-run-lifecycle-proof/workspaces RUN_SPOOL_ROOT=/private/tmp/browser-run-lifecycle-proof/spool go run ./cmd/run`, and `cd platform_web && PLATFORM_API_PROXY=http://127.0.0.1:18080 VITE_PLATFORM_API_BASE_URL=/api/v1 npm run dev -- --port 5173`.
|
||||
- [x] 5.2 Verify platform health, run registration/heartbeat, plugin installation data, and API-backed login before browser walkthrough; record exact curl or test commands used.
|
||||
- [x] 5.3 In a browser with a real API-backed platform administrator session, open 首页、服务器管理、插件市场、用户管理、AI 提供商管理 and confirm the session is not local fallback.
|
||||
- [x] 5.4 In the browser, use one installed local game management plugin to create two server instances, start one, verify the sibling remains stopped, stop the targeted instance, and inspect per-instance operation history.
|
||||
- [x] 5.5 In the browser, inspect plugin marketplace/detail, server list/detail, operation history, log/artifact references, and plugin bridge output to verify no raw host paths, run credentials, direct sockets, bearer tokens, raw AI keys, or plugin-owned transport details are visible.
|
||||
|
||||
## 6. Final Verification and Stream Handoff
|
||||
|
||||
- [x] 6.1 Record implementation evidence in this tasks file only after each command or walkthrough has actually run.
|
||||
- [x] 6.2 Run `scripts/check-structure.sh` and record evidence.
|
||||
- [x] 6.3 Run `openspec validate implement-real-game-plugin-lifecycle-proof --strict` and record evidence.
|
||||
- [x] 6.4 Update `openspec/changes/architecture-delivery-stream/delivery-plan.md` to mark `fix-env-profile-settings` complete, mark `implement-real-game-plugin-lifecycle-proof` complete only after evidence exists, and leave the next queue item pending.
|
||||
- [x] 6.5 Update `openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md` with the next implementation/generator handoff after this change closes.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Plugin contract:
|
||||
- `cd plugins && npm run typecheck` passed.
|
||||
- `cd plugins && npm run test` passed: `tests/manifest-validation.test.ts` passed 11 tests.
|
||||
- `cd plugins && npm run validate:manifest` passed after escalation for `tsx` IPC pipe creation: `validated examples/dev-game-plugin/manifest.json`.
|
||||
- `plugins/examples/dev-game-plugin/manifest.json` declares install/start/stop/restart/status lifecycle actions, `jobs.dispatch`, log/file/artifact/AI bridge actions, and platform-mediated permissions.
|
||||
- `plugins/sdk/index.ts` includes `PluginLifecycleDispatchPayload` and `createLifecycleDispatchRequest(...)` for `jobs.dispatch` lifecycle envelopes containing only logical plugin/server/action/capability/config/idempotency references.
|
||||
- `plugins/tests/manifest-validation.test.ts` asserts lifecycle dispatch envelopes do not contain direct `http://`, `unix://`, `/Users/`, `Bearer `, or `sk-` content.
|
||||
|
||||
- Platform lifecycle API:
|
||||
- `cd platform && GOCACHE=/private/tmp/browser-go-build-cache go test ./api -run TestPluginBridgeExecuteAPI -count=1` passed.
|
||||
- `cd platform && GOCACHE=/private/tmp/browser-go-build-cache go test ./... -count=1` passed for `api`, `config`, `domain`, `dto`, `model`, `repo`, `service`, and `validator`.
|
||||
- `platform/service/server_lifecycle_test.go` includes `TestCoreServicePluginLifecycleManagesMultipleInstancesIndependently`, creating `server-alpha` and `server-beta` from one plugin, starting/stopping only alpha, and verifying beta remains unchanged.
|
||||
- `platform/api/resource_handlers_test.go` includes `jobs.dispatch` lifecycle bridge execution coverage, action/capability mismatch denial, unsafe payload rejection, and forbidden-fragment response checks.
|
||||
|
||||
- Run lifecycle execution:
|
||||
- Initial sandbox run of `cd run && GOCACHE=/private/tmp/browser-go-build-cache go test ./... -count=1` was blocked by `httptest` loopback bind permissions.
|
||||
- Escalated rerun of `cd run && GOCACHE=/private/tmp/browser-go-build-cache go test ./... -count=1` passed for `api`, `config`, `protocol`, `runtime`, and `spool`.
|
||||
- `run/runtime/lifecycle_test.go` includes scoped template execution, unsafe template rejection, workspace escape rejection, cancellation, and sibling workspace isolation.
|
||||
|
||||
- Platform web proof surface:
|
||||
- `cd platform_web && npm run typecheck` passed.
|
||||
- `cd platform_web && npm test` passed: 11 files, 49 tests.
|
||||
- `cd platform_web && npm run build` passed: Vite built `dist/index.html`, CSS, and JS assets.
|
||||
- `platform_web/pages/ServerDetailPage.test.tsx` verifies plugin lifecycle controls call `startServerInstance` / `stopServerInstance`, skip install/restart/status controls, avoid generic `process.start` / `process.stop` job creation, and keep bridge/lifecycle output on platform-owned references.
|
||||
|
||||
- Controlled local full-stack proof:
|
||||
- Used controlled stack after an existing `127.0.0.1:18080` process became unreachable despite still holding the port.
|
||||
- Platform command run from `platform/`: `PLATFORM_ADDR=127.0.0.1:18082 PLATFORM_STORAGE_BACKEND=file PLATFORM_DATA_DIR=/private/tmp/browser-platform-lifecycle-proof-controlled PLATFORM_METADATA_PATH=/private/tmp/browser-platform-lifecycle-proof-controlled/metadata.json PLATFORM_LOG_BODY_BACKEND=file PLATFORM_LOG_DIR=/private/tmp/browser-platform-lifecycle-proof-controlled/logs GOCACHE=/private/tmp/browser-go-build-cache go run ./cmd/platform`.
|
||||
- Run worker command run from `run/`: `RUN_MODE=worker RUN_PLATFORM_URL=http://127.0.0.1:18082 RUN_WORKSPACE_ROOT=/private/tmp/browser-run-lifecycle-proof/workspaces RUN_SPOOL_ROOT=/private/tmp/browser-run-lifecycle-proof/spool RUN_POLL_INTERVAL_MS=250 RUN_HEARTBEAT_INTERVAL_MS=1000 RUN_MAX_JOBS=4 GOCACHE=/private/tmp/browser-go-build-cache go run ./cmd/run`.
|
||||
- Frontend command run from `platform_web/`: `PLATFORM_API_PROXY=http://127.0.0.1:18082 VITE_PLATFORM_API_BASE_URL=/api/v1 npm run dev -- --port 5175`.
|
||||
- Health/login/run checks passed with `curl` against `127.0.0.1:18082`: `/healthz` returned `{"service":"platform","status":"ok","version":"0.1.0-dev"}`, `/api/v1/run/endpoints` returned online `run-local` with `process.install`, `process.start`, and `process.stop`, and `/api/v1/auth/login` authenticated `operator.local@example.test / operator-local` as `user-admin`.
|
||||
- Registered installed proof plugin `game.lifecycle-proof@0.1.1` with lifecycle actions install/start/stop/restart/status, bridge actions server.instances.read/jobs.dispatch/logs.query/artifacts.open/files.request/ai.invoke, declared permissions for lifecycle/files/logs/artifacts/AI, and run-required capabilities narrowed to worker-real `process.install`, `process.start`, `process.stop`.
|
||||
- Created two server instances through platform workflow: `proof-alpha` and `proof-beta`; both install jobs completed via run worker and both reached `ready`.
|
||||
- Browser walkthrough on `http://127.0.0.1:5175/` logged in with the API-backed platform administrator session and opened 首页、服务器管理、插件市场、用户管理、AI 提供商管理. Each page reported `hasLocalFallback: false` and no visible forbidden fragments among `/Users/`, `/private/`, `unix://`, `tcp://`, `Bearer `, `sk-`, `password=`, `apiKeyRef`, or `rawApiKey`.
|
||||
- Browser server detail walkthrough opened `#/servers/proof-alpha`, confirmed `Proof Alpha` was ready with start enabled, clicked `启动`, confirmed the dialog, and observed a visible `process.start` queued operation.
|
||||
- API proof after UI start showed `proof-alpha` state `running`, `proof-beta` state `ready`, alpha start job `server-lifecycle:proof-alpha:start:3981de20495ff68b` succeeded with `process.start completed`, and beta had only its install job.
|
||||
- Browser detail walkthrough then refreshed `proof-alpha`, confirmed it was running with stop enabled, clicked `停止`, confirmed the dialog, and observed a visible `process.stop` queued operation.
|
||||
- API proof after UI stop showed `proof-alpha` state `stopped`, `proof-beta` still `ready`, alpha install/start/stop jobs all succeeded, and beta still had only its install job.
|
||||
- Browser walkthrough visible surfaces did not expose raw host paths, run credentials, direct sockets, bearer tokens, raw AI keys, or plugin-owned transport details.
|
||||
|
||||
- Final gates and stream handoff:
|
||||
- `scripts/check-structure.sh` passed with `structure check passed`.
|
||||
- `openspec validate implement-real-game-plugin-lifecycle-proof --strict` passed with `Change 'implement-real-game-plugin-lifecycle-proof' is valid`; the process exited 0. PostHog telemetry flush reported `ENOTFOUND edge.openspec.dev`, which did not affect validation.
|
||||
- `openspec/changes/architecture-delivery-stream/delivery-plan.md` now marks `implement-real-game-plugin-lifecycle-proof` complete and `harden-log-artifact-channel-isolation` active.
|
||||
- `openspec/changes/architecture-delivery-stream/NEXT_CHANGE.md` now points the next implementation chat at `harden-log-artifact-channel-isolation`.
|
||||
Reference in New Issue
Block a user