77 lines
5.0 KiB
Markdown
77 lines
5.0 KiB
Markdown
# V1 acceptance criteria
|
|
|
|
V1 is accepted only when every mandatory criterion below has an automated test or a documented end-to-end verification result.
|
|
|
|
## Installation and bootstrap
|
|
|
|
- `compose.yaml` starts one public main application and one non-public restricted agent.
|
|
- The main application has no Docker socket mount.
|
|
- First run requires creation of an administrator and refuses normal use until bootstrap is complete.
|
|
- A master encryption key and agent authentication secret are read from files, not literal environment values.
|
|
- All post-bootstrap product settings listed in the specifications are editable in the UI.
|
|
|
|
## Catalog and instance creation
|
|
|
|
- Invalid templates and manifests are rejected with field-specific errors.
|
|
- The Palworld examples validate against the checked-in schemas.
|
|
- Creation presents image, digest or tag, ports, mounts, resources, data origin and backup policy before confirmation.
|
|
- Port conflicts, insufficient disk space and paths outside approved roots block creation.
|
|
- An administrator can create an empty instance or create one from a validated imported save.
|
|
- The created container is registered in SQLite and carries DoGaMa labels and a non-forgeable registration binding checked by the agent.
|
|
- Unrelated Docker containers never appear in the API or UI and cannot be targeted through identifier substitution.
|
|
|
|
## Authorization
|
|
|
|
- Global administrators can manage system configuration and all instances.
|
|
- Non-admin access is absent unless an instance membership exists.
|
|
- User and manager baselines match `docs/domain/authorization.md`.
|
|
- Fine-grained overrides can remove a manager permission or add the separately controlled `backup.restore` permission.
|
|
- Every privileged API endpoint has denial tests; UI hiding alone is not accepted.
|
|
|
|
## Lifecycle and operations
|
|
|
|
- State distinguishes Docker running from game ready and exposes installing, starting, online, stopping, backup, restore, update, degraded, error and unknown conditions.
|
|
- Start, stop, restart, update and delete operations are serialized per instance and are idempotent where applicable.
|
|
- Repeated crash restarts trip a configurable circuit breaker.
|
|
- Resource limits, port mappings and approved storage mounts survive container recreation.
|
|
- Update displays old and new image references, makes a safety backup when configured, verifies health and rolls back or stops safely on failure.
|
|
- Deletion preserves player data and backups unless the administrator separately confirms their removal by typing the instance name.
|
|
|
|
## Backups, imports and exports
|
|
|
|
- Manual and five-field cron schedules work with a retention count per instance.
|
|
- Automatic retention deletes only eligible automatic backups; manual and imported backups are not silently removed.
|
|
- If `online_save` exists, idle shutdown requests and confirms a game save before stopping; otherwise DoGaMa stops first and archives afterward.
|
|
- Backup archives include a manifest and SHA-256 checksum and are written atomically.
|
|
- Restore verifies integrity, creates a pre-restore backup by default, stops the server and has a defined rollback or safe-stop result.
|
|
- Imports are staged and reject absolute paths, traversal, escaping links, device files, excessive file counts and extraction bombs.
|
|
- Import at instance creation does not create the server until validation succeeds.
|
|
- A normal instance export contains no secrets; a backup export is integrity-verifiable.
|
|
|
|
## Modules
|
|
|
|
- Only WebAssembly modules are accepted.
|
|
- The runtime enforces memory, fuel/instruction, time, response-size and concurrency limits.
|
|
- A module receives no filesystem, clock, random, environment, process or raw socket access unless exposed by a documented host function.
|
|
- Network calls can reach only the bound instance endpoint, declared protocol and declared integration port.
|
|
- Capability and function disagreement fails module activation.
|
|
- Template and module versions are independently upgradeable and a compatibility check precedes activation.
|
|
|
|
## Security, audit and notifications
|
|
|
|
- Secrets are encrypted at rest and never returned after write.
|
|
- Authentication is rate-limited; sessions use secure cookie settings and CSRF protection.
|
|
- Audit records important human/security actions but not page views, metrics polling or normal health probes.
|
|
- Audit retention defaults to 30 days and is configurable by an administrator, including a bounded manual purge.
|
|
- Email, generic webhook and Discord can be configured and tested in the UI.
|
|
- Notification delivery is queued, redacts secrets, retries with bounds and never blocks the originating operation.
|
|
- SSRF protections cover artwork downloads, webhook destinations and any administrator-provided URL.
|
|
|
|
## Quality gates
|
|
|
|
- Go tests, static analysis, frontend tests and schema/example validation pass.
|
|
- Database migrations work from an empty database and from the prior released schema.
|
|
- Backup/restore, update rollback, authorization and agent-scope integration tests pass against a disposable Docker environment.
|
|
- Documentation links resolve and examples use the same field names as the schemas.
|
|
|