RFC: single deployment — enterprise installation layer, update lifecycle, PM foundation, single-runtime composition

[rickylabs]

Owner-mandated RFC (2026-07-17), grounded in the eis-chat POC (rickylabs/eis-chat#150, merge aeaf2df — "Prototype full-stack Windows singleton desktop deployment": no-Docker Windows --singleton around Deno Desktop, native window directly supervising the adjacent service graph, Garnet + six compiled Deno processes, Aspire sidecar telemetry, shipped as a single .msi).

The POC proves feasibility. This RFC extracts what SHOULD BE BUILT as foundational layers — we learn from the POC's seams, PRs, issues, and fixes; we do not copy its scripts into NetScript.

Findings that motivate this RFC

1. Process manager is the missing foundation (beta.12 / epic Epic: NetScript Process Manager — bare-metal supervisor + admin console (pup/pm2 done right) #510). The POC's supervision is launch-only: if a sidecar service dies, the frontend is unaware and the only recovery is re-opening the app. Crash survival, restart policy, health propagation to the UI, and lifecycle guarantees must exist BEFORE any desktop deployment ships on NetScript. Sequencing: PM epic (beta.12) is a hard prerequisite of the desktop deployment work.
2. Installation layer is a gap in BOTH epics. The POC ships as a simple .NET AOT host. An enterprise-grade installation layer must handle much more (install/uninstall/repair, per-machine vs per-user, service registration, permissions/elevation, signing, first-run provisioning) and must be integrated WITHIN the Aspire stack, not bolted on outside it. Today this sits in neither the PM epic (Epic: NetScript Process Manager — bare-metal supervisor + admin console (pup/pm2 done right) #510) nor the desktop packaging issues (e.g. PM-32 [process-manager PM-32] Desktop packaging of the console (deno desktop, 5-target cross-compile) #543) — scope it and place it.
3. Update-management lifecycle is unanswered for the combined output. Deno Desktop ships an update story for a single desktop output; our artifact is a combined singleton (window + supervised service graph + sidecars). How updates apply atomically/safely across that graph (staged rollout, rollback, partial-update hazards, service downtime windows) needs a designed answer.
4. Composition with the single-runtime feature. Prior single-runtime issues describe another packaging approach we intend to KEEP alongside the singleton desktop output. The RFC must define how the two compose (shared contracts? shared PM? divergent installers?) rather than letting them fork.

Deliverables

• Gap analysis of epic Epic: NetScript Process Manager — bare-metal supervisor + admin console (pup/pm2 done right) #510 (PM) and the desktop packaging scope against the POC learnings, with concrete sub-issue adjustments (add/re-scope/re-milestone proposals for beta.12/beta.13 — proposals, owner ratifies).
• RFC design for the enterprise installation layer inside the Aspire stack.
• RFC design for update lifecycle of the combined singleton output.
• Composition contract between single-runtime and singleton-desktop approaches.

Run: .llm/runs/rfc-single-deployment--orchestrator/ (Fable 5 · high generator, adversarial Sol · max). No implementation from this RFC; board changes are drafts until owner ratification.

Refs #510, #543, #327, #400.