REMEDIATION: a relock that shrinks the lockfile may be a false green

[bdelanghe]

The ladder tells you how to move versions but never says to check what the relock removed. Three cases in one wave made that concrete — and two of them point in opposite directions, which is exactly why it needs writing down rather than left to instinct.

The false green

fold-engine, deno: a plain deno install produced a lockfile that scanned green by cutting the graph from 52 npm entries to 7. markdown-it and linkify-it stopped being findings because they stopped being present — including a CVSS 8.7.

The scanner reads the lock. A package that isn't in it can't be reported. That is indistinguishable from a real fix if you only look at the check mark.

But a shrink isn't automatically wrong

repo	change	verdict
fold-engine	52 → 7	false green — whole lume subtree vanished
fold-engine (correct regen)	52 → 46	fine — stale nunjucks subtree nothing imports, plus a duplicate zod collapsing
lima-devshell	106 → 97	fine — cfg-gated Windows/wasi crates dropped when windows-sys collapsed to one version

So the rule can't be "a shrink is bad". It's: read the list of what left, not the number.

The signal that's cheap and easy to miss

A finding that is still reported after the relock proves the scan didn't go quiet by omission. On the correct fold-engine regen, markdown-it staying red is what made the other seven fixes believable.

Deno-specific cause, since it will recur

deno install resolves only the imports map and silently drops everything reachable through remote URL imports. Regenerate through the real entrypoints: deno cache src/main.ts src/cli.ts.

Verification

The diff-the-lock snippet was run against a real before/after pair (bounded-tools-mcp, 175 → 175, nothing gone) rather than written from memory.

Placed after rung 1 with a note that it applies to every rung that regenerates a lock.

---

Generated by Claude Code