Choose the least destructive recovery
Use this order when room management is unhealthy:
- Stop new risky actions and preserve the last-known-good snapshot.
- Keep or make the binding locally read-only when authority is uncertain.
- Restore the credential, remote membership/operator capability, provider availability, or authoritative roster, then run a read-only health check.
- Refresh one complete room snapshot and review failed, skipped, or repair-required actions.
- Use Freeze/Unfreeze only for the intended remote posting state.
- Detach if Runekist should stop managing a remote room that must remain.
- Permanently destroy only an eligible Runekist-managed channel that must no longer exist remotely.
Disabling, local read-only, provider freeze, detach, and destruction are different states. Do not substitute one for another.
Separate disabled, read-only, and frozen states
- A disabled binding stops normal polling and scheduled work. Queued remote actions re-check the binding and skip; enable it before expecting fresh work.
- The local read-only guard blocks every supported remote mutation while retaining safe observation. It is the protection for shared or unauthorized rooms and applies even to work queued before the setting changed.
- Freeze room and Unfreeze room are audited mutations of the provider's remote frozen/posting state. A Readonly chat channel type is deliberately kept frozen by settings synchronization and cannot be manually unfrozen.
Changing any of these states does not grant an actor permission, make a public room private, repair a credential, or make a stale roster authoritative.
Recover from common failures
Stale or incomplete snapshot
A refresh can show the complete last-known-good room snapshot with its timestamp while a replacement loads. If no complete snapshot exists, the UI reports it as unavailable rather than empty. Do not reconcile membership, batch-act, or infer that players left until a current complete snapshot succeeds.
Permission or operator loss
The Runekist account may have left the room or lost remote operator capability. Keep the binding read-only, have an authorized room owner restore the exact capability, run health again, and refresh. Retry only an action whose current intent and target remain valid.
Invalid credential
Repeated requests cannot repair an invalid server credential. Replace or rotate it through the authorized server operation, verify health without exposing the secret, then resume scheduled work. Runekist Help and action history never need the raw credential or request headers.
Rate limit or provider outage
Wait for the displayed retry time after rate limiting. During a provider outage, preserve the last-known-good snapshot and avoid loops of refreshes or destructive actions. A provider error is not evidence of an empty room or successful change.
Partial or repair-required action
Read the exact action state. A remote mutation can partly succeed—for example, the provider may remove a kicked player before local invited-access revocation finishes. Retry the same audited intent only where the UI supports safe repair; do not create competing actions against a guessed remote state.
Work queued before disabling or freezing
Execution re-checks the active actor, binding lifecycle, enabled/read-only state, policy, target, and required moderation setting. Work that became unsafe is recorded as skipped. After recovery, review current state and create a fresh action if it is still necessary; do not assume old queued work will resume.
Read action history accurately
The rendered history shows the action and state, exact target label where the action has one, the action time, the requested hide window and affected count for message hiding, and the body for a Runekist-authored outbound message. Successful Kick rows can offer Invite again when the current room is mutable.
The screen does not currently promise a visible actor name, full internal reason/provenance, or provider error detail for every row. Use the visible state as the user-facing result and do not infer missing provenance. Support and operator tooling may retain bounded audit fields without presenting sensitive provider responses in the clan UI.
Choose a lifecycle action
Detach from Runekist
Detach stops local monitoring and automation, makes the Runekist account leave the remote room, and preserves the remote channel. It does not remove other members/operators or clear bans and mutes. This is the normal safe choice for an attached, shared, read-only, or otherwise non-deletable room.
Detached managed channels remain in a bounded recovery list. Check remote status verifies whether the exact channel still exists. Reattach rejoins the Runekist account and creates a fresh binding lifecycle; it does not revive the old lifecycle or its queued work. If the provider removed the room, create or attach a replacement instead.
Destroy Total Battle channel
Permanent destruction removes the entire remote channel, including its remote messages and history. Runekist cannot restore it. The control appears only for an eligible channel created and still managed by Runekist—not an attached, shared, protected, or locally read-only room.
The confirmation shows the exact channel URL and requires the exact channel name. Execution re-checks current leadership, lifecycle/successor state, channel identity, eligibility, and operator capability. A provider failure does not report false success; retry or detach after diagnosing it. Destruction is not a shortcut that must first unmute/unban everyone, and it is never the right recovery for an ordinary credential, roster, or operator problem.
Understand privacy and retention
Runekist does not store bodies of observed inbound room messages. It stores bounded operational metadata, a keyed non-readable equality fingerprint, derived mention/count/classification facts, and recognized typed Ancient vault facts. Fingerprints cannot be read as chat text and are not semantic or fuzzy spam detection.
Messages deliberately authored through Send message as Runekist are a different case: their outbound body is stored in the action audit and rendered in action history so the clan can see what Runekist sent. Do not send secrets or personal data that does not belong in that operational record.
Default cleanup windows are different:
| Data | Default retention |
|---|---|
| derived inbound message observations | 30 days |
| typed Ancient vault posts | 365 days; attribution can remain after the short observation expires |
| terminal action audits, including Runekist-authored outbound bodies | 365 days |
| pending or running action audits | retained until they reach a terminal lifecycle rather than deleted as old terminal work |
Operational configuration can change these defaults. Detach and destroy keep bounded lifecycle/tombstone evidence so a delayed job, event, or retry cannot silently recreate management. Neither the room screen nor retention policy is a permanent archive of every remote event.