Make the KiCad lane match the Altium lane: silkscreen over pads should be reported, not block finish

Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity

Closed feature request

Colby Knox · 22d ago ·closed by John Lauer

adom-aiflow 0.2.17 (wiki head) · altium-bridge 0.2.66 · KiCad lane via KiCad Bridge

The two lanes disagree on silkscreen over pads

The KiCad lane blocks a board on silkscreen findings; the Altium lane only reports them. The same board passes finish in Altium and fails it in KiCad.

KiCad lane: SILK_BLOCKING in crates/aiflow-copper/src/lib.rs:600 (silk_over_copper, silk_overlap, silk_edge_clearance, text_height, text_thickness) makes gate and finish refuse the board (SKILL.md, "Silkscreen the fab would clip blocks the board (0.1.62)").
Altium lane: crates/aiflow-bridge/src/altium.rs:362 grades SilkToSolderMask / SilkToSilk / mask slivers as warnings ("reported, not a failed board"). The delivered TPS54202 buck board (2026-10-20 run) finished with 137 silk-to-mask hits, 48 silk overlaps and 8 mask slivers.

The decision (John, 2026-10-21)

I don't think the kicad Lane should block on that to be honest because all fabs just Auto trim that stuff so they should not be blocking. Perhaps that's just a default design rule and you can override that design rule when you load different design rules

So the request is to make the KiCad lane match the Altium lane: silkscreen findings are reported, not blocking.

Suggested change

gate and finish: grade the SILK_BLOCKING types as advisories (counted and listed in the report, never a refusal). Keep the other manufacturing checks blocking.
Update SKILL.md's 0.1.62 paragraph to say so. Its point that the fab trims ink stays true: that's the reason it doesn't block.
Keep the board looking clean anyway, because people do notice: a YouTube commenter on the Altium video pointed out silk over copper on the first-pass buck board. On the Altium side, altium-bridge will run Altium's own Tools » Silkscreen Preparation (PCB:ClipSilkScreen) automatically before fab outputs and renders. On the KiCad side, board-glb copper already renders the ink clipped at the mask openings; the silkscreen step moving labels off pads is the equivalent clean-up.

Optional

If a fab profile in the spec wants silk clearance enforced, it could opt back into blocking (John's "override that design rule when you load different design rules"). Without one, advisories only, on both lanes.

1 Reply

John Lauer · 20d ago

Done in adom-aiflow 0.2.19, as John decided: the KiCad lane now matches the Altium lane.

Reported, not blocking: silk_over_copper, silk_overlap, silk_edge_clearance, text_height and text_thickness no longer refuse the board in gate or finish, whatever severity the project gives them. They are counted and listed in gate.json, the gate outcome, the live-DRC record and the finish summary. adopt-board, place check and the pattern lane's verdict follow the same rule. Every other manufacturing check still blocks.
Opt back in: with "fab": {"silkBlocking": true} in the spec, or a # adom-aiflow: silkBlocking comment line in the board's .kicad_dru (John's "override that design rule when you load different design rules"). An explicit false in the spec wins over the rules file.
Docs: the 0.1.62 paragraph in SKILL.md now says the fab clips ink at mask openings, which is why it doesn't block. aiflow-silkscreen keeps the advice to move labels off pads so the board still looks clean.
Altium lane: unchanged. Its warning list also includes MinimumSolderMaskSliver and Height, which the KiCad change doesn't touch.
One gap: if a project grades silk rules as errors, the bridge's own routing-validate count in finish may still include them, because that count comes from the bridge.

Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.2.19.

John Lauer closed this · 20d ago