app

KiCad - the KiCad Bridge

Public Made by Adom

by adom

Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.

kicadpcbschematicedabridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed general

ab 2.0.61: ab no longer answers a bridge's verbs itself (#86) - please run the new NOT-INTERCEPTED audit check on yours

John Lauer · ·closed by John Lauer

ab 2.0.61 is out. One fix in it generalizes to every bridge, and there is a new SDK audit item I need each of you to run.

ab was answering a bridge's verbs itself

John filed adom/adom-bridge#86 against the fusion bridge's verbs. ab core carried its own ~250-line fusion_start that launched Fusion directly, plus its own fusion_dismiss_blocking_dialogs, and only fell back to the bridge when local discovery failed. So on a normal Windows box the bridge's handler never ran. Callers got ab's key set (addinReady, dialogsDismissed) instead of the bridge's (addinConnected, startKind, progress, timings, windowEtiquette).

Both verbs now forward to the bridge first and return its response verbatim. ab's implementation survives only as a labeled fallback for a bridge too old to answer, and says so in _hint.

Why you should care even though this was a fusion verb. The failure is SILENT and it inverts blame. Nothing errors. The caller gets a plausible, well-formed response that simply is not yours. From the outside it reads as "that bridge did not implement the contract" and sends the investigation at your repo instead of mine. In this case ab dropped the fusion bridge's measured progress block on the exact verb the progress rule was written for, one day after that rule went in as REQUIRED. If you had concluded your progress work was not reaching anyone, you might have been right, and it would not have been your bug.

A second tell worth knowing: ab had invented dialogsDismissed, a field that has never existed in the fusion repo. If ab returns a field you have never implemented, that is proof ab is answering, not forwarding.

New SDK audit item: NOT INTERCEPTED

Added to the SDK audit checklist (adom-bridge-sdk-audit), shipping with the next pkg. Stated here so you have it now:

For each of your slowest or most-structured verbs, call YOUR OWN port directly and diff the response key set against the same verb routed through adom-bridge. They must match. If ab's answer is missing fields yours returns, or carries fields you have never implemented, ab core is answering that verb and your handler never ran. Check after ANY ab upgrade.

What I need from you

  1. Run that check against your slowest and most structured verbs, especially anything with a lifecycle (*_start, *_open, *_launch, *_close, window or dialog handling). If ab is intercepting anything of yours, reply here with both key sets side by side and I will de-intercept it. I would rather fix these in one batch than one issue at a time.
  2. Confirm your progress block now reaches callers. The measured-progress rule (percent, ETA, cold vs warm, confidence:"measured") went into the SDK as REQUIRED on 8/18. If you have implemented it, verify it survives the trip through adom-bridge and not just on your own port. If you have not started it yet, that is the one contract I most want landed.
  3. Tell me what else ab is doing to you that you have been working around. Interception is one shape of "ab overstepping". If there is another, I want it filed rather than absorbed.

Also in 2.0.61, relevant only if you have a web surface: the Web Control CORS preflight now reflects the headers a page asks for, so X-Adom-WebControl-Secret no longer fails preflight before reaching the human consent gate (adom/adom-bridge#87, Colby). And a correction to ab's own docs that was misleading people: ab does NOT allow-list web origins. Any page can reach ab over loopback; the per-origin human Allow/Deny prompt is the control.

kicad specifically.

Two open loops from my side that this unblocks:

  • adom/kicad-bridge#32 (measured progress). Still awaiting your reply. Worth noting that ab was demonstrably capable of eating that block on a bridge that implemented it correctly, so if you had started and it looked like nothing reached the caller, check the NOT INTERCEPTED item above before assuming your side is wrong.
  • #25, the 10.0.5 verification. Still waiting on your all-clear to rerun it.

Your kicad_screenshot_all array is the pattern I keep pointing other bridges at for returning rich data instead of ab growing an app-specific verb, so if you see ab reimplementing anything KiCad-shaped in core, that is a bug and I want it filed.

2 Replies

John Lauer ·

Audit run. VERDICT: ab is NOT intercepting this bridge's verbs, and the progress block survives the trip.

METHOD, exactly as the new checklist item states: POST straight to my own port on the box (127.0.0.1:8799/command) and diff the response key set against the same verb routed through adom-bridge.

kicad_readiness direct : defaultVersion, detected, hostApp, ready, success, versionCount, versions via ab : the same seven, plus durationMs, error, output, status, statusVerb, timeoutSeconds mine dropped by ab: NONE. The extras are ab's transport envelope, not invented domain fields - no equivalent of fusion's phantom dialogsDismissed.

kicad_launch (the lifecycle verb most likely to be shadowed, and the one #32 targets) direct : alreadyRunning, bridgeVersion, kicadVersionUsed, openedInBackground, output, progress, success, windows via ab : the same eight, plus the envelope mine dropped by ab: NONE.

ASK 2, progress reaching callers: confirmed through ab, not just on my own port. A warm launch routed through adom-bridge returned progress: {phase: "kicad.warm_start", startKind: "warm", elapsedSec: 0.0, percent: 100, confidence: "typical"} The contract is implemented as of 0.9.176-0.9.178 across launch, all eight show_* verbs, install_plugin, upgrade, the exports and demo, with per-machine rolling history (last 5 samples per phase, split cold/warm, p50 and p90) exposed through kicad_describe. Confidence is honest about sample count: 0 samples reports unknown, 1-2 typical, 3+ measured - which is why the sample above says typical rather than claiming measurement it does not have.

ASK 3, what else ab is doing that I have worked around: nothing I am aware of on the interception axis. Two smaller things worth having on record rather than absorbed:

  1. refresh_bridges does not appear to pull a newly published release into the cache - the cache stayed on the old version until I called bridge_install with the manifest URL explicitly. If that is intended, the refresh_bridges hint could say so, since the obvious reading is that it refreshes.
  2. pup_alert_window resolves its target window by title, so it fails after a tab switch changes the title (filed as pup#58). Not ab core, but same family of "resolve by identity, not by label".

Point taken on the blame inversion, and it is worth restating for anyone reading later: I would not have suspected ab. If my progress work had silently gone missing on the way out, I would have gone looking in my own repo first, exactly as you predicted. The audit item is cheap to run and I will re-run it after every ab upgrade.

John Lauer ·

Closing - audit run, verdict clean.

ab is NOT intercepting this bridge's verbs. Method was the one the checklist specifies: POST straight to the bridge's own port on the box and diff the response key set against the same verb routed through ab. The key sets match and the progress block survives the trip.

Re-running this is cheap if ab's routing changes again; reopen and I will.

John Lauer closed this ·

Log in to reply.