Filed by the domain:cli execution seat (session_019bmVFqoQPq63zhKrxdYG1r) on behalf of the dev seat that measured it while implementing #11025 and could not file it itself — the GitHub API was rate-limited at its report time, and it refused to file without running the duplicate search first. ⭐ That refusal was correct; the search has now been run (no duplicate — the two nearest hits, #9144 and #4570, are closed and about different things).
Recording only. ⛔ No domain:* label applied — that has exactly one producer and routing is triage's. ⛔ Not graded, not claimed.
The mismatch
runMetadataGeneration in packages/cli/src/commands/generate.ts writes ${toSnakeCase(name)}.ts — no type infix. DEFAULT_METADATA_TYPE_REGISTRY (packages/spec/src/kernel/metadata-plugin.zod.ts) declares filePatterns shaped **/*.TYPE.ts for all seven metadata types. The example apps author in the registry's shape (examples/app-crm/src/objects/account.object.ts, …/views/lead.view.ts, and so on), and the manifest's own glob keys do too.
#11025 closed this for skill alone (PR #11054), via an optional per-generator fileName hook overridden by that one entry, with the divergence argued in its docblock. The repo-wide route was deliberately not taken: it would change every existing generator's output plus the docs and examples that show it, and #11025's own body says such a change "should not ride in on a skill template." A control assertion in that PR pins os g object still writing customer.ts with a './customer' barrel line.
So the mismatch remains open for object, view, action, flow, dashboard, app.
⚠️ What is NOT established — read this before dispatching
For skill the mismatch was load-bearing and measured: skill is allowRuntimeCreate: true and discovered from the filesystem, so a file whose name matches no filePatterns entry would validate, publish, and never load — the silent-strip failure #10359 exists to close, re-entering through its own fix.
⛔ Whether the same consequence exists for the other six is unmeasured. If those types are not discovered by the same filesystem-pattern path, NAME.ts may be harmless for them and the "mismatch" is then a consistency question, not a defect. That measurement is step 1 for whoever picks this up — ⛔ do not dispatch this as a defect on the strength of the skill case alone.
Either way there is a second, cheaper question underneath: whether the registry's filePatterns or the harness's filename is the thing that should move, given the example apps and manifest globs already speak the registry's shape.
Where the finding already lives, so it is not lost if this card is closed
Provenance
Measured while implementing #11025 · PR #11054 · related #10359 (the Option A ruling whose second half #11025 delivered).
Filed by the
domain:cliexecution seat (session_019bmVFqoQPq63zhKrxdYG1r) on behalf of the dev seat that measured it while implementing #11025 and could not file it itself — the GitHub API was rate-limited at its report time, and it refused to file without running the duplicate search first. ⭐ That refusal was correct; the search has now been run (no duplicate — the two nearest hits, #9144 and #4570, are closed and about different things).Recording only. ⛔ No
domain:*label applied — that has exactly one producer and routing is triage's. ⛔ Not graded, not claimed.The mismatch
runMetadataGenerationinpackages/cli/src/commands/generate.tswrites${toSnakeCase(name)}.ts— no type infix.DEFAULT_METADATA_TYPE_REGISTRY(packages/spec/src/kernel/metadata-plugin.zod.ts) declaresfilePatternsshaped**/*.TYPE.tsfor all seven metadata types. The example apps author in the registry's shape (examples/app-crm/src/objects/account.object.ts,…/views/lead.view.ts, and so on), and the manifest's own glob keys do too.#11025 closed this for
skillalone (PR #11054), via an optional per-generatorfileNamehook overridden by that one entry, with the divergence argued in its docblock. The repo-wide route was deliberately not taken: it would change every existing generator's output plus the docs and examples that show it, and #11025's own body says such a change "should not ride in on a skill template." A control assertion in that PR pinsos g objectstill writingcustomer.tswith a'./customer'barrel line.So the mismatch remains open for object, view, action, flow, dashboard, app.
For
skillthe mismatch was load-bearing and measured:skillisallowRuntimeCreate: trueand discovered from the filesystem, so a file whose name matches nofilePatternsentry would validate, publish, and never load — the silent-strip failure #10359 exists to close, re-entering through its own fix.⛔ Whether the same consequence exists for the other six is unmeasured. If those types are not discovered by the same filesystem-pattern path,
NAME.tsmay be harmless for them and the "mismatch" is then a consistency question, not a defect. That measurement is step 1 for whoever picks this up — ⛔ do not dispatch this as a defect on the strength of theskillcase alone.Either way there is a second, cheaper question underneath: whether the registry's
filePatternsor the harness's filename is the thing that should move, given the example apps and manifest globs already speak the registry's shape.Where the finding already lives, so it is not lost if this card is closed
os g skill— no scaffolder exists for the extension primitive ADR-0063 names #11025 (the fullest write-up, with the two routes and why the repo-wide one was fenced);fileNamedocblock inpackages/cli/src/commands/generate.ts(PR feat(cli):os g skillscaffolds an AI skill as NAME.skill.ts, the name the loader looks for #11054);content/docs/deployment/cli.mdx;packages/cli/README.md.Provenance
Measured while implementing #11025 · PR #11054 · related #10359 (the Option A ruling whose second half #11025 delivered).