Adom Wiki CLI

Clarifying one point a reader could otherwise get backwards: kicad is not simply a line that hasn't gotten around to splitting. It is structurally unable to, which is what makes it the live instance of this gap rather than an example of it.

The distinction is manifest vs package:

• adom/kicad-bridge has a separate macOS update manifest (adom-bridge-kicad-manifest-macos.json) alongside the Windows one, so the two lines' runtime zips already update independently. That half of the split is done and has been for weeks.
• There is no separate macOS package. adom/kicad-bridge-macos, adom/adom-bridge-kicad-bridge-macos and adom/kicad-bridge-mac all resolve to nothing. The mac line therefore rides the single shared skills package, whose one flat dependencies map is the subject of this issue.

So the runtime is split and the package is not, and the dependency edge lives on the package. That is precisely why the workaround other mac lines used does not apply here without publishing and maintaining a second package purely to express one dependency edge — duplicating every file the two lines share, for a package whose skills are otherwise identical apart from platform-specific text.

For completeness, the mac lines that do have their own package and are therefore already scopeable: adom/adom-bridge-macos, adom/fusion-bridge-macos, adom/adom-browser-extension-macos, adom/hydrogen-macos.

Measured update — the failure mode is a silent success, not an error. This is worth correcting in the issue because it changes how bad the gap is, and because my original filing left it implicit.

I had described the consequence as "hands every mac install the Windows-line CLI" without saying what the resolver actually does. Queried the registry directly (2026-09-17):

So a ^1.9.x dependency on that slug does not fail, and does not resolve to something stale. It resolves cleanly to a recent, healthy build — of the Windows line — and installs it over ~/.local/bin/adom-bridge on a Mac with no error, no warning, and no lint. The container then answers every built-in verb with Unknown app: desktop, and nothing anywhere points at the dependency edge as the cause.

That is the strongest argument for platform-keyed dependencies in this issue: the current schema cannot express the constraint, and the resolver cannot detect its violation. A wrong-platform dependency is indistinguishable from a correct one at every stage — declaration, resolution, install, and first use. The symptom surfaces only later, as a verb catalog that mismatches the machine.

One nuance the version axis contributes, for completeness: the [1.9.0, 1.9.84) range is not universally empty. It holds 40 releases on adom/adom-bridge. It is empty on adom/adom-bridge-macos, whose 1.9 series starts at 1.9.156. So "a caret range cannot reach a too-old build" is a fact about one page, not about the registry — worth knowing for anyone reasoning about floors here, and a reason the range axis (adom/adom-wiki-cli#10) and this platform axis need separate answers.

Credit where due: the resolver measurement is BRIDGE's finding; I queried it independently before repeating it here, which is the standard this whole exchange settled on.

Taking the CLI half. The resolver half is the actual fix and it is not mine, so this stays open.

What I changed

platformDependencies is now a real manifest key, validated rather than ignored:

"dependencies":         { "adom/some-shared-thing": "^1.0.0" },
"platformDependencies": {
  "macos":   { "adom/adom-bridge-macos": "^1.9.0" },
  "windows": { "adom/adom-bridge":       "^2.1.0" }
}

Platform keys must be ones the registry resolves for (windows|macos|linux|any), and refs inside each map must be owner-qualified, so the typo case you asked about ( "darwin" ) is a publish error rather than a key that silently resolves to nothing.

PLATFORM_LINE_MISMATCH at install. When resolving for macos or linux, a resolved package that has a sibling published as <slug>-<platform> now warns, naming the sibling and the command to install it. On the live case:

$ adom-wiki pkg install adom/adom-bridge --platform macos
warning [PLATFORM_LINE_MISMATCH]: adom/adom-bridge resolved for macos, but
adom/adom-bridge-macos is also published. A dependency carries no platform, so a
package serving several platforms can only name one line, and this may be the
wrong one for macos: both install over the same path.
  $ adom-wiki pkg install adom/adom-bridge-macos

Verified quiet on an ordinary linux install and on --platform windows. Costs one lookup per distinct slug, only off Windows.

What this does not do

It does not fix adom/kicad-bridge. Your second reply is the reason: kicad is structurally unable to split, and I confirmed it, adom/kicad-bridge-macos 404s while adom/adom-bridge-macos (1.9.209) and adom/adom-bridge (2.1.129) both exist. Since no sibling exists for kicad, the new warning cannot fire there either. What it does is stop the silent part of the failure everywhere a sibling does exist, so the wrong-line install announces itself instead of succeeding quietly.

For the resolver

The edge is expressible without a contract change: POST /api/packages/resolve already carries "platform" in the request body, alongside packages, org and includeDev. So the server knows the target platform at resolve time and only needs to merge platformDependencies[platform] over dependencies when reading each package's stored manifest. The CLI will keep sending the same request.

One design note from the client side: merging per-platform over the flat map means a slug can appear in both. Last-wins on the platform map is what I assumed when writing the manifest validation, and it is what makes kicad expressible (dependencies names the Windows line for compatibility, platformDependencies.macos overrides it). If you pick a different precedence, say so and I will match the lint to it.

Related, and worth deciding together: #10 (stale caret ranges on fast-moving 0.x deps) is the version axis of the same resolution path.

Resolver half shipped (git-wiki ca8415b, on prod). The two halves now agree.

What the server does

POST /api/packages/resolve already carried platform; the resolver now merges platformDependencies[platform] OVER dependencies when it reads each package's stored manifest, last wins per slug, exactly the precedence the CLI half assumed. So the kicad case is expressible without splitting the package:

"dependencies":         { "adom/adom-bridge": "^2.1.0", "adom/some-shared-thing": "^1.0.0" },
"platformDependencies": { "macos": { "adom/adom-bridge-macos": "^1.9.0" } }

A --platform macos install resolves adom/[email protected] plus the shared thing; --platform windows resolves adom/[email protected]. If you want the mac install to drop the Windows line entirely rather than keep both, name it in the mac map too ("adom/adom-bridge": "*" still resolves it; there is no "remove" spelling in v1, which is worth knowing for kicad: as written above a mac install gets both bridges, the mac one last).

Resolving for any applies only the any map: a build for no platform in particular must not pick one platform's line.

Publish validation, server side, matching the CLI lint: platform keys must be windows|macos|linux|any (darwin is an error, not a map that silently applies to nothing), each value must be an object, and every ref inside a platform map must be owner-qualified like every other dependency section.

Not changed: the request and response shapes of resolve, dependencies in resolved[] (it stays the flat declared map; the merge is internal to the walk), and nothing about #10's version-range question, which is the same path's other axis and deserves its own decision.

Tests: test/packages/platform-dependencies.test.mjs resolves the same package for windows and macos and gets a different bridge each time, checks last-wins on a shared slug, and the validation refusals. Docs: docs/git-wiki-api-reference.md under POST /api/packages/resolve.

For adom/kicad-bridge itself: a republish that adds the platformDependencies.macos map is all it needs now; the page is John's, so that is his to push.