test: repro #641 — interleaved GND/VCC brackets cross on the same chip edge

[DPS0340]

Reproduction PR for #641, following the repo's repro-first workflow. Uses bug-report-20260708T055430Z (already in the repo via #642 — the input JSON is byte-identical to the #641 attachment).

The defect

U_MCU's left edge interleaves GND and VCC_3V3 pins (3=GND, 4=VCC, 5=GND, 6=VCC). MspConnectionPairSolver pairs same-net neighbors, producing two bracket traces that each enclose a pin of the other net:

U_MCU.5-U_MCU.3  (GND)      spans y 14.7..15.1, encloses pin 4 (y 14.9)
U_MCU.6-U_MCU.4  (VCC_3V3)  spans y 14.5..14.9, encloses pin 5 (y 14.7)

Interleaved brackets on the same edge always cross — the GND/VCC rails short visually. Same family as repro-atmega328p-missing-gnd-netlabel, where the boxed-in bracket's label is silently dropped.

The test also pins this board's #674-family false junction (FAULT connector crossing U_MCU.18-R_FAULT_PULLUP.1), so both defects on this board are tracked.

A fix should eliminate the bracket-bracket crossing — likely by rendering interleaved same-edge rail pins with per-pin net labels instead of bracket traces. Happy to follow up with that fix PR once this repro lands.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
schematic-trace-solver	Ready	Preview, Comment	Jul 25, 2026 7:31am

[DPS0340]

Rebased onto current main (through #714). Note this one is intentionally a characterization test — it pins the current buggy crossing behavior so #641 is tracked by CI, so it passes on main by design rather than failing. Verified the expected crossings are still exactly the two documented ones after the rebase.

[DPS0340]

@mohan-bee thanks for the review on #700 — much appreciated.

If you have a spare minute, this one is even lighter: 1 file, +78/-0, no production code touched. It's purely a characterization test for #641.

Worth knowing before you look: it passes on main by design. It pins the current buggy behavior — U_MCU's left edge interleaves GND and VCC_3V3 pins, and MspConnectionPairSolver produces two bracket traces that each enclose a pin of the other net, so they always cross. The test asserts exactly the two crossings that exist today:

U_MCU.18-R_FAULT_PULLUP.1 x available-net-orientation-4-FAULT
U_MCU.5-U_MCU.3 x U_MCU.6-U_MCU.4

So it doesn't fix anything — it just makes #641 visible to CI so a future fix has a tripwire. If you'd rather this repo not carry known-failing behavior as a passing test, I'm equally happy to close it; no attachment either way.

[mohan-bee]

no snapshots.

[DPS0340]

@mohan-bee fixed in 05a5e7f — the repro now pins the board render too:

tests/repros/__snapshots__/repro-interleaved-bracket-crossing-641.snap.svg

The test was only asserting the crossing list, so it never rendered anything. Now both are covered, which is more useful here anyway since the whole point is that the two brackets visibly cross.

Full suite: 145 pass / 0 fail. Ready for another look whenever you have a moment.

[mohan-bee]

this is wrong .. please raise a bug report for repros and stuffs.

[DPS0340]

@mohan-bee understood, and you were right — my first attempt made it worse rather than better.

I read "no snapshots" as "please add a snapshot", so I added one. That was the wrong fix: the #641 board is already a bot-imported bug report at tests/bug-reports/bug-report-20260708T055430Z/, and that directory already carries its own snapshot test. My addition was just a second snapshot of the same board.

Fixed in e471260 — the extra snapshot is gone. The repro now only asserts the crossing list, which is the part specific to #641; the render stays pinned by the existing bug report.

If your point was broader — that a repro like this shouldn't live in tests/repros/ at all when the board is already covered by a bug report — I'm happy to just close this PR. The crossing assertion is only worth keeping if you want #641 tracked by CI; otherwise it's noise and I'd rather not leave it in your queue. Your call.

Full suite 145 pass / 0 fail.

[DPS0340]

@mohan-bee thanks for the reviews — both were right, and I've addressed the concrete part. Current state of this branch is a single file:

tests/repros/repro-interleaved-bracket-crossing-641.test.ts

No hand-made tests/bug-reports/ directory (that was my mistake on #703 and I've stopped doing it — #641's board already exists as the bot-imported bug-report-20260708T055430Z, so this repro imports that), and no duplicate snapshot.

Before you spend more time on it, I want to check the premise rather than keep pushing: this PR only pins current behavior, it doesn't fix #641. The assertion records that the interleaved GND/VCC brackets still cross:

"U_MCU.5-U_MCU.3 x U_MCU.6-U_MCU.4"
"U_MCU.18-R_FAULT_PULLUP.1 x available-net-orientation-4-FAULT"

If "this is wrong" meant characterization tests aren't wanted here — i.e. you'd rather see the actual fix (rendering interleaved same-edge rail pins as per-pin net labels instead of bracket traces) than a test that locks in the bug — then I'd rather close this and come back with the fix. Just say the word and I'll close it; no need to review further.

For context on the related ones: #703 fixes the #674 connector crossings, and #716 (stacked on it) takes that board from 3 crossings to 0. The second crossing listed above is from that family and goes away there.

[DPS0340]

@mohan-bee reworked this to match how repro-only PRs actually land here (7343e1d).

I went and looked at #691 — your merged repro-only PR for #687 — and copied its shape: a minimized input under tests/repros/assets/ plus a snapshot, instead of importing a bot-imported bug report directly. That's what I should have done from the start; sorry for the detour.

The scene is now one chip with just the four pins that cause the defect:

U_MCU.3 = GND      y 15.1
U_MCU.4 = VCC_3V3  y 14.9
U_MCU.5 = GND      y 14.7
U_MCU.6 = VCC_3V3  y 14.5

MspConnectionPairSolver pairs same-net neighbours, so it wires 3→5 and 4→6, and each bracket spans the other net's pin sitting between them — they can't not cross.

I also dropped the net-label orientations from the minimized scene, so the assertion is the interleaved-bracket crossing on its own with no label-driven routing mixed in. That takes it from the full board's 6 traces (including an unrelated FAULT crossing) down to 2 traces / 1 crossing.

Full suite 145 pass / 0 fail.

If you'd still rather not carry a known-failing behavior as a passing assertion, say the word and I'll close it — no attachment, I just didn't want #641 to be invisible to CI.

[DPS0340]

@mohan-bee following up once, then I'll act on whatever you prefer rather than keep pushing revisions.

Your second review said "this is wrong .. please raise a bug report for repros and stuffs", and I took that to mean repro-only PRs aren't wanted here. But I went and checked how repros actually land in this repo, and I want to make sure I'm not misreading you.

#695 (merged 2026-07-23, techmannih) — the most recent repro merge — has exactly the file shape this PR now has:

tests/repros/__snapshots__/repro-tps61222-trace-intersection.snap.svg
tests/repros/assets/repro-tps61222-trace-intersection.input.json
tests/repros/repro-tps61222-trace-intersection.test.ts

versus mine:

tests/repros/__snapshots__/repro-interleaved-bracket-crossing-641.snap.svg
tests/repros/assets/repro-interleaved-bracket-crossing-641.input.json
tests/repros/repro-interleaved-bracket-crossing-641.test.ts

Same three files, same layout. #619 (MustafaMulla29) and #588/#587/#589 (Sang-it, an outside contributor) are the same pattern.

So the structural objections from your first review are addressed, and the layout now matches what gets merged. That leaves two readings of your second comment and I'd rather ask than guess:

1. The repro itself isn't wanted — JSON Bug Report: #641's board is already bot-imported, so a separate hand-minimized repro is duplicate coverage. If that's it, I'll close this. No argument.
2. The repro is fine but should have come with the fix, not standing alone. If that's it, I'll close this too and come back with a PR that actually fixes the interleaved-bracket crossing, with this test as the regression guard.

Either way I'm not going to push another revision at you. Just tell me 1 or 2 — or close it yourself, which I'll read as (1) and take no offence at.

For context on why I care about the underlying bug rather than the PR: #641 is still open and unfixed, and the crossing it describes is reproducible on current main.