first commit

2026-07-11 14:56:10 +08:00
commit 7e05d0a4e7
660 changed files with 78119 additions and 0 deletions
@@ -0,0 +1,52 @@
+## ADDED Requirements
+
+### Requirement: Manifest Schema Validation
+The plugin workspace SHALL validate game management plugin manifests with a JSON Schema that defines identity, version, plugin kind, server type, create form schema reference, run capabilities, lifecycle actions, optional pages, AI purposes, and scoped permissions.
+
+#### Scenario: Development plugin manifest validates
+- **WHEN** the development game plugin manifest is validated by the plugin workspace validator
+- **THEN** validation MUST pass and its referenced create form schema MUST also validate
+
+#### Scenario: Unsafe manifest fails validation
+- **WHEN** a manifest requests direct run sockets, host paths, raw credentials, raw AI keys, or direct provider key access
+- **THEN** validation MUST return violations and MUST NOT treat the plugin as installable
+
+### Requirement: Platform Manifest Registration
+The platform SHALL expose a manifest registration API that accepts a structured game plugin manifest payload and converts it into installed plugin registry metadata.
+
+#### Scenario: Valid manifest is registered
+- **WHEN** a valid game management plugin manifest is submitted to the platform registration API
+- **THEN** the platform MUST persist an installed plugin record with manifest reference, create form schema reference, server type, required run capabilities, scoped permissions, pages, and AI purposes
+
+#### Scenario: Duplicate plugin registration is rejected
+- **WHEN** a manifest is submitted for an already registered plugin ID
+- **THEN** the platform MUST return a duplicate error and MUST preserve the existing registry record
+
+### Requirement: Registry Query Surface
+The platform SHALL expose plugin registry list and detail responses suitable for the plugin marketplace and server creation workflows.
+
+#### Scenario: Marketplace lists installed plugins
+- **WHEN** platform clients list game plugins by status or server type
+- **THEN** each response item MUST include plugin identity, version, server type/display metadata, manifest/schema references, run capabilities, scoped permissions, pages, AI purposes, and install status
+
+#### Scenario: Registry detail excludes unsafe internals
+- **WHEN** platform clients fetch one registered plugin
+- **THEN** the response MUST NOT include raw host paths, raw credentials, run connection details, or raw AI provider keys
+
+### Requirement: Backend Safety Validation
+The platform SHALL independently validate plugin manifest safety before registry persistence, regardless of plugin workspace validation results.
+
+#### Scenario: Raw key request reaches platform
+- **WHEN** a registration payload contains raw AI key, provider key, bearer token, or secret-like content
+- **THEN** the platform MUST reject the registration with a validation error
+
+#### Scenario: Direct run or host path request reaches platform
+- **WHEN** a registration payload contains direct run socket, direct run credential, or raw host path access requests
+- **THEN** the platform MUST reject the registration with a validation error
+
+### Requirement: Ownership Boundary Preservation
+The manifest registry implementation SHALL keep `plugins/` validation code and `platform/` backend code in their own roots and share contract shapes only through named DTO/domain/schema files.
+
+#### Scenario: Platform validates registration
+- **WHEN** platform code handles manifest registration
+- **THEN** it MUST use platform DTOs, domain types, and validators rather than importing plugin workspace implementation files