KiCad - the KiCad Bridge

Tracking issue for adom-boardflow: the flow app that runs the board loop (placement, routing, pours, analysis, simulation, gate, landing) as one compiled binary fed by configs, emitting hints so the AI decides what to do next and which stages it takes itself. Decided with John on 2026-09-13; to be built the week of 2026-09-14. Not started.

Why: the ESC round burned about $150 of tokens writing a router, a placer's helpers, a pours tool, an offline DRC gate and a live replayer, all generic apart from a short config. The wiki is a token cache; the mechanics belong in a binary every Adom user installs, and the judgement (what to pour, what not to, where to go back) stays with the AI and the skills.

Name and home: adom-boardflow (not "layout": to many EDA users that means the 2D editor). Page adom/adom-boardflow, an Adom app page: per-platform releases of the adom-boardflow binary, a skills package (the flow skill plus one skill per stage), discovery_triggers for "route the board", "copper pours", "current density", "place the parts". It talks to KiCad offline (board files) and live through kicad-bridge's verbs, and later to Fusion and Altium through their bridges. The bridge verbs stay in the bridges; boardflow is the flow.

Contract: the Adom app CLI contract (result plus hints). Subcommands:

• plan BOARD --spec spec.json: reads the board and the spec (loads, stackup, fab profile, net classes: power, return, switching node, gate drive, sense, analog, clock, differential) and lists the stages this board needs. For each stage it names the engines that can take it: binary, ai, either, with the measured cost and time from past runs. The AI answers --take route=ai --take pour=binary or accepts the defaults. The decision and who did each stage go into the run manifest (provenance for comparison charts).
• place (pack a part into a legal spot by real courtyards, move parts, keep the interface fixed), route (the grid A* router: escapes, plane stubs, per-net vias, rip-up, multi-pass, Kelvin taps), pour (zones and keepouts from a pours config), analyze current (cross-sections and IR drop per net from the load budget), analyze thermal, analyze impedance, analyze loops (switching loop area, dv/dt node size), sim pre and sim post (ngspice through the KiCad export verbs, issue #89), gate (KiCad DRC offline, inherited errors separated), land (replay through the bridge as undo steps), measure (filled copper per layer, the ablation metric).
• Every stage returns hints that depend on this board ("routing closed at 57 of 59; the two open pins are boxed by R27 and TP2; move them or take the stage yourself"). That is the dynamic part of the skill; the static SKILL.md says when to run which stage and what the hints mean.

Scoring: the wiki keeps per-engine per-stage outcomes (time, tokens, dollars, unconnected, DRC, copper kept). Defaults flip per stage on evidence as models improve; a model that says "I'll take routing" takes it, and the manifest records it.

Order of work:

1. 0.1, first days: package what exists now (ai_router.py, escboard.py, write_copper.py, route_live.py, pack_moves.py, move_footprints.py, add_pours.py, add_planes.py, adjust_live.py, pours_live.py, make_placement_fixture.py) behind the adom-boardflow command with the hint contract and the plan/take negotiation, Python for now, so both Claude and Codex stop rewriting it. Configs replace the ESC-specific constants (wide nets, planes, Kelvin pairs, pour regions).
2. 0.2: Rust port of the router core (passes are six to eight minutes each in Python; a compiled core is the difference between one run and ten), plus the analysis passes (current, thermal), then impedance and loops.
3. Cross-link: index in the shared EDA skillpack (eda-engineering issue #1), point kicad-autorouting and kicad-copper-pours at it, and offer Astra the same tool through its skills.

Evidence the design is right: the ESC demo page on this site, Round 2 and the pours round (three engines, the loop back to placement, the Kelvin taps, the copper numbers).