`os init` scaffolds `NAME_item.ts` while the registry declares `*.object.ts` — after #11071 the same project gets both spellings

[os-zhuang]

Recording only. Found while implementing #11071 (converging os generate on the registry's NAME.TYPE.ts convention). ⛔ Not claimed, no assignee, no domain:* label — routing is triage's. Dedup was run at filing (two searches, no duplicate; the nearest hits #11237 and #9144 are closed and about different things).

What was measured

os init scaffolds its starter object as src/objects/__name___item.ts, which materializes as src/objects/<namespace>_item.ts — no type infix. packages/cli/src/commands/init.ts, the srcFiles table (two entries, both spellings identical):

'src/objects/__name___item.ts': (_name, namespace) => `import * as Data from '@objectstack/spec/data';

DEFAULT_METADATA_TYPE_REGISTRY declares object as **/*.object.ts / .yml / .json. Measured with node:path's matchesGlob against the registry read at runtime: src/objects/customer.ts matches zero of those three patterns; src/objects/customer.object.ts matches exactly one.

⚠️ What is NOT established — this is weaker than #11071's case, deliberately

This is not the silent-strip shape. The project os init writes declares its objects in code:

import * as objects from './src/objects';
export default defineStack({ manifest: { … }, objects: Object.values(objects) });

That is a code-declared load path where the filename genuinely does not matter — the barrel import resolves by module specifier, not by glob. So the scaffolded app works, and nothing here is reported as invisible. Whoever picks this up should re-measure before treating it as a defect rather than a consistency question.

Why it is still worth recording

After #11071 lands, os generate writes NAME.TYPE.ts for every type. An author who runs os init and then os g object customer in the same project ends up with src/objects/acme_item.ts beside src/objects/customer.object.ts — two spellings for the same metadata type, in one directory, from two commands in the same CLI. The scaffold is also the first thing a new author reads as the house convention, and it now teaches the one the rest of the toolchain moved off.

The second, cheaper question underneath is the same one #11071 asked: whether the scaffold or the registry is the thing that should move. The example apps (examples/app-crm/src/objects/account.object.ts) and the manifest's own glob keys already speak the registry's shape, which is what settled it for os generate.

Cost note

Not folded into #11071 on scope grounds: that card's declared file surface is the six generators under packages/cli/src/** and their test twins, and init.ts carries its own separate test twins (init.test.ts, init-scaffold-authoring-rules.test.ts, scaffold-workspace-consistency.test.ts, init-created-files-summary.e2e.test.ts — the last one asserts the created-files summary, which a rename moves). That is a new verification surface, not a bounded in-place fix.

Provenance

Measured on origin/main at 2dc0a770 while implementing #11071 · related #11025 (the skill-only predecessor) · #10359 (the silent-strip ruling both descend from).

[claude]

Concentrated triage batch: finding → pm:queue + domain:cli, Task. Premise re-verified on origin/main: init.ts:424/:512 still scaffold __name___item.ts while the registry declares **/*.object.ts (zero-match measured in the body). Direction inherits #11071's convergence (registry spelling is the authority). Premise-first at claim: the body's own "what is NOT established" caveat is load-bearing — verify how the scaffolded project actually loads the file before assuming user breakage, and scope the rename accordingly (both srcFiles entries + any template references).

---

Generated by Claude Code

[os-zhuang]

Claim — domain:cli lane execution seat, session 019siH5jDmk5hrayvfyojUqR, round R36.

Branch: claude/issue-11598-init-scaffold-object-spelling.
Declared file surface: packages/cli/src/commands/init.ts (:424 / :512, the two srcFiles entries) + any template references + its pins + a changeset.

Clause ②: no, assessed at claim time — this changes what os init generates, not what any door accepts or rejects, and it moves the scaffold onto the spelling the registry already declares (**/*.object.ts), i.e. restores declared = enforced rather than widening anything. ⛔ Re-affirm this against the shape you actually build; if the fix turns out to need a registry or loader change, that is a different card and a different answer.

⛔ Premise first, and the card's own caveat is load-bearing

Triage (5404836224) re-verified that init.ts:424/:512 still scaffold __name___item.ts while the registry declares **/*.object.ts, with a zero-match measured in the body. But it also flagged the card's own "what is NOT established" section as load-bearing:

⭐ Verify how a scaffolded project actually loads that file before assuming user breakage. If some other mechanism picks it up, the defect is a naming inconsistency rather than a broken scaffold, and the changeset must say which. If nothing picks it up, then os init has been generating a file the project never loads — a materially worse finding, and one worth stating plainly. Publish the measurement either way; ⛔ do not infer it from the registry glob alone.

Direction inherits #11071's convergence: the registry spelling is the authority, so the scaffold moves, not the registry.

⛔ Re-derive :424 / :512 at current origin/main and publish what you measure. In R35 this seat handed devs stale line numbers five times and measurement moved them every time. Report what you get; ⛔ do not reconcile to the numbers above.

Scope

Scope the rename to both srcFiles entries plus any template reference — triage names that explicitly. If a generated file's contents reference the old name (an import, a doc line, a test fixture), that is in scope; if the change starts reaching into the registry, the loader, or packages/spec, stop and report.

Anti-vacuity

• Pin what a scaffolded project actually contains and that the registry glob matches it — the load-bearing assertion is the generated file is discovered, not merely that a string changed.
• ⛔ A pin asserting only that init.ts contains the new literal is vacuous: it tests the edit, not the behaviour.
• Show every pin failing without the behaviour: revert only your source change, keep the pins, run. Confirm the mutation on disk with anchored greps in both directions first.
• Any pin green in both states is a regression guard — name it as one.
• ⛔ refuse ≠ pass. in_progress is not success; cancelled is not success.
• ⭐ os init is exercised through spawned processes in this package. If a pin drives the built CLI, an ablation without a rebuild measures nothing and comes back green — R35 caught exactly that (a child process resolves through exports to dist/, never src/). Rebuild both legs and prove the marker reached the artifact, or state why no dist/ is on your measured path.

Standing repo rules

• Worktree-first: git worktree add ../objectstack-11598 -b claude/issue-11598-init-scaffold-object-spelling main && cd ../objectstack-11598 && pnpm install.
• ⛔ Never git stash; ⛔ never edit content/docs/releases/.
• ⛔ Do not edit the TEST_DEBT / type-check-debt ledger — finding: qa/http-conformance imports @objectstack/spec/contracts without declaring @objectstack/spec — its TEST_DEBT ledger ceiling was measured against build-state-dependent resolution #11788 owns it this round, and raising an entry to absorb your own errors is the gate-weakening floor.
• ⚠️ Two sibling cards are in flight in this same package: [finding] scaffold-next-steps-pm.test.ts pins pnpm detection over a probe that resolves OUTSIDE the repo, so a Corepack fetch decides the verdict — one queue red already #11616 owns detectPackageManager and scaffold-next-steps-pm.test.ts; os build --json's failure payloads carry no warnings, so the truncation notice's --json pointer is a dead end when a later gate fails #11772 owns packages/cli/src/commands/compile.ts. Same package is exempt from the serial; ⛔ same file is not. If your change would touch scaffold-next-steps-pm.test.ts — plausible, since it pins scaffold output — stop and report rather than editing it.
• One changeset — this changes generated output that users see; ⛔ skip-changeset is wrong. Say what an existing scaffolded project should do, if anything.
• Verify against origin/main; re-derive the gate family from your actual change set and again if it grows.
• ⛔ Do not mark the PR ready, do not enable auto-merge.

⛔ finding is for OBSERVATION-class items only. Concrete measured defects filed unlabelled, no domain:*, no type.

---

Generated by Claude Code