RFC: NetScript Deploy Plugin Family — plugin-deploy core + per-cloud adapters, Deno-native first (#824)

.llm/runs/plan-deploy-plugin--seed/FILING-LOG.md

@@ -0,0 +1,54 @@
+# FILING-LOG — deploy-plugin board (2026-07-19)
+
+> **Authority: GitHub wins on conflict from this point.** Filed on PLAN-EVAL PASS
+> (OpenHands · qwen/qwen3.7-max, verdict comment on PR #891) under the owner directive
+> "dispatch & on pass create the epic, sub issues and prioritize them on milestones (allowed to
+> create further betas)". Source: `filing-manifest.md` (commit `c7c68270`), executed one-shot.
+
+## Created
+
+- Label `epic:deploy-plugin` (5319e7). **Parity follow-up:** add to `.github/labels.yml` in a
+  framework slice (this run cannot edit repo config).
+- Milestones: `0.0.1-beta.15` = #17 (W4 container path) · `0.0.1-beta.16` = #18 (W5 probe-gated
+  clouds). Existing used: `0.0.1-beta.13` = #15 (W1–W3 + host + docs) · `Backlog / Triage` = #3.
+- **EPIC #892** — Epic: Deploy plugin family (beta.13).
+
+## DPB → live issue map
+
+| DPB | # | Milestone | | DPB | # | Milestone |
+| --- | --- | --- | --- | --- | --- | --- |
+| DPB-1 | #893 | beta.13 | | DPB-16 | #908 | beta.13 |
+| DPB-2 | #894 | beta.13 | | DPB-17 | #909 | beta.13 |
+| DPB-3 | #895 | beta.13 | | DPB-18 | #910 | beta.13 |
+| DPB-4 | #896 | beta.13 | | DPB-19 | #911 | beta.13 |
+| DPB-5 | #897 | beta.13 | | DPB-20 | #912 | beta.15 |
+| DPB-6 | #898 | beta.13 | | DPB-21 | #913 | beta.15 |
+| DPB-7 | #899 | beta.13 | | DPB-22 | #914 | beta.15 |
+| DPB-8 | #900 | beta.13 | | DPB-23 | #915 | beta.16 |
+| DPB-9 | #901 | beta.13 | | DPB-24 | #916 | beta.16 |
+| DPB-10 | #902 | beta.13 | | DPB-25 | #917 | beta.16 |
+| DPB-11 | #903 | beta.13 | | DPB-26 | #918 | beta.16 |
+| DPB-12 | #904 | beta.13 | | DPB-27 | #919 | beta.16 |
+| DPB-13 | #905 | beta.13 | | DPB-28 | #920 | beta.13 |
+| DPB-14 | #906 | beta.13 | | DPB-29 | #921 | Backlog/Triage |
+| DPB-15 | #907 | beta.13 | | | | |
+
+All children: `[deploy-plugin DPB-n]` titles; labels `epic:deploy-plugin area:deploy status:plan`
++ one `type:` + one `priority:` + secondary areas per manifest; `Part of #892` bodies with
+`- [ ] gate:` acceptance + `Dependencies:`/`Delivery shape:` metadata.
+
+## Supersession executed (RFC #891 §6)
+
+| Issue | Action |
+| --- | --- |
+| #824 | CLOSED with successor pointer (epic #892 / RFC #891) |
+| #823 | KEPT OPEN — pointer comment: deploy half now owned by #892; single-runtime framing to be re-stated (owner) |
+| #327 | KEPT OPEN — pointer comment: #892 is the deployment architecture successor |
+| #454 | KEPT OPEN — pointer comment: deploy aspect absorbed by the cell/capability model; close-or-fold = owner call |
+| #451 / #453 / #455 | UNTOUCHED (KEEP per RFC) |
+
+## Not done (deliberate)
+
+- GitHub-native sub-issue linkage (opportunistic nice-to-have; Markdown checklist + `Part of`
+  used, per netscript-pr).
+- `.github/labels.yml` parity (framework slice; noted above).

.llm/runs/plan-deploy-plugin--seed/adversarial-brief-r4.md

