epic: NetScript enterprise deployment framework (cloud-agnostic + bare-metal, CLI + Aspire)

[rickylabs]

NetScript Enterprise Deployment Framework

Turn NetScript into an enterprise-grade, cloud-agnostic AND bare-metal-compatible deployment framework, with first-class support through BOTH the CLI and Aspire. NetScript is Deno-native, so Deno deployment targets (especially the new Deno Deploy) are first-class strategic surface. The whole design is grounded on Aspire's publish/deploy model.

This is a child epic of the Road-to-0.0.1-stable umbrella and must not block it — it links in as a child once filed.

Research corpus (77 cached sources), the full architecture spec, the SERVY assessment, and the decision/gap tracker were produced under the harness run epic-deployment-aggregation (branch research/deployment-aggregation). This issue embeds the load-bearing conclusions inline.

---

How NetScript maps onto Aspire's deploy model

• Two-command spine: aspire publish emits static artifacts (compose/Helm/Bicep) for review/GitOps; aspire deploy resolves params + applies. NetScript's CLI wraps both for cloud targets and drives bare-metal directly.
• Compute-environment (compose / k8s / AKS / ACA / App Service) is orthogonal to Aspire-environment (dev/staging/prod).
• Pipelines are step-graphs (AddStep / WithPipelineStepFactory, replacing the deprecated WithPublishingCallback). The TypeScript AppHost drives the full container/cloud lane today — addContainer('denoland/deno:2')/addDockerfile, addDockerComposeEnvironment/addKubernetesEnvironment/addAzureContainerAppEnvironment, per-resource publishAsDockerComposeService/publishAsKubernetesService/publishAsAzureContainerApp callbacks, and app-level pipeline.addStep(...) are all TS-expressible (verified via the ?aspire-lang=typescript doc tab). The only genuinely C#-only capability is authoring brand-new custom resource types, which NetScript's container lane does not need.
• Deno app publish shape is realized with the built-in TS container primitives above (PublishAsNodeServer is Node-runtime-specific and won't run Deno). The ada2a5 AddDenoApp + denoland/deno:2 single-stage publish + OTEL_DENO is optional DX sugar on top, not a prerequisite.
• Deployment state is cached/idempotent (~/.aspire/deployments/{sha}/{env}.json); CI/CD is two-layer (outer GH-Actions/AzDO pipeline invokes the inner Aspire step-graph non-interactively).

CLI surface (generalized beyond today's Windows-only tree)

• Evolve config deploy.windows.* → deploy.targets.* (multi-target).
• netscript deploy <target> <verb> router: cloud targets wrap aspire publish/aspire deploy; bare-metal targets drive an OsServicePort directly.

Bare-metal successor (SERVY verdict: MODERNIZE)

SERVY upstream (aelassas/servy, C#/MIT, v8.5) is healthy — the rot is entirely NetScript-side (Windows-locked, doc/code divergence, no rollback/multi-instance, weak secrets, fake-only tests, dead docker/script config, deno:2.5 pin). Reuse the sound ProcessPort/WindowsServicePort seam and generalize WindowsServicePort → OsServicePort with servy (Windows) + systemd (Linux) adapters, on a deno compile single-binary artifact, adding rollback / multi-instance / secrets / OTEL / health-gate.

---

Per-target readiness & tier proposal

Target	Model	Driven via	First-party Deno	Proposed tier
Deno Deploy (new platform)	deno-native source build	CLI → deno deploy / GitHub-push	Yes (first-party)	1 (beta)
deno compile bare-metal (Linux/Windows)	single binary + systemd/servy	CLI → OsServicePort	Yes (deno-native)	1 (beta)
Docker / Compose (self-host)	image + compose	CLI → aspire publish/deploy (TS AppHost)	TS addContainer/publishAsDockerComposeService (ada2a5 = optional DX)	1 (beta)
Kubernetes	generated manifests/Helm	CLI → aspire publish (TS AppHost)	TS addKubernetesEnvironment/publishAsKubernetesService (ada2a5 = optional DX)	2 (stable)
Azure ACA / App Service / AKS	Aspire compute-env	CLI → aspire deploy (TS AppHost)	TS addAzureContainerAppEnvironment/publishAsAzureContainerApp (ada2a5 = optional DX)	2 (stable)
GCP Cloud Run / Koyeb / DigitalOcean / Render	Docker image / droplet	CLI emits; provider CLI	Docker path (no native)	2 (stable)
Sevalla / Dokploy / Coolify	Docker / self-host compose	CLI emits compose	no native Deno	3 (track)
Vercel / Cloudflare / AWS Lambda	unofficial runtime / isolate / container	RFC-14 Nitro unified-mode	not first-party	3 (track)

Watch-item verdicts

• deno compile single-binary — ADOPT NOW (mature 5-triple cross-compile, asset embedding; the bare-metal artifact).
• deno desktop — TRACK (v2.9 VFS + Deno.autoUpdate; but code signing/notarization not automated).
• Pulumi #3838 (Deno provider, 0.140) — TRACK (0.140 milestone = intent, not shipped; real blocker is gRPC-server-in-Deno, npm:@grpc/grpc-js support for server-side denoland/deno#23714).
• Nitro deno_server preset — TRACK (still needs --unstable; central to RFC-14 unified-mode).
• RFC-14 unified-mode — PRODUCT DECISION (Nitro v3 + oRPC + Fresh 2, mode-parity, sagas excluded, ~3-5 months) — see open decisions.

Critical path (corrected 2026-07-03)

There is no upstream hard dependency on the critical path. The earlier "the Aspire container/cloud lane is gated on the ada2a5 AddDenoApp seam because custom publish steps are C#-only" finding was an artifact of reading only the default C# doc tab and is substantially false — re-verifying the ?aspire-lang=typescript tab shows the TS AppHost drives the whole container lane today (evidence: sources/aspire/*--ts-tab.md). Phases 0-3 (config contract, bare-metal successor, Deno Deploy adapter, AND the Aspire container lane) all have no upstream blocker and can proceed in parallel. ada2a5 AddDenoApp becomes an optional DX enhancement to fold in later (TRACK). The only capability that remains C#-only — authoring brand-new custom resource types — is not needed by this lane.

---

Product decisions — RESOLVED (2026-07-03, delegated to epic supervisor)

The user delegated all six with a prioritize-don't-ship-everything mandate. These are calls, not questions; all reversible.

#	Decision	Verdict	Milestone
D1	RFC-14 unified-mode (tier-3 serverless via Nitro)	WATCH / separate track — not v1. 3-5mo, distinct arch, excludes sagas, --unstable Nitro preset; Aspire+Deno Deploy already give a strong cloud story without it.	deferred (watch)
D2	Flagship one-click	Deno Deploy = beta marquee (deno-native, no Dockerfile, shortest path, Deno-team play); Aspire Docker/Compose ships alongside in beta as the cloud-agnostic proof; k8s/Azure = stable.	0.0.1-beta
D3	Bare-metal hardening line	v1 = systemd + deno compile + atomic rollback + health-gated activation + OTEL_DENO + restricted-perm env-file secrets. Defer multi-instance/HA + external secret store to stable.	beta / stable split
D4	deno compile signing	Accept manual/documented for v1; do not block. Cross-platform signing is platform-specific scope; add a pipeline hook now, automate at stable.	beta (doc) / stable (auto)
D5	deploy.windows.* migration	CLEAN BREAK to deploy.targets.* — no back-compat alias (user override 2026-07-03: "we're alpha, breaking changes are allowed, go production-grade directly"). Windows lane re-keyed to deploy.targets.windows + one-line migration note.	0.0.1-beta
D6	Pulumi IaC adapter	PURE WATCH — not a planned lane. #3838 is OPEN + blocked (gRPC-server-in-Deno denoland/deno#23714 unshipped); Aspire already covers IaC (Bicep/Helm/compose).	deferred (watch)

Strategic plays (informational, not blocking): Deno Deploy first-class support = Deno-team play (D2 marquee); ada2a5 AddDenoApp = Aspire-team play (folded into the Aspire lane as optional DX when it lands). No NEEDS USER: items — all six decided (D5 now a user-overridden clean break); D2 positioning is the most product-facing and cheaply revisitable.

Priority ordering

0.0.1-beta (tier-1): deploy.targets.* contract (clean break, no windows alias) · deployment doctrine archetype · OsServicePort+SystemdAdapter+deno compile+rollback+health-gate+OTEL+basic secrets · Deno Deploy adapter (marquee) · Aspire Docker/Compose via TS AppHost · docs/code divergence fix.
0.0.1-stable (tier-2): k8s + Azure via TS AppHost · Docker-image providers (Cloud Run/Koyeb/Render/DigitalOcean) · CI/CD template gen + state/secret hardening · bare-metal HA + external secret store + signing automation · one-click convergence + release-skill.
Watch (deliberately not v1): RFC-14 unified-mode + Nitro preset (D1) · tier-3 serverless (Vercel/CF/Lambda) · Pulumi #3838 (D6) · exotic self-host (Sevalla/Dokploy/Coolify — generic compose emit) · ada2a5 AddDenoApp (optional DX fold-in) · deno desktop (reference only).

---

Sub-issue slices (filed 2026-07-03 — [Deploy-Sx], grouped by phase)

0.0.1-beta.1 (tier-1):

• [Deploy-S1] deploy.targets.* config contract (clean break, no windows alias) #337 [S1] deploy.targets.* config contract — clean break, no windows alias (Phase 0, D5) · wave:v1-min
• [Deploy-S2] Deployment target-adapter archetype doctrine entry #338 [S2] Deployment target-adapter archetype doctrine entry (Phase 0; coordinate with [S4] Architecture Doctrine revamp #305) · wave:v1-min
• [Deploy-S8] Fix docs/code divergence (deploy.md + cli-deploy-artifacts-missing) #344 [S8] Fix docs/code divergence (deploy.md + cli-deploy-artifacts-missing) (Phase 0) · wave:v1-min
• [Deploy-S3] WindowsServicePort -> OsServicePort + SystemdAdapter #339 [S3] WindowsServicePort → OsServicePort + SystemdAdapter (Phase 1) · wave:v1
• [Deploy-S4] deno compile single-binary bare-metal artifact #340 [S4] deno compile single-binary bare-metal artifact — manual signing (Phase 1, D4) · wave:v1
• [Deploy-S5] Bare-metal hardening (beta): rollback + health-gate + OTEL + secrets #341 [S5] Bare-metal hardening (beta): rollback + health-gate + OTEL_DENO + basic secrets (Phase 1, D3) · wave:v1
• [Deploy-S6] Deno Deploy tier-1 adapter (marquee) #342 [S6] Deno Deploy tier-1 adapter — MARQUEE (Phase 2, D2) · priority:p0 · wave:v1
• [Deploy-S7] Aspire Docker/Compose lane via TS AppHost #343 [S7] Aspire Docker/Compose lane via TS AppHost (Phase 3a; not blocked on Layer B tracking: Aspire Deno hosting (AddDenoApp / DenoAppResource) #320) · wave:v1

0.0.1-stable (tier-2):

• [Deploy-S9] Bare-metal enterprise hardening (stable): cross-host HA + external secret store + signing #345 [S9] Bare-metal enterprise hardening (stable): HA + external secret store + signing automation (D3/D4)
• [Deploy-S10] Aspire Kubernetes + Azure + Docker-image providers #346 [S10] Aspire Kubernetes + Azure + Docker-image providers (Cloud Run/Koyeb/Render/DO) (Phase 3b)
• [Deploy-S11] CI/CD template generation + state/secret hardening #347 [S11] CI/CD template generation + state/secret hardening (Phase 4)
• [Deploy-S12] One-click convergence + release-skill integration #348 [S12] One-click convergence + release-skill integration (Phase 5)

Backlog / Triage (watch — deliberately not v1):

• [Deploy-S13] WATCH: RFC-14 unified-mode + Nitro deno_server (tier-3 serverless) #349 [S13] WATCH: RFC-14 unified-mode + Nitro deno_server preset — tier-3 serverless (D1)
• [Deploy-S14] WATCH: Pulumi #3838 Deno provider (IaC adapter feasibility) #350 [S14] WATCH: Pulumi #3838 Deno provider — IaC adapter feasibility (D6)

---

TIER-4 — Desktop / single-process / offline-first (NEW — milestone 0.0.1-beta.8 core, 0.0.1-stable hardening; low priority; ships FULLY as one tier — no single-process-early / desktop-later split)

NetScript apps shippable to end-user devices as a 1-click, offline-first desktop package, running the backend in-process (true single-process) rather than as separate loopback processes. Grounded in the completed eis-chat deno desktop spike (docs/DESKTOP-SHELL.md, option (b) shipped in prod → option (c) true single-process target). This reclassifies desktop out of the earlier deno desktop — TRACK watch-item posture into a first-class Tier-4.

Precursor (must land before beta.8):

• feat(sdk): in-process link-mode adapter for single-process service mounting #451 [#E1] @netscript/sdk in-process link-mode adapter (createInProcessClientLink + ServiceClientTransport switch + in-process registry). Unblocks true single-process; the server-side ServiceApp.fetch() mount seam already ships. (Strikes the mis-referenced "172a-2 service-base-seam" dependency — PR Re-architect plugin scaffold surface (#157): thin, typesafe, no plugin-source copy #172 is merged CLI type-soundness, unrelated. See drift E1.)

beta.8 core (ship together):

• feat(aspire): first-party deno desktop app type in the generator (folds #375) #452 [#E2] desktop app-type in the Aspire generator (folds feat(aspire): first-party deno desktop app support in the generator (native window as a dev-stack resource) #375, promoted from Backlog/Triage p3) — option (b) desktop shell as a first-class generator primitive.
• feat(desktop): tursodb single-writer relocation + in-process composition root #453 [#E3] tursodb single-writer relocation + in-process composition root — per-user data dir, build() in the desktop process, sole lock holder. Avoids the native-addon-in-VFS spike.
• feat(desktop): true single-process mode (option c) #454 [#E4] true single-process mode — dashboard wired through the link-mode adapter in the packaged binary (option (c)). Deps feat(sdk): in-process link-mode adapter for single-process service mounting #451 + feat(desktop): tursodb single-writer relocation + in-process composition root #453.
• feat(desktop): offline-first via Turso Sync in the single-process host #455 [#E5] offline-first — Turso Sync (pull/push, last-push-wins + transform) in the single-process host.
• feat(deploy): single-artifact packaging + release server + snapshot updater (substrate) #456 [#E6] 1-click packaging + release/update server — deno desktop cross-compile, latest.json + bsdiff + Ed25519-signed manifests, Windows stages-not-applies manual-apply fallback.

stable (hardening + gate):

• test(deploy): single-artifact deploy-e2e — install → update → rollback (Windows + Linux) #457 [#E7] desktop/single-process deploy-e2e — extends test(deploy): no deploy target has any e2e coverage (add deploy e2e gate) #394's bare-metal-first deploy-e2e harness to the desktop target. Foundation: bug(deploy): Aspire compose target not registered in DEFAULT_DEPLOY_TARGETS (docker/compose lane dead) #393 (compose target registration), test(deploy): no deploy target has any e2e coverage (add deploy e2e gate) #394 (deploy-e2e).
• feat(desktop): code-signing automation (macOS notarize / Windows signtool) #458 [#E8] signing automation — macOS Developer-ID + notarytool; Windows signtool (D4: manual/documented for v1, automate at stable).

Naming hygiene: #349 (RFC-14 tier-3 serverless + Nitro deno_server) remains a WATCH sibling here — it is a different "unified" sense (serverless bundling), not merged into the desktop single-process scope. See #371/#372 for the KV-layer "unified" sense (already solved).

---

The full phased execution plan (per-phase goals, deliverables, DAG, acceptance gates) is in the pinned PLAN comment below.

---

_{Grounded on 77 cached sources (Aspire deployment suite, Deno Deploy/sandbox, 10 providers, watch items, netscript-start POC). Full spec: deployment-architecture-spec.md; SERVY assessment: servy-assessment.md; decision/gap tracker: decision-gap-tracker.md — harness run epic-deployment-aggregation.}

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

• Unified single-runtime is its own epic: epic: Unified Single-Runtime Deployment — Nitro v3 single deploy output (Next/Nuxt-class) #823 (beta.13, seed plan: unified-runtime seed run — Nitro v3 validation + epic decomposition #824). Tier-4 in-process issues feat(sdk): in-process link-mode adapter for single-process service mounting #451/feat(desktop): tursodb single-writer relocation + in-process composition root #453/feat(desktop): true single-process mode (option c) #454/feat(desktop): offline-first via Turso Sync in the single-process host #455 re-homed there (milestones → Backlog/Triage pending the seed); [Deploy-S13] WATCH: RFC-14 unified-mode + Nitro deno_server (tier-3 serverless) #349 closed as superseded (Nitro v3 is live).
• New children: feat(deploy): NetScript.Aspire.Packaging — .NET Aspire hosting integration (ATS-exported) for installer authoring #825 (.NET Aspire packaging integration — resolves installer authoring via an ATS-exported NuGet, beta.11) · epic: Desktop Singleton-Graph Deployment — install/update/supervise one artifact #830 (desktop singleton-graph epic, beta.14, sub-issues SD-1..SD-8 + SD-H).
• Shipping order (ratified): PM Epic: NetScript Process Manager — bare-metal supervisor + admin console (pup/pm2 done right) #510 (beta.12) → unified epic: Unified Single-Runtime Deployment — Nitro v3 single deploy output (Next/Nuxt-class) #823 (beta.13) → desktop graph epic: Desktop Singleton-Graph Deployment — install/update/supervise one artifact #830 (beta.14). Substrate (feat(deploy): single-artifact packaging + release server + snapshot updater (substrate) #456/test(deploy): single-artifact deploy-e2e — install → update → rollback (Windows + Linux) #457/feat(aspire): first-party deno desktop app type in the generator (folds #375) #452/feat(deploy): NetScript.Aspire.Packaging — .NET Aspire hosting integration (ATS-exported) for installer authoring #825/fix(service): aggregate health must exclude unconfigured adapters #826) rides beta.11.
• Full RFC: PR RFC: NetScript Single Deployment — process-managed apps, single & multi runtime (#820) #822 (rfc.md).

Option-A addendum (2026-07-17)

• New child: Desktop Frontend epic epic: Desktop Frontend — the full frontend as a native desktop app, the NetScript way #840 (beta.11) — native-first thin-client wave (feat(aspire): first-party deno desktop app type in the generator (folds #375) #452/feat(deploy): single-artifact packaging + release server + snapshot updater (substrate) #456/test(deploy): single-artifact deploy-e2e — install → update → rollback (Windows + Linux) #457 re-scoped + D1 feat(sdk): robust programmatic auto-update — typed wrapper over Deno.autoUpdate + release client #841 auto-update wrapper, D2 feat(sdk/fresh): type-safe desktop bindings — oRPC MessagePort adapter over the bind channel #842 type-safe bindings via oRPC MessagePort, D3 feat(fresh-ui): desktop UI components — tray, menus, dialogs, notifications, window chrome #843 fresh-ui desktop components).
• Update-mechanism tiering ratified: window-only = native Deno.autoUpdate (Windows manual until deno desktop: follow-ups (test coverage, CJS analyzer heuristic, platform gaps) denoland/deno#35269); combined artifact = the snapshot transaction (beta.14). One release-server/manifest lineage. feat(deploy): NetScript.Aspire.Packaging — .NET Aspire hosting integration (ATS-exported) for installer authoring #825 → beta.14.

Windows hybrid tier (owner-directed 2026-07-17)

• New child: feat(deploy): Windows hybrid tier — desktop window + PM-managed sidecars as Windows services & Scheduled Tasks #845 — desktop window + PM-managed sidecars as Windows services & Scheduled Tasks (beta.13): the in-between tier between server Servy deployment and the beta.14 single-output artifact. Composes PM-19 compile + shipped Servy spine + PM-C feat(pm): Windows Task Scheduler adapter — cron-policy processes compile to Scheduled Tasks [PM-C] #844 + epic: Desktop Frontend — the full frontend as a native desktop app, the NetScript way #840 window artifacts; prosumer CLI install v1 (no .NET dependency); consumer MSI variant folds into feat(deploy): installers — scopes, least-privilege ACLs, journaled operations, port registry [SD-3] #833/feat(deploy): NetScript.Aspire.Packaging — .NET Aspire hosting integration (ATS-exported) for installer authoring #825 at beta.14.

[rickylabs]

Correction (2026-07-03): the Aspire container lane is NOT C#-gated

A load-bearing assumption in the original spec/body was wrong and has been corrected (issue body updated).

Old claim: Aspire 13 custom publish/pipeline steps are C#-only, so the entire Aspire container/cloud lane (Phase 3+) is a hard dependency on the ada2a5 AddDenoApp seam.

Why it was wrong: it was drawn from the default C# doc tab. Appending ?aspire-lang=typescript to each Aspire deployment page reveals the TypeScript .mts AppHost codeblocks, which show the container/cloud lane is fully TS-expressible today:

• builder.addContainer('denoland/deno:2', ...) / builder.addDockerfile(...) for the Deno compute resource
• addDockerComposeEnvironment / addKubernetesEnvironment / addAzureContainerAppEnvironment for compute-environments
• publishAsDockerComposeService / publishAsKubernetesService / publishAsAzureContainerApp per-resource publish callbacks
• builder.pipeline.addStep('validate-deployment', async (ctx) => {...}, { requiredBy: ['deploy'] }) for app-level custom steps
• .withEnvironment('OTEL_DENO', ...) and addParameter(name, { secret: true })

The only genuinely C#-only capability is authoring brand-new custom resource types + generic callback-based deployment extensibility (the custom-deployments TS tab says so verbatim) — and NetScript's container lane does not need it (it uses built-in resource types + TS publishAs* callbacks). Minor secondary C#-only item: appsettings.{environment}.json file-layering (TS equivalent via env.isDevelopment() + Parameters__*).

Impact:

• No upstream hard dependency remains on the critical path. Phases 0-3 (config contract, bare-metal, Deno Deploy, AND the Aspire container lane) can all proceed in parallel.
• ada2a5 AddDenoApp drops from hard blocker to optional DX (TRACK). Because new resource types land C#-first (the TS SDK is a generated projection), depending on AddDenoApp is arguably the riskier path than using the built-in TS addContainer/addDockerfile primitives.
• k8s + Azure ACA lose their sole hard blocker; still user-owned auth/RBAC/cluster ops, but no upstream wait.
• Open decision D2 (Aspire lane vs Deno Deploy as flagship) collapses from feasibility-vs-blocker into a pure positioning choice.

Evidence re-cached under the run corpus (sources/aspire/*--ts-tab.md, sources/manifest-g7.md). Spec deployment-architecture-spec.md §2.3/§2.4/§2.6/§6.2/§7/§8 and decision-gap-tracker.md (matrix, Phase 3 gaps, D2, sub-issue #9) updated to match.

[rickylabs]

Product decisions resolved + priority ordering (2026-07-03)

The six product decisions were delegated to the epic supervisor with a "prioritize — not everything ships in v1" mandate. All six are now decided (calls, not questions); the epic body is updated to match. Summary:

#	Decision	Verdict	Milestone
D1	RFC-14 unified-mode (tier-3 serverless)	WATCH / separate track — not v1 (3-5mo, distinct arch, excludes sagas, --unstable Nitro preset; Aspire+Deno Deploy already give a strong cloud story without it)	deferred
D2	Flagship one-click	Deno Deploy = beta marquee; Aspire Docker/Compose ships alongside in beta; k8s/Azure = stable	0.0.1-beta
D3	Bare-metal hardening line	v1 = systemd + deno compile + rollback + health-gate + OTEL_DENO + basic secrets; HA + external secret store → stable	beta/stable split
D4	deno compile signing	Accept manual/documented for v1; automate at stable	beta/stable
D5	deploy.windows.* migration	deploy.targets.* + back-compat alias through beta; remove alias at stable	0.0.1-beta
D6	Pulumi IaC adapter	PURE WATCH (#3838 OPEN + blocked; Aspire already covers IaC)	deferred

Priority ordering

• 0.0.1-beta (tier-1): deploy.targets.* contract (+windows alias) · deployment doctrine archetype · OsServicePort+SystemdAdapter+deno compile+rollback+health-gate+OTEL+basic secrets · Deno Deploy adapter (marquee) · Aspire Docker/Compose via TS AppHost · docs/code divergence fix.
• 0.0.1-stable (tier-2): k8s + Azure via TS AppHost · Docker-image providers (Cloud Run/Koyeb/Render/DigitalOcean) · CI/CD template gen + state/secret hardening · bare-metal HA + external secret store + signing automation · one-click convergence + release-skill.
• Watch (deliberately not v1): RFC-14 + Nitro preset (D1) · tier-3 serverless (Vercel/CF/Lambda) · Pulumi #3838 (D6) · exotic self-host (Sevalla/Dokploy/Coolify) · ada2a5 AddDenoApp (optional DX fold-in) · deno desktop (reference only).

Deliberately NOT shipping in v1 and why: RFC-14 (too large + unstable dep, not needed for a strong cloud story); Pulumi lane (unshipped upstream, Aspire covers IaC); tier-3 serverless + exotic self-host (long tail, no first-party Deno, generic Docker emit suffices); bare-metal HA + external secret stores + signing automation (enterprise depth that can follow the working v1 line); k8s/Azure (feasible but user-owned cluster ops — stable, not beta).

No NEEDS USER: items — all six decided; D2 positioning and D5 alias-window are the most product-facing and both cheaply revisitable. Full rationale + per-phase gaps in decision-gap-tracker.md §4/§4b/§5 (harness run epic-deployment-aggregation).

[rickylabs]

D5 revised — clean break, no alias (user override, 2026-07-03)

D5 (deploy.windows.* → deploy.targets.*) is now a CLEAN BREAK with NO back-compat alias. The prior "alias through beta, remove at stable" plan is dropped entirely.

Rationale (user, verbatim intent): "we're alpha, breaking changes are allowed, and it's the right move to go for the production-grade solution directly." Ship the production-grade deploy.targets.* shape directly — no deprecation seam, no aliasing layer. The Windows SERVY lane is re-keyed to deploy.targets.windows from the outset; a one-line config migration note covers the break. This is lower-complexity than an alias (no shim to build or later remove) and stays a 0.0.1-beta / Phase 0 item.

Epic body (D5 row + priority ordering + config-contract sub-issue) updated to match; spec §3.3/§7/§8 and decision-gap-tracker.md §4/§4b/§5 updated in the harness worktree. No other decisions reopened. Research/spec only — no impl.