Prototype administrative discussion mute controls

Let owners/operators mute or unmute new public/private sends from a human seat while retaining history, incoming messages, gameplay and credentials. Fence metadata and durable audit writes with live authority, membership and versions. Preserve exact admin/message retries and inherit restrictions through seat recovery.

Validation: types/lint, 5431 offline tests, build, 52 HTTP integration tests, 24 administrator HTTP groups, independent SQL/privacy/UI review and desktop/mobile refresh acceptance. All 2230 prior games and 4746 seats preserved. Additive migration 0016. Verified runtime fingerprint 588967fbb9c2e3b6abe2990c4fce96ee69e2256fb7e3ee416314b87593cebba9; documentation-only grammar/button-label review gives b5e57bdd26812debede91c588e38f247f1fa895ad23e7ae30bc8550eedcd90ec. New-revision deployed acceptance remains open; full admin/rules scope is unfinished.

docs/ADMIN_DISCUSSION.md

@@ -0,0 +1,67 @@
+# Administrative discussion controls
+
+**Discussion controls** in the administration directory lets an owner or operator
+mute or unmute new public and private messages from one human seat. Viewers can
+inspect the public roster and discussion settings. A muted player can still read
+history, receive messages and play the game. This prototype does not revoke seat
+access, remove a participant or permit administrators to read private messages.
+
+## Use and recovery
+
+Select the human participant, enter a short operational reason, type the room
+code and acknowledge that the setting follows the seat. **Mute discussion** or
+**Unmute discussion** applies the change. Human seats using AI remain eligible;
+permanent AI seats do not send messages. Closed and archived rooms permit settings
+for reopening; a removed room must first be restored. Closing a room still blocks
+all new sends independently of its seat settings.
+
+The player sees a persistent explanation when muted, with **Refresh discussion
+availability** for checking an unmute while browsing older history. Only the
+caller's mute status is returned with their message page. Other players receive
+no mute indicator or private discussion activity. Incoming history remains under
+the existing sender/recipient privacy rules. Recovery and voluntary handover
+inherit the logical seat's setting; revoked credentials remain invalid.
+
+The exact admin operation, room version, seat-setting revision, target, setting
+and reason are saved in account/room-scoped tab storage before sending. The first
+request shows concise progress. Uncertain requests retain explicit retry controls
+across refresh; success text stays until a deliberate action. Retrying an old
+mute after a later unmute confirms the old receipt without muting again. Existing
+committed message requests can likewise be confirmed while muted; altered or
+new requests cannot bypass the restriction. A new owner cannot replay the former
+credential's message receipt.
+
+## Persistence and authority
+
+Additive migration [0016](../drizzle/0016_seat_discussion_controls.sql) stores
+seat settings separately from game JSON. The action leaves room versions, game
+change timestamps, private custody, credentials, readiness and AI pacing intact.
+It requires the current room version and a separate seat-setting revision. Live
+admin authority, human membership, room availability and both versions are fenced
+at commit. The setting and audit receipt commit together or roll back together.
+Message insertion independently checks the live mute setting in SQL, preventing
+a stale browser from sending. A message committed before a later mute still
+returns its successful receipt.
+
+Controls: [admin panel](../components/admin-discussion.tsx),
+[player discussion](../components/table-talk.tsx),
+[client retry](../lib/admin-discussion-client.ts).
+Server: [route](../app/api/admin/rooms/[code]/discussion/route.ts),
+[admin transaction](../db/admin-discussion.ts), [message store](../db/table-talk.ts).
+
+```sh
+npm test -- admin-discussion table-talk
+npm run test:integration -- admin-boundary table-talk
+```
+
+Focused regressions cover rollback, concurrent/conflicting operations, live
+role/session/membership/version changes, stale revisions after unmute, receipt
+replay, own-only status, incoming messages, mute/send ordering and seat rotation.
+The dedicated admin HTTP verifier creates a new QA room for deny/mute/read/retry/
+unmute flows and preserves both seats. Independent SQL/privacy and UI source
+reviews found no blocking defects. Browser, checkpoint and preservation evidence
+are recorded separately; deployed acceptance must match the running revision.
+
+Access revocation, disruptive participant removal, administrator-assisted recovery,
+backup/restore and operational audit browsing remain unfinished. Discussion
+moderation is a partial participant-support prototype, not full admin acceptance.

docs/ADMIN_PANEL.md

@@ -13,7 +13,7 @@ recovery and persistence systems where suitable.
 | 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 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 lobby configuration](ADMIN_LOBBY_CONFIGURATION.md) adds rules/modules, AI seats and host assignment to an existing human without private access. Reserved human seats remain. | Prototyped, partial |
 | Lifecycle and removal | [Pause/resume and joining locks](ADMIN_ROOM_CONTROLS.md), [administrative close/reopen](ADMIN_ROOM_CLOSURE.md) and [recoverable removal/restoration](ADMIN_ROOM_REMOVAL.md) have controls, durable audit, exact retries and player/AI enforcement. [Archive/unarchive](ADMIN_ROOM_ARCHIVE.md) has separate directory filters and exact retries. Permanent deletion and bulk actions remain missing. | Prototyped, partial |
