Origin: measured by the os-dev run for #12315 (named-$ref link branch) while surveying the emitted packages/spec/json-schema/** tree. Filed on the dev's behalf — recording only, unassigned, awaiting triage. Not fixed under #12315's claim (out of scope: that card is the reference renderer's link branch).
Measurement
At origin/main7bd6447f413d, after pnpm --filter @objectstack/spec gen:schema:
bundle x-schema-count: 1596
bundle $defs actual: 1585
delta: 11
per-schema files on disk (excl. objectstack.json): 1585
The generator's own console agrees with both halves and with the disagreement:
Generated: 1596 (124 as input shape)
✅ Generated bundled schema: objectstack.json (1585 definitions)
✅ Successfully generated 1596 schemas.
Mechanism
packages/spec/scripts/build-schemas.ts increments count once per emitted schema, but records each one into generatedSchemas keyed by `${categorySlug}/${schemaName}` (~line 427), and the bundle's $defs is assembled from that map (~line 2546):
'x-schema-count': count,// 1596 — one per emit
...
for(const[defKey,schema]ofgeneratedSchemas)defs[defKey]=schema;// 1585 — one per KEY
So 11 emits share a def key with an earlier emit and are overwritten. The disk count (1585 files) matches $defs, not count — the same overwrite happens at the file level. findDefKeyCollisions does not stop these; per the in-source note, a self-alias is exempt from that gate (lib/def-key-collisions.ts), which is the most likely population here.
Why it's worth a card
- The field is wrong in a published artifact.
json-schema/** ships in the tarball — 1586 of 1859 files in npm pack --dry-run — so the overstatement is on the consumer's disk, not just in a build log. - A published docs page states the false reading.
content/docs/deployment/troubleshooting.mdx:438 — "its x-schema-count field reports the total number of definitions". It does not; it reports emit attempts, and is high by 11. - It masks the exempt-collision population. The delta is currently the only externally visible signal that 11 emits are being silently overwritten. Whether those overwrites are all benign self-aliases is itself unverified here — the count discrepancy is the symptom, and the resolution should establish which it is.
Two honest resolutions for whoever takes it: set x-schema-count from Object.keys(defs).length so the artifact describes itself (and decide separately whether 11 overwritten emits deserve their own report line), or keep the emit count and rename/redocument the field. The first looks right — a self-describing artifact should count what it contains — but the overwrite population should be identified either way rather than left implied.
Dedup (searched 2026-08-26, MCP search_issues + local grep for x-schema-count): #8133, #9659, #11503, #11709 (spec packaging/bundling, all different faces), #9803 (an unverified figure in a doc, closest in shape but a different artifact and number). No open card covers this field.
Origin: measured by the os-dev run for #12315 (named-$ref link branch) while surveying the emitted
packages/spec/json-schema/**tree. Filed on the dev's behalf — recording only, unassigned, awaiting triage. Not fixed under #12315's claim (out of scope: that card is the reference renderer's link branch).Measurement
At
origin/main7bd6447f413d, afterpnpm --filter @objectstack/spec gen:schema:The generator's own console agrees with both halves and with the disagreement:
Mechanism
packages/spec/scripts/build-schemas.tsincrementscountonce per emitted schema, but records each one intogeneratedSchemaskeyed by`${categorySlug}/${schemaName}`(~line 427), and the bundle's$defsis assembled from that map (~line 2546):So 11 emits share a def key with an earlier emit and are overwritten. The disk count (1585 files) matches
$defs, notcount— the same overwrite happens at the file level.findDefKeyCollisionsdoes not stop these; per the in-source note, a self-alias is exempt from that gate (lib/def-key-collisions.ts), which is the most likely population here.Why it's worth a card
json-schema/**ships in the tarball — 1586 of 1859 files innpm pack --dry-run— so the overstatement is on the consumer's disk, not just in a build log.content/docs/deployment/troubleshooting.mdx:438— "itsx-schema-countfield reports the total number of definitions". It does not; it reports emit attempts, and is high by 11.Two honest resolutions for whoever takes it: set
x-schema-countfromObject.keys(defs).lengthso the artifact describes itself (and decide separately whether 11 overwritten emits deserve their own report line), or keep the emit count and rename/redocument the field. The first looks right — a self-describing artifact should count what it contains — but the overwrite population should be identified either way rather than left implied.Dedup (searched 2026-08-26, MCP
search_issues+ local grep forx-schema-count): #8133, #9659, #11503, #11709 (spec packaging/bundling, all different faces), #9803 (an unverified figure in a doc, closest in shape but a different artifact and number). No open card covers this field.