Found while fixing #10927 (packages/cli/README.md prose). That card's fence is packages/cli/README.md only — this is a different file surface (packages/cli/src/commands/environments/*.ts) and a broader, more invasive fix (exported class renames), so filing separately rather than folding in.
What's wrong
All five command source files under packages/cli/src/commands/environments/ still spell the pre-v5.0-rename os projects command name in places that are not just internal comments — some of it is live, user-facing --help output:
bind.ts — JSDoc says "os projects bind — bind a locally-compiled artifact..."; class is export default class ProjectsBind; the static override examples array has three entries, each starting os projects bind (id argument, then --artifact, --build, or --reseed).create.ts — JSDoc "os projects create — provision a new project."; class ProjectsCreate; four examples entries all say os projects create ....list.ts — JSDoc "os projects list — list projects visible to the current session."; class ProjectsList; three examples entries say os projects list ....show.ts — JSDoc "os projects show (id argument) — show detailed information for a single project."; class ProjectsShow; two examples entries say os projects show ....switch.ts — JSDoc "os projects switch (id argument) — set the active project for this CLI session."; class ProjectsSwitch; two examples entries say os projects switch ....environments.test.ts — imports these five classes by their Projects* names, and its own describe('os projects commands', ...) block title.
oclif prints a command's static override examples verbatim as part of --help. Verified against the built binary at packages/cli HEAD (1b18e1bc82, same tree as #10927's fix):
$ node packages/cli/bin/run.js environments bind --help
...
EXAMPLES
os projects bind (id) --artifact ./dist/objectstack.json
os projects bind (id) --artifact ./dist/objectstack.json --build
os projects bind (id) --reseed
$ node packages/cli/bin/run.js environments create --help
...
EXAMPLES
os projects create --org 00000000-0000-0000-0000-000000000000 --name Staging
os projects create --org $ORG --name Dev --plan free
os projects create --org $ORG --name "Clone" --clone-from (source-id) --no-activate
os projects create --org $ORG --name CRM --artifact ./examples/app-crm/dist/objectstack.json
Both example command lines fail exactly like #10927's README claims did — Error: Command projects:create not found. / Error: Command projects:bind not found. (exit 2, confirmed in #10927's verification). So this is not merely stale internal comments: a user who copy-pastes straight from os environments bind --help hits the same dead command #10927 fixed in the README, sourced from the CLI binary itself rather than from docs.
What's actually fine
The exported default class name (ProjectsBind etc.) has no effect on the registered command id — oclif derives that from the file path (environments/bind.ts maps to environments:bind), confirmed working via --help above. So the class names and the test file's imports are internally-consistent stale naming, not a functional bug on their own — only the examples arrays are user-visible.
Suggested fix
Not fixed here: broader surface than a docs-only prose fix (exported class renames across 5 files plus a test file), no assignee.
Found while fixing #10927 (
packages/cli/README.mdprose). That card's fence ispackages/cli/README.mdonly — this is a different file surface (packages/cli/src/commands/environments/*.ts) and a broader, more invasive fix (exported class renames), so filing separately rather than folding in.What's wrong
All five command source files under
packages/cli/src/commands/environments/still spell the pre-v5.0-renameos projectscommand name in places that are not just internal comments — some of it is live, user-facing--helpoutput:bind.ts— JSDoc says "os projects bind— bind a locally-compiled artifact..."; class isexport default class ProjectsBind; thestatic override examplesarray has three entries, each startingos projects bind(id argument, then--artifact,--build, or--reseed).create.ts— JSDoc "os projects create— provision a new project."; classProjectsCreate; fourexamplesentries all sayos projects create ....list.ts— JSDoc "os projects list— list projects visible to the current session."; classProjectsList; threeexamplesentries sayos projects list ....show.ts— JSDoc "os projects show(id argument) — show detailed information for a single project."; classProjectsShow; twoexamplesentries sayos projects show ....switch.ts— JSDoc "os projects switch(id argument) — set the active project for this CLI session."; classProjectsSwitch; twoexamplesentries sayos projects switch ....environments.test.ts— imports these five classes by theirProjects*names, and its owndescribe('os projects commands', ...)block title.oclif prints a command's
static override examplesverbatim as part of--help. Verified against the built binary atpackages/cliHEAD (1b18e1bc82, same tree as #10927's fix):Both example command lines fail exactly like #10927's README claims did —
Error: Command projects:create not found./Error: Command projects:bind not found.(exit 2, confirmed in #10927's verification). So this is not merely stale internal comments: a user who copy-pastes straight fromos environments bind --helphits the same dead command #10927 fixed in the README, sourced from the CLI binary itself rather than from docs.What's actually fine
The exported default class name (
ProjectsBindetc.) has no effect on the registered command id — oclif derives that from the file path (environments/bind.tsmaps toenvironments:bind), confirmed working via--helpabove. So the class names and the test file's imports are internally-consistent stale naming, not a functional bug on their own — only theexamplesarrays are user-visible.Suggested fix
examplesarrays:os projects ...becomesos environments ..., all five files.os projectsmentions outside the tree listing, none a registered alias #10927 fixed the README (misleading a reader about what currently resolves).describetitle: cosmetic, lower priority — rename for consistency (ProjectsBindbecomesEnvironmentsBind, etc.) if touching these files anyway, but doesn't block theexamplesfix.Not fixed here: broader surface than a docs-only prose fix (exported class renames across 5 files plus a test file), no assignee.