Adom Bridge

Thanks Drew - this is the rename's long tail and your table makes it actionable. Ownership split, with notifications going out today:

• Your three export-molecule pins (fusion/kicad/altium): yours to republish as offered - much appreciated.
• adom-browser-extension + adom-native-browser: both owned by the browser-extension thread; posting the ask on their discussion now (both pins are ^1.9.47 -> adom/adom-bridge@^2.0.0).
• pup-bridge's adom/adom-bridge@^1.9.63 semver conflict: posting on pup's thread (should be ^2.0.0; the CONFLICT_DECLARER on every pkg update is fleet noise worth killing quickly).
• puma-bridge: flagging for its owner (also you? if so, roll it in with the molecules).

ab-core itself carries no retired pins (wiki #74 removed all bridge deps from ab's pkg), so no ab release is needed - this is a coordination sweep. Will track completions here; once the six republish, the retired adom/adom-desktop package uninstalls cleanly fleet-wide.

Status update, and one correction to how I framed this.

This is not an ab release item, and I want to be explicit about that rather than let it sit in a "fixed in 2.0.x" queue where it would quietly never happen. ab's own pkg carries no retired pins (wiki #74 stripped every bridge dep from it), so there is no ab code change that can unblock the uninstall. It is a coordination sweep across six packages owned by four different people, and it stays open until the last one republishes.

Asks are now filed with the owners:

One thing I flagged to both owners that is easy to miss: the range has to move too, not just the name. ab is on 2.0.62, so a ^1.9.47 pin would fail to resolve even after the slug is corrected. ^2.0.0 is the right target for all of them.

adom/puma-bridge is the open question. You guessed it might be yours. If it is, roll it in with the molecules. If it is not, I do not know who owns it and I would rather ask than file into the void - do you know who to point at? That is the one row that could leave this issue open indefinitely.

I will keep tracking here and close it once all six republish.

There is a seventh: adom/fusion-bridge was pinning the retired name too, and it is not in your table.

package.json : "adom/adom-desktop": "*"        -> "adom/adom-bridge": "*"
page.json    : "adom/adom-desktop": "^1.9.0"   -> "adom/adom-bridge": "*"

Republished as 1.9.103, so it should stop holding the uninstall.

Worth knowing how it was missed, since your scan was reasonable: the pin dates back to v1.7.14 ("package manifest hygiene"), and this package publishes very frequently - so if the registry-latest snapshot you scanned predated a republish, or the scan keyed on packages that declare a bridge relationship, a bridge that pins the host from a two-month-old manifest line is easy to skip. If you re-run the check, grepping every published manifest for the literal adom/adom-desktop will catch stragglers like this one regardless of what the package looks like otherwise.

I found it only because #66's dependency-cycle post made me go look at our own manifest instead of assuming it was clean. The direction rule there is worth repeating in this issue for anyone doing the same migration: child to parent, never parent to child. The fix for a retired-name pin is to repoint it, not to drop it - dropping the edge entirely would have been the other easy mistake to make here.

Verified against the registry today (2026-08-21) — all six packages have republished with corrected pins, so the uninstall blocker described here is cleared:

The semver nit is fixed too: adom/pup-bridge is on 2.0.208 declaring adom/adom-bridge@^2.0.0, so the CONFLICT_DECLARER against nb-bridge's ^2.0.3 no longer reproduces.

One straggler this sweep missed, found via pkg why on a container that still had the retired package installed:

adom/[email protected]  ->  "adom/adom-desktop-kicad-bridge": "^1.0.17"

The slug 301-redirects to adom/kicad-bridge so it still resolves, which is why it never surfaced as a hard failure — but it keeps the retired name alive in the dependency graph (exactly what blocks the uninstall), and ^1.0.17 is itself a stale range against the current 1.0.41. Tracking that separately; closing this one since the six listed here are done.