v4 As-Built Order Verification & Footprint Geometry Audit

This page answers two separate questions about the v0.4.0 (4th JLCPCB order) hardware, both at the as-built / geometry level rather than the schematic-correctness level (see v3 USB-PD Failure Diagnosis for the schematic-level pin-18 root cause, which a sibling page covers for v4):

• (a) Did the pin-18 fix and the intended BOM actually reach a real JLCPCB order for v0.4.0?

• (b) Do the U1 / J1 / D4 footprints have the correct physical geometry (pad position, rotation, mirroring) on the board — the class of bug that passes net-matching but still kills the board, because a footprint can be rotated 90/180° while every pad still carries the electrically-correct net.

Method: every claim below is backed by either (1) git history on files tracked in this repo, (2) a KiCad netlist export (__inbox/zudo-pd-netlist.xml, geometry-free pad→net truth), (3) direct pad coordinates read from zudo-pd.kicad_pcb and footprints/kicad/*.kicad_mod, or (4) locally-generated JLCPCB manufacturing files recovered from the gitignored jlcpcb/ working directory on this machine. No KiCad GUI was used.

(a) Did the v0.4.0 order artifacts actually get produced?

Timeline reconstructed from git + local files

Verdict: did the design fix reach a JLCPCB-ready package?

Yes. Verified two independent ways:

1. Netlist (geometry-free, current HEAD): net VBUS_VS_DISCH (net code 39) contains exactly { R14.2, TP6.1, U1.18 }, and net VBUS_IN (net code 37) contains R14.1 alongside J1.A9, J1.B9, U1.24. This confirms VBUS_IN → R14 (470 Ω) → U1 pin 18 is wired in the committed schematic — the fix is real, not just described in prose.

2. Recovered local JLCPCB export (jlcpcb/production_files/, generated 2026-06-05 03:24, ~1.5 h before it was committed as 7854736) contains R14,470ohm,R0603,72.51,-6.08,0.0,top in the CPL and the faston swap (63951-1,"J6,J7,J8,J9",CONN-TH_1217754-1,C591344,4) in the BOM — i.e. a JLCPCB-ready package was generated reflecting the fixed design.

Verdict: was an actual v0.4.0 order placed and manufactured?

Unrecoverable locally. No artifact on this machine confirms the package above was ever uploaded, quoted, or paid for at JLCPCB:

• No jlcpcb-order-snapshots/v0_4_0/ existed before this audit (the gap this task exists to close).

• No gerber/BOM/CPL zip with a JLCPCB order code (the pattern seen for earlier orders is a hash-like folder name + _Y<n>, e.g. 7543760a_y33 for the v3 order, dated 2026-05-31 — before the pin-18 fix) appears anywhere under ~/Downloads after 2026-06-05.

• No from-order-detail-style confirmed BOM (bom.xls), layout render, or product-detail photo exists for a v4 order, unlike v0_1_0 through v0_3_0 which all have one.

• CLAUDE.md's own phase note is present-tense: "v0.4.0 (4th JLCPCB order) — ordering." — consistent with "package prepared, order not yet confirmed placed," not "received and tested."

What the user must do to close this out: log into the JLCPCB order-history page (https://jlcpcb.com/user/order/list or account → Order History) and check for an order placed on/after 2026-06-05 for this board. If one exists:

1. Download the confirmed BOM (JLCPCB's own export, showing any manufacturer-side substitutions) and any layout/product-detail renders from the order-detail page.

2. Drop them into jlcpcb-order-snapshots/v0_4_0/from-order-detail/ (placeholder created by this audit — see below).

3. Re-run the D4/U1/R-value comparison in this doc against the confirmed BOM, not just the locally-generated one, since JLCPCB can silently substitute out-of-stock basic parts.

If no such order exists, v0.4.0 has not been manufactured yet — the fix exists only in git and the local jlcpcb/ export, and the next actionable step is to actually place the order using the recovered files in jlcpcb-order-snapshots/v0_4_0/used-for-order/ (below).

BOM comparison: front-end parts

jlcpcb-order-snapshots/v0_4_0/ scaffold

Created, mirroring the v0_3_0/ layout:

jlcpcb-order-snapshots/v0_4_0/
├── used-for-order/
│   ├── BOM-zudo-pd.csv     ← recovered from gitignored jlcpcb/production_files/, 2026-06-05 03:24
│   ├── CPL-zudo-pd.csv     ← same
│   └── GERBER-zudo-pd.zip  ← same
└── from-order-detail/
    └── README.md           ← placeholder; nothing to recover locally (see verdict above)

The used-for-order/ files are not placeholders — they are the actual locally-generated manufacturing package recovered from this machine's gitignored jlcpcb/ directory (per the "Repository Convention" section of Generate JLCPCB Files with kicad-jlcpcb-tools, that directory is meant to be copied into jlcpcb-order-snapshots/ for exactly this reason, and never was for v0.4.0). from-order-detail/ only gets a README.md placeholder, since the manufacturer-side confirmation cannot be recovered from local files — it requires the JLCPCB account lookup described above.

(b) Footprint geometry audit

Net-level pad→net matching for U1, J1, D4 was already verified correct at plan time (re-confirmed above via __inbox/zudo-pd-netlist.xml). Net matching is number-based, though — it cannot detect that a footprint is drawn/placed correctly. All geometry below is computed directly from (at ...) values in zudo-pd.kicad_pcb and the pad list in the corresponding footprints/kicad/*.kicad_mod library file.

U1 — QFN-24 (STUSB4500QTR)

Board placement (zudo-pd.kicad_pcb): (footprint "zudo-pd:QFN-24_L4.0-W4.0-P0.50-BL-EP2.8" (layer "F.Cu") (at 44.9 12.9 180)) — top side (not mirrored to B.Cu), rotated 180°.

Library footprint (footprints/kicad/QFN-24_L4.0-W4.0-P0.50-BL-EP2.8.kicad_mod), local/unrotated frame:

• Pad 1: (at -1.25 2.00); pin-1 dot marker fp_circle (center -2.00 2.00) on F.Fab.

• Pads 1–6 run along the local y = +2.00 edge (west→east), 7–12 along x = +2.00 (south→north), 13–18 along y = -2.00 (east→west), 19–24 along x = -2.00 (north→south) — i.e. numbering proceeds counter-clockwise in the footprint's own frame, viewed top-down as KiCad renders it. This matches the issue's stated DS12499 QFN-24 convention (CCW numbering, pin-1 corner marker).

Absolute board coordinates after the 180° placement rotation ((x,y) → (-x,-y) for a pure 180° rotation, then translate by (44.9, 12.9)):

• Pad 1 center: (46.15, 10.90) mm

• Pin-1 dot marker: (46.90, 10.90) mm

Since 180° is a pure rotation (no mirror flag, layer stays F.Cu), it preserves chirality — the CCW pad numbering survives placement, so this is not a mirrored footprint.

U1,STUSB4500QTR,QFN-24_L4.0-W4.0-P0.50-BL-EP2.8,44.9,-12.9,90.0,top

J1 — USB-C receptacle (TYPE-C-SMD_TYPE-C-6P)

Board placement: (at 44.68 4.6 180), layer F.Cu (top, not mirrored).

Library footprint pads (local/unrotated, single row at y = -2.03): B12 (-2.70,-2.03), B9 (-1.50,-2.03), A5 (-0.50,-2.03), B5 (0.50,-2.03), A9 (1.50,-2.03), A12 (2.70,-2.03).

After the 180° placement rotation and translation:

180° is a pure rotation (no B.Cu/mirror), so this is not a mirrored footprint — it is a regular end-for-end rotation of a single-row connector. Netlist-confirmed: A9 and B9 are both tied to net VBUS_IN (already electrically redundant — a residual left/right ambiguity in which physical VBUS tab is A vs B is a non-issue), and A5/B5 (CC1/CC2) each go through the D4 ESD array to the STUSB4500's dedicated CC1/CC2 pins, which is exactly what the flip-detection scheme on this chip is designed to tolerate. No functional risk identified from the rotation value itself; the how-to guide for this project's JLCPCB tooling does not list TYPE-C-SMD_TYPE-C-6P among the footprints needing a rotation-correction override, and the recovered CPL leaves J1 at rotation 180.0, unchanged from the raw board value — consistent with "no correction needed" for this connector family.

D4 — SOT-23-6 (USBLC6-2SC6)

Board placement: (at 51.65 11.75) — no rotation specified (0°), layer F.Cu (top, not mirrored). This is the lowest-risk placement of the three: no transform is applied at all, so the library footprint's own layout passes straight through to the board.

Library footprint pads (footprints/kicad/SOT-23-6_L2.9-W1.6-P0.95-LS2.8-BL.kicad_mod):

Pads 1-2-3 run one edge west→east, pads 4-5-6 run the opposite edge east→west (4 opposite 3, 6 opposite 1) — the standard SOT-23-6 perimeter pattern, matching the datasheet pinout given in the issue (1=I/O1, 2=GND, 3=I/O2, 4=I/O2, 5=VBUS, 6=I/O1). The pin-1 marker (fp_circle (center -1.46 1.40) on F.Fab, plus a silkscreen circle) sits directly next to pad 1 at the correct corner. Combined with the netlist confirmation (pins 1↔6 both on the CC1 group, 3↔4 both on the CC2 group, pin 5 on VBUS_IN, pin 2 on GND — see substitution-risk note above), and the project's own JLCPCB-tooling gotcha guide (kicad-jlcpcb-tools.md) documenting that this exact footprint needs rotation = 0 as an override to a default plugin rule that would otherwise mis-rotate it by -90° — which the recovered CPL confirms (D4,USBLC6-2SC6,SOT-23-6_L2.9-W1.6-P0.95-LS2.8-BL,51.65,-11.75,0.0,top) — verdict: correct.

Summary