[runyourempire]

What

This answers recovery-lead's live-check finding (2) on the rebuilt operator app. In navcal, the direct rows for sharp, next and vite told the user to npm install "pkg@^x", although each declared ^ range already admitted the fix target.

When the declared range admits the target, the minimal correct advice is the tool's in-range lockfile refresh, which leaves the manifest as it is. An install command is kept only when the range excludes the target.

Every form was run against the real tool (2026-10-18)

The project declared ms ^2.1.1 with the lock at 2.1.1. Each command moved the lock to 2.1.3, and package.json was unchanged:

Tool	Command	Note
npm 10.9.2	npm update ms	Also inside a workspace member, run in the member's directory, both hoisted and nested
pnpm 10.34.6	pnpm update ms --no-save	Plain pnpm update ms rewrote ^2.1.1 to ^2.1.3. Also inside a workspace member, where only that member's importer moved
yarn 1.22.22	yarn upgrade ms	No version given
yarn 4.9.1	yarn up -R ms
cargo 1.97	cargo update -p itoa@1.0.5 --precise 1.0.11	On itoa = "1.0.5"; Cargo.toml unchanged

How

• DirectFix gains a Refresh(String) variant. direct_fix checks that the declaration admits the installed copy, as before. If it also admits the target, it returns the refresh. Any readable range qualifies: a >= range carries no operator, but it admits the target.
• The declines are unchanged:
  • a yarn workspace member, because yarn's up/upgrade act on the whole workspace;
  • Cargo workspace = true, git, path and registry entries.
• Plan: "Fixable now with a lockfile refresh (the declared range already admits the fix): npm update sharp" when every fix is a refresh. In a mixed row, the refresh is labelled "(a lockfile refresh: the declared range already admits it)".
• Brief: "bump sharp to >= x: within its declared range, run npm update sharp" (DirectFix::brief_clause).
• Parent levers (fix(upgrade-plan): name the parent release that fixes a nested advisory (audit H1) #981): lever_command and the decide-mode vector helper both cover Refresh, and both matches are now exhaustive (the helper had a _ => None that silently dropped it). A lever declared ^4.13.4 moving to 4.22.3 names npm update express.

Vectors

• New, all refresh: true:
  • fix_command fc-054 to fc-058: npm, pnpm, yarn 1, yarn berry and cargo, one line each;
  • fc-059: a >= range;
  • fc-060: an npm workspace member.
• fc-029..035 and fc-037..041: these used targets their own declared range admits, which now correctly gives a refresh. They move to targets outside the range, so they keep pinning the operator-keeping install, and their sources say so.
• fc-036: keeps its decline purpose, using 1.x → 2.0.0.
• parent_release pr-001: now expects npm update express. The rule text says why. pr-002..004 declare exact versions and keep their installs.
• The MCP mirror: it has implemented the same rule and passes these lines on its side. It is pending the repin.

Checks

• cargo clippy --locked -- -D warnings: clean.
• osv::, brief, evidence::, morning_ and preemption: 914 passed, including the vector gate, rebased on main d63fd7c.
• New tests:
  • every refresh form, by lockfile kind;
  • a >= range;
  • the note wording, for refresh-only and mixed rows;
  • an end-to-end plan row for ~1.2.5, which names the refresh;
  • the end-to-end and Brief/plan parity tests, now on an exact pin so the install path stays covered.

🤖 Generated with Claude Code

https://claude.ai/code/session_015KSXWNneouUjTiVV3Rc3FH