Role added, prefix on. Role removed, prefix off.

What half-done labels cost

The nickname prefix is how your officers read the member list at a glance — who is staff, who is a recruit, who is an ally. When it is applied by hand it drifts: promoted members keep old tags, departed tags linger, and the one officer who did the renaming goes on holiday.

Ping roles have the opposite problem. Members want them, staff have to hand them out, and the queue of "can I get the ZvZ ping" messages never ends — or worse, someone gets Manage Roles just to self-serve, which is how privilege creep starts.

Both jobs are mechanical, which is exactly why a bot should hold them: the prefix follows the role the moment it changes, and the menu hands out only the roles you pre-approved, checked again on every press.

The rules the sweep lives by

Never doubled. `[GG] Name` stays `[GG] Name`, never `[GG] [GG] Name` — and an existing accidental double is collapsed rather than preserved.

Highest role wins. When several mapped roles apply to one member, the prefix comes from the highest role position — an officer who is also a recruit reads as an officer.

Members keep their own names. The bot never fights a nickname a member set for themselves. The one deliberate exception is the approval moment on an application, where an operator has just confirmed their in-game name.

Skips are named. Discord never lets a bot rename the server owner, and hierarchy blocks anyone whose highest role sits above the bot's. The sweep reports each skip with its reason instead of quietly moving on.

Why a menu is security-relevant

A role menu is member-decided with no approval step. So the refusal list is long and absolute: @everyone, bot and integration roles, staff roles, anything carrying Administrator, Manage Guild, Manage Roles, Manage Channels, Ban, Kick, Manage Messages or Timeout — and the guild-member and recruit roles, because guild-member status decides who is taxed and who receives a payout share.

The check runs when you build the menu and again on every press, because a role's permissions can be raised after the menu was built. A menu is never a standing exception to your permission model.

🔘 Pick one is for mutually exclusive labels — "which alliance guild are you". Choosing another swaps it; pressing your current pick clears it. ☑️ Pick many is for ping roles. Both answer with a private copy where your current roles are ticked and green.

One choice, recorded against a version

The mode is one exclusive choice — Off, before the form, or in the thread — rather than two toggles, because two on/off buttons allow a redundant both-on state and cannot show the current selection at a glance.

In-thread mode hard-blocks approval until they agree; deny is unaffected. The review card shows ✅ Agreed (vN) or ⏳ Not yet agreed — approval blocked, so officers see consent at a glance.

Acceptance is recorded against a version number, and re-asking is driven by an explicit Bump version button — the only honest signal, since the bot cannot see that you edited a linked Discord post. Underneath it is a reusable ledger keyed by an opaque policy string, so other features can adopt the same mechanism later.