CLI Dispatch: rationale

A catch-all dispatcher reads "anything I do not recognise" as "something to fetch or run". That makes the set of inputs that cause network access and code execution unbounded: every misspelling, every command from a different version of the tool, and every command meant for a sibling tool qualifies.

An error costs the user one retry. A wrong guess can cost a download, a build, a run of code nobody reviewed, or, in the best case, a confusing message about a package that does not exist. The asymmetry is why CD-1 makes the unknown command an error and CD-2 forbids acting before the command is known.

When a tool ignores input it does not understand, nobody can tell whether a flag did something, did nothing, or does something undocumented. A GUI launcher that accepts and drops --reset looks identical to one that reset settings. Rejecting stray input is a cheap proof that the documented surface is the whole surface. CD-16 closes the other side: whatever dispatches must also appear in help.

Scripts and agents cannot see what a human "meant". They see an exit code and stderr. A stable exit code 2 plus a did-you-mean line is something they can act on; a successful run of the wrong package is not.

A wrapper that forwards everything inherits every catch-all below it, and one that silently does nothing makes failure look like success. Naming the tool that does implement a command keeps the user moving and keeps the wrapper honest about its scope.

Deprecation warnings that never become errors leave implicit behaviour in place forever: users learn to ignore the warning, and new scripts keep depending on the old form. A dated changeover at the next major version is what actually removes the behaviour, and semantic versioning already tells users that a major version may break them. No opt-out is offered because there is nothing to preserve: most packages do not care whether they were invoked implicitly or explicitly.

The timeline in CD-15 gives users a warning release before the break, and the fixed message shape in CD-13 means the warning always contains the exact replacement command, so fixing a script is a copy-paste. Keeping --strict accepted after the switch (CD-14) means scripts that opted in early never break.

Implicit or natural-language dispatch fits tools whose name is a verb. install foo, open foo and make target read as sentences: the tool name is the verb and the leftover token is its object. A tool named with a noun, such as git, cargo or redub, puts the verb in the first-argument slot instead. When that slot is filled with an object, as in redub foo, the command has no verb, and the user has to guess whether foo is a verb or an object. That guess is the mental-model violation, and it is the same guess that turned dubx search into a fetch. Whether a name is a verb or a noun is decided by the role it plays for the people who use it, not by its spelling or origin. dub looks like an English verb, but to downstream developers it is a noun: the tool they invoke, with verbs as its subcommands (dub build, dub run).

So CS-10 recommends the resolver style only for verb-named tools, and the strict style with verb subcommands for noun-named ones; CS-9 makes that a single decision for the whole tool.

Implicit resolution is not always wrong; a universal install <thing> that searches several package managers can be genuinely helpful. It is wrong when it is silent. CLI Styles keeps strict as the default and lets other styles exist only under a contract that shows the resolution, asks before acting on ambiguity, and never fetches or runs silently.