@@ -615,6 +615,10 @@ jobs:
              dist/MoonLight-control-surface.json
           ls -la dist/MoonLight-control-surface.json
 
+      # The module help this release's app shows, so a device reads the help of the firmware it runs: a newer file names controls it lacks. deploy-pages mirrors it beside the release's binaries, where the device's page can read it.
+      - name: Stage the module help
+        run: cp docs/help/help.json dist/MoonLight-help.json
+
       - name: Resolve effective tag
         id: tag
         env:
@@ -743,6 +747,7 @@ jobs:
             dist/MoonLight-*.tar.gz
             dist/MoonLight-*.zip
             dist/MoonLight-control-surface.json
+            dist/MoonLight-help.json
             dist/MoonLight-*.dmg
             dist/MoonLight-*-setup.exe
             dist/moonlight_*.deb
@@ -950,6 +955,7 @@ jobs:
               --pattern 'manifest-*.json' \
               --pattern 'MoonLight-*.tar.gz' \
               --pattern 'MoonLight-*.zip' \
+              --pattern 'MoonLight-help.json' \
               --pattern 'MoonLight-*.dmg' \
               --pattern 'moonlight_*.deb' \
               || echo "  (skip $T — no matching assets)"
@@ -991,23 +997,6 @@ jobs:
           done
           ls -la pages/ pages/install/
 
-      # gen_api.py runs Doxygen -> moxygen to generate the per-module technical pages
-      # (moonmodules/{core,light}/moxygen/*.md) from each `.h`'s /// comments at
-      # MkDocs-build time. moxygen runs via `npx moxygen@2.1.10`, so Node must be
-      # present; pin it explicitly (rather than lean on the runner image's default) so
-      # a future image change can't silently drop npx or shift its behavior. Doxygen
-      # is the one apt binary we add — the justified non-uv dependency (like ESP-IDF's
-      # Python). With the tools present, a moxygen/doxygen failure now RAISES (gen_api
-      # GenApiError) and fails this build, rather than shipping a site with no API pages.
-      - name: Set up Node (for npx moxygen)
-        uses: actions/setup-node@v4
-        with:
-          node-version: '20'
-      - name: Install Doxygen (source-generated API pages)
-        run: |
-          set -euo pipefail
-          sudo apt-get update && sudo apt-get install -y doxygen
-
       - name: Build docs site into Pages root
         run: |
           set -euo pipefail
 