-| Participant support | [Participant AI](ADMIN_PARTICIPANT_AI.md) enables an existing difficulty on an eligible human seat in a paused game, retaining access/takeback and private custody. Participant restrictions/removal, access revocation, assisted recovery and further replacement remain. Existing lobby controls can reassign the host. | Prototyped, partial |
+| Participant support | [Participant AI](ADMIN_PARTICIPANT_AI.md) enables an existing difficulty on an eligible human seat in a paused game, retaining access/takeback and private custody. [Discussion controls](ADMIN_DISCUSSION.md) mute/unmute new sends while retaining history and gameplay. Participant removal, access revocation, assisted recovery and further replacement remain. Existing lobby controls can reassign the host. | Prototyped, partial |
 | 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 |
 
@@ -56,6 +56,8 @@ No default key, public account creation or host-to-administrator promotion exist
 [Participant AI](ADMIN_PARTICIPANT_AI.md) lets owners/operators support an absent
 human in a paused, started game. The player retains access and takeback controls;
 the administrator receives no private seat. Resume remains a separate action.
+[Discussion controls](ADMIN_DISCUSSION.md) restrict new messages from a human seat,
+including after recovery/handover, without exposing private history.
 
 The directory uses an explicit field allowlist, independent of any player view.
 It never returns hands, Traitors, predictions, plans, private messages, recovery
@@ -129,7 +131,8 @@ room IDs and safe outcomes, never keys/cookies. The container verifier provision
 its own disposable QA account and checks admin-session continuity across restart
 and replacement, followed by the HTTP flow and HTTPS-proxy cookie behavior.
 Participant checks use another new QA room for paused AI enable, private-seat
-continuity, takeback and durable retries after resuming.
+continuity, takeback and durable retries after resuming. Discussion checks use a
+new QA room for mute/unmute, own-only status, incoming messages and saved retries.
 
 Local browser checks cover sign-in, directory filters, refresh restoration and
 mobile layout. Final source-bound checks and separately recorded deployed

docs/CURRENT_STATUS.md

@@ -6,13 +6,19 @@ Expansion starts and full rules/publication acceptance remain gated.**
 
 ## Current checkpoint and work
 
-Current work adds [participant AI support](ADMIN_PARTICIPANT_AI.md): a live
-owner/operator can enable an existing AI difficulty for an eligible human in a
-paused, started game. Saved custody and seat access remain; the human can take
-back control, and resume is separate. Atomic audit, exact saved retries and
-commit-time room/seat/authority checks are connected. Participant restrictions,
-access revocation, assisted recovery, permanent deletion, bulk actions and
-backup/operations tools remain unfinished. This adds no strategic AI refinement.
+Current work adds [discussion moderation](ADMIN_DISCUSSION.md): owners/operators
+can mute or unmute new public/private messages from a human seat. History,
+incoming messages, game state and credentials remain saved; the setting follows
+recovery/handover. Atomic authority/version fences, durable audit and exact
+admin/message retries are connected. This is partial participant support;
+access revocation, participant removal, assisted recovery, permanent deletion,
+bulk actions and backup/operations tools remain unfinished.
+
+[Participant AI](ADMIN_PARTICIPANT_AI.md) checkpoint `2cddf03` is pushed. Types/lint,
+5,408 offline tests, 52 HTTP tests, build, twenty-two administrator HTTP groups
+and desktop/mobile browser acceptance passed. Deployment request delivery remains
+unconfirmed; the latest confirmed production revision is `e918e2e`. No strategic
+AI refinement was added.
 
 Readable-notice checkpoint `137f922` is pushed. Types/lint, 5,381 offline tests,
 52 HTTP tests, build and delayed-response desktop/mobile browser QA passed.

docs/IMPLEMENTATION_STATUS.md

@@ -1,5 +1,21 @@
 # Dune implementation status
 
+## 26 September 2026 — Administrative discussion moderation prototype
+
+[Discussion controls](ADMIN_DISCUSSION.md) connect human-seat mute/unmute to the
+admin directory and player message panel. New public/private sends are blocked
+at commit; history, incoming messages and exact committed retries remain usable.
+Settings survive seat recovery/handover without reviving old credentials. Game
+JSON, versions, timestamps, private custody and AI pacing remain unchanged.
+
+Atomic live authority/membership/version fences, per-seat revisions and audit
+receipts protect concurrent and uncertain requests. Independent SQL/privacy and
+UI source review found no blocking defects. Focused regressions cover mute/send
+ordering, rollback, stale unmute races and exact retry privacy. Browser, HTTP,
+source-bound checkpoint checks and preservation evidence accompany this slice.
+New-revision deployed acceptance remains open; full administration and game
+rules/expansion completion remain unfinished.
+
 ## 26 September 2026 — Administrative participant AI prototype
 
 [Participant AI](ADMIN_PARTICIPANT_AI.md) connects paused human-seat support to

docs/TABLE_DISCUSSION.md

@@ -28,6 +28,16 @@ resumes updates. Channel changes discard obsolete read results. There are no
 public direct-message counts, typing indicators or global sequence numbers.
 Messages are stored durably; pagination does not delete old history.
 
+## Discussion moderation
+
+An administrator can [mute new messages from a seat](ADMIN_DISCUSSION.md). The
+player sees a persistent explanation; reading history, receiving messages and
+playing remain available. The setting follows recovery or handover and is never
+shown as another player's private activity. New sends are checked at database
+commit. An exact previously committed send can still be confirmed while muted;
+no new message is created. Refresh availability after an unmute, or allow the
+normal latest-message poll to update the controls.
+
 ## Saved retries and state isolation
 
 The browser saves an exact message UUID, recipient and body in tab storage before