[ViperJuice]

The last v12 phase. Cached server descriptions were paired with a config by name and freshness decided on version alone, at three sites — so swapping the configured package at an equal version served the wrong package's tool descriptions indefinitely.

Executed as five lanes in isolated worktrees, reviewed by a four-seat board before merge.

What changed

• Package-identity gate at all three sites (refresh_server, refresh_all, check_staleness). An unknown side means "cannot confirm identity", which resolves to refresh — never to "cannot compare, so skip the check", the fail-open collapse that shipped three times (fix: version comparison fails closed instead of fabricating update notices #155, Follow-ups from #155: hand-written semver, negation hazard, digest ambiguity, CI guard fragility #156, fix: close the four #155 follow-ups (#156) #163).
• package_type on the cached entry. A bare name cannot tell npm foo from pypi foo, and both produce orderable release versions so compare_versions never returns incomparable. Pre-existing caches have no type, read as unknown, and refresh once. No format bump.
• --check-versions honours --cache-dir — it computed the path and then dropped it.
• --check-versions splits its report. A server whose package cannot be classified is reported as unconfirmable, not stale, and without the --force remedy that would never settle it.
• Probe-window environment contract documented and pinned, both halves: a config-driven change (including a rotated manifest credential) is refused; a genuinely ambient variable is live at spawn.

Three defects the pre-merge board caught

Board: grok PARTIALLY AGREE, codex DISAGREE, fable PARTIALLY AGREE, gemini ERROR. Every finding was verified against source and proved by mutation before being acted on.

1. The phase hollowed out two pre-existing regression guards. Adding _same_package as an earlier conjunct meant TestUpToDateShortCircuit's fixtures — which carry no package_type — now fail identity and never reach compare_versions. Both tests still passed, for the identity reason. Rewriting the short-circuit to != "newer", so an incomparable pair reads as up to date — precisely the #156/#164 fail-open — left the entire suite green. A phase whose purpose is closing a fail-open had silently removed the only coverage of a different one.

2. update_server was a third write site for package identity, not the second. It set version, tools and generated_at but never package/package_type. So an entry could carry the new package's version and live tools under the old package's label — after which _same_package would confirm identity against the stale label and the short-circuit would serve the wrong package's descriptions. That is this phase's headline defect, reachable in three operator steps, in code the phase itself touched. The lane audited two sites and the plan repeated the count.

3. The CLI split's group boundary was unpinned. The swap test asserted only that the server name appeared — and it appears in both groups. Routing a classifiable equal-version mismatch into the "could not confirm" group, withholding the remedy that actually settles it, left the suite green.

Two operator-visible consequences, documented not hidden

• refresh_all now drops an unclassifiable server's cached descriptions when regeneration fails, where it previously kept them. For a node/python server there was never evidence of a mismatch, only an inability to confirm one. Deliberate: the alternative — "only drop when positively different" — recreates the two-meanings-for-one-boolean shape behind the three bugs above. Both boards ruled the trade correct.
• A cache written before this change refreshes once, because it has no recorded package type.

Verification

2699 passed, 3 skipped, 0 failed; ruff clean; mypy clean (42 files); validate-roadmap OK; validate_plan_doc 0 errors.

roadmap_sha256 was re-pinned at closeout — the board split on this and the maintainer chose a clean-validating artifact over preserving the planning-time binding. Reasoning is recorded in the plan; UPDPATH is the first plan to refresh at closeout, and that is the convention going forward.

🤖 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 delta — both CLI seats DISAGREE, three findings, all fixed

The first board reviewed 40426cf. The fixes made in response landed after it and were unreviewed, so they went back to the board as their own delta. That round found that the fix for the first board's finding was itself defective. Fixed in be01820.

1. My F2 test was a hollow pin — the exact failure mode the previous commit documented

test_update_server_relabels_the_entry_... asserted entry.package == "@playwright/mcp" against a fixture already labelled @playwright/mcp — the value detect_package_type returns there. So the assertion held whether or not the assignment ran:

deleted: desc_entry.package = package_name
1 passed

Two seats found this independently. It was written one commit after the amendment explaining that green is not evidence. The entry now starts under a different package, and each assignment is pinned by its own mutant.

2. Relabelling was the wrong repair — it made a mixed entry permanent

update_server deliberately preserves capability_summary on a version bump, on the reasoning that it only feeds startup MCP-instructions text and being one refresh cycle behind is a small, non-functional gap.

That reasoning does not survive a relabel. Once package and version both name the new package, the freshness short-circuit CONFIRMS identity and never regenerates the entry — so the old package's summary would be served under the new package's label permanently, not one cycle behind. My fix satisfied the identity check that would otherwise have healed it.

A genuine package change now drops the entry and lets the next refresh rebuild it wholesale — this phase's own rule applied to itself: cannot confirm the cache describes this package → refresh, never patch around it. A same-package version bump is unchanged and still backfills package_type.

The drop exposed a real regression in an unrelated test: test_update_server_uses_configured_override_not_manifest used cache-entry survival as a proxy for "the override drove the probe", while its override names a different package than the fixture's label. Fixed the fixture rather than weakening the guard, and recorded which test now owns that behaviour.

3. Known limitation, filed not fixed — #180

detect_package_type collapses distinct packages for some legal command forms:

docker ['run', 'registry:5000/old-image'] -> ('docker', 'registry')
docker ['run', 'registry:5000/new-image'] -> ('docker', 'registry')
npm   ['exec', 'old-pkg']                 -> ('npm', 'exec')

So _same_package confirms identity across a real swap for those forms, and EC-UPDPATH-1/3/6 do not hold there. Pre-existing — nothing compared package names before this phase — and detect_package_type backs every version lookup in the codebase, so re-parsing it has blast radius well beyond this closeout. Filed as #180 and recorded in the phase's amendments so the next phase inherits the boundary rather than assuming the gate is total.

Verification

2700 passed, 3 skipped, 0 failed; ruff clean; mypy clean; validate-roadmap OK; validate_plan_doc 0 errors.

roadmap_sha256 re-pinned a third time. That is the documented ordering trap working as described: the pin must be computed after the last roadmap edit, and recording each board round amends the roadmap again. Round 1 saw 060fe0, round 2 shipped e2511bc, final is 2015eca.

Board tally across both rounds

Round	grok	codex	fable	gemini
Phase @ 40426cf	PARTIALLY AGREE	DISAGREE	PARTIALLY AGREE	ERROR
Delta	DISAGREE	DISAGREE	no report	EMPTY

Six findings total, six fixed or filed. The two that mattered most were both in code I had already verified and signed off.