Negotiate capacity-aware region paths

[ShiboSoftwareDev]

Problem

RegionPathSolver estimated capacity from a region's area and did not reserve the physical port-points between neighboring regions. A large region could therefore look almost unlimited even when the boundary leading out of it had only one usable lane.

The planner is greedy, so a flexible net could take that one-lane boundary first. A constrained net would then be assigned to the same boundary, leaving the detailed router with an impossible pair of coarse paths.

Fix

• Derive a region's pass-through capacity from its real boundary port-points. One route needs an entrance and an exit.
• Give each region boundary its exact port-point capacity.
• Count distinct nets, because routes on the same net may share copper.
• If a planning pass overbooks a region or boundary, add historical congestion cost and plan again. This moves flexible nets while preserving the only path available to constrained nets.
• Use the resulting region paths as corridors for detailed routing. A failed detailed search expands by one region, then two, then falls back to the full graph, so the coarse plan is guidance rather than a hard restriction.

No ports, regions, or via locations are synthesized.

Snapshot

This is the same fixture and snapshot introduced in #153. The constrained blue net keeps the center path, while the flexible magenta net uses the real upper detour. Every used boundary is now within its physical capacity (1/1 nets).

Validation

bun test tests/solver/region-path-solver.test.ts tests/solver/region-path-capacity-negotiation.test.ts --timeout 9999999
5 pass, 0 fail

The downstream srj24 sample 4 integration reached the next pipeline phase with all 841 port-point routes resolved. The full benchmark will be run from the stacked autorouter PR so it uses the repository's GitHub Actions benchmark environment.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
tiny-hypergraph	Ready	Preview	Aug 7, 2026 1:11pm

[tscircuitbot]

Benchmark This PR

Run benchmarks by commenting on this PR:

/benchmark [benchmark.sh args...]
/benchmark --dataset <hg07|srj18> --limit <n> --solver <core|poly> --families <default|default+deep|all> --concurrency <n|auto>

Everything after /benchmark is forwarded directly to ./benchmark.sh.
The result comment shows the matching dataset from the latest stored main-branch benchmark artifact beside the PR run; main is not rerun for each PR benchmark request.

Examples:

• /benchmark -> hg07, all samples, core solver
• /benchmark --dataset srj18 --limit 20 -> first 20 srj18 samples
• /benchmark --dataset srj18 --concurrency auto -> srj18 samples with runner CPU-count concurrency
• /benchmark --sample sample002 -> one hg07 sample
• /benchmark --limit 20 --solver poly -> first 20 hg07 samples with the poly solver
• /benchmark --limit 40 --families default+deep -> first 40 hg07 samples with deeper candidate families

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