Add configured room creation to administration

Create an explicitly owned new host seat with supported rules/modules and ordered AI seats through one live-authorized transaction. Save exact account-bound retries across refresh, record durable audit metadata, and never restore a revoked or transferred host credential. Connect invitation joining and ordinary voluntary host handover. Preserve normal readiness and Advanced preview gates.

Verified types, lint, 5240 offline tests, 52 HTTP tests and build. Eight authenticated HTTP groups and independent privacy/persistence review passed. Browser QA confirmed one room after a lost response and refresh/retry, working host controls and saved continuation. Mobile layout passed; requested desktop viewport override did not take effect. Existing games preserved. Authenticated deployed administrator acceptance remains pending explicit QA access.

docs/ADMIN_PANEL.md

@@ -11,7 +11,7 @@ recovery and persistence systems where suitable.
 | --- | --- | --- |
 | Administrator access | Personal access keys, server-enforced owner/operator/viewer roles, persistent eight-hour sessions, individual/all-session sign-out and operator provisioning/revocation. A room host is not a site administrator. Account-management UI and further operational permissions remain. | Prototyped |
 | Room directory | Search room codes/public player names, filter status/rules/availability, sort and paginate; show host, roster, modules, game change time, pause/join flags and bounded decision ownership. Detailed setup/shared-window ownership remains. | Prototyped |
-| 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 |
+| Create and configure | [Create a lobby](ADMIN_ROOM_CREATION.md) with an explicitly owned new host seat, Basic/Advanced preview and initial AI configuration; invite humans and use ordinary lobby controls/voluntary host-seat handover. Neutral administration of lobby configuration, reserved human seats and reassignment to another existing player remain. | Prototyped, partial |
 | Lifecycle and removal | [Pause/resume and joining locks](ADMIN_ROOM_CONTROLS.md) have controls, durable audit, exact retries and player/AI enforcement. Close/end, archive, restore and recoverable/permanent removal remain missing. | Prototyped, partial |
 | 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 |
@@ -36,6 +36,8 @@ All three roles may read the current directory and sign out their own sessions.
 Owners/operators may pause/resume rooms and lock/unlock new joins through
 [Room controls](ADMIN_ROOM_CONTROLS.md). The role is checked from the live
 account, never accepted from a client.
+Owners/operators can also [create a configured lobby](ADMIN_ROOM_CREATION.md),
+with explicit new-host ownership and saved exact retries.
 Disabling an account invalidates its sessions; later re-enabling it cannot restore
 them. The database refuses to disable, demote or delete the final enabled owner.
 No default key, public account creation or host-to-administrator promotion exists.
@@ -103,8 +105,8 @@ checks its ID before proceeding: it creates a named QA room and signs out all
 sessions of that QA account. Never supply a human operator's normal key. It checks
 authentication, cookie properties, ordinary-host denial, directory privacy,
 session revocation and unchanged game/seat continuation. Operator/owner QA keys
-also create one additional room for joining locks, pause/takeback/resume and
-account-bound request checks. Private reports retain
+also create dedicated rooms for joining locks, pause/takeback/resume,
+administrator creation, invitations and voluntary host handover. Private reports retain
 room IDs and safe outcomes, never keys/cookies. The container verifier provisions
 its own disposable QA account and checks admin-session continuity across restart
 and replacement, followed by the HTTP flow and HTTPS-proxy cookie behavior.

docs/ADMIN_ROOM_CREATION.md

