14 lines
1.5 KiB
Markdown
14 lines
1.5 KiB
Markdown
# Platform Validation Rules
|
|
|
|
- API handlers must use named DTOs from `platform/dto`.
|
|
- Platform services must not accept raw plugin-provided host paths.
|
|
- AI provider secrets must be stored by reference and hidden from platform diagnostics and plugin bridge responses.
|
|
- Game management plugin installation must validate manifest identity, server type, required run capabilities, pages, permissions, and schema references.
|
|
- Server instance creation must validate plugin installation state and run endpoint capability compatibility.
|
|
- `platform/validator/resources.go` validates required IDs, enum values, AI key-reference shape, bounded progress summaries, artifact metadata, log stream cursors, and run capability compatibility.
|
|
- `platform/service.Core` must call validators before repository writes and must reject server creation when the plugin is not installed, the run endpoint is disabled/offline, or required run capabilities are missing.
|
|
- Job creation must require an idempotency key and return the existing job for duplicate `(runEndpointId, idempotencyKey)` pairs.
|
|
# Runtime and bridge validation
|
|
|
|
Runtime validation rejects undeclared operations, stale attempt/key generations, cross-owner/server/target artifacts, unavailable endpoints, raw secrets, endpoint/socket values, traversal or absolute executable references, shell metacharacters, and unbounded timeouts. Game-client bridge validation keeps operator-facing transport metadata bounded before it crosses the Platform boundary; plugin-owned request text, result payloads, records, and log bodies remain opaque.
|