plugin-registry.zod.ts has zero consumers outside packages/spec, and is now the sole surface keeping PluginCapabilityManifestSchema published #13285

Observation recorded while executing #11332 (retirement of the manifest's dead capabilities / configuration / extensions containers); not measured to the enforce-or-remove standard, so filed as a finding for the liveness program rather than as a retirement unit.

• packages/spec/src/kernel/plugin-registry.zod.ts declares capabilities: PluginCapabilityManifestSchema.optional() (around line 205) on its registry-entry shape.
• Importers of the module, whole monorepo, non-dist: packages/spec/src/kernel/index.ts (re-export), packages/spec/scripts/build-docs.ts, its own test file, and the type-alias convention pin. Zero consumers outside packages/spec.
• After Three plugin-manifest blocks — capabilities, configuration, extensions — have zero reads of the container itself, so all 8 keys beneath them are inert (configuration.properties.secret promises encryption/masking) #11332, the manifest's capabilities key is a tombstone, which makes plugin-registry the ONLY surface still publishing PluginCapabilityManifestSchema — the retirement deliberately kept the def published for this reason (recorded in the retired-key entry kernel/Manifest:capabilities).
• What this card asks: a proper census of the plugin-registry surface (who parses PluginRegistryEntry-shaped data, does any marketplace/cloud path mirror it, does the capabilities block there have any reader), with positive controls, before anyone either builds on it or retires it. If the surface reads zero everywhere, its capabilities block inherits the exact false-promise shape Three plugin-manifest blocks — capabilities, configuration, extensions — have zero reads of the container itself, so all 8 keys beneath them are inert (configuration.properties.secret promises encryption/masking) #11332 just removed one level down — "interoperability and automatic discovery" no discovery path performs.

Generated by Claude Code