embedded-constrained-codinglisted

# Embedded / Constrained Coding Server-side code that "should be fine, it's not doing much" is usually fine. The same instinct on a microcontroller or a phone's inference budget is how a demo that worked on a dev board dies in the field. This skill forces the budget to be explicit before code gets written, and checks it was actually respected after. ## Step 1 — State the actual budget before writing anything RAM, flash/storage, power draw, and latency ceiling — as numbers, not "should be small." If the user hasn't stated them, ask or use the documented figures for the stated target (the specific chip's actual SRAM/flash ceiling, the specific device's actual thermal/battery constraints for sustained inference) rather than assuming server-class headroom. ## Step 2 — Avoid patterns that are fine on a server and dangerous here - **Dynamic allocation that fragments a constrained heap** — repeated alloc/free of varying sizes on a device with no memory compaction will eventually fail even when total free memory looks sufficient. Prefer static allocation or fixed pools where the target supports it. - **Assuming the standard library behaves the same** — many embedded toolchains ship cut-down or different-behaving libc equivalents; verify rather than assume. - **Blocking calls inside interrupt handlers or tight real-time loops** — a call that's harmless latency on a server can blow a hard deadline or starve the watchdog here. - **Ignoring watchdog timers** — any loop or blocking o