@@ -0,0 +1,70 @@
+use harness
+
+# Brief — Round 2: adversarial/collaborative pass over corpus r4 (Sol · xhigh, same thread)
+
+You reviewed this run's r1 corpus (SF-1…SF-16). Since then, three amendment waves landed — this
+round verifies the WHOLE architecture is still sound after them. Same constructive stance:
+findings + concrete adoptable amendments, not demolition.
+
+## What changed since your review (read in this order)
+
+1. `adversarial-sol-triage.md` — all 16 of your findings ACCEPTED; integrated as **r2**.
+2. `doc-story-kimi.md` + `doc-story-kimi-triage.md` — Kimi doc-story pass; 13 DX findings
+   (KF-1…13) ACCEPTED; integrated as **r3** (highlights: no preinstalled target; `deploy-deno`
+   declares NO `emit` — flow `plan → up`; `baremetal` one target with `windows|linux` variants;
+   `--env` grammar; `.deploy/<target>[@<env>]/artifact-manifest.json` `--prebuilt` contract;
+   `cells apply` + selector vocabulary; `target remove` semantics; capability preview catalog;
+   verdict-surface precedence; op grammar sketch).
+3. **`design/canonical/DP-9-aspire-composition.md`** + r4 amendments (DP-2 §2/§6, DP-3 §1,
+   DP-4 §4, DP-5, plan.md DPB-8/DPB-29 + risk row, `rfc.md` Addendum A) — the owner-directed
+   Aspire-composition pass: per-seam keep-or-delegate, the `netscript-capability-check`
+   pipeline-step integration, Radius as a future `deploy-aspire` target key.
+4. `rfc.md` — the RFC now mirrored as draft PR #891's body (do NOT touch the PR).
+
+## Attack surface (round 2)
+
+1. **DP-9 delegation verdicts** — attack each keep/delegate call. Examples worth pressure:
+   is `plan` still *pure* while surfacing `aspire deploy --list-steps`? Does the
+   `--env → aspire --environment` pass-through with the production default conflict with the
+   config `environments` overlay semantics or the r3 `--env` registry-key mapping? Does
+   adopting `addParameter({secret:true})` + `Parameters__*` for `secrets` on Aspire targets
+   stay consistent with the secrets-reference/redaction law (values in Aspire's state cache are
+   plaintext — is the caveat placement sufficient)? Is `up --prebuilt` on Aspire-managed
+   targets concrete — given DP-9 §0's ground truth that `aspire deploy` does not consume
+   published assets, WHO is the applier per target (compose vs k8s vs azure) and does the card
+   say so?
+2. **Cross-revision consistency sweep** — three amendment waves touched DP-0…DP-9, plan.md,
+   rfc.md. Hunt contradictions and staleness: op-count naming, `emit` claims vs the deno card,
+   preinstalled-target statements, baremetal naming (config keys vs variants vs registry keys),
+   `DPB-n` references, DP-N §x cross-references that moved, anything the amendments orphaned.
+   `rfc.md` is a summary — flag any place it now misstates the corpus it summarizes.
+3. **The `netscript-capability-check` pipeline step** (DP-4 §4, DP-9 §2) — registration point,
+   behavior when the deploy plugin is absent from the project, double-gating semantics
+   (NetScript CLI plan AND the aspire pipeline step both run the compiler — divergence risk?),
+   failure UX inside `aspire deploy`.
+4. **Radius position** (DP-9 §3) — is "a `radius` target key on `deploy-aspire`" the right
+   shape vs a separate variant/adapter? Is the gating condition (#18759 shipped in the pinned
+   CLI + TS surface stable) well-formed and testable?
+5. **Anything else** the three waves broke or weakened — board DAG (29 children), gate
+   selection, migration map, owner-fork table accuracy.
+
+Verification: corpus + repo ground truth first-hand (as in round 1). The Aspire facts in DP-9
+§0 carry citations from same-day doc reads — treat them as given unless internally inconsistent
+or contradicted by something you can check; if your tooling can fetch aspire.dev, add
+`?aspire-lang=typescript`.
+
+## Output contract (strict)
+
+1. Write `.llm/runs/plan-deploy-plugin--seed/adversarial-sol-r4.md`: H1 + one-paragraph
+   overall verdict (is r4 sound to file and implement against?), findings `SG-1…SG-n` with
+   `[BLOCKER|MAJOR|MINOR|ENHANCE]`, one-line claim, evidence (corpus/repo refs), concrete
+   suggested amendment; then `## Quick wins`.
+2. Commit ONLY that file (message:
+   `plan(deploy-plugin): Sol r4 adversarial findings — aspire composition + consistency sweep`)
+   and push with `git push origin HEAD:plan/deploy-plugin`.
+3. End your final response with exactly `DONE` (or `BLOCKED: <reason>`).
+
+## Stop-lines (unchanged)
+
+Findings only — no edits to any other file; no GitHub mutations (no PR/issue/label/milestone
+touches); no `packages/`/`plugins/` source edits; no other agents; this branch only.

