Confirm the room and payload
Participation is available only when the binding's channel type is Ancient vaults. A Chat or Readonly chat room does not process vault participation even if players discuss vaults there.
Runekist recognizes the stable typed Total Battle payload structure, not prose, localized names, or text typed by a player. A supported vault link contains the expected coordinate/point-of-interest structure and valid coordinates. A supported battle report contains the expected journal/attack structure. Static IDs in the supported Ancient vault family encode levels 5 through 45; Runekist derives the level from that ID rather than trusting a separate displayed value.
If a player writes “level 30 vault at 100:200” as ordinary chat text, it is ignored by design. Ask them to share the supported in-game link or report.
Read participation by reset window
Choose a clan period and open Ancient vault participation. Results are scoped to the one selected room and split the period into Total Battle game- reset windows, not the viewer's local calendar days. A post close to reset may therefore belong to a different row than its local date suggests.
Each window can show:
- the authoritative eligible member count, recognized posters, and members with no recognized post;
- recognized post counts by supported vault level;
- each matched participant's distinct levels and total post count;
- unresolved posters separately; and
- Who didn't post? with a copyable exact member list when coverage is safe.
Provider redelivery of the same remote message does not create a second fact: imports and live processing are idempotent by room and remote message ID. This transport safeguard is different from the participation review trail, where two different messages can still describe the same vault or report.
When a matched participant has more than one recognized post, open Extra vault shares to review and read the rows in time order:
- First share is the participant's first coordinate-vault share in that reset window.
- Same vault repost means the static vault ID, kingdom, x coordinate, and y coordinate all match an earlier share from that participant.
- Additional vault means the later coordinate identity is different. A missing coordinate identity is never grouped with another incomplete post.
- Battle report is a recognized report without coordinate evidence. A later report is labelled Same report repost only when it repeats a nonblank journal identifier.
The trail shows the remote sender, post time, and available coordinate evidence for manual review. It does not identify or reassign the in-game player who created a vault: Total Battle's supported payload does not provide that identity. Review detail is capped at 100 rows across the current report page; when rows are omitted, choose a narrower period or reset window. Aggregate counts still use the complete bounded participation query.
An unmatched poster proves only that the exact remote sender made a recognized post. It does not prove which roster member they are, and it is not silently credited by a similar display name.
Understand eligible-roster coverage
No-post reporting needs a current exact-identity roster. Runekist uses the latest valid immutable Sendbird member-mapping revision. The revision must be current, clan-scoped, and identity-complete.
If neither source is usable, known posts and unmatched posters remain visible, but Who didn't post? is unavailable. Runekist does not guess an eligible population, treat missing identity as absence, or infer membership from a nickname. Refresh collector/roster data before using the report for follow-up.
Diagnose no recognized posts
Check these boundaries in order:
- The selected binding is an Ancient vaults room.
- The selected clan period and game-reset windows include the remote message timestamps.
- Players shared supported typed links or attack reports, not prose mentions.
- The static ID represents a supported level from 5 through 45 and coordinates are valid where required.
- Live observation or the historical import cursor has reached those messages.
“No recognized posts” does not mean nobody discussed a vault. It means no supported typed fact exists in the selected room/window.
Diagnose no eligible roster
If recognized posts exist but no-post coverage is unavailable, check the latest member-mapping revision and its observation timestamp. A revision can be unusable because it is missing, stale, empty, incomplete, or lacks an exact SUID for one or more people. Correct the collector mapping source and refresh; do not copy an unmatched poster into the roster by assumption.
Import older history
Import older history moves backward from the saved room cursor. Each pass is capped at 500 provider messages and reports messages considered, recognized vault posts, existing observations, safely skipped messages, and messages that could not be processed. Run another pass to continue from the older cursor. An exhausted import remains disabled until a deliberate new history path is available.
Imports are duplicate-safe. A previously stored unknown observation can be reprocessed only by fetching its provider payload again; Runekist cannot parse the original body from the database because observed inbound bodies and raw structured payloads are not stored. If the provider no longer returns that message, there is nothing local to reparse.
Historical import never triggers automatic moderation. It records bounded message metadata and recognized typed vault facts only. Observations expire after 30 days by default; typed Ancient vault facts have a separate 365-day default retention window. Configuration can change those operational defaults, so this report is not a permanent archive.