docs: record the two CPL export steps the recipe was missing

Regenerating the production files for the V2.1 eFuse rework surfaced two steps that neither the skill nor CPL_ROTATIONS.md documented, both caught only by diffing against the previously-shipped CPL: - --exclude-dnp does not drop 'in_bom no' parts, so J4 and TP1-TP5 landed in the raw export although the shipped CPL excluded them. Filter to designators that have a BOM line; the two sets should end up equal. - kicad-cli emits signed rotations while the correction step's % 360 only normalises corrected parts. Mixing the two made the diff show 34 phantom rotation changes (270.0 vs -90.0 is the same angle), burying the 2 real ones. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-02 15:20:56 +02:00
parent c32ae49f28
commit f2a721cb1f
2 changed files with 36 additions and 0 deletions
@@ -99,6 +99,27 @@ with open('re-bba-rb-cpl.csv', 'w', newline='') as f:
                          f"{float(r['Rot']):.6f}"])
 ```

+**Two filtering/formatting steps the raw export does NOT do** (both were
+silently missing once and had to be rediscovered by diffing against the
+previously-shipped file — do them every time):
+
+1. **Drop rows with no BOM line.** `--exclude-dnp` only filters `dnp yes`.
+   Parts marked `in_bom no` but `in_pos_files yes` and `dnp no` — on this board
+   J4 (unpopulated debug header) and TP1–TP5 (bare test pads) — still land in
+   the raw export. The assembler has no part to place for them. Filter the CPL
+   to designators that appear in the BOM; afterwards the two sets should be
+   exactly equal, which is a good assertion to make:
+   ```python
+   placed = {x.strip() for r in csv.DictReader(open('re-bba-rb-bom.csv'))
+             for x in r['Designator'].split(',') if x.strip()}
+   rows = [r for r in rows if r['Designator'] in placed]
+   ```
+2. **Normalise every rotation to [0, 360).** `kicad-cli` emits signed angles
+   (`-90`), while the correction step's `% 360` leaves corrected parts in
+   0–360. Mixing the two makes a diff against the previous CPL show ~34
+   phantom changes (`270.0` vs `-90.0` is the same angle) and buries the real
+   ones. Apply `% 360` to **all** rows, not just corrected ones.
+
 **Then — before treating this as done — reapply every correction in
 [`hardware/re-bba-rb/CPL_ROTATIONS.md`](../../../hardware/re-bba-rb/CPL_ROTATIONS.md).**
 KiCad's raw per-footprint rotation frequently does not match what the
@@ -23,6 +23,21 @@ between the two tools). **Do not reapply the community table wholesale to
 this board.** Every correction below was derived per-part from direct visual
 verification against JLCPCB's placement-preview render, not from that table.

+## Two steps besides the corrections (easy to miss)
+
+Both were absent from a regeneration once and only caught by diffing against
+the previously-shipped CPL:
+
+- **Filter to designators that have a BOM line.** `--exclude-dnp` does not
+  remove `in_bom no` parts: **J4** (unpopulated debug header) and **TP1–TP5**
+  (bare test pads) are `in_pos_files yes, dnp no`, so they appear in the raw
+  export but were *not* in the shipped CPL. Assert CPL designators == BOM
+  designators when done (144 parts as of 2026-10-02).
+- **Normalise all rotations to [0, 360).** `kicad-cli` emits signed angles;
+  the correction step's `% 360` only normalises corrected parts. Mixing them
+  makes a diff show ~34 phantom changes (`270.0` vs `-90.0` are the same
+  angle) and hides the real ones.
+
 ## Rotation sign convention

 The CPL uses JLCPCB's Y-up coordinate frame (`kicad-cli`'s csv pos format