.llm/runs/plan-deploy-plugin--seed/adversarial-brief.md

@@ -0,0 +1,82 @@
+use harness
+
+# Brief — Constructive adversarial pass over the deploy-plugin seed corpus (Sol · xhigh)
+
+You are the **stage-2 constructive/collaborative adversarial reviewer** of the harness run
+`plan-deploy-plugin--seed` (branch `plan/deploy-plugin`, this worktree). The generator (Claude
+Fable 5 · xhigh) produced a complete seed corpus for the NetScript **deploy plugin family**. Your
+role is to **ENHANCE that output, not ruin it**: find real defects, weak spots, and missed
+opportunities, and for each one propose a concrete, adoptable amendment. You are the
+`review_claude` lane (Codex · GPT-5.6 Sol · xhigh) of `.llm/harness/workflow/lane-policy.md`.
+
+## SKILL
+
+Read and follow, in order:
+
+1. `.agents/skills/netscript-harness/SKILL.md` — run mechanics, artifact map, evaluator separation.
+2. `.agents/skills/netscript-doctrine/SKILL.md` — pointers into `docs/architecture/doctrine/`
+   (you will judge archetype fit, thinness, anti-patterns, gates).
+3. `.agents/skills/netscript-tools/SKILL.md` — only if you run validation tooling; prefix
+   read-heavy git commands with `rtk`.
+
+## Read order (the corpus under review)
+
+All under `.llm/runs/plan-deploy-plugin--seed/`:
+
+1. `kickoff.md` (the owner's ratified concept — the design must serve it)
+2. `supervisor.md`, `drift.md`
+3. `research.md`, then `research/*.md` (six cited corpus files)
+4. `design/canonical/DP-0…DP-8` (the design under review)
+5. `plan.md` (locked decisions LD-1…12, owner forks OF-1…8, board sketch, §10 attack list)
+
+Spot-verify load-bearing repo claims first-hand (`deno doc`, direct file reads): the shipped
+7-op port (`packages/cli/src/kernel/domain/deploy/deploy-target-port.ts`), the deploy conventions
+(`packages/cli/src/kernel/domain/deploy/`), the auth composition pattern (`plugins/auth`,
+`packages/plugin-auth-core`), the plugin host contribution types
+(`packages/plugin/src/config/domain/plugin-contributions.ts`, `src/domain/constants.ts`), and the
+config deploy schema (`packages/config/src/domain/schemas/deploy-schema.ts`). A corpus claim you
+verify false is a finding.
+
+## Attack surface (start here, then go wherever the corpus is weakest)
+
+From `plan.md` §10 plus supervisor additions:
+
+- **Capability vocabulary granularity** (DP-2 §4): is the closed `DeployCapabilityId` set the
+  right cut? What breaks first — too coarse (verdicts lie) or too fine (manifest rot)?
+- **`cli-command` contribution axis** (DP-4 §5): design soundness, collision rules, registry
+  emission, the shim interplay (DP-4 §6). Is the three-extension host change minimal and safe?
+- **`plan` subsumes `emit`** (DP-2 §2): does that survive real artifact workflows (CI split
+  build-vs-deploy, `--prebuilt` flows, image push timing)?
+- **W1 slice ordering vs the actual CLI file graph** (DP-6, plan §5): is the extraction sequence
+  real — check the desktop-subgroup entanglement (M-16/R-M4) against the actual
+  `public/features/deploy/` tree.
+- **Manifest honesty in DP-3**: attack every capability sketch row; any row the cited provider
+  evidence does not support is a finding.
+- **The dependency law R-GRAPH-1…5** (DP-1 §2): can you construct a cycle or a god-object path
+  the rules fail to forbid? Is the `deploy-container` shared-port exception sound?
+- **Migration compatibility contract** (DP-6 §3): find the user-visible break the map misses.
+- **Board sketch** (plan §5): wrong dependencies, missing children, mis-sized slices (<30 total).
+- **Owner forks OF-1…8**: any recommendation you would flip, with grounds.
+- Anything else: naming, JSR surface, gate selection, scaffold stories realism (DP-8).
+
+## Output contract (strict)
+
+1. Write your findings to `.llm/runs/plan-deploy-plugin--seed/adversarial-sol.md`:
+   - H1 + one-paragraph overall verdict (is this corpus sound to build on?).
+   - Findings numbered `SF-1…SF-n`, each: `[BLOCKER|MAJOR|MINOR|ENHANCE]` severity, one-line
+     claim, evidence (corpus refs `DP-N §x` and/or repo `path:line`), and a **concrete suggested
+     amendment** (exact replacement wording or design change — adoptable as-is).
+   - A final `## Quick wins` list: small improvements not worth a numbered finding.
+2. Commit ONLY that file (message:
+   `plan(deploy-plugin): Sol xhigh constructive adversarial findings`) and push with the explicit
+   refspec `git push origin HEAD:plan/deploy-plugin`.
+3. End your final response with exactly `DONE` on its own line (or `BLOCKED: <reason>`).
+
+## Stop-lines (verbatim, in force — same as the run's kickoff)
+
+- Findings only: do NOT edit the DP docs, plan.md, research files, or any other run artifact —
+  the supervisor triages and amends.
+- No GitHub issues, PRs, labels, or milestones may be created or changed.
+- No product code changes: no `packages/` or `plugins/` source edits (reading is required).
+- Do not dispatch any other agent or eval.
+- Commit to this branch only; push only `HEAD:plan/deploy-plugin`.

.llm/runs/plan-deploy-plugin--seed/adversarial-sol-r4-triage.md

@@ -0,0 +1,26 @@
+# Triage — Sol round-2 findings (SG-1…SG-9, corpus r4)
+
+Supervisor triage of `adversarial-sol-r4.md` (commit `38ccc2c5`). Verdict adopted: architecture
+sound, **not fileable unchanged** — defects cluster at the new Aspire composition boundary. All
+nine findings **ACCEPTED**; fixes land as corpus **r5** (this commit series). Family topology,
+ports, and the 29-child board count are unchanged.
+
+| Finding | Sev | Disposition | Landed in |
+| --- | --- | --- | --- |
+| SG-1 `up --prebuilt` has no per-target applier contract for Aspire outputs | BLOCKER | **ACCEPT** — Aspire **applier matrix** added (`compose → docker compose -f … up -d`; `kubernetes → kubectl apply -f …`; `azure-* → named Azure-native command over emitted Bicep + pre-pushed immutable tags`), each row declaring `ApplierPort` owner, accepted manifest entries, tools/permissions, idempotency key, status/log/rollback pairing, digest-before-first-mutation test; **a variant without a row omits `up --prebuilt`** and must not advertise the CI split | DP-9 §2, DP-3 §1, plan DPB-8 |
+| SG-2 Aspire plaintext state cache undercuts the secret law | BLOCKER | **ACCEPT** — secret parameters only via process env (`Parameters__*`) or never-persisted prompt; **every secret-resolving Aspire operation runs no-save/clear-cache**; state persistence only for an allow-list of non-secret provisioning answers; if the pinned CLI cannot prove the separation, persistence is disabled and **doctor fails closed** on a cache containing secret-mapped keys; sentinel-secret absence tests (cache, artifacts, manifest, argv, logs, telemetry, errors) | DP-9 §2/§4, DP-3 §1, DP-2 §7 |
+| SG-3 Pipeline step assigned before its dependencies exist | BLOCKER | **ACCEPT** — step delivery moved **DPB-8 → DPB-17** (deps DPB-5, DPB-8, DPB-15); DPB-8 exposes only an adapter-neutral `runCapabilityCheck` callable; the generated helper registers the step **conditionally** (deploy plugin present + ≥1 Aspire target descriptor resolved; otherwise no import, no step — raw `aspire start/deploy` stays valid) | plan DPB-8/DPB-17, DP-4 §4, DP-9 §2 |
+| SG-4 Double-compile divergence + raw-Aspire failure UX | MAJOR | **ACCEPT** — one pure compiler entrypoint + versioned **`CapabilityCheckInput` snapshot** (graph digest, effective env, registry digest, manifest ids/versions/probe dates); plan embeds it; the Aspire step verifies-or-supersedes it; standardized failure: one-line summary + recovery command (`netscript deploy <target> plan --env <env>`) + diagnostics path + stable exit code; parity tests (identical verdict JSON via CLI and raw Aspire) | DP-2 §4, DP-9 §2, DP-4 §4 |
+| SG-5 Omitted Aspire env yields two identities (`<target>` vs `<target>@production`) | MAJOR | **ACCEPT** — single `resolveDeploymentEnvironment(target, requestedEnv)` normalization before registry/overlay/artifact resolution; one normalized value everywhere (registry key, overlay merge order base→`environments.<env>`→flags, artifact path, manifest field, cache key, events, `--environment`); bare + `@production` registrations rejected as aliases; non-Aspire adapters keep their own declared defaults | DP-2 §6, DP-9 §2 |
+| SG-6 Aspire card contradicts r4 (`emit`/`secrets` missing; "unchanged" wording) | MAJOR | **ACCEPT** — DP-3 §1 ops paragraph replaced by an explicit **target × operation table** (emit wherever `aspire publish` yields a supported manifest — repo ground truth already advertises it; secrets only where set/list/unset semantics exist, not mere env injection); "moved unchanged" → "extracted behind compatibility behavior first; r4/r5 changes activate behind the plugin-era canonical verbs"; `operations` + docs generated from the table | DP-3 §1 |
+| SG-7 Compatibility contract overstates "Aspire unchanged" | MAJOR | **ACCEPT** — DP-6 §3 + RFC §6 enumerate the plugin-era changes (legacy invocations keep publish-on-plan/compose-down via the compat shim; canonical plan pure / emit publishes / down uses the declared teardown executor; env normalization; SG-2 cache policy); golden argv/side-effect/exit-code tests on both paths | DP-6 §3, rfc.md §6 |
+| SG-8 Radius gate untestable; static capability risk | MAJOR | **ACCEPT** — `radius` = descriptor-selected Aspire compute-environment **variant**; gate replaced with machine-verifiable predicates (pinned CLI ≥ first release with the TS API; `deno check` of a minimal `addRadiusEnvironment` fixture; `aspire publish` emits `app.bicep`; `--list-steps` shows the Radius step; recipe-derived binding-verdict fixture); only runtime/process traits static — Recipe/resource-group capabilities per-environment, `unverified` until probed | DP-9 §3, DP-3 §1, plan DPB-29 |
+| SG-9 Plan "purity" under `--list-steps` needs a boundary | MINOR | **ACCEPT** — purity defined as "no workspace-owned deployment artifacts, no provider mutation"; documented toolchain cache/restore effects permitted in an isolated non-interactive subprocess; inspection output captured to diagnostics; failure = `AspirePipelineInspectionError`, never a capability rejection; RFC "nothing mutated" scoped | DP-2 §2, DP-9 §2, rfc.md |
+
+**Quick wins:** applied — DPB-1 acceptance gains the shipped-port comment fix ("uniform 7-op" →
+eight-op/declared-subset, incl. doctrine/gate wording); DP-3 §1 permission/doctor matrix extended
+(applier binaries, `--environment`, `--clear-cache`, secret-state paths); RFC Addendum A says the
+helper registers the step **conditionally** and names DPB-17; rfc.md provenance corrected to
+`DP-0…DP-9 (r5)`; rfc.md §5 DPB-29 summary now mentions Radius. **Not reproducible:** the
+"duplicated risk-table header (plan.md 123–126)" — HEAD has exactly one header at line 125;
+treated as a stale line-number read, no change needed.