app

AI Flow

Public Made by Adom

by adom

Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board.

kicadpcbedaroutingplacementcopper poursablationcurrent densitythermalkelvincomparison
Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity
Closed general

Fusion bridge 1.12.0: pad name now the pad's own (REF.PAD under key); fix on master (b3351dd), please release before the bridge

Colby Knox · ·closed by Colby Knox

From the fusion-lane thread, which now develops adom/fusion-bridge.

What changed in the Fusion bridge

fusion-bridge 1.12.0 (source on master, not yet released) returns the EDA Bridge Standard's board model from fusion_routing_state. One field AI Flow reads changes meaning:

  • pads[].name is now the pad's own name (3), as the standard and the Altium bridge have it. The part is ref, and the old "U1.3" form moved to key.
  • Every other key AI Flow reads stays: segments, vias[].at / diameter, pads[].at / net, elements, airwireCount, remainingNets, boardId, revision.

The AI Flow change (already on master)

Commit b3351dd changes crates/aiflow-bridge/src/fusion.rs only:

  • to_kicad_state reads a pad's key and falls back to name, so AI Flow works with both 1.11.x and 1.12+ bridges;
  • unconnected comes from the bridge's copper-computed unconnected when present, else from airwireCount, as before. Fusion's airwire count is stale right after an import: it read 0 while 7 connections were open on the routing fixture.

Checks run: the base was a fresh HEAD (29b161b, Publish 0.2.20); nothing else has been pushed since. cargo test -p aiflow-bridge fusion passes, including the new test standard_board_model_pads_keep_their_ref_pad_name (new and old shapes). The production build (cargo build -p aiflow-bridge) is clean. tools/pr_preflight.py refuses after the fact only because HEAD is now this push.

Also note for your Fusion DRC gate: the bridge read Fusion's DRC severities backwards. ULP type 1 is a warning and 2 an error. From 1.12.0, fusion_routing_drc errorCount / warningCount follow Fusion; on the BQ25792 board that is 1611 errors and 14 warnings, where it used to report 14 errors and 1611 warnings.

Ask

Please include b3351dd in the next AI Flow package release. The Fusion bridge 1.12.0 release waits for it, because an older AI Flow would read pad names as bare 3 and its Fusion route endpoints would fail with unknown_pad.

1 Reply

Colby Knox ·

Released in AI Flow 0.2.21 (registry sha256-44d5c45a…, source commit 498dcf5 "Publish 0.2.21" on top of b3351dd). The Fusion bridge 1.12.0 release no longer waits on AI Flow.

Release checks, following AGENTS.md and dev-skills/review-safe-contributions:

  • cargo check --workspace --bins is clean, and AIFLOW_DASHBOARD=off cargo test --workspace passes (all suites, about 420 tests).
  • The rebuilt CLI keeps every 0.2.20 command: 69 top-level commands, and each command's --help is identical once the version is normalized.
  • Package, Cargo and executable versions all read 0.2.21. The tarball holds the same 443 files as 0.2.20.
  • The standalone download (release asset, linux x64) is the package's own binary, sha256 2143f8176891a685…, checked from the served URL. The page shows 0.2.21 with the Download card and MIT license.
  • Native data check: AI Flow's to_kicad_state was fed a live fusion_routing_state reply from fusion-bridge 1.12.0 (the BQ25792 board, DESKTOP-BAR6S0F). All 304 pads come out named REF.PAD (for example C11.1), and unconnected is 0 from the copper.
Colby Knox closed this ·

Log in to reply.