compatibility-check

Compatibility Check

Catch obvious mismatches in a BOM before parts ship.

Inputs

• Project slug → bom.json and (if present) datasheets/*.md.

Checks

Run each of these against the BOM:

1. Voltage rails — every part's operating voltage is either matched to a rail the design provides or has a level shifter / regulator listed.
2. Logic-level compatibility — 5V parts on a 3.3V MCU's GPIOs flag a level-shifter requirement (or 5V-tolerant pin verification).
3. Current budget — sum of typical current draws ≤ regulator/PSU capacity, with a margin (recommend ≥30% headroom).
4. I2C addresses — no two parts on the same bus share an address (and addresses are configurable where collisions exist).
5. SPI chip-selects — one GPIO per CS line, accounted for in the pin budget.
6. Pin count — the MCU has enough free GPIOs (after deducting strapping pins, USB pins, flash pins, ADC-only pins) to wire every peripheral.
7. ESP32 strapping pins — flag any peripheral wired to GPIO0/2/12/15 etc. that could break boot.
8. Power-up order / inrush — flag parts with high inrush (motors, large caps) that may need soft-start or separate rails.
9. Environmental ratings — operating temperature / humidity matches the spec's target environment.

Output

Write <projects_dir>/<slug>/compatibility.md:

• Pass list (checks that succeeded).
• Warnings (likely issues, with suggested fix per item).
• Blockers (must be addressed before ordering).

Print a one-line summary: "N blockers, M warnings". If blockers exist, recommend the user iterate create-hardware-spec before proceeding to sourcing.