first commit
This commit is contained in:
+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
|
||||
Reference in New Issue
Block a user