[finding] the default/local-dev environment id has three spellings — `proj_local`, `env_local` and `default` — and one consumer deliberately accepts two of them

[zhuangjianguo]

Filed unassigned and ungraded by the domain:skills dev seat while executing the ruled #12747 / #12748 convoy (PR #13364). Out of scope for that PR, which is docs-only; recorded rather than fixed.

Nothing is broken at runtime that this seat measured. This is a vocabulary-residue finding of the same family as #12747.

Measured on main (merge base e5ed94343, non-test sources under packages/)

The id stamped for the local / default environment is spelled three different ways, in three different packages:

Spelling	Site
proj_local	packages/runtime/src/standalone-stack.ts:567 — cfg.environmentId ?? process.env.OS_ENVIRONMENT_ID ?? 'proj_local'
proj_local	packages/metadata/src/plugin.ts:903 — this.options.environmentId ?? 'proj_local'
default	packages/runtime/src/package-state-store.ts:25 — const DEFAULT_ENVIRONMENT_ID = 'default', used as the same fallback slot at :32
env_local and proj_local	packages/cloud-connection/src/cloud-connection-plugin.ts:177

The last one is the sharp one, because it is not drift that nobody noticed — it is deliberate, and the comment above it says so:

// The CLI's local-dev defaults ('env_local' / 'proj_local')
if (fixed && fixed !== 'env_local' && fixed !== 'proj_local') return fixed;

That is one consumer branching on two spellings of the same sentinel. Whatever produced env_local and whatever produced proj_local are both treated as live.

Why it is worth recording

The v5.0 project to environment rename took no aliases — deliberately, and PR #13364 has just written that decision and its reasons into ADR-0006 v4 where four inbound pointers had been sending readers to find them. A tolerated dual spelling of the default environment id is the same shape one layer down: two forms are correct, so every new consumer has to decide which to emit or which to accept, and there is nothing to tell it that one of them is residue.

The three-way split also means there is no single source for this value. A reader cannot answer "what is the default environment id" from any one file, and the two packages that pick proj_local and the one that picks default disagree about it.

⚠️ What this finding is NOT

• ⛔ Not a claim that the rename is incomplete on the surfaces it covered. These are opaque id values, not the vocabulary surfaces the rename named. The CLI command group, the /api/v1/cloud/environments routes, the X-Environment-Id header and OS_ENVIRONMENT_ID all carry a single spelling — measured while writing that section, and it explicitly scopes its claim to those surfaces.
• ⛔ Not a contradiction of the ADR-0006 v4 section PR docs(adr): record the v5.0 project to environment rename in ADR-0006, and land its inbound pointers #13364 adds. That section's What this section does not claim paragraph already fences off exactly this: it does not claim the string project is absent from the tree.
• ⚠️ The producer of env_local was not located by this seat. The comment attributes it to "the CLI's local-dev defaults", but a grep of packages/cli non-test sources for the literal did not find it emitted there. Whoever takes this establishes where it comes from before deciding whether it is live or dead — it may be a cloud-side or historical value, in which case the fix is deleting one arm of that condition rather than unifying three constants.

Re-check

grep -rn --include='*.ts' "proj_local" packages/ | grep -v node_modules | grep -v '\.test\.'
grep -rn --include='*.ts' "env_local"  packages/ | grep -v node_modules | grep -v '\.test\.'
grep -rn --include='*.ts' "DEFAULT_ENVIRONMENT_ID" packages/ | grep -v node_modules | grep -v '\.test\.'

⛔ Do not re-check with a bare project grep — it answers non-zero on the npm/monorepo sense and on domain fixtures modelling a customer's own project object, neither of which is this. Reverse-check any zero against a literal known present in the same population.

Duplicate check

Searched this round, targeted. Nearest neighbour is #10967 (closed) — same family, different subject: os projects leaking into CLI --help text. ⛔ No open card covers the id-value spellings. ⚠️ The search instrument answered non-empty on that query, so the near-zero is a reading rather than a broken probe; not exhaustively deduped outside this one targeted search.

Refs

• [finding] ADR-0006 is what AGENTS.md and three ADR banners cite for the v5.0 project → environment rename — and its body does not contain that rename, nor does the changeset they name still exist #12747 / [finding] ADR-0006 is linked under two filenames — ADR-0007 and ADR-0008 point at the Superseded v3, everyone else at the Accepted v4, and the link checker is green either way #12748 / PR #13364 — where this was measured; that PR records the no-alias decision but deliberately does not touch code
• ADR-0006 leftovers in @objectstack/client: client.project() / ScopedProjectClient / two test titles still speak the pre-v5.0 noun #12882 — a separate project-spelled SDK surface, adjudicated on its own card