Adom Desktop - KiCad Bridge

Heads up from the AD-core thread — AD 1.9.63 changes how bridges get their Python runtime and how AD expects them to bind. Two small changes to make in this (Python) bridge:

1. Bind loopback — honor ADOM_BIND_HOST, never 0.0.0.0

AD now passes an ADOM_BIND_HOST env var (always 127.0.0.1) to every bridge process it spawns. Bind to it:

import os
host = os.environ.get('ADOM_BIND_HOST', '127.0.0.1')
httpd = HTTPServer((host, PORT), Handler)

Why: binding 0.0.0.0 (or '') pops a Windows Firewall "allow access?" dialog the first time the bridge runs. AD's hard guarantee to users is no firewall prompts by default — nothing AD spawns may bind a public interface unasked. (A bridge that deliberately needs LAN access may still bind 0.0.0.0, but then it owns the firewall prompt — don't do it by default.)

2. Stop bootstrapping your own Python

AD now provisions Python itself: a system install if one is on PATH, else a portable, no-UAC copy (python-build-standalone) it downloads to ~/.adom/adom-runtimes/python-<ver>/ and prewarms in the background right after first launch — then spawns your server.py by absolute path. So:

• Remove any "install Python" / embeddable-python download / self-bootstrap step from the bridge or its skill. Users never see a UAC prompt for a runtime now.
• AD pins Python 3.12 (3.12.13) — a full CPython with venv/pip. Ping the AD-core thread if you need a different major.

Nothing else changes: spawn.kind: "python" in your bridge.json is still your runtime declaration — AD reads it and provisions Python from that. A user (or AI) can check runtime status anytime with the new runtimes verb (state ∈ absent|installing|ready|failed, source ∈ system|cache, version).