hardware

# Hardware — parts, circuits, firmware, bring-up, traps Rule content lives in the five files below; this SKILL.md only routes (`doctrine/04-maintenance.md` governs edits to this bundle too). ## Route by moment | You are about to… | Read (in this folder) | |---|---| | Pick an MCU, module, sensor, or any component; judge a BOM or parts proposal | `parts.md` | | Design or review a circuit: power, protection, interfaces, layout concerns | `circuits.md` | | Write or review embedded firmware (loops, ISRs, watchdogs, OTA, flash) | `firmware.md` | | Debug a physical board, plan first power-up, or validate before shipping | `bringup.md` | | Estimate battery life or a power budget ("how long on a 2000mAh cell?") | `circuits.md` §1 + `traps.md` A5 — peak budgeting, measured charge per duty cycle | | Review a hardware project's health; name why a design or process feels fragile | `traps.md` | A new design usually runs `parts.md` → `circuits.md` (power tree first) → `firmware.md`, with `bringup.md` §1 consulted BEFORE layout — bring-up is designed, not improvised. ## Scope and neighbors Physical-world engineering judgment. Firmware architecture inherits `backend/logic.md` (this bundle adds the physics); debugging inherits `methods/investigate.md` (this bundle adds instruments and the four failure domains); whether to delegate → `doctrine`. ## The stance The physical world is analog, undocumented, and expensive to iterate: **derate, measure, and design for bring-up** — and treat every datasheet as a contract whose real terms are in the footnotes (`parts.md` §4). One honest limit governs all debugging here: the model cannot see the board, so measurements come before theories (`bringup.md` §4).