diff --git a/AGENTS.md b/AGENTS.md index 47fbacd6..9fa8a645 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -28,6 +28,10 @@ for the in-memory SQLite tests. `tsx` is a pinned development dependency. - Track missing, prototyped, integrated, verified and polished work in the existing checklist. Prototypes need usable controls, a legal AI path and saved continuation; placeholders and disconnected helpers are not completed features. +- A complete administration panel is required non-AI scope: room creation, + lifecycle/removal, participant support, backups/restoration and operations. + Follow `docs/ADMIN_PANEL.md`; retain authorization, privacy, audit history and + saved-game safeguards. Adding this scope does not authorize a game reset. - Keep focused checks for crashes, deadlocks, legality, custody, privacy and save integrity. Defer exhaustive combinations and visual polish until broader functional coverage, unless current failures require them. @@ -69,6 +73,10 @@ for the in-memory SQLite tests. `tsx` is a pinned development dependency. to obtain a green result; the runner self-test checks real failure propagation. - Report actual check results and limitations. Passing focused tests does not certify a complete faction, expansion or rules mode; preserve release gates. +- Verify relevant runtime changes on `https://dune.procrastination.games` after + deployment, matching the deployed revision to the checkpoint. Use dedicated + QA rooms and preserve existing games; local success is not deployed evidence. + Follow `docs/VERIFICATION_WORKFLOW.md` for production checks and limitations. ## Preserve development state diff --git a/docs/ADMIN_PANEL.md b/docs/ADMIN_PANEL.md new file mode 100644 index 00000000..d55cd99a --- /dev/null +++ b/docs/ADMIN_PANEL.md @@ -0,0 +1,82 @@ +# Administration panel requirements + +Added to the goal on 22 September 2026 at the user's request. This is required +product scope, not a claim that the panel is implemented. Reuse the existing +room, session, recovery and persistence systems where suitable. + +## Required capabilities + +| Area | Required behavior | Stage | +| --- | --- | --- | +| Administrator access | Secure administrator sign-in, server-enforced permissions, session revocation and a documented initial-owner setup. A room host is not automatically a site administrator. | Missing | +| Room directory | Search, filter, sort and paginate rooms; show lifecycle status, host, roster, rules/modules, last activity and pending decision ownership without exposing private game information. | Missing | +| Create and configure | Create rooms with supported rules and human/AI seats, manage lobby settings and invitations, and assign a host through an explicit workflow. Preserve normal prerequisites and readiness rules. | Missing | +| Lifecycle and removal | Pause/resume, lock/unlock new joins, close/end, archive, restore and delete selected rooms. Offer recoverable removal and explicit permanent deletion with clear scope, consequences and safeguards for related records. | Missing | +| Participant support | Remove disruptive participants or revoke access, manage appropriate restrictions, assist saved-seat recovery and host reassignment, and use supported AI takeover/replacement without losing forces, cards or decisions. | Missing | +| Saved-game operations | Create/list/download backups, validate imports, restore a selected checkpoint safely, and diagnose or resume interrupted automatic work through authoritative game actions. | Missing | +| Operations and audit | Show server/build/storage health, room/player counts and actionable errors; provide maintenance controls and a searchable record of administrator actions. | Missing | + +Track each area through Missing, Prototyped, Integrated, Verified and Polished. +As implementation begins, link its controls, server actions, persistence, +documentation and evidence. A working directory alone is not a full admin panel. + +## Behavior and safeguards + +Every privileged endpoint must authenticate and authorize its caller. Support +least-privilege roles, secure initial provisioning, safe credential/session +management, and accessible desktop/mobile controls. Do not ship default shared +credentials or expose administrator capabilities through ordinary room cookies. + +Default views must preserve hands, Traitors, predictions, sealed plans, private +discussion and recovery credentials. Any necessary private support access must +be separately authorized and audited; it must not reveal information to other +players or feed an administrator's playing seat or AI strategy. Redact secrets +and private card contents from routine logs and reports. Backup access needs +equivalent protection, since backups can contain private state. + +Pausing must stop human mutations and automatic/AI continuation consistently +without losing pending decisions. Resuming restores the same turn and pacing. +Seat removal or reassignment must explain the effect on an active game and +preserve a legal continuation; do not simply delete a faction's physical pieces. +Existing consent/recovery boundaries remain applicable to seat access. + +Use authoritative rules and the existing concurrency model. Reject stale or +duplicate destructive actions safely. Imports and restoration must validate +schema, custody, private-information boundaries and session ownership; capture +a recovery checkpoint before replacing current progress. Never restore old +credentials in a way that silently reauthorizes a revoked participant. + +Room removal should be reversible by default. Permanent deletion and bulk +operations must identify the selected rooms and dependent records, explain +irreversibility, require deliberate confirmation and retain appropriate audit +evidence without keeping purged secrets. Protect unrelated games. The existing +saved-game preservation rules still govern development and maintenance; they +do not preclude intentional room deletion through the authorized product workflow. + +Record who acted, when, the affected room/seat, operation, reason, outcome and +safe before/after metadata. Maintenance controls must warn about interruptions +to active games and preserve restoration. Do not recreate recurring restarts or +cleanup schedules. Do not add an arbitrary game-state editor that bypasses rules, +silently changes outcomes or makes unfinished modes appear complete. + +## Development order and acceptance + +Prototype permissions and the room directory first, then room creation and +reversible lifecycle operations, participant support, backup/restore and +operational tools. Include functional server actions and saved continuation in +each slice; continue independent game features in parallel where useful. +Administration is part of the non-AI completion gate in the +[AI development plan](AI_DEVELOPMENT_PLAN.md). + +Acceptance requires working controls and documented setup/recovery procedures, +with authenticated HTTP and persistence tests for authorization, privacy, +concurrent actions, exact retries, related-record handling and safe restoration. +Verify pause/resume with both humans and AI, archive/delete/restore with saved +rooms, and denied admin actions by ordinary players. Exercise desktop/mobile +flows and server restart recovery. Use dedicated test rooms and preserve all +unrelated saved games; complete independent security/privacy/persistence review. +Verify the panel's relevant deployed flows at +**https://dune.procrastination.games**, including denied access by ordinary +players, using the [production verification workflow](VERIFICATION_WORKFLOW.md#verify-the-deployed-application). +The full goal remains unfinished until this scope and the other completion +criteria are satisfied. diff --git a/docs/AI_DEVELOPMENT_PLAN.md b/docs/AI_DEVELOPMENT_PLAN.md index 6026bc51..3b91183d 100644 --- a/docs/AI_DEVELOPMENT_PLAN.md +++ b/docs/AI_DEVELOPMENT_PLAN.md @@ -1,6 +1,6 @@ # AI development order and difficulty targets -Updated 20 September 2026 at the user's request. This is the current development +Updated 22 September 2026 at the user's request. This is the current development plan; the [earlier calibration studies](AI_CALIBRATION.md) are historical results, not evidence that the new targets have been met. @@ -9,8 +9,9 @@ not evidence that the new targets have been met. Full AI implementation, strategic refinement and difficulty tuning start only after all non-AI game features are complete: Basic and Advanced rules, all twelve factions, the three expansions, applicable optional modules and interactions, -multiplayer functions and the required player-facing features. Do not spend time -tuning strategy against incomplete rules. +multiplayer functions, the required player-facing features and the complete +[administration panel](ADMIN_PANEL.md). Do not spend time tuning strategy against +incomplete rules or move AI refinement ahead of the administration requirement. Until then, preserve existing profiles and provide only the minimal legal AI participation needed to exercise new features. Fix crashes, deadlocks, illegal diff --git a/docs/CURRENT_STATUS.md b/docs/CURRENT_STATUS.md index 196d3cda..48cba95c 100644 --- a/docs/CURRENT_STATUS.md +++ b/docs/CURRENT_STATUS.md @@ -1,11 +1,24 @@ # Current development status -Updated 21 September 2026. **The full twelve-faction goal is unfinished. Basic +Updated 22 September 2026. **The full twelve-faction goal is unfinished. Basic is playable and the six classic factions have a user-authorized Advanced preview. Expansion starts and full rules/publication acceptance remain gated.** ## Current checkpoint and work +The user added a complete [administration panel](ADMIN_PANEL.md) to the goal on +22 September: secure admin access, room creation/removal and lifecycle controls, +participant support, backup/restore, operational views and audited actions. +This is required scope, not implemented functionality, and belongs before full +AI refinement/calibration. Existing rules, Git, subagent and preservation +requirements remain in force. + +The goal also requires testing the deployed application at +**https://dune.procrastination.games**. Match the running revision, exercise +relevant real player/admin flows in dedicated QA rooms, and record deployed +results separately from local checks. See [production verification](VERIFICATION_WORKFLOW.md#verify-the-deployed-application). +This requirements update does not claim a new deployed test result. + Latest delivered checkpoint: `0f79f28`, [forced Harkonnen exchange return](HARKONNEN_EXCHANGE.md). Types, lint, **5,150 offline tests**, **49 HTTP tests** and the production build passed. One complete Advanced sample had no rejected actions across 158 actions @@ -112,6 +125,7 @@ These links define bounded working behavior, not complete module certification. | Twelve factions and all optional modules | Every missing effect, remaining skill bands, Ecaz card variant, Kull Wahad, unfinished Richese cards, Terror effects, occupation entitlement, Nexus interactions, contested Discoveries and complete games across valid combinations. Detailed boundaries remain in the checklist/decision index. | | AI | Maintain minimal legal participation and critical correctness fixes while game features are unfinished. Full implementation, strategy refinement and calibration wait until all non-AI features are complete; then target approximately 75% higher-tier wins for Medium/Easy, Hard/Medium and Brutal/Hard. See the [AI development plan](AI_DEVELOPMENT_PLAN.md). These targets remain unverified. | | Multiplayer | Broader disconnected/abandoned-seat recovery, unattended continuation and network-failure acceptance, while preserving authoritative versioning, custody, privacy and saves. | +| Administration | Complete the [admin panel](ADMIN_PANEL.md): permissions, room directory and creation/removal, lifecycle controls, participant support, backup/restore and operational audit tools. Required before full AI refinement. | | Components and experience | Full component inventory/text verification, all readable inspectors, original artwork, animation/sound/accessibility/mobile polish, complete internal guidance and end-to-end human play. | [AI calibration](AI_CALIBRATION.md), [multiplayer audit](MULTIPLAYER_AUDIT.md), diff --git a/docs/IMPLEMENTATION_STATUS.md b/docs/IMPLEMENTATION_STATUS.md index df6bdc2a..dd08d8f7 100644 --- a/docs/IMPLEMENTATION_STATUS.md +++ b/docs/IMPLEMENTATION_STATUS.md @@ -1,5 +1,20 @@ # Dune implementation status +## 22 September 2026 — Administration and deployed verification added to the goal + +The user requested a complete [admin panel](ADMIN_PANEL.md), including adding +and removing rooms and other useful operational actions. The goal now includes +room lifecycle management, participant support, backups/restoration, health views +and audited, authorized administration. This is a requirements checkpoint only; +no admin capability or live room change is claimed. Administration is explicitly +part of the non-AI completion gate; the existing Git, selective-subagent, rules +coverage and saved-game preservation requirements remain unchanged. +The user also requires relevant browser acceptance against the actual deployment +at **https://dune.procrastination.games**, matching its revision and preserving +human games. The [verification workflow](VERIFICATION_WORKFLOW.md#verify-the-deployed-application) +records the distinction from local checks. No new production test is claimed by +this documentation checkpoint. + ## 21 September 2026 — Selectable Advanced preview The user-authorized [Advanced preview](ADVANCED_PREVIEW.md) now has room-creation diff --git a/docs/VERIFICATION_WORKFLOW.md b/docs/VERIFICATION_WORKFLOW.md index 76b2177b..11b7820b 100644 --- a/docs/VERIFICATION_WORKFLOW.md +++ b/docs/VERIFICATION_WORKFLOW.md @@ -4,6 +4,45 @@ Use the [development guide](DEVELOPMENT.md) to choose checks appropriate to the change. These wrappers retain the existing test runner and simulation harness; they do not replace rules, browser or release acceptance. +## Verify the deployed application + +The user requires testing the actual application at +**https://dune.procrastination.games**, added to the goal on 22 September 2026. +Local development, a local production build and container smoke tests do not +replace testing that deployed origin. + +After relevant application changes are deployed, identify the running revision +or image digest and match it to the checkpoint under test. Record when testing +occurred, what revision actually ran, the routes/actions exercised, results and +remaining limitations. If the deployed revision is older, label the results for +that older revision; do not claim that new source passed deployed acceptance. +If access or deployment is unavailable, report the gap and keep acceptance open. + +Use the production browser flow to verify relevant navigation and deep links, +bundled assets and rendering, HTTPS/proxy behavior, cookies and authentication, +room creation/join, rules selection, human/AI decisions, multiplayer updates, +private views and refresh/reconnection. Exercise changed gameplay and admin +operations through the real controls and server, with desktop/mobile coverage +where relevant. Do not rely solely on HTTP status codes or local test results. +Keep checks focused on the changed behavior and its dependencies; broad final +acceptance must cover the complete game and administration scope. + +Create clearly identified QA rooms/seats and track their IDs privately. Protect +human games, private information, recovery credentials and logs. Admin tests +must use explicitly authorized admin access, with destructive or restoration +checks restricted to designated test records and appropriate recovery snapshots. +Do not reset production storage, interrupt live human play, weaken permissions +or restart the server merely to run a routine smoke test. + +When a deployment or necessary restart occurs, verify saved-game and seat +continuity afterward, distinguishing legitimate gameplay changes from data loss. +Use the existing hosting/deployment procedure and additive migrations; testing +requirements do not authorize bypassing completion or publication gates. +Documentation-only checkpoints need documentation/link review, not an unrelated +production gameplay run. Record production evidence separately from the local +source-bound checks below, and repair runtime-specific failures before treating +the affected deployed feature as verified. + ## Compact checks and source evidence ```sh