@@ -0,0 +1,88 @@
+# Creating rooms from Administration
+
+Owners and operators can choose **Create a room** in the administrator directory.
+Select a host name/faction, Basic or Advanced preview, optional Tech Tokens and
+Stronghold Cards, and zero to five AI players with individual difficulties.
+Other human players join through the ordinary invitation. The new human host
+stays unready; nothing starts automatically. Tech Tokens still require three
+players at start, and Stronghold Cards require Advanced rules. Expansion starts
+and complete-mode acceptance remain gated.
+
+Creation explicitly gives this browser the **new** host seat. Open it to change
+lobby settings, configure player circles, invite humans and start normally. To
+set up for another person, use the existing **Pass your seat to another player**
+flow in that lobby; the host player identity and room progress survive transfer.
+This workflow grants no access to any existing participant's seat.
+
+This is a connected room-creation prototype, not complete neutral administrator
+lobby management. Creating reserved human seats, assigning a different existing
+participant as host and managing lobbies without a playing seat remain part of
+[the full panel requirements](ADMIN_PANEL.md).
+
+## Saved confirmation
+
+Before sending, the client saves one account-scoped creation request privately
+in this tab. It contains the exact setup, operation identifier and a new host
+session proof. Keep this tab and its storage until confirmation. A timeout or
+lost response leaves **Retry saved room creation**; after refresh, reopen
+**Create a room** to confirm that same request. It never automatically submits a
+second creation. Expired or switched administrator access retains the original
+account's pending record for later sign-in.
+
+A matching response replaces the private retry proof with a safe room receipt.
+The result stays visible until closed or **Create another room** is selected.
+Invitation codes are public to intended players; the private session proof must
+never be placed in a URL, log or shared invitation. This temporary retry record
+does not replace the host's long-term saved-seat recovery kit.
+
+An exact server retry returns the original room without resetting its lobby,
+readiness or later game progress. If the original host session was revoked or
+transferred, the receipt reports that access is unavailable and sends no seat
+cookie. A stale creation retry cannot recover a transferred seat or overwrite
+the recipient's credentials.
+
+## Authority and persistence
+
+The [creation endpoint](../app/api/admin/rooms/route.ts) requires the configured
+origin, an administrator session, an owner/operator role and the displayed
+account identifier. Ordinary room hosts and viewer administrators cannot use it.
+The [database operation](../db/admin-room-creation.ts) rechecks the live account,
+role, session generation and expiry inside its atomic write transaction.
+
+Existing engine actions construct the configured lobby in memory. The room,
+hashed host session and durable creation receipt/audit commit together or roll
+back together. The receipt binds the actor, ordered setup, reason and private
+session hash. Reusing an operation for different input or another account fails;
+reusing a session proof already recorded in any seat also fails. Random invitation
+collisions retry a bounded number of times without replacing another room.
+
+The additive [migration](../drizzle/0010_admin_room_creation.sql) stores safe
+configuration, actor, reason, time and hashed receipt identifiers. It does not
+copy private game contents or plaintext credentials into the audit. Administrator
+responses contain only the room/host identifiers and confirmation flags. Private
+gameplay is loaded through the normal authenticated room route.
+
+## Verification
+
+Focused tests cover supported setup and start gates, ordered AI seats, exact
+concurrent retries, transaction rollback, live authority, credential reuse,
+restart recovery and transfers. Client tests check account-scoped private proof,
+storage failure and replacing it only with a matching safe receipt.
+
+The dedicated-operator HTTP verifier creates one extra lobby for this flow,
+checks invitation joining and performs a voluntary transfer within that QA room.
+It confirms that subsequent creation retries do not revive the former host's
+access. The lobby remains saved and does not start AI play. No existing human
+room is used. The expanded authenticated HTTP verifier passed all eight groups.
+
+Local browser QA lost one successful creation response, refreshed, reopened the
+saved request and confirmed exactly one room and receipt. Its configured host
+seat opened through the ordinary route; readiness survived another refresh, and
+the QA lobby was left unready. The completed receipt also survived refresh.
+At a reported 390-pixel viewport, the form used 16-pixel text and a 44-pixel create
+button without horizontal overflow. A requested 1280-pixel override continued to
+report 390 pixels, so this run does not establish desktop layout acceptance.
+
+Source, browser, container and deployed acceptance are separate
+evidence; authenticated production checks still require explicitly authorized QA
+administrator access.

docs/CURRENT_STATUS.md

@@ -6,13 +6,19 @@ Expansion starts and full rules/publication acceptance remain gated.**
 
 ## Current checkpoint and work
 
-Current implementation adds [administrator pause/resume and joining locks](ADMIN_ROOM_CONTROLS.md):
-usable controls, availability filters, player guidance, stopped human/AI
-decisions, durable audit and account-bound exact retries. Recovery, discussion
-and AI takeback remain available. Focused persistence, authenticated local HTTP
-and desktop/mobile browser checks accompany the checkpoint. Remaining lifecycle
-and full-admin requirements stay open; authenticated production acceptance waits
-for the required QA-access confirmation.
+Current work adds [administrator room creation](ADMIN_ROOM_CREATION.md): a new
+explicitly owned human host seat, supported rules/modules, initial AI seats,
+invitation joining and exact saved retries. Creation uses ordinary engine setup
+and preserves normal readiness/start gates. Neutral administrator configuration,
+reserved human seats and reassignment to existing participants remain unfinished.
+
+Checkpoint `8c922b4` added [pause/resume and joining locks](ADMIN_ROOM_CONTROLS.md)
+and passed types/lint, 5,223 offline tests, 52 HTTP tests and build, with independent
+review and dedicated local administrator/browser checks. It is deployed on the
+NAS: container verification passed, migration 0009 applied, all eight prior rooms
+and ten seats were preserved, and a saved seat restored through public HTTPS.
+Anonymous administrator requests remain denied. Authenticated production admin
+acceptance still requires the pending QA-access confirmation.
 
 Checkpoint `f29d056` was pushed and deployed to the NAS instance. Readable
 create/join progress and Continue notices passed actual HTTPS browser acceptance,
@@ -27,8 +33,8 @@ Continue control. It does not add confirmation steps to game rules or AI turns.
 
 Administrator access/directory checkpoint `c2d392e` passed types, lint, 5,196
 offline tests, 52 HTTP tests and build, plus focused authenticated/browser checks.
-Its production acceptance is being combined with this readability follow-up to
-avoid two deployments; saved games and full administration gates remain intact.
+Its authenticated production acceptance remains pending; the current deployment
+preserves saved games and full administration gates.
 
 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,

docs/IMPLEMENTATION_STATUS.md

@@ -1,5 +1,15 @@
 # Dune implementation status
 
+## 22 September 2026 — Administrator room creation
+
+Added [configured lobby creation](ADMIN_ROOM_CREATION.md) with explicit new-host
+ownership, initial AI factions/difficulties, supported optional rules, invitations
+and the ordinary voluntary host-seat transfer path. Atomic live-authorized writes
+and saved account-bound requests keep retries from duplicating rooms or reviving
+revoked private-seat access. Normal readiness and preview gates remain. Full
+neutral lobby administration, participant support and authenticated production
+acceptance remain unfinished; verification evidence accompanies the checkpoint.
+
 ## 22 September 2026 — Administrator room pause and joining locks
 
 Added reversible pause/resume and joining-lock controls, availability filters