Found while implementing #10967 (environments/*.tsos projects → os environments) — same defect class, different files, unrelated topic history, so filing separately rather than folding in.
What's wrong
Three commands live at the root of packages/cli/src/commands/ (no topic directory), so oclif's pattern-strategy loader (processCommandIds in @oclif/core) registers them under their bare file name — register, whoami, logout. But their static override examples (live, user-facing --help output) and exported class names both spell a os auth <cmd> shape that has never resolved:
| File | Registered id (real) | examples claim | Class name |
|---|
register.ts:66-68 | register | os auth register (×3) | AuthRegister |
whoami.ts:12-14 | whoami | os auth whoami (×3) | AuthWhoami |
logout.ts:12 | logout | os auth logout (×1) | AuthLogout |
Verified against the built CLI at this tree's HEAD:
$ node packages/cli/bin/run.js auth whoami --help
› Error: Command auth:whoami not found.
$ node packages/cli/bin/run.js auth register --help
› Error: Command auth:register not found.
$ node packages/cli/bin/run.js whoami --help
Show current session information
USAGE
$ os whoami [-u <value>] [-t <value>] [-f json|table|yaml]
A user who copy-pastes os auth whoami (or register/logout) straight out of --help hits a dead command — the same shape #10927 and #10967 both fixed for other topics, sourced from the CLI binary itself.
What's actually fine
The class name has no effect on the registered id (file-path-derived, confirmed via --help above and by reading processCommandIds in the installed @oclif/core's lib/config/plugin.js) — so AuthRegister/AuthWhoami/AuthLogout are internally-consistent stale naming, not a functional bug on their own. login.ts is clean — its examples already say $ os login (no stale auth prefix), so it is not part of this card.
Suggested fix
Same three-part shape as #10967:
Not fixed here: out of scope for #10967's dispatched file surface (packages/cli/src/commands/environments/* only). No assignee.
Found while implementing #10967 (
environments/*.tsos projects→os environments) — same defect class, different files, unrelated topic history, so filing separately rather than folding in.What's wrong
Three commands live at the root of
packages/cli/src/commands/(no topic directory), so oclif's pattern-strategy loader (processCommandIdsin@oclif/core) registers them under their bare file name —register,whoami,logout. But theirstatic override examples(live, user-facing--helpoutput) and exported class names both spell aos auth <cmd>shape that has never resolved:examplesclaimregister.ts:66-68registeros auth register(×3)AuthRegisterwhoami.ts:12-14whoamios auth whoami(×3)AuthWhoamilogout.ts:12logoutos auth logout(×1)AuthLogoutVerified against the built CLI at this tree's HEAD:
A user who copy-pastes
os auth whoami(orregister/logout) straight out of--helphits a dead command — the same shape #10927 and #10967 both fixed for other topics, sourced from the CLI binary itself.What's actually fine
The class name has no effect on the registered id (file-path-derived, confirmed via
--helpabove and by readingprocessCommandIdsin the installed@oclif/core'slib/config/plugin.js) — soAuthRegister/AuthWhoami/AuthLogoutare internally-consistent stale naming, not a functional bug on their own.login.tsis clean — its examples already say$ os login(no staleauthprefix), so it is not part of this card.Suggested fix
Same three-part shape as #10967:
examplesarrays:os auth register→os register,os auth whoami→os whoami,os auth logout→os logout(7 occurrences total across the three files).AuthRegister→Register,AuthWhoami→Whoami,AuthLogout→Logout(or whatever the next dev judges most consistent with this package's naming — no test file imports these three by name, so there's no test-import fallout to carry).os projectsin examples, class names, and docstrings — leaks into live--helpoutput #10967'senvironments/*.ts) — only theexamplesarrays and class names are stale.Not fixed here: out of scope for #10967's dispatched file surface (
packages/cli/src/commands/environments/*only). No assignee.