boards/external/softstart: re-attempt routing with current main (post #3120/#3124/#3128/#3131 unblockers)

[rjwalters]

Successor to #3085 (open, currently `loom:blocked`, scoping comment 2026-05-25 noted the named blocker #3117 resolved but did not lift the floor).

Why a fresh attempt now

Since the 2026-05-22 builder's last attempt on #3085, four architectural unblockers have merged that could collectively change the outcome:

• feat(router): lex-tuple primary key = nets_fully_connected (closes #3117) #3120 (PR feat(router): lex-tuple primary key = nets_fully_connected (closes #3117) #3120): lex-tuple primary key = `nets_fully_connected`. Best-snapshot now preserves the iteration with the most pad-connected nets, not the most route fragments.
• router: Optimizing-traces phase destroys best-state routes (segments 2147→192 = -91%) #3124 (PR fix(router): detect partial-net regressions in finalize, preserve micro vias #3126): finalize-phase regression detector. Optimize → drc-nudge → finalize no longer silently drops connectivity below the iter-N best.
• router: micro-via in-pad rescue for non-GND fine-pitch escape #3128 (PR router: micro-via in-pad rescue for non-GND fine-pitch escape #3128): micro-via in-pad rescue for non-GND clearance failures (router: micro-via for non-GND in-pad rescue (decomposed from #3094-a) #3118). The U1-13 `via_in_pad` error on `GATE_POS` (one of softstart's named errors per boards/external/softstart: router completes only 3/10 signal nets (post #3050 repair) #3085 body) is exactly the case this PR addresses — for jlcpcb-tier1 boards.
• feat(router): C++ pathfinder per-net trace width / via emit (closes #3130) #3131 (PR feat(router): C++ pathfinder per-net trace width / via emit (closes #3130) #3131): C++ per-net trace/via widths. Power rails can now have wider traces.

The prior builder concluded softstart hit a 4/10 fully-connected floor. With these merged, the floor may have risen — or the via_in_pad error may have disappeared entirely.

Critical first step

Empirically re-route softstart with current main BEFORE filing scope. Run:

uv run python boards/external/softstart/generate_design.py
kct check --mfr jlcpcb-tier1 boards/external/softstart/output/
kct fleet status --boards-dir boards/external

Capture:

• Routing reach (fully-connected nets out of 10)
• DRC error count + categories
• ship_ready boolean

If the result is now ship_ready: close #3085 directly.

If still failing, narrow the scope

The original prior-builder analysis (2026-05-22) suggested three independent paths. After re-running, pick the one most likely to close the gap:

1. Manufacturer profile: switch `boards/external/softstart/softstart.kicad_dru` to `jlcpcb-tier1` (allows via-in-pad). With router: micro-via in-pad rescue for non-GND fine-pitch escape #3128 the via_in_pad case is now routable; this switch should be evaluated.
2. Placement spread: prior builder's 9/10 fragments → 5/10 final result on attempted spread. With feat(router): lex-tuple primary key = nets_fully_connected (closes #3117) #3120 + router: Optimizing-traces phase destroys best-state routes (segments 2147→192 = -91%) #3124, the spread may now hold.
3. Trace clearance tightening: 0.3 mm → 0.127 mm (DRU minimum).

Acceptance criteria

1. `uv run python boards/external/softstart/generate_design.py` exits 0.
2. Routing reach ≥ 9/10 fully-connected signal nets.
3. DRC error count ≤ 3 (or all in documented allowlist).
4. `kct fleet status --boards-dir boards/external` reports softstart as ship_ready.
5. Manufacturer bundle regenerated.

Out of scope

• Schematic changes (already PASS post-boards/external/softstart: 39 ERC errors + 5 single_pad_net DRC errors (netlist drift?) #3050).
• Router algorithm changes beyond what's in main.
• New manufacturer profile creation.

References

• Predecessor (open, loom:blocked): boards/external/softstart: router completes only 3/10 signal nets (post #3050 repair) #3085
• Architectural unblockers: router: lex-tuple metric counts route fragments not fully-connected nets (blocks #3085) #3117/feat(router): lex-tuple primary key = nets_fully_connected (closes #3117) #3120, router: Optimizing-traces phase destroys best-state routes (segments 2147→192 = -91%) #3124/fix(router): detect partial-net regressions in finalize, preserve micro vias #3126, router: micro-via for non-GND in-pad rescue (decomposed from #3094-a) #3118/router: micro-via in-pad rescue for non-GND fine-pitch escape #3128, router: C++ pathfinder per-net trace width support (blocks M-E ship_ready on board 05) #3130/feat(router): C++ pathfinder per-net trace width / via emit (closes #3130) #3131
• Schematic predecessor: boards/external/softstart: 39 ERC errors + 5 single_pad_net DRC errors (netlist drift?) #3050.
• Memory: `project_routing_gaps_2026_05` (general routing completion gaps).

Estimated ~100 LOC.

[rjwalters]

Curator notes (2026-05-27) — empirical re-route on current main

Ran the prescribed first step on this worktree at commit 2bb1670e (HEAD of main), C++ backend built and verified.

Empirical baseline

$ time uv run python boards/external/softstart/generate_design.py
...
=== Negotiated Routing Complete ===
  Successful: 9
  Final overflow: 15
  Total time: 199.8s
...
   PARTIAL: Routed 4/10 signal nets

real    3m23.68s
user    3m25.40s

$ uv run kct check --mfr jlcpcb boards/external/softstart/output/softstart_routed.kicad_pcb
  Errors:     23
  Warnings:   0
  connectivity: 15 errors
  clearance_pad_segment: 6 errors
  clearance_segment_via: 1 error
  via_in_pad: 1 error  <-- U1-13 GATE_POS, (117.800, 76.600)

$ uv run kct check --mfr jlcpcb-tier1 boards/external/softstart/output/softstart_routed.kicad_pcb
  Errors:     22
  connectivity: 15 errors
  clearance_pad_segment: 6 errors
  clearance_segment_via: 1 error
  (via_in_pad: 0 — confirms #3128 path works)

$ uv run kct fleet status --boards-dir boards/external
softstart   35/94   37%  -  -  -  NO  (incomplete routing (15/21 nets))

ship_ready: NO. Result is identical-magnitude to the 2026-05-23 builder's run (routed_count=9, nets_fully_connected=4, ~23 DRC errors). The 4/10 fully-connected floor has not moved.

Which unblockers actually changed the outcome

PR	Mechanism	Effect on softstart
#3120 (lex-tuple nets_fully_connected primary)	Best-snapshot now keyed on pad-connectivity	Active and validated — restores iter-0 state correctly. But iter-0 itself is only 4/10 connected, so the lifted floor is the same. No improvement.
#3124 / #3126 (finalize-phase regression detector)	Prevents optimize→drc-nudge→finalize from dropping below best	Likely firing silently. Final count = iter-0 count (4), so the regression detector is doing its job. No further improvement available beyond what iter-0 produces.
#3128 (micro-via in-pad rescue for non-GND)	Allows via on pad for jlcpcb-tier1/pcbway profiles	Confirmed: switching --mfr from jlcpcb to jlcpcb-tier1 drops the 1 via_in_pad error to 0. But this is just relabeling the existing routed via — the rescue isn't being invoked during routing because the generator hard-codes jlcpcb as the manufacturer (line 1606: "2-layer, 2oz copper, JLCPCB target"). Net DRC count under tier-1: 22 (still 15 connectivity + 6 clearance_pad + 1 clearance_segment_via).
#3131 (C++ per-net trace/via widths)	Power rails can have wider traces	Not exercised: this generator's route_pcb() builds a single uniform DesignRules(trace_width=0.3, trace_clearance=0.3, ...) (lines 1621-1627), skips all power nets via skip_nets (lines 1637-1642), and never invokes per-net widths. No effect.

Bottom line: only #3128 has a measurable effect, and even that only renames an existing error rather than unblocking new routing. The remaining 15 connectivity + 6 clearance_pad + 1 clearance_segment_via errors are all on signal nets the router cannot connect at iter-0.

Which prior 2026-05-22 findings are still ground truth

The 2026-05-22 builder's analysis is unchanged where the underlying code hasn't changed:

• Placement is unchanged from boards/external/softstart: router completes only 3/10 signal nets (post #3050 repair) #3085 baseline: generate_design.py:1048-1071 is byte-identical to what the 2026-05-22 and 2026-05-23 builders saw (U1 at y=75, D2/R12 east at y=70/76, J5 at x=142, C2-C4 at 6mm pitch, SW1 row at y=90). The spread experiment they ran (D2/R12 north to y=64, J5 to x=148, C2-C4 to 9mm pitch, SW1 row to y=94, U4+C6-C8 west to x=70-78) was never committed. Their finding stands: "iter 0: Routed 9/10 nets, overflow: 15" with the spread, but only +1 pad-connectivity net (4→5) on the 2026-05-23 retry.
• DRU file is generic, not tier-0 specific: boards/external/softstart/softstart.kicad_dru (32 lines, audited above) defines min track 0.127mm, clearance 0.127mm, via 0.6/0.3mm — these match jlcpcb-tier1 minima. The "tier-0 forbids via-in-pad" effect comes from --mfr jlcpcb (the runtime profile), not from the DRU file. So "switching the DRU to tier-1" is a misnomer — the actual switch is in kct check's --mfr flag (and any embedded manufacturer-profile call in the generator).
• Trace clearance hard-coded at 0.3mm: route_pcb() line 1623-1624 uses trace_width=0.3, trace_clearance=0.3. DRU minimum is 0.127mm. The router is voluntarily using ~2.4× the minimum clearance. Tightening to 0.2mm or 0.15mm would widen channels in the MCU cluster significantly.
• Root cause unchanged: dense MCU cluster (U1 TSSOP-20 + U4 SOT-223 + 7 decoupling caps + SWD header + status LED in ~30×20mm region). RSMT partial-fragment problem on 3-pad nets (ZC_DETECT, GATE_NEG, STATUS_LED, V_AC_SENSE, SWCLK) crossing the U1 east-side channel.

Why a "fresh attempt" produces an unchanged result

The four unblockers improve the router's bookkeeping (which iteration to keep, when to stop, whether finalize destroys good routes, what via-in-pad is allowed), but they do not improve the router's ability to find new paths. The first-iteration A* + RSMT result was already 9/10 fragments / 4/10 pad-connected before #3120/#3124/#3128/#3131, and it still is. The unblockers prevent regression below that floor — they cannot lift it.

Recommended next step — empirical rationale

Of the three fallback paths in the body, the cheapest unblocker is #3 (trace clearance tightening) combined with #1 (manufacturer profile bump). Rationale:

1. Trace clearance 0.3 → 0.15 mm in route_pcb() line 1624. The DRU minimum is 0.127mm; 0.15mm preserves ~18 µm margin and roughly halves the keep-out width per trace. Estimated effect: opens 1-2 additional escape channels in the U1 east cluster. Lowest risk: pure parameter change, no placement edits.
2. Manufacturer profile bump in generator output: hard-code or surface a manufacturer setting so kct check defaults to jlcpcb-tier1. The current 1 via_in_pad error is real-board-shippable on tier-1; with router: micro-via in-pad rescue for non-GND fine-pitch escape #3128 the rescue could also be invoked during routing for additional dense-pad escapes.
3. Placement spread (path Install Loom 0.1.0 (e9765c9) #2 in body) is invalidated as a standalone fix by the 2026-05-23 evidence: the spread reached 9/10 fragments but only 5/10 pad-connected — it raised the floor by exactly +1. Path Install Loom 0.1.0 (e9765c9) #2 should be combined with path Install Loom 0.1.0 (d6cf9ac) #3 (clearance) to compound effects, not pursued alone.

The combination most likely to clear acceptance: clearance to 0.15 mm + jlcpcb-tier1 mfr profile + the 2026-05-22 placement spread. Each contributes independently; together they could plausibly hit ≥9/10 pad-connected.

Refined acceptance criteria

1. uv run python boards/external/softstart/generate_design.py exits 0.
2. Routing reach ≥ 9/10 fully-connected signal nets (router get_statistics()['nets_routed'] reports pad-connected count post-feat(router): lex-tuple primary key = nets_fully_connected (closes #3117) #3120, not fragment count). 10/10 preferred.
3. DRC error budget by category:
   • connectivity: 0 (or ≤ 1 with skip_nets justification in the generator docstring)
   • clearance_pad_segment: 0
   • clearance_segment_via: 0
   • via_in_pad: 0 under whichever manufacturer profile the generator is configured to target (jlcpcb tier-0 OR tier-1, but consistent between generator config and kct check invocation).
4. kct fleet status --boards-dir boards/external reports softstart as ship_ready.
5. If the generator switches to jlcpcb-tier1, the docstring of route_pcb() (or a top-of-file comment) explicitly records the tier choice and the rationale (per router: micro-via in-pad rescue for non-GND fine-pitch escape #3128 micro-via rescue).

Explicit out-of-scope

• Schematic changes: already PASS post-boards/external/softstart: 39 ERC errors + 5 single_pad_net DRC errors (netlist drift?) #3050/fix(softstart): schematic repair — ERC 39 → 0, single_pad_net DRC 5 → 0 (partial, routing follow-up #3085) #3086/fix(softstart): tie R11 pad2 to SWCLK net to match schematic (closes #3087) #3088. ERC = 0, single_pad_net = 0. Do not touch the schematic.
• Router algorithm changes: the RSMT partial-fragment problem identified by the 2026-05-23 builder is a real router gap, but it is not in scope here. If empirical evidence in this attempt re-surfaces it, file a fresh issue against src/kicad_tools/router/algorithms/negotiated.py:route_net_negotiated (citing the 2026-05-23 finding) and block this issue against the new one rather than expanding scope.
• New manufacturer profile creation: stick to the existing jlcpcb / jlcpcb-tier1 / pcbway profiles. Do not invent a softstart-specific tier.
• Placement spread alone: invalidated by 2026-05-23 evidence as a standalone path. Only acceptable as part of a combined intervention.

Files referenced (absolute paths)

• /Users/rwalters/GitHub/kicad-tools/boards/external/softstart/generate_design.py:1048-1071 (placement positions — unchanged from boards/external/softstart: router completes only 3/10 signal nets (post #3050 repair) #3085 baseline)
• /Users/rwalters/GitHub/kicad-tools/boards/external/softstart/generate_design.py:1612-1714 (route_pcb() — invocation config with hard-coded 0.3mm trace/clearance)
• /Users/rwalters/GitHub/kicad-tools/boards/external/softstart/generate_design.py:1637-1642 (skip_nets — power + ISENSE_POS only)
• /Users/rwalters/GitHub/kicad-tools/boards/external/softstart/softstart.kicad_dru (generic DRU, 0.127mm/0.127mm minima — already permissive enough)
• /Users/rwalters/GitHub/kicad-tools/boards/external/softstart/project.kct (board spec, no manufacturer-tier key currently)
• /Users/rwalters/GitHub/kicad-tools/boards/external/softstart/output/softstart_routed.kicad_pcb (just-generated 2026-05-27 artifact for comparison)

Estimated LOC: ~30 in generate_design.py (clearance change + tier annotation + optional placement spread). Builder should re-run the full empirical cycle after each independent change to attribute effects.

[rjwalters]

Builder report (2026-05-27) -- blocked on router-side gap

Implemented the curator's recommended combined intervention and validated each component empirically. The combined intervention moves the routing floor from 4/10 to 6/10 pad-connected signal nets (a +2 improvement) but does not reach the >= 9/10 acceptance criterion. Filed follow-up issue #3138 to address the deeper router-side gap and marked this issue loom:blocked against it.

Setup

• Worktree: .loom/worktrees/issue-3134/
• Commit: f653033f (HEAD of main at start of attempt)
• C++ backend: built and verified (router_cpp.cpython-314-darwin.so v1.0.0)

Per-intervention empirical contribution

Variant	clearance	placement	drc_aware	mfr	Nets routed	DRC errors
Baseline (main)	0.3mm	original	off	jlcpcb (tier-0)	4/10	23
Clearance only + tier1	0.15mm	original	off	jlcpcb-tier1	5/10	26
Placement only + tier1	0.3mm	spread	off	jlcpcb-tier1	5/10	28
Intermediate clearance	0.2mm	spread	on	jlcpcb-tier1	5/10	21
Combined	0.15mm	spread	on	jlcpcb-tier1	6/10	20

Each individual intervention contributes +1 net. Combined gives +2 (the interventions overlap on the same U1 east-side escape channels).

What I tried beyond the curator's prescription

1. drc_aware=True on the TraceOptimizer (with drc_manufacturer="jlcpcb-tier1", drc_layers=2, drc_copper_oz=2.0). This is intended to roll back per-net optimizations that worsen DRC. Net effect on this board: ~3-fewer DRC errors at the same 6/10 routing count, but the clearance_pad_segment errors with negative actual_value persist - the rollback isn't catching them.

2. grid_resolution adjustment (0.1mm -> 0.075mm) required by router/io.py::validate_grid_resolution() strict mode when clearance drops to 0.15mm. Confirmed routing still completes within the 240s route_all_negotiated() budget.

3. Tried intermediate clearance (0.2mm at grid=0.1mm) - 5/10 routed (worse than 0.15mm).

Stranded routable signal nets (after combined intervention)

All four stranded routable signal nets terminate at U1:

• GATE_NEG (1/3 pads stranded)
• I_SENSE_OUT (1/2 stranded)
• SWCLK (2/3 stranded)
• ZC_DETECT (1/3 stranded)

The remaining 9 connectivity errors are on skip_nets (GND, +3.3V, FUSED_LINE, AC_LINE, AC_NEUTRAL, VRECT, SCAP_POS+, SCAP_NEG+, ISENSE_POS) - these are intended for user hand-routing and are expected.

The geographic concentration is conclusive: the residual gap is U1 east-side escape congestion, exactly as the 2026-05-23 builder's RSMT partial-fragment analysis predicted.

Decision

Per the issue body's explicit guidance ("If even the combined intervention doesn't lift the floor to >= 9/10, set loom:blocked with empirical numbers ... and file a follow-up issue for the deeper router-side gap (likely U1 cluster congestion)"):

• Reverted the working tree (no partial-credit PR for code that doesn't meet AC).
• Filed router: U1 cluster congestion caps softstart routing at 6/10 nets (followup #3134) #3138 capturing the empirical baseline, per-intervention contribution table, and the four diagnostic recommendations for the router-side fix.
• Set this issue to loom:blocked pending router: U1 cluster congestion caps softstart routing at 6/10 nets (followup #3134) #3138.

When #3138 lands, this issue can be reopened/re-claimed and the combined-intervention patch (preserved in /tmp/softstart_combined2.log on the worktree machine for reference) re-applied with the new router behavior.

Curator's prediction validated

The 2026-05-23 builder's RSMT partial-fragment hypothesis is confirmed: A* + RSMT cannot escape U1's dense pin-side channels under any combination of placement spread / clearance tightening / tier-1 micro-via-in-pad rescue that this board's parameters can offer.