compatibility-check

name	compatibility-check
description	Sanity-check the parts in a BOM against each other — voltage levels, logic-level compatibility, current draw vs. regulator capacity, I2C address conflicts, shared bus contention, and pin count adequacy on the chosen MCU. Flags issues before the user orders.

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.