Build and ship NucleoOS to BOTH Cardputer units — the original and the ADV — in one pass. Use when the user wants to release/build/OTA/flash for both boards, the ADV and non-ADV Cardputers, or two devices at once. Encodes the key fact that it's ONE universal binary (runtime board auto-detect), so you build once and fan out the shipping to each unit, then verify per board.
Build, gate, and ship NucleoOS to the Cardputer — firmware via OTA and the web/SD payload via the device file API. Use when the user asks to release, deploy, flash, OTA, sync the SD, or push a web app to the device. Covers the one-command release, firmware-only and SD-only paths, and the gotchas (PIN, .gz shadowing, never /MIR).
Debug and develop NucleoOS firmware/ANIMA logic on the PC without flashing — the host harness compiles the real C and runs it locally. Use when working on ANIMA (the offline NL assistant), retrieval cascade, NLU, knowledge graph, or any firmware logic, and when deciding how to verify a change. Lists the gate suites to run before claiming a fix.
Scaffold and implement a NucleoOS native firmware app (C++) correctly — anti-flicker, poll handler, RAM discipline, input routing, registration. Use when creating or fixing a native app in firmware/components/nucleo_app/.
Scaffold a new NucleoOS web app correctly — manifest, www assets, registry entry, ANIMA launch aliases, i18n, icon — so it shows up, launches by name, and passes validation. Use when adding a new app to the OS, creating an app folder, or wiring an existing app folder into the registry.
How to verify a NucleoOS change actually works before claiming done or releasing — the full preflight matrix (registry/manifest validation, i18n, gzip parity, API spec drift, ANIMA gate, app tests) plus running the device simulator for web changes. Use when finishing a change, before a release, or when asked to verify/test that something works.