[ViperJuice]

Narrows #180. Deliberately does not close it — see What this does not fix.

2.4.0's identity gate decides whether a cached description still describes the configured package by comparing the name detect_package_type returns. A name that is stable across two different packages is therefore not a cosmetic parsing wart: _same_package reads it as a positive confirmation, and the freshness short-circuit goes on serving the wrong package's tool descriptions.

Two causes, both closed

Docker split on the first : — so registry:5000/old-image and registry:5000/new-image both resolved to registry, the registry host rather than an image. A colon only introduces a tag in the final path segment; before the last / it is a host:port.

The correct rule already existed in the same module as _docker_image_tag, which is what pin detection uses. So the fix adds its paired complement _docker_image_name — same design as _strip_npm_tag/_npm_tag — rather than a second, divergent implementation. My first draft did write a second rule, and the board caught that it both regressed img:1.2@sha256:abc (→ img:1.2@sha256, where today's code correctly gives img) and disagreed with _docker_image_tag on that same input.

npm subcommands were taken as the package — npm exec old-pkg and npm exec new-pkg both resolved to exec. A leading subcommand is now skipped once, and for npm only:

• once, not repeatedly, because i and exec are real npm packages — a docker-style anywhere-loop turns npm install i and npm exec exec into None
• npm only, because npx -y exec genuinely names a package called exec
• x is included; without it npm x collides exactly as npm exec did

_npm_package_arg gains a required command parameter, not a defaulted one: a default would let one of the two shared call sites keep old behaviour silently while type-checking clean — the exact drift the shared scan exists to prevent.

Two live defects found along the way

Neither is in #180; both fell out of the same shared-scan bugs.

• A docker digest was reported as a version pin. img@sha256:abc reported a pin of abc — a fragment of the digest — and img:1.2@sha256:abc reported 1.2@sha256:abc rather than 1.2.
• A pin on an npm exec server was reported as unpinned. npm exec pkg@1.2 scanned to exec, which carries no version suffix, so a real pin was missed.

What this does not fix

My plan asserted that docker's image-token selection was sound and only tag-stripping was broken. The board falsified that. Identity is still collapsed wherever a flag's value is taken as the package name — and these are ordinary forms:

docker run --env-file .env old-image / new-image     -> both ('docker', '.env')
docker run --mount type=bind,src=/a A / B            -> both ('docker', 'type=bind,...')
npm exec --package=old-pkg / new-pkg -- shared-bin   -> both ('npm', 'exec')

Tracked on #182 (broadened for this), with #183 for the more serious consequence: update_server builds npx -y {parsed}@latest --help, and npx -y installs without prompting, so a misparsed npm run <script> installs and executes a registry package.

Verification

2717 passed, 3 skipped, 0 failed; ruff clean; mypy clean (42 files).

Six mutants, each run against one test node alone — never the class. A class-level run reddens on any member, so it cannot show the specific test is load-bearing; that is the hole two hollow tests shipped through in this repo's last two phases.

mutant	kills
docker → raw.split(":")[0]	the docker collision test
skip_subcommand = False	both npm collision tests
skip fires repeatedly	both real-package-name tests
digest not stripped first	only the 2 digest cases, 8 others green
pin site → _npm_package_arg(args, "npx")	the pin matrix
_docker_image_tag stops stripping digest	the pin matrix

The last two are what pin the helpers as complements: each half has its own mutant, so a divergence cannot pass silently.

Collision tests assert inequality of real pairs rather than single expected values — a value assertion passes against a parser that collapses both forms onto some other shared name.

Migration

Affected servers refresh once: a docker server on a host:port registry or an npm exec server now has a different package identity than its cache recorded, so that entry fails the identity check once and regenerates. Same one-time migration 2.4.0's package_type addition caused.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XbREMUsxgJ8TDBLpJ56PWb

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[ViperJuice]

Second board round on the implementation — all four seats, four findings, all closed in 360f226

Seat	Verdict
grok-4.6 (adversarial)	DISAGREE — surviving mutant A
gpt-5.6-sol (red-team)	DISAGREE — digest-pin regression
gemini-3.7-flash (alternative-approach)	AGREE
claude-fable-5 (correctness)	PARTIALLY AGREE — confirmed A, found B

1. A regression this PR introduced (red-team, confirmed by correctness)

Stripping @digest before the tag read was correct for the name and broke the pin:

BEFORE  img@sha256:abc  -> pin 'abc'   (garbage, but truthy → refusal fired)
AFTER   img@sha256:abc  -> pin None    (reads as UNPINNED)

A digest is the tightest pin docker offers. With None, update_server would pull image:latest, restart the unchanged digest-pinned configuration, and record the registry's newest digest — announcing an update while still running the old immutable image. I converted wrong-but-safe into right-looking-but-unsafe, which is strictly worse than the bug I was fixing.

Fixed with _docker_image_digest, the third member of the reference-splitting family, consulted before the tag. img:latest@sha256:… is the same trap wearing a tag that the == "latest" test would otherwise discard. All eight docker pin forms verified.

2. Surviving mutant A (grok and fable, independently)

Swapping the flag-skip and subcommand checks passed all 2717 tests. The code was already correct — npm --silent exec old-pkg → old-pkg — but nothing pinned the ordering, because every npm test put the subcommand first. Correct by accident is not correct by contract. Now pinned; the mutant dies.

3. Surviving mutant B (fable, unique) — the guard I wrote was itself hollow

detect("npm","npx",["-y","exec@1.2"]) == "1.2", commented "npx still must not skip a package genuinely named exec", cannot enforce that. The skip matches the raw token against _NPM_SUBCOMMANDS, and exec@1.2 is not in the set — so a call site hardcoded to "npm" returns the identical 1.2:

correct : npx -y exec@1.2     -> '1.2'
mutant  : npx -y exec@1.2     -> '1.2'    <- no divergence, guard useless
correct : npx -y exec pkg@1.2 -> None
mutant  : npx -y exec pkg@1.2 -> '1.2'    <- divergence

That is the third hollow test in three phases, and the second written by the agent that had just documented the failure mode. Reading an assertion cannot distinguish a hollow one from a real one; only mutating the exact line it claims to pin can.

4. Tooling: stale bytecode fabricates false red and false green

A full-suite run reported mutant A's new test as FAILING against correct source. Cause: a pure-reorder mutant has identical byte size, and apply/compile/restore inside one second defeats .pyc invalidation (whole-second mtime + size). Purging src/**/__pycache__ → 5 passed.

The same mechanism can fabricate a false green — certifying a mutant as killed when it was not. All nine proofs re-confirmed with __pycache__ purged and PYTHONDONTWRITEBYTECODE=1, and .consiliency/evidence/mutation-180.md now requires it for any future proof in this repo.

Evidence location

Moved from scratch into the repo at .consiliency/evidence/mutation-180.md. The plan required the mutation output recorded; scratch is not the repo, so that acceptance criterion was genuinely unmet until now (red-team finding 2).

Verification

2718 passed, 3 skipped, 0 failed with pycache purged and bytecode disabled; ruff clean; mypy clean. CI green on all ten checks.