Fix cramped port point HD polyline acceptance

[seveibar]

Motivation

• The Multi-Head HD polyline solver was rejecting valid layouts when port points (endpoints) were very close together or cramped at the node border, causing false negative acceptance even though the only remaining clearance violation was inherent to fixed endpoint spacing.

Description

• Add computeRequiredMinGapBtwPolyLines to estimate a per-pair minimal required gap based on fixed start/end port spacing so the solver doesn't demand the global obstacleMargin when it is impossible due to fixed endpoints (added to MultiHeadPolyLineIntraNodeSolver).
• Change checkIfSolved to compare computed minGaps against the per-pair required minimums rather than the global obstacleMargin for all pairs, allowing acceptance when the only bottleneck is unavoidable endpoint spacing.
• Relax boundary-padding checks for control points adjacent to endpoints so those control points may inherit the border clearance already enforced by their fixed start/end port points, avoiding rejection of otherwise valid candidates.
• Add a regression test tests/multi-head-hd/hdpolyline12-cramped-port-points.test.tsx reproducing the reported cramped mixed-layer case and asserting the solver now solves it.

Testing

• Ran bun test tests/multi-head-hd/hdpolyline12-cramped-port-points.test.tsx and the test passed (solver now solves the cramped case).
• Ran bun test tests/multi-head-hd/same-net-coincident.test.tsx tests/multi-head-hd/hdpolyline12-cramped-port-points.test.tsx and both tests passed.
• Ran type-check with bunx tsc --noEmit which succeeded.
• Ran code formatting with bun run format (biome) which completed.

---

Codex Task

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
capacity-node-autorouter	Ready	Preview, Comment	Mar 23, 2026 2:03am

[tscircuitbot]

🏃 Benchmark This PR

Run benchmarks by commenting on this PR:

/benchmark [benchmark.sh args...]

Everything after /benchmark is forwarded directly to ./benchmark.sh.

Examples:

• /benchmark -> AutoroutingPipelineSolver, all scenarios (default concurrency uses the benchmark runner CPU count)
• /benchmark AutoroutingPipelineSolver -> one solver, all scenarios
• /benchmark all 20 -> all solvers, first 20 scenarios
• /benchmark AutoroutingPipelineSolver 20 --concurrency 8 -> one solver, 20 scenarios, 8 workers
• /benchmark AutoroutingPipelineSolver 20 --effort 2 -> one solver, 20 scenarios, 2x effort
• /benchmark AutoroutingPipelineSolver --dataset zdwiel -> one solver, all scenarios, zdwiel dataset
• /benchmark all 20 --dataset dataset01 --concurrency 8 -> all solvers, 20 scenarios, dataset01, 8 workers
• /benchmark --pipeline 4 -> same as ./benchmark.sh --pipeline 4

Any PR whose title contains [BENCHMARK TEST] will automatically run the benchmark workflow on PR updates.

[github-actions]

This PR has been automatically marked as stale because it has had no recent activity. It will be closed if no further activity occurs.

[github-actions]

This PR was closed because it has been inactive for 1 day since being marked as stale.