Add same-net trace combining phase

[janishahn]

/claim #29
/claim #34

Summary

• add SameNetTraceCombiningSolver as a post-cleanup pipeline phase
• snap close overlapping same-net horizontal/vertical internal trace segments onto a shared run
• preserve pin endpoints, leave different-net traces unchanged, and reject snaps that would cross different-net traces or chip obstacles
• feed combined traces into downstream net-label placement and example phases

Proof

• focused solver tests cover the same-net merge reproduction, different-net non-merge behavior, and chip-obstacle rejection
• full GitHub checks are green: test, format-check, type-check, and Vercel
• the automated Codex review concern about chip/body obstacles was addressed in the latest pushed commit

Verification

• npx -y bun@latest test tests/solvers/SameNetTraceCombiningSolver/SameNetTraceCombiningSolver.test.ts
• npx -y bun@latest test
• npx -y bun@latest run build
• npx -y bun@latest run format:check

[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 10, 2026 6:45pm

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e9c66a977b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve obstacle clearance when snapping same-net segments

The snap acceptance path only rejects moves when crossesDifferentNetTrace(...) is true, then immediately commits tracePath: simplifyPath(nextPath), so this phase can shift a segment into a chip/body obstacle without any geometry guard. Because the pipeline wires this solver with only traces (no inputProblem obstacles), dense layouts can regress from valid routed traces to traces that cut through components after this phase, which downstream steps do not re-validate.

Useful? React with 👍 / 👎.

[janishahn]

Fixed in 7223eee. The pipeline now passes inputProblem into SameNetTraceCombiningSolver; the solver builds chip obstacle rects with the existing getObstacleRects helper and rejects candidate snaps when any changed segment intersects a chip obstacle. Added a focused regression for this case.

Verification:

• npx -y bun@latest test tests/solvers/SameNetTraceCombiningSolver/SameNetTraceCombiningSolver.test.ts
• npx -y bun@latest test
• npx -y bun@latest run build
• npx -y bun@latest run format:check

[janishahn]

Reproduction/proof note for #29/#34:

• The focused test snaps close same-net internal segments onto a shared run reproduces the issue with two same-net traces whose overlapping horizontal runs are separated by 0.1 units (y=0 and y=0.1). After SameNetTraceCombiningSolver, the movable internal segment is snapped onto the shared y=0 run while preserving both pin endpoints.
• leaves close segments on different nets unchanged verifies the same geometry is not merged across nets.
• rejects snaps that would cross a chip obstacle covers the automated review concern: a candidate snap that would cross a chip/body rectangle is rejected.
• Full PR checks are green: test, format-check, type-check, and Vercel.

This is why the same implementation claims both /claim #29 and /claim #34: the behavior is the close same-net segment merge / same-X-or-same-Y normalization requested in both issues.