Skip to content

Epic: NetScript Process Manager — bare-metal supervisor + admin console (pup/pm2 done right) #510

Description

@rickylabs

Epic — NetScript Process Manager

Part of #327 (Deployment epic, bare-metal lane). No closing keyword — this umbrella closes by hand when its children land.

The bare-metal deployment target of #327: how NetScript apps are run, supervised, and administered on bare metal. The concept of pup + pm2, rebuilt for 2026 as a first-party NetScript plugin (@netscript/plugin-process-manager(-core), CLI group netscript pm) at the quality bar of workers/auth.

1. Problem statement

Today --no-aspire bare-metal supervision is zero automation beyond deno task --cwd <m> dev run by hand in N terminals. Production restart/liveness is 100% delegated to systemd/Servy with no NetScript-owned aggregate status/logs, no runtime-mutable process list, no admin console. This epic fills that gap without re-importing pm2's god-daemon failure class.

2. Prior art (verdicts)

  • pup (MIT, dormant ~19.5mo): excellent concept — declarative pup.json, 3 start policies, one REST control plane consumed by CLI/plugins/UI alike. Aged code: dax-sh over Deno.Command, deprecated @std/io readLines, god-object Pup class, bespoke polling-IPC telemetry, unfixed descendant-kill bug. We keep the concept, not the code.
  • pm2 (v7, Node/Bun): rich restart strategies worth matching; its always-on god-daemon caused repeated unbounded-RSS (150GB+) and daemon-duplication incidents — a structural warning, not a model.
  • Servy / systemd: NetScript already ships production Servy + systemd adapters behind OsServicePort; extend (WatchdogSec/Type=notify/hardening/cgroups), don't replace.
  • process-compose / s6-rc / Quadlet: the generator-to-native-supervisor precedent and the dependency-ordered graph model we converge on.

3. Architecture (one paragraph)

Supervision engine as a library: dev mode runs it foreground-attached (netscript pm dev, no daemon); production compiles the declarative process graph into OS-native units (systemd/Servy via the existing renderers + OsServicePort, extracted to @netscript/deploy-core at PM-20), and the pm's resident piece is a control-plane service — itself one more OS-supervised unit hosting the typed oRPC control plane, never a parent of the workload. If it dies, the workload keeps running and the OS restarts the control plane. This structurally eliminates the god-daemon failure mode.

4. Scope / non-scope (binding)

In: typed dependency-ordered process-graph contract; dev foreground engine; compile-to-OS-units; resident control-plane oRPC service; netscript pm CLI (pup parity floor); OTEL netscript.process domain; --no-aspire resolvers; browser-served admin console (desktop packaging deferred, PM-32); OsServicePort renderer extensions; packages/deploy-core extraction.
Out: re-implementing restart/liveness in production (OS owns it); a deployment/rollout system (#327 owns it); a monitoring product (OTEL export only); a production load balancer; milestone-1 N-instance clustering (OF-5 → Backlog, PM-35); macOS/launchd (OF-6). No god-daemon, no SaaS monitoring, no git+SSH deploy inside the pm, no untyped config, no fake cluster mode.

5. Surfaces

6. Owner forks — RATIFIED 2026-07-06

All nine forks ratified by the owner (in-session, Stage H): OF-1..OF-8 = recommendation (a); OF-5 clustering explicitly re-homed to Backlog / Triage (PM-35); OF-9 hard fork resolved: milestone 1 = 0.0.1-beta.8 (beta.7 already carries 28 open issues). PM-0 rides beta.6 as an independent fix-forward precursor.

7. Cross-epic dependency edges

8. Milestone train (post-ratification)

9. Sub-issues

10. Open questions (carried from plan §9)

  1. Telemetry T2 owner sign-off on E15 (mint only netscript.process; no netscript.service.instance).
  2. epic: NetScript Dev Dashboard — the Aspire/Scalar satellite that drives the framework (ships as a plugin, beta.6) #400's answer to CR-DDX-HOSTAGNOSTIC — gates PM-33's milestone only.
  3. followLogs rate-cap numbers (bounded policy required by PM-13 acceptance; exact figures at implementation).
  4. fresh-ui L3-blocks sequencing for PM-29.

11. Design source

.llm/runs/plan-process-manager--seed/ on PR #504: plan.md (Stage E, amended at Stage F, PLAN-EVAL PASS) + research/design/d1..d5-*.md + research.md §C1–C7.

RFC #820 additions (owner-ratified 2026-07-17 — PR #822)

Acceptance amendments applied on PM-1 #512, PM-5 #516, PM-15 #526 (see each issue's RFC section). Sequencing: PM is the first shipping wave (beta.12) — desktop singleton-graph (#830, beta.14) consumes this epic's engine.

PM-C addition (owner-directed 2026-07-17)

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:cliarea:deployDeployment: CLI/Aspire deploy, targets, bare-metalarea:docsarea:pluginsplugins/* and plugin-core packagesarea:telemetryepic:process-managerProcess manager plugin epic (bare-metal supervisor + admin console, child of #327)priority:p1HighrfcRequest for Comments - substantial/breaking design changestatus:planHarness plan phasetype:umbrellawave:v1

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions