Add SameNetTraceCombiningSolver pipeline phase (#29)

[brone1323]

/claim #29

Closes #29.

Why a new phase

The existing trace solvers (SchematicTraceLinesSolver, TraceOverlapShiftSolver, TraceCleanupSolver) shape traces independently per MSP connection pair. When two pairs in the same net produce axis-parallel segments that happen to land close to each other (the three-pin row in the issue screenshot is the canonical case), the rendered schematic shows visually duplicated parallel lines instead of a single tree-like trace with a junction. TraceOverlapShiftSolver deliberately ignores same-net overlaps because shifting them apart isn't the right move — they should merge, not separate.

This is exactly the post-processing step the issue calls out, and it's the same observation seveibar made in tscircuit/tscircuit-autorouter#66: "good trace adjacency behavior (combining traces in the same net when they're nearby) is a bit better than thickness, and maybe a good idea to do prior to this."

Approach

New solver SameNetTraceCombiningSolver:

1. Group SolvedTracePaths by globalConnNetId.
2. For each group, walk every (segmentA, segmentB) pair drawn from distinct traces. Same orientation only — purely orthogonal segments are the only ones the existing pipeline emits and the only ones that visually duplicate.
3. Mergeability test: orthogonal distance < mergeDistance (0.15) AND parallel-axis overlap >= minOverlap (0.05). The pin grid in this project sits at 0.2 increments, so 0.15 catches visible duplication without crossing into legitimately distinct same-net runs.
4. The shorter segment is snapped onto the longer segment's axis. Anchoring on the longer segment minimizes downstream disturbance — the dominant trace doesn't move.
5. Junction recorded at the endpoint where the snapped segment rejoins the rest of its trace, so renderers can draw a dot at the branch.

Output extends the existing trace shape; only the geometry of tracePath is mutated (on a clone of the input — the upstream solvers' state is untouched).

Pipeline wiring

Inserted as a new pipelineDef step right after traceCleanupSolver. Downstream consumers (netLabelPlacementSolver, example28Solver) prefer the combined output via the existing ?? fallback chain, so if the phase is skipped or absent the pipeline still works exactly as before.

Tests

tests/solvers/SameNetTraceCombiningSolver/SameNetTraceCombiningSolver.test.ts covers four cases:

• Close-parallel same-net segments are merged onto a shared axis with a junction recorded.
• Segments from different nets are left alone even when they sit close together.
• Same-net segments well outside mergeDistance are left alone.
• Same-net segments that only touch at a single endpoint (no real overlap) are left alone.

All existing tests still pass; type-check is clean.

Files

• lib/solvers/SameNetTraceCombiningSolver/SameNetTraceCombiningSolver.ts (new)
• tests/solvers/SameNetTraceCombiningSolver/SameNetTraceCombiningSolver.test.ts (new)
• lib/solvers/SchematicTracePipelineSolver/SchematicTracePipelineSolver.ts (pipeline wiring)

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
schematic-trace-solver	Ready	Preview, Comment	May 6, 2026 8:20pm

[brone1323]

Demo video

▶ Watch demo (1.0MB MP4)

Generated programmatically (HTML deck → Playwright recordVideo → ffmpeg). Hosted as a release asset on the fork to comply with the Algora claim requirement.

Sammy / @brone1323