Deferred scope from the #813/#817 E2E fixes, proven live during the v0.0.1-beta.10 release: Deno 2.9's default minimum-dependency-age (~24h) rejects same-day-published versions. The E2E harness now pins --minimum-dependency-age=0, but real users are still exposed during the first ~24h after every release:
- the shipped CLI's own
deno x shell-outs (dispatchPluginVerb, the AI plugin command) resolve lockstep jsr:@netscript/*@<fresh> siblings;
- generated-project flows that resolve freshly-released
@netscript/* versions in project context;
agent init-written MCP configs invoking jsr:@netscript/cli@<fresh>.
Observed failure shape: Could not find version of '<pkg>' that matches specified version constraint '<v>' — A newer matching version was found, but it was not used because it was newer than the specified minimum dependency date … (see #817's PR body for the exact call-site inventory).
Direction to decide
Lockstep siblings are by definition exactly as old as the CLI invoking them — exempting them is sound. Options: (a) CLI-internal shell-outs pass --minimum-dependency-age=0 (or the config-level equivalent — deno exposes min_release_age_days/trust-policy knobs in config parsing; identify the sanctioned key) only for @netscript/* lockstep specifiers; (b) scaffold writes the policy override into generated project config with a comment explaining scope; (c) document the window + workaround only. Prefer (a)+docs; never blanket-disable the supply-chain protection for third-party deps.
Acceptance: fresh scaffold + plugin verbs + agent-init flow all work within minutes of a release (proven against a canary publish per #811/#812); third-party dependency age policy untouched; regression tests at the shell-out builders.
Refs #813, #817, #811.
Deferred scope from the #813/#817 E2E fixes, proven live during the v0.0.1-beta.10 release: Deno 2.9's default minimum-dependency-age (~24h) rejects same-day-published versions. The E2E harness now pins
--minimum-dependency-age=0, but real users are still exposed during the first ~24h after every release:deno xshell-outs (dispatchPluginVerb, the AI plugin command) resolve lockstepjsr:@netscript/*@<fresh>siblings;@netscript/*versions in project context;agent init-written MCP configs invokingjsr:@netscript/cli@<fresh>.Observed failure shape:
Could not find version of '<pkg>' that matches specified version constraint '<v>' — A newer matching version was found, but it was not used because it was newer than the specified minimum dependency date …(see #817's PR body for the exact call-site inventory).Direction to decide
Lockstep siblings are by definition exactly as old as the CLI invoking them — exempting them is sound. Options: (a) CLI-internal shell-outs pass
--minimum-dependency-age=0(or the config-level equivalent — deno exposesmin_release_age_days/trust-policy knobs in config parsing; identify the sanctioned key) only for@netscript/*lockstep specifiers; (b) scaffold writes the policy override into generated project config with a comment explaining scope; (c) document the window + workaround only. Prefer (a)+docs; never blanket-disable the supply-chain protection for third-party deps.Acceptance: fresh scaffold + plugin verbs + agent-init flow all work within minutes of a release (proven against a canary publish per #811/#812); third-party dependency age policy untouched; regression tests at the shell-out builders.
Refs #813, #817, #811.