Declares the INPUT contracts of the host-driven lifecycle classes exported
by @objectstack/core — PluginHealthMonitor (reads PluginHealthCheck,
emits PluginHealthStatus / PluginHealthReport) and HotReloadManager
(reads HotReloadConfig, snapshots via PluginStateSnapshot). The kernel
does not construct either class: a HOST composes them and passes these
shapes directly (content/docs/protocol/kernel/lifecycle.mdx, the #11811
examples, is the supported usage).
This module deliberately declares NO authorable configuration surface — see
the #11825 retirement record below.
[REMOVED] HotReloadConfig.watchPatterns was removed in @objectstack/spec 18 (ADR-0049 enforce-or-remove) — nothing ever read it. Its only two uses were log lines in HotReloadManager, and one of them announced 'File watching started' at INFO level while no watcher was ever constructed: startWatching held a placeholder, and watchHandles was read, deleted, iterated and cleared but never set. So an author could declare a glob and no file change could ever trigger a reload. Delete the key. File watching is the HOST's job in this host-driven library: run your own watcher, declare your globs wherever that watcher reads them, and call HotReloadManager.scheduleReload(pluginName, reloadFn) when one matches — the debounced integration point this class does implement, and which is unchanged.
[REMOVED] PluginHealthCheck.autoRestart was removed in @objectstack/spec 18 (ADR-0049 enforce-or-remove) — it never restarted a plugin.A PluginHealthMonitor never restarted anything. attemptRestart called plugin.destroy() and stopped there — the in-source comment said "Call destroy and init to restart", but init appeared in health-monitor.ts ONLY inside that comment. What a plugin actually got was: destroy, a log line reading 'Plugin restarted', status recovering, and periodic health checks continuing against the destroyed instance — which the default check ({ name: 'plugin-loaded', status: 'passed' }, used whenever no checkMethod resolves) passes forever, so the terminal report on a destroyed, never-re-initialised plugin was healthy. Delete the key. Restarting a plugin is the HOST's job in this host-driven library, and the monitor could not do it even in principle: Plugin.init(ctx) needs a PluginContext, which only the kernel constructs and which it exposes to nobody (ObjectKernel.context is private; KernelBase.createContext is protected). Poll getHealthStatus(pluginName) / getHealthReport(pluginName) and act on unhealthy / failed at the level that owns the plugin's lifetime — recreate the kernel, or let your supervisor restart the process. The monitor reports; it does not act.
maxRestartAttempts
never
optional
[REMOVED] PluginHealthCheck.maxRestartAttempts was removed in @objectstack/spec 18 (ADR-0049 enforce-or-remove) — it capped a restart that never happened.A PluginHealthMonitor never restarted anything. attemptRestart called plugin.destroy() and stopped there — the in-source comment said "Call destroy and init to restart", but init appeared in health-monitor.ts ONLY inside that comment. What a plugin actually got was: destroy, a log line reading 'Plugin restarted', status recovering, and periodic health checks continuing against the destroyed instance — which the default check ({ name: 'plugin-loaded', status: 'passed' }, used whenever no checkMethod resolves) passes forever, so the terminal report on a destroyed, never-re-initialised plugin was healthy. The cap counted destroy calls, so raising it only scheduled further "restarts" of a plugin that was never brought back up. Delete the key. Restarting a plugin is the HOST's job in this host-driven library, and the monitor could not do it even in principle: Plugin.init(ctx) needs a PluginContext, which only the kernel constructs and which it exposes to nobody (ObjectKernel.context is private; KernelBase.createContext is protected). Poll getHealthStatus(pluginName) / getHealthReport(pluginName) and act on unhealthy / failed at the level that owns the plugin's lifetime — recreate the kernel, or let your supervisor restart the process. The monitor reports; it does not act.
restartBackoff
never
optional
[REMOVED] PluginHealthCheck.restartBackoff was removed in @objectstack/spec 18 (ADR-0049 enforce-or-remove) — it delayed a restart that never happened.A PluginHealthMonitor never restarted anything. attemptRestart called plugin.destroy() and stopped there — the in-source comment said "Call destroy and init to restart", but init appeared in health-monitor.ts ONLY inside that comment. What a plugin actually got was: destroy, a log line reading 'Plugin restarted', status recovering, and periodic health checks continuing against the destroyed instance — which the default check ({ name: 'plugin-loaded', status: 'passed' }, used whenever no checkMethod resolves) passes forever, so the terminal report on a destroyed, never-re-initialised plugin was healthy. The chosen strategy only moved when the destroy landed. Delete the key. Restarting a plugin is the HOST's job in this host-driven library, and the monitor could not do it even in principle: Plugin.init(ctx) needs a PluginContext, which only the kernel constructs and which it exposes to nobody (ObjectKernel.context is private; KernelBase.createContext is protected). Poll getHealthStatus(pluginName) / getHealthReport(pluginName) and act on unhealthy / failed at the level that owns the plugin's lifetime — recreate the kernel, or let your supervisor restart the process. The monitor reports; it does not act.
ObjectStack