Architecture

Three contracts under which projectMM v2 is built and changed. Every pull request must fit all three; anything that doesn't carries a paired ADR. Architecture changes only via ADR — never silently.

• System architecture — the four core pieces (MoonModule, ModuleManager, Scheduler, Pal) in one page. What lives in core and what doesn't (networking, lighting, persistence are all modules, not core). The MoonModule contract — lifecycle + setup-time hooks (onBuildControls, onAllocateMemory, onUpdate) + control system — read by anyone writing or extending a module.
• Process architecture — the four rules under which the project evolves: Minimalism (the main driver), Guardrails (enforced mechanically by scripts/check_*.py + pre-commit + CI), Anti-drift (the framework itself does not erode), and Port-and-minimize (where substantive modules come from). Read this when proposing structural changes or new files.
• Product requirements — what the product must deliver: binding capacity floors (≥4096 LEDs on a no-PSRAM ESP32), throughput ceilings (ESP32-P4), a desktop-first UX following recognised prior art (TouchDesigner / MADRIX), and test transparency. Binding targets change only via ADR; aspirational ones are stretch goals. System/process say how the code is shaped; this says what it owes the user.

Per-module specifics — controls, lifecycle overrides — live in the User Guide, not here. This section is the contract; the User Guide is the catalogue.