Start with the public-room boundary
Every Total Battle user-created room remains public. Open, Clan only, Clan + invited, and Invite only control Runekist's best-effort membership work; none of them creates privacy. Authorize people and compare rosters by exact Total Battle SUID, never by a display name.
Before connecting a room, decide who owns it, what kind of payload it should process, whether Runekist is allowed to mutate it, and whether the mapping roster is fresh enough for enforcement.
Create or attach a room safely
- Create room asks Total Battle to create a new room, joins the Runekist account, and verifies that account as an operator before saving the binding. Runekist records it as a managed channel.
- Attach room searches the exact room name, joins the Runekist account, and verifies the capability required by the selected safety mode. The room existed independently, so attachment does not transfer ownership to Runekist.
Keep an attached, shared, or third-party room locally read-only unless its owner explicitly authorized Runekist to change it. Known protected rooms cannot be changed out of read-only mode. Created and attached rooms can both be detached without deleting the remote channel; only an eligible channel created and still managed by Runekist can later offer permanent destruction.
Choose a channel type
Channel type describes remote behavior and content processing. It is not the same setting as Runekist's independent local read-only safety guard.
| Channel type | Remote posting behavior | Runekist processing | Important boundary |
|---|---|---|---|
| Chat | ordinary room members can post according to Total Battle capability | room membership, moderation, and supported management | does not recognize or report Ancient vault participation |
| Readonly chat | Runekist synchronizes the room's provider posting policy for managed use | room membership and supported management remain mutable | this is a channel type, not the local read-only guard; the product does not pair it with that guard |
| Ancient vaults | ordinary chat capability remains provider-defined | recognizes supported typed vault links/reports and builds participation history | prose mentions are ignored; use it only where vault reporting is intended |
Changing an Ancient vaults room to Chat keeps already captured vault facts but stops processing and displaying new participation until the type changes back.
Choose an access policy
- Open performs no automatic roster enforcement. An authorized Leader or Superior can still invite an eligible exact player while the room is mutable.
- Clan only previews the latest current mapping roster, invites eligible exact SUIDs, removes ordinary outsiders, and checks for outsiders who return.
- Clan + invited adds active exact-SUID exceptions created through Runekist. Full reconciliation can re-invite an absent listed player; drift checks remain removal-only for ordinary outsiders.
- Invite only does not use the clan roster. It retains the Runekist account, protected remote operators, configured allowlist entries, and active exact-SUID invited-access grants. Full reconciliation can restore a missing invited player, while drift reconciliation removes ordinary outsiders without adding anyone. Selecting it requires an explicit acknowledgement because ordinary clan-roster members are not automatically retained.
Runekist uses the latest valid immutable Sendbird member-mapping revision. It must be current, clan-scoped, complete, and identity-complete. If the revision is missing, stale, empty, or lacks exact identities, Runekist does not guess from names and does not apply unsafe reconciliation. Remote operators, the Runekist bot, and active deliberate bans remain protected conflicts.
Invited entries stay active when switching between Clan + invited and Invite only. They are inactive but retained when the policy changes to Clan only or Open, and reactivate when either invited policy is deliberately selected again. A successful Kick revokes the target's invited exception. Removing an invited exception does not override membership in the current mapping roster under Clan + invited; under Invite only, clan membership alone never restores access.
Separate safety, moderation, and scheduling
- The local read-only guard blocks invitations, membership enforcement, operator changes, messages, moderation, message hiding, cleanup, and remote deletion—even for work queued earlier. Safe observation and vault reporting may continue.
- Restrictive moderation gates one-hour Ban, automatic restrictive rules, and destructive cleanup. It does not gate a deliberate Leader/Superior Mute or Kick and does not change the access policy.
- Enabled controls scheduled work and normal polling. When disabled, queued remote actions re-check the binding and skip rather than mutating it.
Read health and snapshots
Use Run read-only health check to verify the credential, room access, Runekist membership, and—where mutation is expected—operator capability. Refresh rooms and Refresh room data mark only affected collections stale and coalesce background refreshes.
Runekist saves one complete room snapshot shared by bindings for that remote room. A refreshing notice can show the complete last-known-good snapshot while a replacement is loading. An unavailable notice means no complete snapshot exists; do not interpret it as an empty room. Reconciliation, membership repair, moderation checks, and other authoritative actions require stricter freshness and fail closed when current complete data is unavailable.
Health can report healthy, rate limited, permission error, invalid credential, disabled, or a Total Battle failure. Wait for a displayed retry time after rate limiting. A permission error often means the Runekist account left or lost operator capability. An invalid credential requires server-side replacement. Repeated provider failures are a reason to keep the room read-only, not to retry destructive work.
Apply the decision to common rooms
- Clan-owned roster room: create or deliberately attach it, select the type that matches its work, verify Runekist as operator, then preview a fresh roster before choosing Clan only or Clan + invited.
- Explicit-grant room: choose Invite only only after reviewing the access diff and acknowledging that ordinary clan members are not retained. It does not need authoritative roster evidence, but it still needs a complete current room snapshot and exact invited-access grants.
- Shared or third-party room: attach it locally read-only. Use observation or vault reporting only; do not remove the guard without the owner's explicit authorization and a reviewed operator/access plan.
- Protected room: keep the enforced read-only state. If the desired workflow requires mutation, create a separate clan-owned room instead of weakening the protected room's boundary.