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]].