@tscircuit/schematic-trace-solver 0.0.197 → 0.0.199

package/tests/repros/repro-am3352-sheet3-power-rails.md

@@ -0,0 +1,66 @@
+# AM3352 sheet 3: connector power and ground rails
+
+This is a reduced, runnable solver repro for the J_SD, J_SPI, J_I2C and J_USB0
+section of **03-Interfaces — Storage, USB and cable interfaces** (sheet 3).
+It records the baseline for future V3V3/GND label and trace improvements.
+No solver implementation is changed.
+
+## Source and reduction
+
+- Deployment: https://am3352-dev-board.vercel.app/#file=index.circuit.tsx
+- Circuit JSON: https://am3352-dev-board.vercel.app/index/circuit.json
+- User-supplied source link: https://github.com/tscircuit/am3352-dev-board
+  (returned 404 when this repro was made).
+- Retrieved 2026-09-15. Circuit JSON SHA-256:
+  `a9216069870f58ab841446871ed9101d09aabe2eb7457d130e1285cc204006c3`.
+- Solver baseline: `77c271b` (`@tscircuit/schematic-trace-solver` 0.0.197).
+
+The fixture preserves the deployed component centers, sizes, all 36 port
+positions and directions, eight component text obstacles, and 19 named nets.
+Component/port IDs become readable `J_SD` / `J_SD.4` identifiers. Net membership
+comes from source-port connectivity keys, not intersections in the screenshot.
+V3V3 connects J_SD.4, J_SPI.2 and J_I2C.2; GND has 16 terminals, including shield
+and mounting pins. USB0_VBUS remains a separate power net.
+
+Other sheet components are omitted. Signals leaving this crop become named
+one-pin nets. The fixture contains no pre-routed output or manually imposed
+trace paths. All selected source connections are port-to-net connections, so
+`directConnections` is empty.
+
+This is reconstructed solver input, not a captured original solver invocation.
+Label dimensions and text obstacles follow the current core conventions:
+0.42 rail height; net text width `0.12 * (length + 1)` at 0.18 font size;
+0.12 inline font size with proportionately smaller width; refdes clearance
+0.06 with 0.01 overlap into the component. `maxMspPairDistance: 2.4` uses the
+current core default; the deployment does not expose its original setting.
+
+## What it reproduces
+
+The baseline routes V3V3 from J_SD.4 down and across to J_I2C.2, and routes GND
+from J_SPI.1 down to J_I2C.1. J_SPI.2 has its own V3V3 label. Ground pin banks
+on the connectors form short buses. These are generated by the solver, not
+hard-coded. The screenshot's external MMC0_DAT2/I2C0_SCL runs are intentionally
+reduced to labeled stubs.
+
+The standard snapshot includes both the solver debug view and the semantic
+schematic renderer. Its diagnostic text boxes and generic label rendering are
+not a pixel-for-pixel copy of the deployed site's rail symbols. Use the
+pipeline debugger and stage artifacts to inspect actual placement geometry.
+
+## Run
+
+```sh
+bun install
+bun test tests/repros/repro-am3352-sheet3-power-rails.test.ts
+bun run debug:pipeline tests/repros/assets/repro-am3352-sheet3-power-rails.input.json --svg
+bunx tsc --noEmit
+```
+
+For interactive investigation, run `bun start` and open
+`SchematicTracePipelineSolver/repro-am3352-sheet3-power-rails` in Cosmos.
+
+To intentionally update the baseline after an improvement:
+
+```sh
+BUN_UPDATE_SNAPSHOTS=1 bun test tests/repros/repro-am3352-sheet3-power-rails.test.ts
+```

package/tests/repros/repro-am3352-sheet3-power-rails.test.ts

@@ -0,0 +1,39 @@
+import { expect, test } from "bun:test"
+import { SchematicTracePipelineSolver } from "lib/solvers/SchematicTracePipelineSolver/SchematicTracePipelineSolver"
+import type { InputProblem } from "lib/types/InputProblem"
+import "tests/fixtures/matcher"
+import input from "./assets/repro-am3352-sheet3-power-rails.input.json"
+
+// Reduced from the deployed AM3352 board, sheet 3 (03-Interfaces).
+// See the companion .md for provenance and reconstruction details.
+test("repro AM3352 sheet 3 connector power and ground rails", async () => {
+  const problem = structuredClone(input) as InputProblem
+  expect(problem.chips.map((chip) => chip.chipId).sort()).toEqual([
+    "J_I2C",
+    "J_SD",
+    "J_SPI",
+    "J_USB0",
+  ])
+  expect(
+    problem.netConnections.find((net) => net.netId === "V3V3")?.pinIds,
+  ).toEqual(["J_SD.4", "J_SPI.2", "J_I2C.2"])
+  expect(
+    problem.netConnections.find((net) => net.netId === "GND")?.pinIds,
+  ).toHaveLength(16)
+
+  const pinIds = problem.chips.flatMap((chip) =>
+    chip.pins.map((pin) => pin.pinId),
+  )
+  expect(new Set(pinIds).size).toBe(36)
+  expect(problem.netConnections.flatMap((net) => net.pinIds).sort()).toEqual(
+    pinIds.sort(),
+  )
+  expect(problem.availableNetLabelOrientations.V3V3).toEqual(["y+"])
+  expect(problem.availableNetLabelOrientations.GND).toEqual(["y-"])
+
+  const solver = new SchematicTracePipelineSolver(problem)
+  solver.solve()
+  expect(solver.solved).toBe(true)
+  expect(solver.failed).toBe(false)
+  await expect(solver).toMatchSolverSnapshot(import.meta.path)
+})

package/tests/repros/repro-normal-net-label-branch-from-junction.test.ts

@@ -69,5 +69,18 @@ test("repro: V3V3 net-label branch does not start at the R8 edge", () => {
   expect(
     solver.inlineNetLabelSolver!.getOutput().inlineNetLabelPlacements,
   ).toHaveLength(0)
+  const connector = solver.netLabelToTraceSolver!.outputTraces.find(
+    (trace) => trace.mspPairId === "available-net-orientation-1-V3V3",
+  )
+  expect(connector?.tracePath[0]).toEqual({ x: -6.5, y: -19 })
+  const hostTrace = solver.netLabelToTraceSolver!.outputTraces.find((trace) =>
+    trace.pinIds.includes("R8.pin2"),
+  )
+  const v3v3Label = solver.netLabelToTraceSolver!.outputNetLabelPlacements.find(
+    (label) => label.netId === "V3V3",
+  )
+  expect(hostTrace?.tracePath).toContainEqual(connector!.tracePath[0]!)
+  expect(connector?.tracePath.at(-1)).toEqual(v3v3Label?.anchorPoint)
+  expect(connector?.tracePath.at(-1)?.y).toBeCloseTo(-18.649)
   expect(solver).toMatchSolverSnapshot(import.meta.path)
 })