AI Flow

@@ -25,10 +25,10 @@ Router, same boards before and after (`route`, then `gate`):  These boards were stripped of copper and routed with `route` alone; route times did not go up (ESC 122 s to 96 s). StickHub reports more connections short while DRC finds fewer unconnected. Pad entries along the pad's own axis are not done for every pad, and some wiggles remain, so #127 stays open. -Checked live on Fusion, bridge 1.13.73, on a new board with no schematic:+Checked live on Fusion, on new boards with no schematic. Bridge 1.13.74 for the moves and for replacing a pour as it grows and shrinks; bridge 1.13.73 for the rest: - Bottom parts at MR0, MR90 and MR180 and a top part moved, with every pad where the run's board has it; landing twice changed nothing; a part flipped by hand stopped the landing by name. - `land pours`: landed, landed again with nothing added, changed outline replaced the old pour, a hand-drawn pour left alone, then adopted with `verify-pours --adopt` and replaced. - `fusion export` on a 4-layer board: 13 files including `.G1` and `.G2`. - With the test point's page blocked, `fusion library` used the bundled files and built the library. It stopped at the 3D upload, which was not run. -Not checked: the pour re-land on bridge 1.13.74, the bottom-part fix on a linked board, `place land` putting old pours back after a failed landing (unit test only), a 0-byte clip from a real failed pull (today's Adom Bridge leaves none), and the Altium lane, which writes bottom parts the same way and may land them at the wrong angle.+Not checked: `place land` on a board linked to a schematic (the bridge's own drill covers the same `MR` move there), `place land` putting old pours back after a failed landing (unit test only), a 0-byte clip from a real failed pull (today's Adom Bridge leaves none), and the Altium lane, which writes bottom parts the same way and may land them at the wrong angle.