`rs gain grant Saul` failed with "Selector matched multiple records. Suggestions:
Saul, cu_a28...33ab5c, Saul, cu_5a5...b6add3." Nicknames are not unique — one
person re-verifying from a new browser produces a second verified record with the
same name — so an exact nickname match can legitimately return several records,
and the shared resolver refuses on ambiguity.
That refusal is correct for deter, kick, and verify, where acting on the wrong of
two plausible targets is a moderation mistake. It is wrong for gain: granting a
volume ceiling to the wrong account belonging to the same person is recoverable.
So the disambiguation is local to this command and resolvers.js is untouched.
Order of preference on an exact match with several hits:
1. The account that is currently online, since that is who the admin is reacting
to. Sockets are deduped to user ids first, so extra tabs do not matter.
2. Otherwise the first stored record.
Either way the reply says which happened and how many accounts shared the name.
A selector with no exact match still goes through the shared fuzzy resolver, so
typo tolerance and the existing error text are unchanged.
Also adds `rs gain help`, which lists the subcommands and explains the selector
and the online-wins rule. The previous unknown-subcommand fallback listed the
subcommands inline; it now shares the same help text.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds a `fun` category to the operator command registry, reachable identically
from site chat and Discord:
- text: bonk, hug, slap, 8ball, roll, coin, ship, rate, uwu, wanted
- counters: bonkboard, pet, snitch
- hardware: honk, boo, spin, disco, vibecheck
Supporting pieces:
- `permission: 'public'` in the registry. The dispatcher previously decided
non-admin access with a hardcoded chain of `action !== '...'` comparisons, so
every new public command needed a dispatcher edit. That chain is replaced by a
registry lookup plus SELF_GATED_ACTIONS, which names the commands that enforce
their own permissions internally (goal/reason are read-public write-admin;
verify/deter reject non-lockdown-admins themselves). Existing behavior for
every pre-existing command is unchanged.
- `cooldowns.js`, a per-actor per-command in-memory gate. Site chat's own rate
limit is per-socket-per-message and does not bound a specific command, so
without this one person could turn `rs honk` into a siren. Site chat rebuilds
its router per message, so the gate is created at module scope there and
injected.
- `funStatsService`, a small JSON store for the persistent tallies. Counters are
keyed by an actor key spanning transports (`user:<id>` / `discord:<id>`), and a
Discord id has no row in `users`, so `user_feature_state` could not hold them
without violating its foreign key.
Safety notes:
- `issueCommand` is the raw rover transport and performs none of the ownership,
deterrence, or private-safety checks the socket `command` handler applies, so
honk and spin re-check `canDrive` themselves and spin re-applies
`applyPrivateDriveSafety`. Both are therefore site-chat only: a Discord message
has no socket and can never satisfy those checks.
- `boo` speaks a canned taunt rather than caller-supplied text, so it cannot
become an unmoderated TTS channel aimed at whoever is nearest a rover.
- `disco` obeys the existing room-light lock and the homeAssistant feature gate.
- The whole fun category is suspended in lockdown mode.
- Mute and deterrence already stop command-shaped chat before the router runs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Admins can now run 'rs gain list|grant <vip>|revoke <vip>' from web chat or
Discord. Grant matches only against the verified list and revoke only
against current holders, so a nickname shared with an unverified visitor
reports not-found rather than resolving to someone ineligible. The action
joins the moderation set so lockdown narrows it to lockdown admins.
Also extracts the ceiling math into audioLevelsService/gainMath.js and
covers both it and the command with node:test suites.
Co-Authored-By: Claude <noreply@anthropic.com>
legop3