os init and os generate still emit the annotated-literal `.object.ts` shape — item ① of ruling 5644350230, the sibling half of #17418 (and the ruling under-names it: generate.ts too)

[os-warren]

Filed by domain:spec execution seat 2, session session_01UDXER3sdqfeVYpEWZs5mZx, 2026-09-22T11:1xZ. ⛔ Unlabelled and unrouted — an execution seat files, triage grades and routes. Suggested lane: domain:cli, because that is the lane the ruling itself names.

This is half of a ruled change, and the ruling drew the line

Ruling 5644350230 (director seat, decision batch #122 item 1, maintainer 「同意」 2026-09-12) makes ObjectSchema.create({ … }) the one authorised shape for a *.object.ts. Its item 4:

The taker declares the file surface; if it crosses packages/cli and packages/spec / scripts, the cli half is a sibling PR by the domain:cli seat, ⛔ not a rider across lanes.

The spec/scripts half — item ② (the gate refuses the non-factory shape by name) and item ③ (census and convert in-repo literal-shaped object files) — is card #17418 / PR #19720, which opens 「Part of #17418」 rather than Fixes precisely so the card stays open for this half. This card is item ①.

⚠️ The ruling UNDER-NAMES its own item ①

Item ① names only init.ts TEMPLATES. Measured: there is a second emitter, and it carries a declared coupling to the first.

site	what it emits
packages/cli/src/commands/init.ts:649 and :744	the two TEMPLATES entries for src/objects/__name___item.object.ts, both emitting a Data.ServiceObject-annotated object literal
packages/cli/src/commands/generate.ts:99	os generate object emits the SAME annotated literal — ⛔ named nowhere in the ruling

generate.ts's own docblock declares the coupling, quoted:

「#9666 took it once for the os init templates, and this emits the SAME value with the same explanation, so the two doors an author can arrive through agree. If that template value ever moves, this one moves with it.」

⇒ converting init.ts alone breaks the parity that docblock asserts. Both move together or neither does.

Pins that move with them

• packages/cli/test/generate-refuses-unparseable-name.test.ts:255 — asserts the emitted source contains a Data.ServiceObject binding line.
• packages/cli/test/generate-emission-parses.test.ts:148 — same assertion, plus its docblock worked example at :14.
• packages/cli/test/scaffold-emission-typechecks.test.ts:26 — its docblock states the repair is Data.ServiceObject.
• packages/cli/test/init.test.ts:493 — reads the scaffolded my_app_item.object.ts; re-check its assertions against the new bytes.
• packages/cli/test/init-template-comments-self-contained.test.ts — ⚠️ the templates carry a long authored org-wide-default comment block that must survive the rewrite.

Docblock only, ⛔ no behaviour change: packages/cli/src/utils/emitted-source-parses.ts:14 — the utility is shape-agnostic (it asks the TypeScript parser whether the emitted bytes parse); only its worked example names the literal shape.

Coupled, probably no edit: scripts/sync-scaffold-emission-policy.mjs (its POLICY_SOURCE is packages/cli/src/commands/init.ts) syncs pnpm/typescript version ranges, ⛔ not declaration shape — but re-run it, because create-objectstack's bundled note.object.ts is already the factory shape, so the two scaffolders would finally agree.

Docs: content/docs/deployment/cli.mdx:1323.

⭐ The changeset obligation is THIS card's, not the spec half's

The ruling asks the changeset to state the one mechanical user rewrite (wrap the literal). That rewrite is something a user experiences, and the user-facing change is item ① — os init and os generate emitting the factory shape from a published package. The spec half publishes nothing (scripts/ sits in no package directory; measured, 77 manifests censused for files[] escape hatches, zero found), so it carries skip-changeset. ⇒ the ruling's changeset obligation attaches here.

Ordering, measured rather than assumed

⛔ There is no blocking dependency in either direction, and this was measured rather than guessed. check:keyed-text-bounds selects its population by filename suffix (walkObjectFiles over *.object.ts, repo-wide minus SKIP_DIRS): 112 files on origin/main, ZERO under packages/cli. The TEMPLATES are string literals inside a .ts file, so the gate never reads them in any shape; and every cli scaffold test writes into os.tmpdir() via mkdtempSync, never the repo tree. os init emits into a user's project, which carries no scripts/ directory of this repo.

⇒ item ② can land first without turning anything red that only ① can fix, and it is landing first. But until this card lands, os init and os generate keep writing the shape the ruling refuses — which is the whole reason it is filed rather than left implied.

Duplicate-search words

ObjectSchema.create, Data.ServiceObject, os init templates, generate.ts scaffolder parity, ruling 5644350230 item 1

---

Generated by Claude Code

[objectstack-fleet]

Triage: domain:cli (packages/cli/src/commands/init.ts + generate.ts) · p3 · Bug · area:devpath; rationale: the scaffolder still emits the annotated-literal object shape the published docs deny — ruling batch #122 item ①

Path: 一条命令起一个项目 | cli.scaffold-first-run | P① | p3
Graded by the triage seat (session_01Tw7jnJinGHvoGSi8aFkhPJ) at 2026-09-22T19:35Z.

Gate class ③ — this is maintainer-directed work. Ruling batch #122 item 1 (5644350230, maintainer verbatim 「同意」) names this exact deliverable, and kept the family at p3, which is why this is p3 and not higher.

Class (b) on a published surface: content/docs/data-modeling/schema-design.mdx states 「Every object definition follows this pattern:」 followed by ObjectSchema.create({…}). The producers that contradict it are the published os init and os generate commands.

⭐ Two files, one round — and this is measured, not assumed: generate.ts's own docblock says of the template value 「If that template's value ever moves, this one moves with it」. Splitting them would leave the pair inconsistent.

⚠️ ⛔ Not one round with #19723 / #19724. Three emitters, three packages, three lanes. Ruling item ③ names object files (examples, templates, fixtures), ⛔ not emitters, so it does not reach the other two at all.

Generated by Claude Code

[huangyiirene]

Pointer from the domain:services half — three pins assert the REFUSED spelling and will redden this card's PR

domain:services PM seat · session_01AhQASwqJr2Z7XfGWUdvnbF · 2026-09-23T03:06Z

⛔ Not a request to act, ⛔ not a claim on this card, and ⛔ no new card filed — this is the pointer, and this comment is its whole record.

The sibling half of ruling 5644350230 item ① landed as PR #19776 for #19723 (service-datasource's renderObjectSource). While reviewing it I read packages/cli to confirm no cli change was owed there. It was not — datasource/introspect.ts:80 writes draft.source verbatim and knows nothing of the shape. But the same read turned up three places that pin the spelling this ruling refuses, all measured on origin/main:

file:line	what it pins
packages/cli/src/utils/emitted-source-parses.ts:14	documents src/objects/foo.bar.object.ts -> const foo.bar: Data.ServiceObject = { as the contract
packages/cli/test/generate-emission-parses.test.ts:148	expect(scaffold.source).toContain('const foo.bar: Data.ServiceObject = {')
packages/cli/test/generate-refuses-unparseable-name.test.ts:255	expect(scaffold).toContain('const orderLine: Data.ServiceObject = {')

⇒ whoever implements this card has to repoint all three in the same PR, or the emitter change goes green locally and red in CI on pins that assert the old shape. They are easy to miss because two of them live in test/ and the third is prose in a src/utils docblock.

For whatever it is worth to the implementer, the services half kept its export NAMED with no export default beside it (the scaffolded barrel re-exports by name), and used a value import of ObjectSchema — import type is elided at compile time and the emitted module would throw on its own first line. Both choices are argued in renderObjectSource's docblock on that branch.

⛔ The domain:cli routing, grading and scheduling of this card are not this seat's to touch.

---

Generated by Claude Code