Found while measuring the contributes block for #10627 (census only; deliberately not fixed there). Measured on origin/main (299b85e9d). Two small things about the single member of that block that does have a reader — recorded so the "LIVE" verdict is not read as stronger than it is.
1. The value flows into a bucket nothing typed reads
packages/objectql/src/engine.ts:4499-4503
if (manifest.contributes?.kinds) {
for (const kind of manifest.contributes.kinds) {
this._registry.registerKind(kind);
packages/objectql/src/registry.ts:3668-3673
registerKind(kind: { id: string, globs: string[] }) {
this.registerItem('kind', kind, 'id');
}
getAllKinds(): { id: string, globs: string[] }[] {
return this.listItems('kind');
}
getAllKinds() has zero callers — grep -rn "getAllKinds" over *.ts,*.tsx,*.mts returns only its own definition in objectstack, and nothing at all in objectui. So the declaration is genuinely read and stored, but the typed accessor for the stored value is never called.
That is not automatically dead: GET /metadata/:type passes an arbitrary type string through to protocol.getMetaItems({ type: typeOrName, … }) (packages/runtime/src/domains/meta.ts:735-749), so kind items may be observable generically over that door. Unverified — establishing whether the kind bucket resolves there is what this card is for, and it is the difference between "live, with a generic reader" and "registered into a bucket nobody ever reads", which would put kinds in the same enforce-or-remove queue as its nine dead siblings (#10724).
The schema's stated purpose (manifest.zod.ts:322-330: "Enables the system to parse and validate new file types … Example: Registering a BI plugin to handle *.report.ts") describes a glob-driven file-parsing behaviour. No consumer of globs was found on the census — worth confirming separately from the bucket question.
2. The registration site logs two fields the schema does not declare
packages/objectql/src/engine.ts:4503
this.logger.debug('Registered Kind', { kind: kind.name || kind.type, from: id });
contributes.kinds items are declared as { id, globs, description? } (manifest.zod.ts:327-331) and registerKind types its parameter { id: string, globs: string[] }. Neither name nor type exists on either shape, so this debug line logs undefined for every conforming manifest. Harmless in itself (a log field), but it is evidence that the site was written against a different, earlier kind shape — and registerItem('kind', kind, 'id') keying on id while the log reaches for name/type is the kind of drift worth a two-line fix rather than a comment.
Filed unassigned for triage; both halves are small and could ride one PR.
Generated by Claude Code
Found while measuring the
contributesblock for #10627 (census only; deliberately not fixed there). Measured onorigin/main(299b85e9d). Two small things about the single member of that block that does have a reader — recorded so the "LIVE" verdict is not read as stronger than it is.1. The value flows into a bucket nothing typed reads
getAllKinds()has zero callers —grep -rn "getAllKinds"over*.ts,*.tsx,*.mtsreturns only its own definition inobjectstack, and nothing at all inobjectui. So the declaration is genuinely read and stored, but the typed accessor for the stored value is never called.That is not automatically dead:
GET /metadata/:typepasses an arbitrary type string through toprotocol.getMetaItems({ type: typeOrName, … })(packages/runtime/src/domains/meta.ts:735-749), sokinditems may be observable generically over that door. Unverified — establishing whether thekindbucket resolves there is what this card is for, and it is the difference between "live, with a generic reader" and "registered into a bucket nobody ever reads", which would putkindsin the same enforce-or-remove queue as its nine dead siblings (#10724).The schema's stated purpose (
manifest.zod.ts:322-330: "Enables the system to parse and validate new file types … Example: Registering a BI plugin to handle*.report.ts") describes a glob-driven file-parsing behaviour. No consumer ofglobswas found on the census — worth confirming separately from the bucket question.2. The registration site logs two fields the schema does not declare
contributes.kindsitems are declared as{ id, globs, description? }(manifest.zod.ts:327-331) andregisterKindtypes its parameter{ id: string, globs: string[] }. Neithernamenortypeexists on either shape, so this debug line logsundefinedfor every conforming manifest. Harmless in itself (a log field), but it is evidence that the site was written against a different, earlier kind shape — andregisterItem('kind', kind, 'id')keying onidwhile the log reaches forname/typeis the kind of drift worth a two-line fix rather than a comment.Filed unassigned for triage; both halves are small and could ride one PR.
Generated by Claude Code