Found by e2e-cli-prod against published 0.0.1-beta.7 (run 29153083989 + deterministic local repro), after #624/#631 unmasked the deeper published-mode path.
Defect
netscript init --package-source jsr (published CLI) generates a root deno.json whose import map has no @netscript/sdk / @netscript/sdk/client entries (they exist only in per-app configs via generate-app-deno-json.ts). The workers plugin scaffolds workers/jobs/health-check.ts, which imports @netscript/sdk/client, and the generated Aspire workers resource runs deno run … --watch workers/runtime.ts resolving against the root config. Result:
TypeError: Import "@netscript/sdk/client" not a dependency and not in import map
from ".../workers/jobs/health-check.ts"
The background worker crashloops (--watch restarts), behavior.workers-executions fails: {"executions":[],"total":0} — no job ever executes in a published-mode scaffold with the workers plugin.
Why CI never caught it
Local-source mode emits the SDK entries through the local import resolver (kernel/adapters/scaffold/import-resolver.ts maps NETSCRIPT_SDK* to packages/sdk/...), so the per-PR scaffold-runtime job passes. Published mode resolves through the JSR resolver but the root-config emission omits the SDK keys. Pre-existing: a 0.0.1-beta.6 scaffold shows the same empty mapping — every earlier prod round failed before this gate (beta.6 telemetry crash #624, dup dep-age flag #631), so this is the third layer of the same onion.
Consequence for beta.7 verification
JSR versions are immutable — the published beta.7 CLI keeps generating the broken root map, so e2e-cli-prod cannot go fully green against 0.0.1-beta.7 (38/39 gates pass; behavior.workers-executions fails deterministically). Fixing main makes the next cut (beta.8) clean.
Acceptance
Refs #612, #624, #631. Filed by beta-7 orchestrator (session df71d36c).
Found by
e2e-cli-prodagainst published0.0.1-beta.7(run 29153083989 + deterministic local repro), after #624/#631 unmasked the deeper published-mode path.Defect
netscript init --package-source jsr(published CLI) generates a rootdeno.jsonwhose import map has no@netscript/sdk/@netscript/sdk/cliententries (they exist only in per-app configs viagenerate-app-deno-json.ts). The workers plugin scaffoldsworkers/jobs/health-check.ts, which imports@netscript/sdk/client, and the generated Aspire workers resource runsdeno run … --watch workers/runtime.tsresolving against the root config. Result:The background worker crashloops (
--watchrestarts),behavior.workers-executionsfails:{"executions":[],"total":0}— no job ever executes in a published-mode scaffold with the workers plugin.Why CI never caught it
Local-source mode emits the SDK entries through the local import resolver (
kernel/adapters/scaffold/import-resolver.tsmapsNETSCRIPT_SDK*topackages/sdk/...), so the per-PRscaffold-runtimejob passes. Published mode resolves through the JSR resolver but the root-config emission omits the SDK keys. Pre-existing: a0.0.1-beta.6scaffold shows the same empty mapping — every earlier prod round failed before this gate (beta.6 telemetry crash #624, dup dep-age flag #631), so this is the third layer of the same onion.Consequence for beta.7 verification
JSR versions are immutable — the published beta.7 CLI keeps generating the broken root map, so
e2e-cli-prodcannot go fully green against 0.0.1-beta.7 (38/39 gates pass;behavior.workers-executionsfails deterministically). Fixing main makes the next cut (beta.8) clean.Acceptance
jsr) rootdeno.jsonmaps@netscript/sdkand@netscript/sdk/client(aligned with the local resolver's key set for scaffolded-code imports).@netscript/*specifier imported by root-level scaffolded code (workers/, contracts/, etc.) resolves in the generated root import map in BOTH package-source modes (prevents the next omission of this class).scaffold.runtimegreen; published-mode re-verification deferred to the next cut.Refs #612, #624, #631. Filed by beta-7 orchestrator (session
df71d36c).