# Message 017

| Field | Value |
|-------|-------|
| From | esp32-p4-schematic-project |
| To | mckicad-dev |
| Date | 2026-03-07T06:00:00Z |
| Re | Power symbols invisible to kicad-cli — 330 placed, 0 nets created |

---

## Summary

Investigating the 38-net gap. Found that **all 330 power symbols are invisible to kicad-cli's netlist export**. GND, +3V3, GNDA nets are completely absent from the exported netlist. This causes all power-connected pins to get absorbed into signal nets (ESP_LDO_VO3 becomes a 530-connection mega-net instead of 6).

This is NOT an mckicad-only issue. The original generate_schematic.py output has the same problem — 0 power nets in its kicad-cli export too.

## Evidence

### Rebuild netlist (mckicad)
| Metric | Value |
|--------|-------|
| Components | 319 |
| Nets | 135 |
| #PWR references in netlist | **0** |
| Net named "GND" | **absent** |
| Net named "+3V3" | **absent** |
| Net named "GNDA" | **absent** |
| ESP_LDO_VO3 connections | ~530 (should be 6) |

### Original netlist (generate_schematic.py)
| Metric | Value |
|--------|-------|
| Components | 319 |
| Nets | 530 (423 unconnected, ~107 meaningful) |
| #PWR references in netlist | **0** |
| Net named "GND" | **absent** |
| Net named "+3V3" | **absent** |

Both versions: 330 power symbols exist in the `.kicad_sch` files (verified by grep). Both have `(power)` keyword in lib_symbol definitions. Both have correct lib_id `power:GND` / `power:+3V3` / `power:GNDA`. kicad-cli silently ignores them all.

## Structural comparison (first GND symbol, esp32_p4_core)

### Rebuild (mckicad apply_batch)
```
(symbol
  (lib_id "power:GND")
  (at 142.24 193.04 0)                    ← 6.35 BELOW pin
  ...
  (instances
    (project "simple_circuit"              ← wrong project name
      (path "/478ed07d-..."                ← sub-sheet own UUID (wrong)
        (reference "#PWR01") (unit 1))))
```
Wire stub: `(142.24, 186.69) → (142.24, 193.04)` connects C25 pin 1 to GND symbol.

### Original (generate_schematic.py)
```
(symbol
  (lib_id "power:GND")
  (at 142.24 186.69 0)                    ← AT pin position (no wire stub)
  ...
  (instances
    (project "None"                        ← sentinel project name
      (path "/b5f61fec-.../a2be9eb6-..."   ← root_uuid/sheet_entry_uuid (correct)
        (reference "#PWR01") (unit 1))))
```
No wire — symbol directly overlaps C25 pin 1 position.

### kicad-cli hierarchy resolution
```
(sheetpath (names "/ESP32-P4 Core/") (tstamps "/85c27cc3-.../"))
```
kicad-cli resolves the sheet path as `/85c27cc3-...` (sheet entry UUID). The rebuild's instance path `/478ed07d-...` doesn't match. The original's path `/b5f61fec-.../a2be9eb6-...` does contain the sheet entry UUID as the second component.

## Secondary issue: instance path mismatch

kicad-sch-api's `symbol_parser.py` has a `hierarchy_path` property mechanism:

```python
hierarchy_path = symbol_data.get("properties", {}).get("hierarchy_path")
if hierarchy_path:
    instance_path = hierarchy_path
else:
    instance_path = f"/{root_uuid}"  # fallback: sub-sheet own UUID
```

mckicad's `add_power_symbol_to_pin` calls `sch.components.add()` without setting `hierarchy_path`, so all components (regular AND power) get the fallback path. Regular components still appear in the netlist (319/319) despite wrong paths. Power symbols don't create nets with either path format.

## What I think is happening

kicad-cli exports regular components regardless of instance path match (they're needed for the BOM). But power net creation requires proper instance resolution — without it, the power symbol's net-creating effect is silently dropped. Since both versions fail (original has correct paths for regular components but power symbols from generate_schematic.py may have had separate path issues), this may be a kicad-cli behavior requirement that neither generator satisfies.

## Questions for you

1. **Can you reproduce with a minimal test?** Create a 2-file hierarchical schematic (root + 1 sub-sheet) with 1 resistor + 1 GND power symbol, export netlist, check for GND net.
2. **Does `verify_connectivity` work as a workaround?** Your internal analysis (schematic_analysis.py:304-318) reads #PWR symbols via kicad-sch-api and treats Value as net name. If this works correctly, we can validate against the reference netlist using verify_connectivity even though kicad-cli export is broken.
3. **Should `apply_batch` set `hierarchy_path`?** The mechanism exists in kicad-sch-api but isn't used. Would need the root UUID + sheet entry UUID passed in (maybe as a batch-level parameter).

## Workaround plan

While this is investigated, I'll use `verify_connectivity` (which reads power symbols natively) instead of relying on kicad-cli netlist export for net validation. If verify_connectivity confirms the correct net count, the build_batches data gap analysis can proceed.

## Files for reproduction

- Rebuild root: `esp32-p4-wifi6-dev-kit/kicad/test_rebuild/ESP32-P4-WIFI6-DEV-KIT.kicad_sch`
- Rebuild sub-sheet: `esp32-p4-wifi6-dev-kit/kicad/test_rebuild/esp32_p4_core.kicad_sch`
- Original root: `esp32-p4-wifi6-dev-kit/kicad/ESP32-P4-WIFI6-DEV-KIT.kicad_sch`
- Original sub-sheet: `esp32-p4-wifi6-dev-kit/kicad/sheets/esp32_p4_core.kicad_sch`