Keep selective rerip repairs local with additive resource search

[seveibar]

Selective reripping currently searches a Pareto frontier of distinct blocker-owner sets. Large graphs can spend substantial time enumerating those sets, then discard nearly complete routing because old owner dependencies form a cycle even after the owners have moved.

Use one shortest-path label per directed hop, minimizing occupied resource uses before routing cost. Repeated conflicts increase the cost of the resource that caused them, allowing the search to move past a repeating local conflict. Every owner encountered by the selected path remains in its rip set. Remove those owners and commit the cleared witness after rechecking every hop with the ordinary hard-constraint cost function. Other committed routes remain in place. This removes the historical-cycle and alternate-owner branches and avoids searching the newly cleared route again.

Relaxed search now includes static port penalties, congestion history, and the cost of a layer change in its secondary routing cost, so the witness does not ignore expensive cramped ports or via demand.

Ordinary routing uses a cached reverse shortest-path lower bound that includes port costs, reservations, and occupied ports. Adding routes can only remove available edges; removing routes clears the cache so that reopened corridors are available again. The relaxed search ignores entry direction and region crossings, and its cache follows the active goal, including partial-route goals.

The reverse search is resumable: it settles only the ports requested by ordinary A*, retaining its original occupancy snapshot until a rip invalidates it. Its indexed priority queue stores each unsettled port once, decreases priorities in place, and skips already-settled neighbors. This avoids stale heap entries and repeated distance work without changing edge costs or route selection.

Completed routing rounds retain the lowest region cost. The former segment-count selection could replace a substantially less congested route with a slightly shorter route, as long as both were below a ceiling derived from the first routing round. Removing that comparison eliminates 27 lines of selection logic.

A rejected or deferred goal transition no longer stops expansion of the other exits in its region. A six-port regression verifies that the router can go around a blocker and reach the goal through its other incident region without reripping.

Stacked on fix/preload-preservation-on-current-pin (c1043b3), the dependency revision used by the autorouter. Caller-owned initial-assignment preservation remains unchanged.

Validation: all 135 tests (7,990 assertions, including the existing routing snapshot) and the full TypeScript project pass. A deterministic queue regression covers priority decreases, ties, removal, and reinsertion; the occupied-port and resumed-search regressions remain unchanged. Captured production graph replays for SRJ18 samples 4, 6, and 12 preserve every routing iteration, statistic, and byte of route output. In sequential Linux ARM/Bun 1.4.2 replays, sample 12 drops from 39.95 to 22.25 seconds; native sample 6 drops from 22.65 to 18.74 seconds and sample 4 from 1.145 to 1.005 seconds. These are pathing diagnostics, not a claim about the complete hosted benchmark.

The pathing changes complete ordinary hard-constrained SRJ18 graph routing for samples 14 and 15 within the existing 2,000,000-iteration budget, without reaching the greedy final phase. True end-to-end autorouter runs on the preceding static-heuristic revision confirm graph completion but still have downstream DRC errors. Current full-board quality and performance validation is ongoing for the follow-up to tscircuit/tscircuit-autorouter#2442; this dependency PR does not claim the final >90% benchmark result.

[vercel]

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

Project	Deployment	Actions	Updated
tiny-hypergraph	Ready	Preview	Sep 8, 2026 6:44am UTC

[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.
Every command runs current main and the PR head sequentially on the same Blacksmith machine, then reports their results side by side.

Examples:

• /benchmark -> all committed completed SRJ18 Pipeline7 cases, core solver
• /benchmark --limit 4 -> first four committed Pipeline7 cases
• /benchmark --dataset srj18 --concurrency auto -> srj18 samples with runner CPU-count concurrency
• /benchmark --sample sample003 -> one committed SRJ18 Pipeline7 case
• /benchmark --dataset hg07 --limit 20 --solver poly -> first 20 hg07 samples with the poly solver
• /benchmark --dataset hg07 --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.