Audit the modern SIR admin command tree, shipped command nodes, and the permission differences from Legacy.

Main admin command

Modern SIR declares one top-level administrative command in plugin.yml:

commands:
  sir:
    permission: sir.admin

The plugin then expands that into subcommands in MainCommand:

Admin permission tree

Permission	What it unlocks
`sir.admin`	Access to the root `/sir` command
`sir.admin.*`	All admin subcommands below
`sir.admin.modules`	Module state management
`sir.admin.about`	Version and runtime info
`sir.admin.reload`	Reloading config and runtime state
`sir.admin.help`	Help output
`sir.admin.commands`	Command provider state management
`sir.admin.support`	Support link output
`sir.admin.migrate`	Migration commands

Command	What it does
`/sir`	Shows the main help output
`/sir about`	Shows plugin, server, and Java details
`/sir modules`	Opens the module GUI on supported versions, or lists / manages modules from CLI
`/sir modules [module] [state]`	Changes a module's enabled state
`/sir commands`	Opens the provider GUI on supported versions
`/sir commands [provider] [state]`	Changes a provider's enabled state
`/sir reload`	Reloads runtime data and language files
`/sir support`	Prints the support link
`/sir migrate [Essentials/SIR]`	Runs a supported migration routine

The modern branch defines its command providers with commands.yml files inside command/*.

Command	Source	Aliases	Base permission
`/announce`	`announcements` module	`announcer`, `announcements`, `announcement`	`sir.announce`
`/chat-view`	`channels` module	`chatview`, `chat-toggle`, `chattoggle`, `ctoggle`	No explicit node declared in the shipped YAML
`/clear-chat`	`clear-chat` provider	`clearchat`, `cc`, `clear`	`sir.clear-chat`
`/chat-color`	`color` provider	`chatcolor`, `color`	`sir.color`
`/ignore`	`ignore` provider	`ig`	`sir.ignore`
`/message`	`message` provider	`m`, `msg`, `tell`	`sir.message`
`/reply`	`message` provider	`r`	`sir.reply`
`/mute`	`mute` provider	none	`sir.mute`
`/tempmute`	`mute` provider	`temp-mute`, `tmute`	`sir.temp-mute`
`/unmute`	`mute` provider	none	`sir.unmute`
`/check-mute`	`mute` provider	`cmute`, `checkmute`	`sir.check-mute`
`/nick`	`nick` provider	`nickname`	`sir.nick`
`/print`	`print` provider	`raw-message`, `raw-msg`, `rawmsg`	`sir.print`
`/chat-settings`	`settings` provider	`settings`, `chatsettings`, `csettings`, `c-settings`	`sir.chat-settings`

Some providers also generate permission nodes from their sub-commands section:

Parent command	Derived subcommand nodes you should expect
`chat-color`	`sir.color.black`, `sir.color.bold`, `sir.color.gradient`, `sir.color.reset`, and so on
`nick`	`sir.nick.other` is explicitly declared for editing someone else's nick
`print`	`sir.print.targets`, `sir.print.chat`, `sir.print.action-bar`, `sir.print.title` when you use the default blank subcommand mapping
`announce`	The subcommand map is declared, and the effective subcommand permission behavior is derived by the command system from the provider data

When the YAML leaves a subcommand value blank, the loader derives it from the base permission plus the subcommand key.

Modern SIR persists runtime command state to commands/states.yml:

providers:
  message:
    enabled: true
    commands:
      message: true
      reply: true

This matters because the state file is not just a provider toggle. It also stores per-command override state inside that provider.

The module equivalent looks like this:

modules:
  announcements:
    enabled: true
  moderation:
    enabled: true

If a command seems to be missing after startup, inspect commands/states.yml before assuming the jar failed to load.

This is one of the most important migration pain points.

Legacy node	Modern node	Why it matters
`sir.clearchat`	`sir.clear-chat`	Dash-separated naming in Modern
`sir.chatcolor`	`sir.color`	Provider renamed from feature-style naming to provider naming
`sir.chatview`	No explicit shipped node in the modern module YAML	Needs manual audit if you locked this command previously
`sir.mute.perm`	`sir.mute`	Simpler permanent mute naming
`sir.mute.temp`	`sir.temp-mute`	Modern tempmute naming
`sir.checkmute`	`sir.check-mute`	Dash-separated modern naming
`sir.announcer.*`	`sir.announce` plus subcommand-derived behavior	Announcement command structure changed
`sir.admin.update`	not present in Modern `plugin.yml`	Legacy update command node does not carry over

If your permissions plugin has explicit grants, build a migration checklist for nodes before you swap jars.

For production servers, a healthy permission model usually looks like this:

grant sir.admin.* only to trusted staff
grant player-facing nodes individually, such as sir.message, sir.reply, sir.ignore, or sir.chat-settings
treat sir.print* and sir.announce* as elevated staff tools
audit derived subcommand nodes if you want fine-grained color or print access

If you are still on Legacy, compare this page with Legacy Branch before migrating.

Use these pages when you want the command family behavior itself, not just the top-level permission tree: