copperpour stored as one pcb_copper_pour per fill fragment: KiCad export emits a zone per fragment and refills destroy the pour

[maci0]

A single <copperpour> whose fill is split by traces produces one pcb_copper_pour record per disjoint fill fragment, and the KiCad exporter (correctly, given its input) emits one (zone) per record. On a real board we got 65+ GND zones from one pour. Minimal repro (a full-width trace splits the pour; GND anchors on both sides keep both fragments):

export default () => (
  <board width="20mm" height="20mm">
    <resistor name="R1" resistance="1k" footprint="0402" pcbX={-9} pcbY={-5} />
    <resistor name="R2" resistance="1k" footprint="0402" pcbX={9} pcbY={-5} />
    <resistor name="R3" resistance="1k" footprint="0402" pcbX={0} pcbY={5} />
    <trace from=".R1 > .pin2" to=".R2 > .pin1" />
    <trace from=".R3 > .pin1" to="net.GND" />
    <via connectsTo="net.GND" holeDiameter="0.3mm" outerDiameter="0.6mm"
         fromLayer="top" toLayer="bottom" pcbX={0} pcbY={-8} />
    <copperpour connectsTo="net.GND" layer="top" clearance="0.3mm" />
  </board>
)

Circuit json: 2 pcb_copper_pour records (brep outer rings spanning y[-9.7,-5.38] and y[-4.62,9.7]). KiCad export: 2 zones, each (net_name GND), each outline being one fragment's computed fill shape.

Expected: one zone per <copperpour> whose outline is the requested pour region, with the fill left for KiCad to compute.

Why it matters: in KiCad the zone outline is design intent and the fill is derived. With outline == previous fill fragment, any refill (edit + B, or a pcbnew script) reapplies clearances inside the already-shrunk outline, so copper shrinks every refill and fragments that split further are deleted as islands. Dozens of independent zones per pour also make the file uneditable, and a script that unions fragments into one zone cannot save the result (a KiCad zone keeps a single outline).

Cause: CopperPour.doInitialPcbCopperPourRender (lib/components/primitive-components/CopperPour/CopperPour.ts:73-87) inserts one record per solver brep_shape, drops the source region, and the records carry no id linking them to the pour element, so downstream cannot even union them per pour.

Suggested fix: store the requested pour region on the pcb_copper_pour (one record per pour element), with the solver's computed fragments in a separate fill field or in records referencing the pour id, so viewers render fills while exporters emit the region.

[techmannih]

Hey @maci0 , thanks for reporting, we will take a look

[DPS0340]

Reproduced on current main with the exact snippet from the report:

pour record count: 2
pcb_copper_pour_id: [ pcb_copper_pour_0, pcb_copper_pour_1 ]
pcb_group_id:       [ undefined, undefined ]

Two things confirmed beyond the original report:

1. CopperPour.doInitialPcbCopperPourRender inserts one record per solver brep_shape and drops the requested region, as described.
2. It also never sets pcb_group_id, unlike every other PCB primitive (PcbVia, CourtyardRect, SilkscreenPath, Hole, Port, PcbNoteDimension all pass this.getGroup()?.pcb_group_id). So today there is genuinely no field on the emitted records that ties fragments back to their source <copperpour> — downstream can't union them even as a workaround.

I'd like to fix this, but the shape of the fix is a circuit-json schema decision rather than a core-only change, so I don't want to guess. PcbCopperPourBRep currently has no field for the requested region:

interface PcbCopperPourBRep {
  type, pcb_copper_pour_id, covered_with_solder_mask,
  pcb_group_id?, subcircuit_id?, layer, source_net_id?,
  shape: "brep", brep_shape
}

Three options, in increasing scope:

• A — one record per pour, region as outline + fragments as fill. Matches the suggested fix and what KiCad wants (outline = design intent, fill derived). Needs a new fill field in circuit-json and updates in viewers that currently treat brep_shape as the fill.
• B — keep one record per fragment, add a parent id (e.g. source_copper_pour_id) so exporters can union per pour. Smaller schema delta, keeps existing rendering intact, but exporters still do the union work.
• C — core-only stopgap: populate pcb_group_id like the other primitives. Cheap and consistent, but it does not solve this issue — a board-level pour has no group, so it stays undefined in the repro above. Worth doing separately for consistency regardless.

I'm set up to implement whichever you prefer (repro test + KiCad-export assertions included). @techmannih @seveibar — do you want A, or is B the preferred near-term shape given the viewer impact?

[DPS0340]

Opened #2829 as a partial step here — flagging it so the two don't get conflated.

It only fixes the second of the two problems I described above: CopperPour was the one PCB primitive that never set pcb_group_id, unlike PcbVia, CourtyardRect, SilkscreenPath, Hole, Port and PcbNoteDimension. So pours inside a <group> came out ungrouped:

before:  via group: ["pcb_group_0"]   pour group: [undefined]
after:   via group: ["pcb_group_0"]   pour group: ["pcb_group_0"]

It does not close this issue. A board-level <copperpour> has no enclosing group, so the repro in the original report still emits 2 records with pcb_group_id: undefined — the fragments still can't be tied back to their source pour. That needs the circuit-json schema decision (options A/B/C in my earlier comment), which I'm still happy to implement once someone picks a direction.

Merging #2829 independently seems safe to me since it's a 1-line consistency fix with its own regression test and doesn't constrain whichever schema option you choose later. But if you'd rather land the whole thing at once, I can hold it and fold it into the eventual fix instead — just let me know.