Vibecode a BLE Remote PCB with AI: RF Refusal Design Guide

MakeIRL's generator treats a BLE remote prompt as a self-contained project board. Current status: refused.

The deterministic policy refuses RF and lithium/battery requests. The checked ESP32-C3 seed is not permission to generate a BLE remote or claim antenna and battery performance.

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 pre-certified radio module, approved antenna/reference layout, region, enclosure/body proximity, range, coexistence, and certification plan
2. Battery chemistry/cell, protection/charging ownership, peak/sleep budget, buttons, LEDs, wake behavior, and firmware update path
3. Enclosure and button mechanics, antenna edge/keepout, ESD, programming, factory test, labeling, and field lifetime

Block plan:

• No custom RF, matching, or antenna block is generated
• No lithium/coin-cell charging or battery-safety block is generated
• Safe alternative uses current USB power plus wired GPIO/button/status blocks

Interfaces: wired GPIO alternative, optional I²C expansion, BLE only after a verified module block and policy change. Power plan: Current safe alternative is USB powered. Battery life, charger, cell protection, and RF peaks remain out of scope.

• A future module carrier must preserve the manufacturer's antenna edge and keepout, isolate user ESD, and keep battery/copper/enclosure out of the RF field.
• 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. For the wired alternative, prove no RF/battery circuitry exists and verify buttons, boot pulls, USB power/CC/ESD, LED current, and programming access.
2. S1Catalog and exact-MPN provenance. Every BLE remote 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.

• A qualified reviewer owns RF module certification scope, antenna/enclosure behavior, battery safety, EMC, regional approval, sleep budget, and firmware security.
• 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:

• A certified module can lose range or invalidate assumptions when the carrier puts copper, a battery, a hand, or an enclosure in its antenna keepout.
• 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:

• Validate only the wired alternative today; future BLE hardware needs conducted/radiated RF, enclosure range, coexistence, current profiling, battery, ESD, and compliance tests.
• 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 all custom RF/BLE design, antenna matching, batteries, and charging under current policy.
• Do not describe an ESP32-C3 carrier as a validated BLE remote merely because its module contains a radio.

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.