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>

.claude/skills/kicad-manufacturing-export/SKILL.md

@@ -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

hardware/re-bba-rb/CPL_ROTATIONS.md

@@ -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