Found while implementing #11811 (correcting the checkMethod example in
lifecycle.mdx). Out of that card's scope — its dispatch ruled packages/spec
and packages/core off-limits, so this is recorded rather than acted on.
What was measured
AdvancedPluginLifecycleConfigSchema
(packages/spec/src/kernel/plugin-lifecycle-advanced.zod.ts:431) is the only
container for PluginHealthCheckSchema and its four siblings:
health: PluginHealthCheckSchema.optional(),// :435hotReload: HotReloadConfigSchema.optional(),degradation: GracefulDegradationSchema.optional(),updates: PluginUpdateStrategySchema.optional(),
Repo-wide references to AdvancedPluginLifecycleConfig (excluding
node_modules and dist) are 5, and every one is the schema's own file or
its own test:
| location | what it is |
|---|
plugin-lifecycle-advanced.zod.ts:431 | the declaration |
plugin-lifecycle-advanced.zod.ts:495,497 | the two exported types |
plugin-lifecycle-advanced.test.ts:11,308,310,350,360,377 | its own schema tests |
plugin-loading.zod.ts:53 | a comment mentioning .hotReload |
Positive control in the same sweep: checkMethod = 8 hits in packages/,
spanning schema, consumer and two test files — so the zero is a reading, not a
dead probe.
The consumer side matches. PluginHealthMonitor is constructed in exactly one
place repo-wide, and it is not the kernel:
packages/core/src/kernel.ts — no occurrence of HealthMonitor (nor does
packages/core/src/index.ts beyond the export * at :76).packages/core/examples/phase2-integration.ts:53 — new PluginHealthMonitor(...),
an example file.
So nothing in the boot path ever calls registerPlugin() / startMonitoring().
The class works and is unit-tested; it is simply never wired.
Why this is a finding rather than a defect report
PluginHealthCheckis carried in packages/spec/authorable-surface/kernel.json,
i.e. it is declared as an authorable surface. The liveness ledger
(packages/spec/liveness/*.json) cannot catch this because it is scoped by
metadata type (object, field, view, flow, …) and these kernel
plugin-lifecycle schemas are not a metadata type — so no existing ratchet is
looking at them.
That is the declared != enforced shape of Prime Directive #10, in its
authorable-surface form: five config groups an author can write, parse-validated
by Zod, that no runtime path reads.
⚠️Not the same as "dead code" — the capability is genuinely reachable:
PluginHealthMonitor is exported from @objectstack/core, so an embedding
application can drive it by hand, which is exactly what #11811's corrected doc
example now shows. The open question is only whether the declarative config
surface should exist with nothing consuming it. Three routes, none of them
chosen here — this needs someone who knows whether the kernel is meant to grow
the wiring:
- Wire it — the kernel reads
AdvancedPluginLifecycleConfig off the plugin
and drives the monitor, making the declared surface real. - Retire the container under ADR-0049 enforce-or-remove, keeping the classes
as a host-driven library. - Leave it and say so — record it as a deliberately-published intention.
Not asserting more than was checked
Only AdvancedPluginLifecycleConfig and the PluginHealthMonitor construction
sites were traced. The other three groups (hotReload, degradation, updates)
were counted through the same container but their own consumers were not
audited individually — HotReloadManager does have registerPlugin callers in
packages/core/src/hot-reload.test.ts, so at least one of them may have a
different wiring story. No sibling repo was examined.
Found while implementing #11811 (correcting the
checkMethodexample inlifecycle.mdx). Out of that card's scope — its dispatch ruledpackages/specand
packages/coreoff-limits, so this is recorded rather than acted on.What was measured
AdvancedPluginLifecycleConfigSchema(
packages/spec/src/kernel/plugin-lifecycle-advanced.zod.ts:431) is the onlycontainer for
PluginHealthCheckSchemaand its four siblings:Repo-wide references to
AdvancedPluginLifecycleConfig(excludingnode_modulesanddist) are 5, and every one is the schema's own file orits own test:
plugin-lifecycle-advanced.zod.ts:431plugin-lifecycle-advanced.zod.ts:495,497plugin-lifecycle-advanced.test.ts:11,308,310,350,360,377plugin-loading.zod.ts:53.hotReloadPositive control in the same sweep:
checkMethod= 8 hits inpackages/,spanning schema, consumer and two test files — so the zero is a reading, not a
dead probe.
The consumer side matches.
PluginHealthMonitoris constructed in exactly oneplace repo-wide, and it is not the kernel:
packages/core/src/kernel.ts— no occurrence ofHealthMonitor(nor doespackages/core/src/index.tsbeyond theexport *at:76).packages/core/examples/phase2-integration.ts:53—new PluginHealthMonitor(...),an example file.
So nothing in the boot path ever calls
registerPlugin()/startMonitoring().The class works and is unit-tested; it is simply never wired.
Why this is a finding rather than a defect report
PluginHealthCheckis carried inpackages/spec/authorable-surface/kernel.json,i.e. it is declared as an authorable surface. The liveness ledger
(
packages/spec/liveness/*.json) cannot catch this because it is scoped bymetadata type (
object,field,view,flow, …) and these kernelplugin-lifecycle schemas are not a metadata type — so no existing ratchet is
looking at them.
That is the
declared != enforcedshape of Prime Directive #10, in itsauthorable-surface form: five config groups an author can write, parse-validated
by Zod, that no runtime path reads.
PluginHealthMonitoris exported from@objectstack/core, so an embeddingapplication can drive it by hand, which is exactly what #11811's corrected doc
example now shows. The open question is only whether the declarative config
surface should exist with nothing consuming it. Three routes, none of them
chosen here — this needs someone who knows whether the kernel is meant to grow
the wiring:
AdvancedPluginLifecycleConfigoff the pluginand drives the monitor, making the declared surface real.
as a host-driven library.
Not asserting more than was checked
Only
AdvancedPluginLifecycleConfigand thePluginHealthMonitorconstructionsites were traced. The other three groups (
hotReload,degradation,updates)were counted through the same container but their own consumers were not
audited individually —
HotReloadManagerdoes haveregisterPlugincallers inpackages/core/src/hot-reload.test.ts, so at least one of them may have adifferent wiring story. No sibling repo was examined.