Vetox Command Management — capability reference

What it is

Command Management is two distinct per-server control surfaces kept in two separate stored documents. The system switchboard is 30 boolean toggles deciding which Vetox subsystems run in a server at all. Command Config is the per-command surface: for each individual slash command and subcommand, whether it is enabled, which roles may or may not use it, which channels it works in, prefix-free aliases, auto-delete behaviour and preset moderation reasons. A system toggle governs a whole feature’s runtime; a command config governs one invocable command. Turning Leveling off stops the XP engine entirely; disabling /rank only removes that one command.

The problem it solves

A bot that ships every feature switched on floods a server with behaviour nobody asked for — XP messages, welcome embeds, starboard reposts, log spam. The switchboard makes every subsystem opt-in, so an operator adds exactly the features they want. The per-command layer solves the second-order problem: once a feature is on, its commands still need scoping — a trial moderator who should run /warn-add but not /ban, a fun command that must not fire in the announcements channel, a ticket subcommand restricted to seniors while the rest stays open to the team.

How it works

System toggles. One document per server, three groups — system (20 booleans), ai (2), notifications (8) — every one of the 30 declared false by default at three independent layers: the storage schema, the API’s normalization step (so a server with no document still receives a complete 30-key object of false), and the Bot’s own fallback if Kafka does not answer. A fresh server therefore has every optional subsystem off, confirmed at all three layers independently.

Command Config. One document per server holding an array of command entries, each carrying enabled (defaults true — the opposite polarity of a system toggle), category, and an options object: enabledRoles, disabledRoles, enabledChannels, disabledChannels (each default empty), autoDeleteCommand, deleteWithCommand, autoDeleteReply (each default false), aliases, reasons, and subcommandSettings for per-subcommand overrides.

Where the command list comes from. The Bot’s leader cluster broadcasts its live command registry to the API, which merges it with a deploy-time fallback file and the server’s own stored settings — so the dashboard’s command list can never drift from what the Bot actually has registered, and it never lists a command the Bot has not confirmed it runs.

Runtime enforcement, checked in order on the slash path: is the command disabled; is the server or the invoking user blacklisted; does an enabledChannels list exist and exclude this channel; is this channel in disabledChannels; do the invoker’s roles pass enabledRoles / disabledRoles; then — for a subcommand, applied only after every command-level check passes — the same channel and role checks again at the subcommand level; then the per-command cooldown.

The prefix-free text path runs a parallel check. A message starting with the server’s configured prefix character is ignored outright — shortcuts are plain messages. The first word of a plain message is matched, lowercased, against the server’s own stored aliases first, and only then against the command’s built-in default alias, before the same enable/role/channel/blacklist/ cooldown gates apply. See the Commands reference for exactly which 68 of 71 command files support this path.

Preset reasons. A dropdown of canned justifications exists on exactly five commands — ban, mute-text, mute-voice, warn-add, timeout — of which four also accept a duration value.

What is configurable

The 30 system toggles — all default false

Per-command settings

Tier availability

Neither surface carries a tier gate — every server can toggle all 30 systems and configure every command from Starter. What is gated separately are the features certain toggles switch on: the two AI toggles require Black, Anti-Raid requires Basic, and the eight notification toggles require Basic — gates on the destination feature, never on the toggle mechanism itself.

Commands

Neither surface has a slash command of its own — both are dashboard-only. What they govern is the full command set documented on the Commands reference: 70 top-level slash commands plus one context-menu command, three of them carrying 22 subcommands between them.

Dashboard surface

Setup renders 41 module cards across 11 categories. Thirty are the persisted toggles above; the other 11 are always-on cards with no stored state at all — Overview, Setup, Commands, AI Usage, Auto-Mod, Moderation Tools, Giveaways, Embed Messages, Backup, Access Control and Dashboard Watcher. See the Server Setup reference for the full 41-card breakdown.

Permissions required

Reaching either surface requires an authenticated session plus Discord Administrator or guild ownership — the same baseline covered in full on the Permissions reference. No Discord permission is required by Vetox itself to store the configuration; enabledRoles grants the command, it does not grant Vetox the Discord permission the command’s action requires.

What it connects to

• Governs every system feature — each toggle name maps directly to that feature’s own runtime: leveling to the Leveling engine, tickets to Tickets, serverStats to Server Insights, and so on for all 20.
• Depends on the Bot’s live command registry, so the per-command surface cannot list a command the Bot has not itself confirmed it runs.
• Feeds Dashboard Watcher — every toggle flip and every command change is recorded in the server’s audit trail, with subcommand changes attributed to the parent command’s name.
• Gates the notification pollers and the reminder poller on the API side, since those run on a schedule with no per-event Bot gate to protect them otherwise.

Who it is for

Every server that installs Vetox passes through the switchboard, because the bot ships inert. It matters most to large servers that want a handful of features and none of the rest, and to any server with a delegated moderation team, where per-command role scoping is the difference between handing out Administrator and handing out one command.

Practical use cases

1. A fresh install. Vetox joins and does nothing until the owner switches on Welcomer, Leveling and Logging and saves once.
2. Trial moderators without Discord permissions. Add a Trial Moderator role to enabledRoles on /warn-add and /timeout only — they can run those two commands without holding Manage Messages or Moderate Members anywhere in the server.
3. Splitting a ticket team. Keep /ticket close open to all support staff while restricting /ticket merge to seniors via its own subcommand settings.
4. Keeping fun commands out of serious channels. Add the announcements channel ID to disabledChannels on a game command.
5. A prefix-free shortcut. Set b as a stored alias for /ban; a moderator then types b @user spam as a plain message and the ban runs under the exact same gates.

How it compares

Every general-purpose bot needs some form of module toggling; the depth of per-command scoping on top of it is where the category diverges sharply.

Dyno’s closest equivalent bundles module access with numeric limits that mostly require payment to remove, and Carl-bot’s per-command control is a simple enable/disable rather than a role-and-channel matrix. Vetox’s per-command layer — role, channel, alias and preset-reason control together, with no numeric ceiling on any of them and no tier requirement — is a materially deeper scoping model than either, available in full from the free Starter tier.