Moderate Total Battle chat and handle incidents

Choose the right action

Use the least destructive action that addresses the current incident. Manual leadership decisions, automatic rules, access-policy reconciliation, restorative actions, recent-message hiding, and exact cleanup are separate paths.

Operation	Enabled, mutable room; restrictive moderation off	Enabled, mutable room; restrictive moderation on	Binding disabled	Local read-only guard
Manual Mute	active Leader/Superior may queue it	active Leader/Superior may queue it	blocked or skipped on execution	blocked or skipped on execution
Manual Kick	active Leader/Superior may queue it	active Leader/Superior may queue it	blocked or skipped on execution	blocked or skipped on execution
One-hour Ban	blocked	active Leader/Superior may queue it	blocked or skipped on execution	blocked or skipped on execution
Unmute / Unban	available for an actionable restriction while mutable	available while mutable	blocked until enabled	blocked until mutable
Disabled observe-only rule	stored but produces no action	stored but produces no action	no evaluation/mutation	no mutation
Enabled automatic restrictive rule	skipped because restrictive moderation is off	may act only from configured evidence	skipped	skipped
Hide exact recent messages with Mute/Kick	may be requested with the manual action	may be requested with the manual action	blocked/skipped	blocked/skipped
Exact-message cleanup	blocked	preview plus confirmation required	blocked/skipped	blocked/skipped

Clan only, Clan + invited, or Invite only can separately kick an ordinary outsider during access reconciliation. That is not a manual moderation Kick, Ban, or rule decision. Turning restrictive moderation off does not turn membership enforcement off and does not revoke a deliberate Leader/Superior Mute or Kick capability.

Understand repeated authorization

At initiation, Runekist loads the active membership and verifies Leader/Superior authority for the selected clan, current binding, requested operation, and exact target SUID. It does not authorize by nickname, a stale browser row, Total Battle clan rank, or previous operator status.

Queued work repeats the decision immediately before remote execution. It checks:

• the actor still has an active authorized membership in the same clan;
• the binding is the same active lifecycle, is enabled, and is not read-only;
• restrictive moderation is still on where Ban, automatic action, or cleanup requires it;
• the exact target is still a current actionable room member where required;
• the target is not the Runekist account or a protected remote operator; and
• authoritative room evidence and remote capability are still usable.

If a boundary changed, the action is recorded as skipped or failed instead of using old permission. Audits distinguish pending/running/succeeded/failed/skipped and repair-required outcomes; a confirmation alone never guarantees execution.

Apply manual Mute, Kick, and Ban

Mute requires a human-readable reason from 1 to 200 characters. Use it when the player should remain in the room but stop posting. Unmute restores the provider mute when the current room state makes that action available.

Kick removes the current ordinary player. A successful Kick also revokes an active invited-access exception under Clan + invited or Invite only, so an absent outsider is not automatically re-invited from that exception. Kick is not a reversible Ban: restoration may require a fresh in-policy invite, and under Clan + invited an authoritative current clan member may still be eligible for later roster reconciliation.

One-hour Ban requires restrictive moderation. A successful Runekist Ban is recorded in the room-specific ban ledger so enforcement does not immediately re-invite that exact SUID while the ban is active. Unban records the restoration, but provider lists can lag before the UI reflects it.

A Mute or Kick confirmation can request exact recent-message hiding for 0–24 hours; 0 leaves messages visible. Runekist resolves a bounded set of exact remote message IDs for that target and window. It cannot promise deletion of every historical message or messages that arrive after the request.

Provider operations can be partly complete. A Kick transport sequence can leave a repair-required audit, and a retry may finish local invited-access revocation after the provider already removed the player. Treat the audit outcome—not the button press—as the result.

Read restrictions and rule evidence

Runekist bans is a room-specific projection of successful Runekist Ban and Unban actions. It is not a provider-wide restriction list. Muted members is the provider's current reported state for this room. Total Battle may not reveal who created a mute, and the list can lag after restoration. Unknown origin must remain unknown rather than being attributed to Runekist.

The current clan UI creates rules only as disabled observe-only records. It does not expose enabling, editing, or choosing restrictive actions. Do not expect those records to delete, mute, or ban anyone, and do not weaken this safety limit as a documentation side effect.

Current rule kinds use bounded derived evidence:

• Per-player burst (user_burst) counts messages from one exact player in a window. Busy coordination can look like a burst, so start with evidence.
• Repeated exact content (content_repeat) counts the same keyed content fingerprint. The fingerprint is a non-readable equality signal; it does not understand meaning, spelling variants, or similar-looking spam.
• Repeated coordinate (coordinate_repeat) counts the same fingerprint for a recognized typed coordinate payload. Legitimate coordination around one target can repeat, so the typed classification does not prove abuse.
• Mention flood (mention_flood) counts derived mentions in a message/window. A legitimate callout can mention many players.

