riverctl: `debug bans` does not show whether a ban still enforces

[sanity]

Problem

riverctl debug bans <room> prints every ban with banned_user_id, banned_by_id and banned_at_secs, but gives no indication of whether the contract still enforces that ban.

Since deputy ban authority (#410), a ban can be present in state and completely inert. BansV1 computes enforcement separately from storage: MembersV1::check_banned_members only collects a ban's target (and their downstream subtree) when MembersV1::is_ban_authorized(ban.banned_by, ban.ban.banned_user, …) returns true at the time state is applied. That predicate is re-evaluated against current state, so a ban stops enforcing when any of these later become true:

• the banner's deputy authority was revoked (their deputizer removed them from deputies);
• the banner was pruned or left, so banner_is_member is false and the deputy-derived branches (steps 3 and 5) no longer grant;
• the banner's deputizer left, so the banner is no longer a deputy of a genuine invite ancestor of the target;
• the target has since deputized the banner, tripping the step-4 guardrail (and no absolute grant applies).

A moderator reading debug bans sees the ban listed and reasonably concludes the member is banned. They may well be back in the room.

Why it matters more now

#470 adds member deputized-by, so a moderator can now discover that nobody has deputized member X. What they still cannot see is the consequence: every ban X issued is dead. The two halves of the picture are split across commands, and only one of them exists.

Suggested fix

BansV1::ban_is_enforcing is already pub (common/src/room_state/ban.rs). Add an enforcing: bool to BanInfo in cli/src/commands/debug.rs, populate it from that predicate, and surface it in both the human and -f json branches. Mark the non-enforcing ones clearly in the human output, since that is the case a moderator needs to notice.

Worth considering alongside: a short reason for a non-enforcing ban (banner absent / authority revoked / guardrail), which is the information that makes it actionable.

Notes

Found while reviewing #470 (deputy-status read commands). Deliberately left out of that PR: it is ban status rather than deputy status, and it changes an existing command's output shape.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-07-29T16:13:11.509964452+00:00
Issue hash: ad920727

Value Assessment

Confirmed: the issue is fully accurate and still unaddressed. debug bans (cli/src/commands/debug.rs:341-358) still only surfaces banned_user_id/banned_by_id/banned_at_secs, with no call to BansV1::ban_is_enforcing (common/src/room_state/ban.rs:250), which is indeed pub and ready to use. The fix is exactly as scoped: add an enforcing: bool field, call the existing predicate, and branch the human/JSON output.

This is a small, low-risk, well-scoped CLI/observability fix — pure additive display logic touching only cli/src/commands/debug.rs, no contract/delegate WASM, no migration, no wire format change. It doesn't block other work, but it directly complements #470 (member deputized-by), which this issue explicitly says was deliberately deferred from that PR. Without it, the deputy-authority feature (#410) has a genuine trust gap: a moderator can see a ban listed and reasonably but wrongly assume it's active, when deputy-revocation or banner-departure has silently made it inert. That's a real correctness-of-perception bug in a moderation tool, not cosmetic — a moderator could leave a room believing someone is banned when they can freely rejoin.

Impact is moderate rather than urgent: only affects users of riverctl debug bans (a power-user/moderator diagnostic path, not the main UI), and there's no evidence of user complaints or incidents tied to it yet — it was self-discovered during #470's review. There's no time pressure or external deadline. Given the low implementation cost (an afternoon's work, one file, straightforward test with BansV1/MembersV1 fixtures) versus real value (closes a trust gap in ban enforcement visibility, pairs naturally with #470), this is a good, cheap, well-justified fix — reasonable to pick up opportunistically but not urgent enough to preempt higher-severity work.

Cost Assessment

This confirms the issue is still fully actionable — ban_is_enforcing exists exactly as described, and debug.rs's Bans branch builds BanInfo without it.

Assessment

This is low-to-moderate cost and the code matches the issue description exactly, so no rethinking is needed. BansV1::ban_is_enforcing(ban, members_by_id, member_info, owner_id, owner_vk) (common/src/room_state/ban.rs:250) is already pub and takes exactly the inputs available at the Bans match arm in cli/src/commands/debug.rs:337-380 (room_state.members, room_state.member_info, plus owner_id/owner_vk derivable from room_state/owner_vk already in scope). The main work is building members_by_id: HashMap<MemberId, &AuthorizedMember> from room_state.members (a one-liner, likely already done elsewhere in this file or in MembersV1/BansV1 helpers — worth checking for a reusable constructor before hand-rolling it), adding enforcing: bool (and optionally a reason string) to the BanInfo struct, populating it per-ban, and updating both the JSON serialization (automatic via serde) and the human-readable println loop to flag non-enforcing bans distinctly (e.g. a suffix marker).

Scope is a single file (cli/src/commands/debug.rs), touching one struct and one match arm — no contract/delegate WASM changes, no migration entry needed since this is CLI-only display logic reading existing state. Complexity is low: the enforcement predicate already encapsulates all the tricky logic (deputy revocation, pruned banner, guardrail cases); the CLI just calls it per ban. The "short reason" stretch goal mentioned in the issue is somewhat more work, since ban_is_enforcing returns only a bool — to get a human-readable reason (banner absent / authority revoked / guardrail) would require either duplicating its internal branching or refactoring it to return an enum/reason, which is a slightly bigger, more careful change touching the ban.rs semantics rather than just CLI plumbing; that part could reasonably be deferred or done as a simple heuristic re-check in the CLI without touching common/.

No external dependencies (no network calls, no signups, no coordination) — this is pure local code reading state already fetched via api.get_room. Risk is minimal: it only changes the output shape of one CLI command (adds a field/marker), doesn't touch contract logic, verification, or wire format. Testing is straightforward — likely a few unit/integration tests constructing a room state with an enforcing and a non-enforcing ban (e.g. via deputy revocation) and asserting the CLI's BanInfo/JSON output reflects enforcing correctly; existing test fixtures for ban authorization (referenced in ban.rs's round-3/4 comments) probably already provide reusable scenarios. Overall: a small, well-scoped, low-risk change — a few hours of work including tests, with the optional "reason" field adding modest additional effort if pursued.

---

Generated by issue-prioritizer