@@ -136,11 +136,6 @@ __pycache__/
 # (the CLI generate_test_docs.py can still write them locally, but they are not committed).
 /docs/reference/tests/*.md
 
-# Generated per-module technical pages — Doxygen+moxygen from each `.h`, built into
-# the site by moondeck/docs/mkdocs_hooks.py (via gen_api.py). Regenerated every build.
-/docs/moonmodules/core/moxygen/
-/docs/moonmodules/light/moxygen/
-/docs/moonmodules/platform/moxygen/
 
 # Read-only hardware snapshots (flash/NVS dumps pulled off reverse-engineered boards).
 # Root-anchored + dir-scoped, like /build/ above: a bare `.snapshots` would also swallow any
 
@@ -56,8 +56,6 @@ BasedOnStyles =
 BasedOnStyles =
 [docs/tests/*.md]
 BasedOnStyles =
-[docs/moonmodules/**/moxygen/*.md]
-BasedOnStyles =
 
 # CLOSING THE NET. A page the sweep has finished is held to every rule on the whole file: a
 # suggestion becomes an error there, so a regression fails the gate instead of annotating a PR.
 
@@ -4,7 +4,7 @@ The rules that bind every change. What the system is: [README.md](README.md). Ho
 
 A high-performance system driving large LED installations and DMX fixtures. One source tree drives ESP32, Teensy, Raspberry Pi, macOS, Windows and Linux.
 
-**Read on every task**: this file. **Read when the task touches them**: the architecture, the two standards pages, and the spec of the module being changed. Everything else is linked from where it applies.
+**Read on every task**: this file. **Read when the task touches them**: the architecture, the two standards pages, and the header of the module being changed. Everything else is linked from where it applies.
 
 ## Principles
 
@@ -130,7 +130,7 @@ flowchart TB
 
 Keep each commit under ~100 changed files: CodeRabbit reviews the files a pushed commit changes, and past that the commit silently loses a review layer. A mechanical sweep (em-dashes, a metrics refresh) is a commit of its own, apart from behavioral fixes, so both stay reviewable.
 
-**A contributed pull request is one topic, about 400 changed lines and ten files at most**, tests included. Generated files (metrics, images, scenario observations) are a category of their own, outside the count. Past a few hundred lines a review stops catching defects (the SmartBear and Cisco review study; Google's guide on small changes), and the product owner reviews every line. Every pull request is based on main. The one exception is a step of a larger topic, which lands as its own pull request and may build on the step below it. A stacked pull request from a fork shows its parents, so it is reviewed once the one below it merges.
+**A contributed pull request is one topic, max 400 changed lines and ten files**, tests included. Generated files (metrics, images, scenario observations) are a category of their own, outside the count. Past a few hundred lines a review stops catching defects (the SmartBear and Cisco review study; Google's guide on small changes), and the product owner reviews every line. Every pull request is based on main. The one exception is a step of a larger topic, which lands as its own pull request and may build on the step below it. A stacked pull request from a fork shows its parents, so it is reviewed once the one below it merges.
 
 ### Build and test
 
@@ -173,7 +173,7 @@ New behavior is pinned before it ships: a unit test for module logic, a scenario
 
 ### Document
 
-Docs land with the code: the module's spec and catalog card describe what shipped, a breaking change gets its [MIGRATING](docs/reference/MIGRATING.md) entry, and a shipped backlog item or spec draft is deleted. The merge gate verifies this happened. How the writing looks and how much of it there is: [documentation-standards.md](docs/contributing/documentation-standards.md), which is the one home for all of it.
+Docs land with the code: the module's header describes what shipped, a breaking change gets its [MIGRATING](docs/reference/MIGRATING.md) entry, and a shipped backlog item or spec draft is deleted. The merge gate verifies this happened. How the writing looks and how much of it there is: [documentation-standards.md](docs/contributing/documentation-standards.md), which is the one home for all of it.
 
 ### Commit
 
 
@@ -251,10 +251,13 @@ add_custom_target(build_info_gen ALL
 # (no semicolons on the command line — those would either get split by `make`
 # on POSIX hosts or land as literals in the value on MSBuild) and let
 # embed_ui.cmake assemble the `<uv> run python` list internally.
+# Every UI file, by glob, so a file added to src/ui re-embeds without a second edit here: the hand-kept list had already missed migrate.js, semver.js and preview-adapt.js.
+file(GLOB UI_SOURCES CONFIGURE_DEPENDS ${CMAKE_SOURCE_DIR}/src/ui/*.js ${CMAKE_SOURCE_DIR}/src/ui/*.html
+     ${CMAKE_SOURCE_DIR}/src/ui/*.css ${CMAKE_SOURCE_DIR}/src/ui/*.png ${CMAKE_SOURCE_DIR}/src/ui/vendor/*.js)
 add_custom_command(
     OUTPUT ${CMAKE_SOURCE_DIR}/src/ui/ui_embedded.h
     COMMAND ${CMAKE_COMMAND} -DUI_DIR=${CMAKE_SOURCE_DIR}/src/ui -DOUT=${CMAKE_SOURCE_DIR}/src/ui/ui_embedded.h -DUV_EXECUTABLE=${UV_EXECUTABLE} -P ${CMAKE_SOURCE_DIR}/src/ui/embed_ui.cmake
-    DEPENDS ${CMAKE_SOURCE_DIR}/src/ui/index.html ${CMAKE_SOURCE_DIR}/src/ui/app.js ${CMAKE_SOURCE_DIR}/src/ui/style.css ${CMAKE_SOURCE_DIR}/src/ui/install-picker.js ${CMAKE_SOURCE_DIR}/src/ui/vendor/prism.js ${CMAKE_SOURCE_DIR}/src/ui/preview3d.js ${CMAKE_SOURCE_DIR}/src/ui/moonmodules-logo.png ${CMAKE_SOURCE_DIR}/src/ui/embed_ui.cmake
+    DEPENDS ${UI_SOURCES} ${CMAKE_SOURCE_DIR}/src/ui/embed_ui.cmake
     COMMENT "Embedding UI files"
 )
 add_custom_target(ui_embed DEPENDS ${CMAKE_SOURCE_DIR}/src/ui/ui_embedded.h)
 
@@ -28,9 +28,9 @@ If you like MoonLight, give it a star, fork it, or open an issue. It helps the p
 
 🎵 **Audio-reactive**: an I²S microphone drives a 16-band FFT spectrum and sound level.
 
-🏠 **Home automation**: a device joins Homebridge and any MQTT hub for on/off, brightness and color. See [the MQTT module](docs/moonmodules/core/services.md#mqtt).
+🏠 **Home automation**: a device joins Homebridge and any MQTT hub for on/off, brightness and color. See [the MQTT module](https://moonmodules.org/MoonLight/moonmodules/core/system.html#mqtt).
 
-📁 **On-device file manager**: browse and edit the device filesystem from the browser, with drag-drop upload and [firmware update over the LAN](docs/moonmodules/core/services.md#firmware-update).
+📁 **On-device file manager**: browse and edit the device filesystem from the browser, with drag-drop upload and [firmware update over the LAN](https://moonmodules.org/MoonLight/moonmodules/core/system.html#firmware-update).
 
 🛡️ **Robust to any input**: add, delete, replace or reconfigure any module in any order, at any grid size, and the device keeps running. Every crash found becomes a regression test.
 
@@ -94,35 +94,35 @@ The domain-neutral runtime: the module base class, controls, scheduling, persist
 
 ![The Services card, built from declared controls](docs/assets/core/Services.png)
 
-Architecture: [MoonCore](docs/explanation/architecture/mooncore.md) · [MoonModule](docs/explanation/architecture/moonmodule.md) · Use it: [System](docs/moonmodules/core/system.md) · [Control](docs/moonmodules/core/system.md#control) · [Services](docs/moonmodules/core/services.md)
+Architecture: [MoonCore](docs/explanation/architecture/mooncore.md) · [MoonModule](docs/explanation/architecture/moonmodule.md) · Use it: [System](https://moonmodules.org/MoonLight/moonmodules/core/system.html) · [Control](https://moonmodules.org/MoonLight/moonmodules/core/system.html#control) · [Services](https://moonmodules.org/MoonLight/moonmodules/core/services.html)
 
 ### MoonLight
 
 The light domain, and the bigger half of the code: light values, layouts, layers, mapping, blending, effects, modifiers and LED drivers. This is what you build a light show from, stacking a layout, then layers of effects and modifiers, then a driver.
 
 ![The Layers panel: a layer, an effect, and its controls](docs/assets/light/Effects.png)
 
-Architecture: [MoonLight](docs/explanation/architecture/moonlight.md) · Use it: [Effects](docs/moonmodules/light/effects.md) · [Layouts](docs/moonmodules/light/layouts.md) · [Modifiers](docs/moonmodules/light/modifiers.md) · [Drivers](docs/moonmodules/light/drivers.md)
+Architecture: [MoonLight](docs/explanation/architecture/moonlight.md) · Use it: [Effects](https://moonmodules.org/MoonLight/moonmodules/light/effects.html) · [Layouts](https://moonmodules.org/MoonLight/moonmodules/light/layouts.html) · [Modifiers](https://moonmodules.org/MoonLight/moonmodules/light/modifiers.html) · [Drivers](https://moonmodules.org/MoonLight/moonmodules/light/drivers.html)
 
 ### MoonLive
 
 Scripts compiled to native machine code on the device. Write an effect in the browser, and it runs at the speed of compiled code rather than an interpreter, on ESP32 and on the desktop alike.
 
 ![A MoonLive effect running](docs/assets/light/effects/MoonLiveEffect.gif)
 
-Architecture: [MoonLive](docs/explanation/architecture/moonlive.md) · Use it: [MoonLiveEffect](docs/moonmodules/light/moonlive.md) · [the script language](moonlive/README.md)
+Architecture: [MoonLive](docs/explanation/architecture/moonlive.md) · Use it: [MoonLiveEffect](https://moonmodules.org/MoonLight/moonmodules/light/moonlive.html) · [the script language](moonlive/README.md)
 
 ### MoonI80
 
-Our own DMA driver for parallel WS2812 output, one of the backends [ParallelLedDriver](docs/moonmodules/light/drivers.md#parallelled) selects. It adds a streaming ring and 74HCT595 expander support, which is what drives 12,288 lights from a single board.
+Our own DMA driver for parallel WS2812 output, one of the backends [ParallelLedDriver](https://moonmodules.org/MoonLight/moonmodules/light/drivers.html#parallelled) selects. It adds a streaming ring and 74HCT595 expander support, which is what drives 12,288 lights from a single board.
 
-Architecture: [MoonLight drivers](docs/explanation/architecture/moonlight.md#drivers) · Use it: [LED drivers](docs/moonmodules/light/drivers.md#moonled)
+Architecture: [MoonLight drivers](docs/explanation/architecture/moonlight.md#drivers) · Use it: [LED drivers](https://moonmodules.org/MoonLight/moonmodules/light/drivers.html#parallelled)
 
 ### MoonBase
 
 A small maintenance image in the factory slot that installs updates into one large app slot, instead of spending half the flash on a second copy of the firmware. A power cut mid-update lands back in MoonBase rather than a half-written app.
 
-Architecture: [MoonBase](docs/explanation/architecture/moonbase.md) · Use it: [System modules](docs/moonmodules/core/system.md)
+Architecture: [MoonBase](docs/explanation/architecture/moonbase.md) · Use it: [System modules](https://moonmodules.org/MoonLight/moonmodules/core/system.html)
 
 ### MoonCloud
 
@@ -213,21 +213,7 @@ We built and maintained these, so MoonLight rests on our own hands-on experience
 
 ## Credits
 
-People whose work directly shaped parts of MoonLight. We study their thinking with respect and write our own code against our architecture:
-
-- **[WLED](https://github.com/wled/WLED) and [WLED-MM](https://github.com/MoonModules/WLED)**: MoonLight is born out of WLED and takes the usermod idea further, where everything is a module. A MoonLight device also acts as a WLED device and talks to WLED devices.
-- **Frank ([softhack007](https://github.com/softhack007))**: main author of the WLED-MM audio-reactive usermod. The ideas behind [AudioService](docs/moonmodules/core/moxygen/AudioService.md), including the adaptive noise gate analyzed with his permission, descend from years of collaboration.
-- **[troyhacks](https://github.com/troyhacks/WLED)**: reworked the WLED-MM audio DSP onto Espressif's [esp-dsp](https://github.com/espressif/esp-dsp) FFT, the same choice AudioService makes.
-- **[Stefan Petrick](https://github.com/StefanPetrick)**: the generative-field vocabulary from [Animartrix](https://github.com/StefanPetrick/animartrix), [FunkyNoise](https://github.com/StefanPetrick/FunkyNoise) and [ColorTrails](https://github.com/StefanPetrick/ColorTrails). [Aurora](docs/moonmodules/light/effects.md#aurora), [PolarNoise](docs/moonmodules/light/effects.md#polarnoise), [Tunnel](docs/moonmodules/light/effects.md#tunnel) and [Trails](docs/moonmodules/light/effects.md#trails) sit in that tradition, written on the published algorithms underneath.
-- **[hpwit](https://github.com/hpwit) (Yves Bazin)**: the clockless I2S, RMT and Parlio driver techniques, and the [ESPLiveScript](https://github.com/hpwit/ESPLiveScript) engine behind MoonLive.
-- **Christophe Gagnier ([@Moustachauve](https://github.com/Moustachauve))**: author of the native [WLED-Android](https://github.com/Moustachauve/WLED-Android) and [WLED-iOS](https://github.com/Moustachauve/WLED-iOS) apps, whose source let MoonLight devices appear in them.
-- **The [Improv Wi-Fi](https://github.com/improv-wifi) project**: the open serial provisioning standard the web installer uses.
-- **[FastLED](https://github.com/FastLED/FastLED)**: the canonical LED-effects library whose names and models MoonLight carries forward (`scale8`, `sin8`, the gradient-palette model, the `beatsin8` family) so a contributor recognizes them on sight. The implementations are our own, integer-only and hot-path-tuned.
-- **[FPP](https://github.com/FalconChristmas/fpp) (Falcon Player)**: the show player that prompted [PanelCardDriver](docs/moonmodules/light/drivers.md#panelcard): if a Linux host can feed a wall of HUB75 panels, so can the board already rendering them.
-- **[Tasmota](https://github.com/arendst/Tasmota) and Mathieu Carbou's [MycilaSafeBoot](https://github.com/mathieucarbou/MycilaSafeBoot)**: the safeboot pattern behind [MoonBase](docs/explanation/architecture/moonbase.md), our from-scratch minimal take on it.
-- **Damian Schneider ([dedehai](https://github.com/DedeHai))**: author of the WLED Particle System, whose shape our [particle kernel](docs/moonmodules/light/power-functions.md#particles) follows in fixed point.
-- **[Piper](https://github.com/OHF-Voice/piper1-gpl) (OHF-Voice)**: the offline text-to-speech that narrates the documentation clips, with voice models from [rhasspy/piper-voices](https://huggingface.co/rhasspy/piper-voices). GPL, and used as a tool rather than linked: MoonTube calls it to render an audio track.
-- **wladi ([myhome-control](https://shop.myhome-control.de))**: designer of the [MHC-WLED ESP32-P4 shield](https://shop.myhome-control.de/en/ABC-WLED-ESP32-P4-shield/HW10027), and the source of the pinout details that got its line-in audio working.
+The people, projects and published algorithms whose work shaped MoonLight, each with what it shaped and the modules that name it, are on the [Attributions](docs/reference/attributions.md) page.
 
 ## Contributing