Autorouter emits overlapping GPIO35/PSRAM vias causing a deterministic short

[seveibar]

Summary

tsci check shorts found a deterministic short in the SPI display/webcam interceptor board after routing. The short is between two different autorouter connections, not a copper-pour-only artifact:

• source_trace_155__source_trace_156_mst1_0 (GPIO35 / BOOT) places a 0.6 mm via at (6.539759, 4.785715) from top to inner2.
• source_trace_126__source_trace_127__source_trace_128__source_trace_130__source_trace_132_mst0_0 (PSRAM power) places a 0.6 mm via at (6.190585, 4.298298) from inner1 to top.

The via centers are only 0.567 mm apart, below the 0.700 mm center spacing needed for two 0.6 mm pads with 0.1 mm clearance. Because both vias touch top and inner1, tsci check shorts reports the same short on both layers. The short report contains route/via geometry from the two connections and no copperpour:* group.

Reproduction input

The phase-0 SimpleRouteJson input dumped from the board is here:

https://gist.github.com/seveibar/5033268f8e1b21e34216dc96bfed2adc

The input has 93 connections and 328 obstacles. The affected endpoints are:

source_trace_130: pcb_port_247 (7.24, 5.00) -> pcb_port_94 (5.49999, 5.025018)
source_trace_156: pcb_port_93 (5.49999, 4.675006) -> pcb_port_273 (11.199928, 15.425072)

The board was using @tscircuit/capacity-autorouter@0.0.817. The failing route output is the frozen autorouter output in the board repository's routing.json; the two via records above are the exact records that trigger the checker.

Expected behavior

The autorouter should either keep different-net via pads at least the requested clearance apart or report that the connections could not be routed. It should not return a route containing overlapping different-net copper.

Workaround

Moving the PSRAM via to (6.25, 4.25) in the post-routing route adjustment makes tsci check shorts pass and leaves placement and hard DRC clean.

[obmakesomething]

Update with a current-upstream replay, plus one correction to the evidence boundary.

I replayed the issue's exact phase-0 gist (93 connections / 328 obstacles) against current tscircuit/tscircuit-autorouter@6c3fe1d6dc9b456598ea435127978efe77b249da using the repository's own scripts/run-sample.ts --pipeline 7 runner and its built-in relaxed DRC.

Result:

pipeline status: solved
command exit: 0
relaxed DRC: FAIL
DRC errors: 12

So current main still produces a route that violates clearance contracts on this exact input. However, the specific published GPIO35/PSRAM via-via pair from the issue body did not appear among the current final DRC errors. The current errors are 6 via↔trace and 6 pad↔trace clearance failures; the PSRAM aggregate connection appears in a pad↔trace failure, but not as the historical via↔via short.

That changes the precise evidence status:

• historical published GPIO35/PSRAM geometry: CONFIRMED FAIL (published coordinates recompute to ~0.5996 mm, still < 0.700 mm)
• current main on exact issue input: CONFIRMED ROUTE-LEVEL DRC FAIL, but historical specific via-via failure NOT REPRODUCED in the final DRC set
• stated (6.25, 4.25) workaround: NOT_EVALUATED without comparable post-adjust route/via records
• causal stage for the historical pair: NOT LOCALIZED

I also checked the current high-density acceptance code: it already computes via-to-via gap and requires minGap >= obstacleMargin, so a patch based on “the solver simply ignores via-via clearance” would target a falsified root-cause hypothesis.

Durable replay receipt is being recorded in my external verification harness. I would still appreciate the post-adjust routing.json excerpt if available; it is the missing comparison needed to reconcile the workaround claim with the published geometry.