---
name: unknown-chanmode-letter-is-gt
description: "Use '>' as the guaranteed-unknown mode letter in tests (channel AND user modes), not a real letter"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 3d08dabd-56e5-4be2-bfbc-65c9d16999b4
---

In leveva tests that assert a mode letter is **unknown** — for either a channel mode
(`ChanMode::try_from(...) == Err(UnknownMode(...))`) **or a user mode**
(`UserMode::try_from(...) == Err`, a `MODE <nick> +<x>` → `501 ERR_UMODEUNKNOWNFLAG` case, or the
"unknown letter" arm of a umode proptest) — use the letter `'>'`.

**Why:** `>` is never used as a mode by any IRC daemon. charybdis uses it as the example mode
letter for a *non-existent* mode in its example extension modules, so it is the canonical
"guaranteed unknown" placeholder. Picking an ordinary unused alpha letter is fragile — a future
slice can claim it for a real mode and silently break the assertion. This bit us in slice 252:
several umode tests used `'z'` as their unknown example, then operwall claimed `+z` and they broke
(`unknown_flag_gives_501_and_no_state_change`, `mixed_known_and_unknown_*`, `user_mode_char_round_trips`,
and the `LETTERS` alphabets in `usermode_proptest`/`bot_mode_proptest`). User then made the rule
explicit: use `>` for umode unknowns too.

**How to apply:** for the negative/unknown case write `ChanMode::try_from('>')` /
`UserMode::try_from('>')` / `MODE <nick> +>`; reserve real letters for the positive round-trip
cases. See `leveva/src/mode.rs` `chan_mode_char_round_trips`/`user_mode_char_round_trips`. Related:
[[leveva-noctcp-and-flag-mode-wiring]], [[leveva-user-mode-wiring]].