3.4 KiB
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