first commit
This commit is contained in:
npc0-hue
+44
@@ -0,0 +1,44 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Game management plugin manifest defines server creation
|
||||
A game management plugin SHALL provide a manifest that declares plugin identity, supported server type, create form schema, server lifecycle actions, required run capabilities, optional plugin pages, and AI/file/log permissions.
|
||||
|
||||
#### Scenario: Valid plugin installed
|
||||
- **WHEN** a plugin manifest declares a valid server type and required capabilities
|
||||
- **THEN** the platform MUST expose it in the plugin marketplace and allow creating server instances from it
|
||||
|
||||
#### Scenario: Plugin manifest requests unsafe access
|
||||
- **WHEN** a plugin manifest requests direct run credentials, raw host paths, or raw AI provider keys
|
||||
- **THEN** the platform MUST reject or disable that contribution
|
||||
|
||||
### Requirement: Plugins use platform bridge only
|
||||
Plugin page and plugin actions SHALL access platform abilities through a typed bridge or platform API and MUST NOT connect directly to run, log storage, artifact storage internals, or AI provider endpoints.
|
||||
|
||||
#### Scenario: Plugin reads logs
|
||||
- **WHEN** a plugin needs logs for a server instance
|
||||
- **THEN** it MUST query platform log APIs by server instance, stream, time range, cursor, or analysis window
|
||||
|
||||
#### Scenario: Plugin invokes AI
|
||||
- **WHEN** a plugin invokes AI for config or log assistance
|
||||
- **THEN** it MUST send a scoped platform AI request and receive a bounded response that excludes provider secrets
|
||||
|
||||
### Requirement: Local plugin development is first-class
|
||||
The project SHALL support local game management plugin development where a plugin can be registered as a dev plugin, provide UI from a dev server or static directory, and exercise real platform-run job, file, log, and AI flows against a selected test server instance.
|
||||
|
||||
#### Scenario: Developer runs local plugin
|
||||
- **WHEN** a developer starts a local plugin in dev mode
|
||||
- **THEN** platform_web MUST show the plugin as a dev game management plugin without requiring a marketplace publish
|
||||
|
||||
### Requirement: Plugin definitions are organized
|
||||
The `plugins/` workspace SHALL keep manifests, schemas, UI contracts, action definitions, test fixtures, and shared plugin SDK code in predictable directories.
|
||||
|
||||
#### Scenario: Plugin adds action input schema
|
||||
- **WHEN** a plugin adds or changes an action input
|
||||
- **THEN** the schema MUST live in a dedicated schema/contract location and tests MUST cover validation behavior
|
||||
|
||||
### Requirement: Plugin can create many server instances
|
||||
A game management plugin installation SHALL be reusable for multiple server instances with isolated configuration, artifacts, jobs, logs, and permissions per server instance.
|
||||
|
||||
#### Scenario: Two servers from one plugin
|
||||
- **WHEN** a user creates two server instances from the same plugin
|
||||
- **THEN** each instance MUST have separate configuration state, run binding, log streams, and artifact references
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Platform navigation scope
|
||||
The platform SHALL define the primary product surface as 首页、服务器管理、插件市场、用户管理、AI 提供商管理.
|
||||
|
||||
#### Scenario: Navigation is generated
|
||||
- **WHEN** platform_web renders authenticated navigation
|
||||
- **THEN** it MUST expose 首页、服务器管理、插件市场、用户管理、AI 提供商管理 as the primary areas
|
||||
|
||||
### Requirement: Game management plugins create server instances
|
||||
The platform SHALL model game management plugins as definitions for creating and managing game server types, and each installed game management plugin MUST be able to create multiple server instances.
|
||||
|
||||
#### Scenario: Create server from plugin
|
||||
- **WHEN** a user creates a server from an installed game management plugin
|
||||
- **THEN** the platform MUST create a server instance linked to that plugin and a selected run endpoint
|
||||
|
||||
#### Scenario: Multiple instances per plugin
|
||||
- **WHEN** a game management plugin is installed once
|
||||
- **THEN** users MUST be able to create more than one server instance from that plugin without reinstalling the plugin
|
||||
|
||||
### Requirement: AI providers are platform-managed
|
||||
The platform SHALL manage AI provider configuration for OpenAI-compatible, GPT, Claude, local, or relay endpoints, including base URL, key reference, model settings, timeout, and routing metadata.
|
||||
|
||||
#### Scenario: Plugin requests AI assistance
|
||||
- **WHEN** a plugin needs AI assistance for config reading, config generation, or log diagnosis
|
||||
- **THEN** it MUST call a platform AI capability and MUST NOT receive raw provider API keys
|
||||
|
||||
#### Scenario: AI suggests a config change
|
||||
- **WHEN** AI generates a server configuration change
|
||||
- **THEN** the platform MUST present a bounded diff or recommendation before any run-side file write job is dispatched
|
||||
|
||||
### Requirement: Platform data definitions are centralized
|
||||
The platform backend SHALL keep database models, DTOs, domain types, API route declarations, repository contracts, service interfaces, validators, and shared helpers in fixed directories.
|
||||
|
||||
#### Scenario: New API added
|
||||
- **WHEN** platform code adds a new HTTP/API endpoint
|
||||
- **THEN** its request and response DTOs MUST be defined in the platform contract/DTO area and route declarations MUST be discoverable in the API area
|
||||
|
||||
#### Scenario: New database table added
|
||||
- **WHEN** platform code adds a new database table
|
||||
- **THEN** its model MUST be defined in the database model area with field comments and tags before migrations or repositories reference it
|
||||
|
||||
### Requirement: Platform does not expose run internals to plugins
|
||||
The platform SHALL mediate all plugin access to files, jobs, logs, AI providers, and run endpoints.
|
||||
|
||||
#### Scenario: Plugin requests file operation
|
||||
- **WHEN** a plugin requests file access for a server instance
|
||||
- **THEN** the platform MUST authorize the request and dispatch a scoped job or artifact operation instead of exposing host paths or run credentials
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Console exposes required pages
|
||||
The platform web console SHALL provide 首页、服务器管理、插件市场、用户管理、AI 提供商管理 as first-party pages.
|
||||
|
||||
#### Scenario: Authenticated user opens console
|
||||
- **WHEN** an authenticated user opens platform_web
|
||||
- **THEN** the primary navigation MUST include 首页、服务器管理、插件市场、用户管理、AI 提供商管理
|
||||
|
||||
### Requirement: Server management uses routed or modal details
|
||||
Server management SHALL avoid fixed left-list/right-detail master-detail layouts and MUST use routed details, modal details, or drawers for server detail flows.
|
||||
|
||||
#### Scenario: User opens a server
|
||||
- **WHEN** a user selects a server from the server list
|
||||
- **THEN** platform_web MUST navigate to a detail route or open an overlay detail surface rather than permanently occupying a right-side detail pane
|
||||
|
||||
### Requirement: Plugin page is hosted through platform context
|
||||
Plugin page SHALL run inside a platform-controlled host that supplies theme tokens, server instance context, safe API access, AI invocation, log queries, artifact references, and job operations.
|
||||
|
||||
#### Scenario: Plugin page loads
|
||||
- **WHEN** a user opens an authorized plugin page for a server instance
|
||||
- **THEN** the host MUST pass only safe context and MUST not expose platform auth storage, AI keys, run credentials, or host paths
|
||||
|
||||
### Requirement: Frontend definitions are centralized
|
||||
platform_web SHALL keep API clients, route definitions, page contracts, bridge contracts, shared component types, schemas, and validation helpers in dedicated directories.
|
||||
|
||||
#### Scenario: New API call added
|
||||
- **WHEN** a frontend change adds a platform API call
|
||||
- **THEN** the call and related request/response types MUST live in the API/contract area rather than inside a view component
|
||||
|
||||
### Requirement: Logs and files are separate user flows
|
||||
The frontend SHALL treat log history/tail views and file/artifact operations as separate workflows so file operations do not imply log stream interruption.
|
||||
|
||||
#### Scenario: User uploads a file while viewing logs
|
||||
- **WHEN** a user uploads or downloads a server file from a plugin or file page
|
||||
- **THEN** active log history or tail views MUST continue to query or subscribe through the platform log APIs independently
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Four-root project layout
|
||||
The repository SHALL use `run/`, `platform/`, `platform_web/`, and `plugins/` as the only first-class implementation roots for executor, backend, frontend, and game management plugin work.
|
||||
|
||||
#### Scenario: Bootstrap layout exists
|
||||
- **WHEN** a contributor inspects the repository root
|
||||
- **THEN** the root MUST contain `run/`, `platform/`, `platform_web/`, and `plugins/`
|
||||
|
||||
#### Scenario: New implementation is placed under the correct root
|
||||
- **WHEN** a change adds executor, backend, frontend, or game management plugin implementation
|
||||
- **THEN** the files MUST be placed under the matching implementation root
|
||||
|
||||
### Requirement: Governance documentation is mandatory
|
||||
The repository and each first-class implementation root SHALL contain an `AGENTS.md` and `README.md` that describe scope, directory rules, and verification expectations.
|
||||
|
||||
#### Scenario: Root governance files exist
|
||||
- **WHEN** a contributor starts work from the repository root
|
||||
- **THEN** root `AGENTS.md` and `README.md` MUST explain cross-project rules and verification commands
|
||||
|
||||
#### Scenario: Subproject governance files exist
|
||||
- **WHEN** a contributor works inside `run/`, `platform/`, `platform_web/`, or `plugins/`
|
||||
- **THEN** that directory MUST contain local `AGENTS.md` and `README.md` with root-specific rules
|
||||
|
||||
### Requirement: Definition directories are fixed
|
||||
Backend subprojects SHALL keep DTOs, domain structs, database models, API route definitions, validation rules, protocols, and shared helpers in dedicated directories. Frontend and plugin page subprojects SHALL keep API clients, route definitions, page types, schemas, bridge types, and shared utilities in dedicated directories.
|
||||
|
||||
#### Scenario: Backend code adds a request DTO
|
||||
- **WHEN** backend code adds a request or response structure
|
||||
- **THEN** the structure MUST live in a dedicated DTO or contract directory rather than inside a handler function
|
||||
|
||||
#### Scenario: Frontend code adds a shared type
|
||||
- **WHEN** frontend code adds a shared API, route, bridge, or component type
|
||||
- **THEN** the type MUST live in a dedicated type, contract, schema, or API directory rather than inside a page component
|
||||
|
||||
### Requirement: Structure checks gate completion
|
||||
The repository SHALL provide a structure validation command that verifies mandatory roots and governance files, and future changes MUST update that validator when adding new structure rules.
|
||||
|
||||
#### Scenario: Required directory missing
|
||||
- **WHEN** `scripts/check-structure.sh` runs and a required root or governance file is missing
|
||||
- **THEN** the command MUST fail with a clear missing-path message
|
||||
|
||||
#### Scenario: Rule changes with no validator update
|
||||
- **WHEN** a change adds a new mandatory directory or governance rule
|
||||
- **THEN** the change MUST update the structure checker before the task can be marked complete
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Run control channel is lightweight
|
||||
The run executor SHALL use a lightweight control channel for hello, heartbeat, capability reporting, version reporting, and capacity reporting only.
|
||||
|
||||
#### Scenario: Run starts
|
||||
- **WHEN** run starts and reaches the platform
|
||||
- **THEN** it MUST register through hello and report capabilities before accepting jobs
|
||||
|
||||
#### Scenario: File transfer is active
|
||||
- **WHEN** run is uploading or downloading large artifacts
|
||||
- **THEN** control heartbeats MUST remain independent from artifact transfer progress
|
||||
|
||||
### Requirement: Job channel supports lifecycle semantics
|
||||
The run executor SHALL support job claim, ack, progress, result, cancel, and reconcile semantics for server lifecycle, config, database, backup, and plugin-triggered work.
|
||||
|
||||
#### Scenario: Job accepted
|
||||
- **WHEN** run accepts a job
|
||||
- **THEN** it MUST return a structured ack before execution and terminal result after execution
|
||||
|
||||
#### Scenario: Run restarts during job
|
||||
- **WHEN** run restarts or reconnects after accepting a job
|
||||
- **THEN** the platform MUST be able to request reconciliation using job identity or idempotency identity
|
||||
|
||||
### Requirement: Logs use durable ingest
|
||||
Run SHALL collect server logs into a local spool and upload compressed batches with stream identity, monotonic sequence range, checksum, and acknowledgement handling.
|
||||
|
||||
#### Scenario: Platform unavailable
|
||||
- **WHEN** platform log ingest is temporarily unavailable
|
||||
- **THEN** run MUST retain unacknowledged log batches locally and retry without losing sequence continuity
|
||||
|
||||
#### Scenario: User transfers files while logs are active
|
||||
- **WHEN** artifact transfer is consuming bandwidth
|
||||
- **THEN** log flush MUST keep priority over artifact chunks so historical logs continue to advance
|
||||
|
||||
### Requirement: Artifact transfer is isolated
|
||||
Run SHALL transfer files through an artifact channel with chunking, checksums, resume support, concurrency limits, and throttling separate from logs and control.
|
||||
|
||||
#### Scenario: Plugin writes a config file
|
||||
- **WHEN** a plugin asks the platform to write a config file
|
||||
- **THEN** run MUST receive a scoped job that references an artifact or bounded inline content and MUST write through a safe temp-and-replace flow
|
||||
|
||||
#### Scenario: Large file download active
|
||||
- **WHEN** a large file download is active
|
||||
- **THEN** job ack/result and log batch upload MUST NOT wait behind all artifact chunks
|
||||
|
||||
### Requirement: Game client bridge is optional and separate
|
||||
The system SHALL support an optional game client bridge channel for games that require in-game command execution or structured snapshots, but it MUST remain separate from run lifecycle and log ingestion channels.
|
||||
|
||||
#### Scenario: Game needs in-game command bridge
|
||||
- **WHEN** a game management plugin declares that a game needs an in-game client bridge
|
||||
- **THEN** the platform MUST route game command polling and snapshot reporting through the client bridge contract rather than the run artifact or log channels
|
||||
Reference in New Issue
Block a user