Problem
A Toolcraft CLI with a root default command treats an unknown bare word as the default command positional argument instead of reporting an unknown command.
Concrete repro from Wire:
Current output after the Wire launcher reexec stack was fixed:
Expected source URL: switch
Run wire --help for usage.
That message comes from Wire's default URL command, not from Toolcraft command routing. It is confusing because switch looks like a command typo, not a source URL.
Expected
Toolcraft should handle this at the router level, likely by offering a default-command routing policy or by diagnosing unknown command-looking tokens before falling through to the default command. For this repro, a better message would be something like:
Unknown command "switch".
Run wire --help for usage.
If there is a close visible command, Toolcraft should keep using its existing suggestion behavior.
Observed implementation detail
findUnknownCommanderCommand currently returns undefined whenever the current Commander node has a default command:
if (current.commands.length === 0 || getDefaultCommanderCommandName(current) !== undefined) {
return undefined;
}That makes all root-level unknown bare tokens eligible for the default command.
Notes
The separate noisy Node stack was caused by Wire's execFileSync reexec wrapper and was fixed in Wire by switching that reexec path to spawnSync and exiting with the child status. This issue is only about the Toolcraft routing/error message behavior.
Problem
A Toolcraft CLI with a root default command treats an unknown bare word as the default command positional argument instead of reporting an unknown command.
Concrete repro from Wire:
Current output after the Wire launcher reexec stack was fixed:
That message comes from Wire's default URL command, not from Toolcraft command routing. It is confusing because
switchlooks like a command typo, not a source URL.Expected
Toolcraft should handle this at the router level, likely by offering a default-command routing policy or by diagnosing unknown command-looking tokens before falling through to the default command. For this repro, a better message would be something like:
If there is a close visible command, Toolcraft should keep using its existing suggestion behavior.
Observed implementation detail
findUnknownCommanderCommandcurrently returnsundefinedwhenever the current Commander node has a default command:That makes all root-level unknown bare tokens eligible for the default command.
Notes
The separate noisy Node stack was caused by Wire's
execFileSyncreexec wrapper and was fixed in Wire by switching that reexec path tospawnSyncand exiting with the child status. This issue is only about the Toolcraft routing/error message behavior.