nx_mcu_fit.nx

nx_mcu_fit.nx -- does a model config fit a specific MCU's memory hierarchy? Pure decision logic. THE ONE RULE THAT MAKES THIS HONEST: an UNMEASURED resource is REFUSED, never assumed. mcu_targets.conf carries -1 for every field we have not put on a bench, and a -1 must never be silently treated as 0 (infinite room) or as a datasheet guess. If we cannot decide, we say so and name the field to go measure. That is what makes this organ useful for hardware bring-up rather than merely decorative: pointing it at an unmeasured board returns a WORK ORDER, not a verdict. The second rule, inherited from the memfloor incident: REFUSE, NEVER SILENTLY SHRINK. An allocator that quietly reduces a grid to make it fit froze every seat's builds for minutes. So there is no "nearest fitting config" return path here -- the caller is told which wall it hit and decides. Resource model, matching how a PLE-style model actually lands on an ESP32-S3: dense core -> internal SRAM (fast, tiny, the real constraint that sizes the model) weights+table-> SPI flash (large, slow, XIP / memory-mapped) KV + scratch -> PSRAM (medium, bandwidth-bound) Checks run in that order so the BINDING constraint reported is the tightest real one, deterministically. license_tier: ORIGINAL No hw writes (Rule 26).