## 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