[process-manager PM-6] Supervisor loop + composable start policies (autostart/cron/watch)

[rickylabs]

Summary

The supervision engine loop composing PM-3/4/5, with the three start policies: autostart, cron via @netscript/cron createScheduler(), and watch via Deno.watchFs. Dependency-ordered graph startup.

Scope

• Archetype / area: packages/plugin-process-manager-core engine
• Part of Epic: NetScript Process Manager — bare-metal supervisor + admin console (pup/pm2 done right) #510
• Depends on: [process-manager PM-3] Core package scaffold: ports + KV registry adapter #514, [process-manager PM-4] Restart controller: pure nextDelay(state, policy, clock) #515, [process-manager PM-5] Process runner: Deno.Command-native spawn + descendant-tree kill #516 · Blocks: PM-8, PM-10, PM-35

Design source

• research/design/d1-supervision-engine-core.md (D1-S7) · plan.md §4 PM-6

Acceptance criteria

• gate: start policies composable per process; cron reuses @netscript/cron (wrap-don't-reinvent)
• gate: dependency-ordered startup with readiness gating (E14 grace-window default; sd_notify/HTTP probe opt-in)
• gate: engine is a library — zero daemon assumptions (C1)
• gate: scoped check/lint/fmt wrappers green (--ext ts,tsx)

Non-scope

• Control plane (PM-10); dev CLI (PM-27).

Drift / Debt

• none

[rickylabs]

Cron-primitive lineage + upstream watch (owner note, 2026-07-06)

Closing the loop on the Stage-C/D open question ("does NetScript already have a scheduling/cron primitive a cron start-policy should sit on top of?") — yes, and the decision lineage predates this epic:

1. @netscript/cron is the repo primitive (this slice already binds to createScheduler()). The anti-fragmentation law was locked in the Group-F (Triggers) plan — rickylabs/netscript-start#93: core defines a scheduler port; the @netscript/cron adapter is supplied at composition, preventing primitive fragmentation (pup's bundled @hexagon/croner is exactly the fragmentation we avoid). The cron start-policy here should follow the same port-plus-adapter shape rather than importing @netscript/cron into the engine directly.

2. Upstream watch: feat(ext/cron): scaffold Deno.cron.persistent API (no backends yet) denoland/deno#33965 — Deno.cron.persistent scaffold (OPEN): persistent cron jobs registered with the host OS scheduler (crontab / launchd / schtasks) so they survive process exit and reboot; Deno.cron.persistent / .remove / .list compose with the in-memory Deno.cron; Cloudflare-Workers-shaped default.scheduled(controller) entry point; gated behind --unstable-cron, per-OS backends still unimplemented. This is philosophically identical to this epic's production mode (the OS is the supervisor of record): when the backends land, a production schedule: start-policy could compile to Deno.cron.persistent/OS scheduler entries instead of pm-generated timer units. Keeping the scheduler behind a port (point 1) makes that adoption an adapter swap, not a re-architecture.

Neither item changes this slice's milestone-1 scope; both bind its shape (port seam) and name the future adapter.

Refs #510 · Refs denoland/deno#33965