Observe evidence over representative busy periods and review false positives before considering any future restrictive rollout. The clan-wide Spam view surfaces these similarity signals for human review, but they never trigger an automatic remote action and must not be used for an automatic ban.

Review clan-wide spam safely

The Spam view is scoped to the current clan, not the selected room. Room is only a filter and a column. The queue contains derived reasons, similarity and exact-copy counts, versions, and action outcomes; it does not store message bodies or readable domain fingerprints. Use Reveal current message only when the current remote text is needed. Runekist fetches that exact observation from its clan-authorized room and keeps the text only in the temporary browser interaction. An unavailable or deleted message is not evidence of spam.

Mark spam is the one automatic exception to shadow mode. Its confirmation shows the current count of byte-identical copies and the number of affected, eligible, and non-enforceable clan rooms. The short-lived signed confirmation is bound to the clan, moderator membership, observation, fingerprint version, and count snapshot. If that scope changes, review a fresh confirmation.

Confirming creates a clan-only exact-body rule. Eligible known copies queue one audited deletion each, and eligible future copies with the same UTF-8 bytes queue automatically. Case, whitespace, punctuation, Unicode normalization, line order, similar templates, and similar domains are not exact copies. A confirmed exact copy never automatically mutes, kicks, or bans its sender.

Some copies remain non-enforceable, including historical imports, protected bot/operator/allowlist senders, disabled or read-only moderation, stale rooms, unavailable credentials/capability, and physical rooms shared by another clan. The label remains clan-local and the action audit records the skip reason; do not interpret a skip as permission to bypass the boundary manually.

Legitimate appends a correction and revokes future exact-copy deletion for that clan, but it cannot restore messages already deleted. Unsure records review feedback and creates or revokes no automatic rule. Always read the per-copy queued, succeeded, failed, or skipped audit outcome after a label.

Clean up exact messages carefully

Direct cleanup is destructive remote deletion. It requires restrictive moderation, an enabled mutable room, a bounded sender/time/limit preview, and a second confirmation token tied to that preview. The configured default window is 24 hours, the hard cap is 250 exact messages, and the confirmation expires after a short interval.

Review the exact count and scope. Messages arriving after the preview are not silently added, and missing/already-deleted IDs produce bounded audit outcomes. Cleanup cannot restore deleted messages. Prefer Mute and evidence review when stopping current harm does not require erasing the remote record.

Respond to common incidents

Repeated link spam

Capture the exact player and room, review current messages and observe-only evidence, then use a reasoned manual Mute if posting must stop. Hide only the necessary recent window. Escalate to Kick or, with restrictive moderation on, a one-hour Ban only when the narrower response is insufficient. Do not enable automatic Ban from a single incident.

Accidental mute, kick, or ban

For Mute or Ban, use the matching Unmute/Unban action and verify the provider state after any list lag. A Kick has no inverse: confirm access policy and exact identity, then invite again only if the player is still eligible. Deleted messages cannot be restored.

Runekist loses operator capability

Stop repeated mutations. Keep or set the room read-only, restore the Runekist account's remote operator capability through an authorized owner, run the read-only health check, refresh a complete snapshot, and retry only failed or repair-required work whose intent is still valid.

An outsider returns

Check that the access policy is Clan only, Clan + invited, or Invite only; the exact SUID is not a protected operator, active invited exception, or otherwise eligible target; and no active action conflicts. Clan policies also require a fresh authoritative roster. Invite only does not: use its reviewed access diff and complete room snapshot. Never target a similar display name.

The roster is stale or the snapshot is incomplete

Do not run roster-backed reconciliation, batch-act, or infer that the room is empty. Refresh the mapping roster and room data. Leave Clan only and Clan + invited enforcement unapplied until the UI reports a current authoritative roster and one complete room snapshot. Invite only is roster-independent, but still requires a complete current room snapshot and exact invited-access data.

Credential, rate-limit, or provider outage

An invalid credential needs server-side replacement. After rate limiting, wait until the shown retry time. During an outage, preserve the last-known-good snapshot and avoid destructive retries; restore health first.

Work was queued before disabling or freezing

Disabled and read-only checks run again at execution, so queued remote work should record a skip rather than mutate. After re-enabling or unfreezing, review current actor, policy, room, roster, and target state and create a fresh action only if the intent remains valid. Never assume an old queue will resume safely.