Vibecode a Multi-Sensor Hub PCB with AI and Gate Checks

MakeIRL's generator treats a multi-sensor hub prompt as a self-contained project board. Current status: in envelope needs block.

The current Qwiic block supports one connector, not arbitrary sensor composition. A hub needs exact catalog sensor/connector blocks plus address, current, and bus-capacitance resolution.

MakeIRL V2 extracts a strict CarrierSpec from the prompt, applies a deterministic scope policy, resolves only cataloged blocks, composes deterministic connectivity and exact-MPN BOM data, emits KiCad artifacts, and runs the manufacturing gate. The language model does not invent pins, topology, parts, placement, routing, or substitutions.

1. Exact sensor/module MPNs, voltages, interfaces, addresses and alternatives, pull-ups, interrupt pins, sample rates, and startup states
2. Port count and connector pinout, cable lengths/capacitance, hot-plug policy, aggregate current, power switching, and fault isolation
3. Controller/module, enclosure and port faces, sensor placement/airflow, programming, labels, mounting, and test strategy

Block plan:

• Current checked ESP32-C3 carrier when that module fits
• Current Qwiic/status block plus a separately verified multiport/pull-up selection block
• Only exact cataloged sensor modules; otherwise expose reviewed ports rather than invent onboard sensors

Interfaces: I²C/Qwiic, GPIO interrupts, UART/slow SPI only for cataloged modules. Power plan: USB-derived 3.3 V with aggregate sensor, cable, radio and startup budget plus 30% headroom; no unknown hot-plug loads.

• Keep ports accessible and consistently oriented, put protection/power control at each cable entry, and separate heat/airflow-sensitive sensors.
• Freeze the board outline, mounting holes, connector faces, component height zones, test access, and keepouts before evaluating generated placement or routing.

Gate checks:

1. S1Generated connectivity and schematic parity. Detect I²C address conflicts, excessive parallel pull-ups, voltage mismatches, duplicate interrupts, reversed ports, missing grounds, and current-headroom failures.
2. S1Catalog and exact-MPN provenance. Every multi-sensor hub block, footprint, pin map, required companion, BOM line, and block-status claim must resolve to the pinned catalog version; the prompt cannot create missing hardware.
3. S2PCB DRC, fabrication profile, and release identity. Run KiCad DRC and schematic parity, compare geometry with one quoted fab profile, regenerate Gerbers/drills/BOM/CPL from the approved revision, and inspect both local and supplier previews.

• Review bus capacitance and cable length, hot plugging, address straps, sensor interaction/self-heating, connector ecosystem, fault isolation, and firmware scheduling.
• A reviewer must check primary datasheets, exact symbol-to-footprint mapping, power and protection, return paths, connector orientation, mechanical fit, test coverage, and every gate waiver before release.

Failure modes:

• Several individually valid I²C sensors can share an immutable address or parallel enough pull-ups to exceed sink-current limits.
• ERC and DRC can prove encoded consistency but cannot prove requirements, component source truth, analogue stability, RF/EMI, thermal margin, firmware, safety, compliance, or delivered product function.

Validation plan:

• Populate sensors incrementally, scan addresses, measure rise time and rail peaks at full cable length, test disconnect/short cases, and compare sensor behavior in enclosure.
• Bring up first articles with current limiting, measure every rail before fitting expensive modules, program minimal test firmware, exercise every interface and fault assumption, and retain measurements against the released revision.

• Refuse unknown sensor modules, invented address straps, unsupported hot-plug/power switches, or aggregate loads outside the envelope.
• A generic Qwiic port does not verify every module attached to it.

The intended carrier envelope is 2-layer FR-4, at most 100 × 100 mm, at most 40 BOM lines, at most 12 V SELV and 2 A, with cataloged modules and low-speed I²C, UART, GPIO, slow SPI, or power-only USB-C connections. The current catalog is narrower than that intended envelope.

Deterministic policy refuses unsupported or hazardous requests, including mains, motors, lithium charging, RF design, switch-mode power, high-speed buses, excessive size/current, and unknown modules. A refusal is a safety and truthfulness result, not a failed attempt to improvise a circuit.

The current seed catalog contains ESP32-C3 carrier, USB-C power, and Qwiic/status-LED blocks at checked status. They have passed deterministic checks but are not yet physically verified through the documented two-lot bring-up ladder; pages must not call those current seeds verified.

The output is a gated design candidate for engineering review. Current placement/routing can still produce blocking or review findings, so a generated board is not automatically fab-ready, functionally validated, certified, or safe to order. MakeIRL does not autonomously place a fabrication order from a prompt. Human review, source and output inspection, gate resolution, order-specific fab confirmation, and physical bring-up remain required.