diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index c9e33d18..327459f4 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -529,6 +529,7 @@ jobs:
             dist/projectMM-*.tar.gz
             dist/projectMM-*.zip
             dist/projectMM-*.dmg
+            dist/projectMM-*-setup.exe
             dist/projectmm_*.deb
 
   # Deploy the web installer to GitHub Pages. Separate from `release` because
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ab8f51a4..492a4b38 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -207,8 +207,37 @@ add_custom_target(ui_embed DEPENDS ${CMAKE_SOURCE_DIR}/src/ui/ui_embedded.h)
 # running); wiring the dep here makes the ordering explicit on every consumer.
 add_dependencies(mm_core ui_embed build_info_gen)
 
+# Windows: give the exe its own icon, so it is recognizable in Explorer, the taskbar and the Start
+# menu whether it was installed or just unzipped. Generated from the same web-installer/favicon.png
+# the macOS .icns comes from, so the mark has one source rather than a checked-in binary per
+# platform. Nothing here runs on macOS or Linux, which carry their icon in the .app and the .deb.
+set(MM_WIN_RESOURCES "")
+if(WIN32)
+    set(MM_ICON "${CMAKE_BINARY_DIR}/projectMM.ico")
+    set(MM_RC   "${CMAKE_BINARY_DIR}/projectMM.rc")
+    add_custom_command(
+        OUTPUT "${MM_ICON}"
+        # `uv run <script>` rather than the usual `uv run python <script>`: make_ico.py declares
+        # Pillow inline (PEP 723), and only the script form makes uv honour that declaration.
+        COMMAND ${UV_EXECUTABLE} run "${CMAKE_SOURCE_DIR}/moondeck/ci/make_ico.py"
+                "${CMAKE_SOURCE_DIR}/web-installer/favicon.png" "${MM_ICON}"
+        DEPENDS "${CMAKE_SOURCE_DIR}/web-installer/favicon.png"
+                "${CMAKE_SOURCE_DIR}/moondeck/ci/make_ico.py"
+        COMMENT "Generating projectMM.ico from favicon.png"
+        VERBATIM)
+    # Forward slashes: rc.exe accepts them, and a backslash here would be an escape.
+    file(WRITE "${MM_RC}"
+         "// Generated by CMake from web-installer/favicon.png. Do not edit.\n"
+         "IDI_ICON1 ICON \"${MM_ICON}\"\n")
+    # The .ico rides along as a source so the custom command runs, but it is data, not something to
+    # compile; the .rc recompiles whenever the icon is regenerated.
+    set_source_files_properties("${MM_ICON}" PROPERTIES HEADER_FILE_ONLY TRUE)
+    set_source_files_properties("${MM_RC}" PROPERTIES OBJECT_DEPENDS "${MM_ICON}")
+    set(MM_WIN_RESOURCES "${MM_RC}" "${MM_ICON}")
+endif()
+
 # Application
-add_executable(projectMM src/main.cpp src/platform/desktop/main_desktop.cpp)
+add_executable(projectMM src/main.cpp src/platform/desktop/main_desktop.cpp ${MM_WIN_RESOURCES})
 target_link_libraries(projectMM PRIVATE mm_core mm_platform)
 add_dependencies(projectMM ui_embed build_info_gen)
 
diff --git a/README.md b/README.md
index 0864afe5..0da7efe8 100644
--- a/README.md
+++ b/README.md
@@ -96,15 +96,17 @@ The numbers above are observations. The **contracts** projectMM commits to, what
 
 ![Installer](docs/assets/ui/installer.png)
 
-**Desktop: download and run.** Grab the build for your OS from the [releases page](https://github.com/MoonModules/projectMM/releases):
+**Desktop: download and run.** Grab the build for your OS from the [releases page](https://github.com/MoonModules/projectMM/releases). Step-by-step with screenshots for Windows: [Installing projectMM on a desktop](docs/tutorials/installing-to-desktop.md).
 
-- **macOS arm64:** `projectMM-macos-arm64-vX.Y.Z.dmg`: open it and drag projectMM to Applications, then launch it like any app. A Terminal window opens showing what it is doing, your browser opens the UI, and closing that window stops it. (`projectMM-macos-arm64-vX.Y.Z.tar.gz` is the same binary without the wrapper, for scripting.) x86-64 macOS is supported and tested, but only the arm64 build is packaged: build from source for an Intel Mac. The app is ad-hoc signed rather than notarized, so the first launch is refused with "Apple could not verify projectMM is free of malware". On macOS 15 and later that dialog offers no way through, so clear the download flag once in Terminal and open it again: `xattr -dr com.apple.quarantine /Applications/projectMM.app` (or `./projectMM` for the tarball).
-- **Windows x64:** `projectMM-windows-x64-vX.Y.Z.zip`: unzip, double-click `projectMM.exe`. SmartScreen may warn on first run because the binary is unsigned (More info → Run anyway).
+- **macOS arm64:** `projectMM-macos-arm64-vX.Y.Z.dmg`: open it and drag projectMM to Applications, then launch it like any app. A Terminal window opens showing what it is doing, your browser opens the UI, and closing that window stops it. (`projectMM-macos-arm64-vX.Y.Z.tar.gz` is the same binary without the wrapper, for scripting.) x86-64 macOS is supported and tested, but only the arm64 build is packaged: build from source for an Intel Mac. The binary is ad-hoc signed rather than notarized, so Gatekeeper says it cannot verify the developer; right-click → Open and confirm, or clear the flag with `xattr -dr com.apple.quarantine ./projectMM`.
+- **Windows x64:** `projectMM-windows-x64-vX.Y.Z-setup.exe`: run it and projectMM installs for your user (no admin prompt) with a Start-menu entry and an uninstaller. `projectMM-windows-x64-vX.Y.Z.zip` is the same binary without the installer, to unzip and run from anywhere. SmartScreen may warn on first run because neither is signed (More info → Run anyway).
 - **Linux x64:** `projectMM-linux-x64-vX.Y.Z.tar.gz`, or `projectmm_X.Y.Z_amd64.deb` on Debian, Ubuntu and Raspberry Pi OS (`sudo apt install ./projectmm_X.Y.Z_amd64.deb` puts it on your PATH).
 
 Then open `http://localhost:8080/`. It opens by itself on start; pass `--no-browser` to suppress
 that (a headless server, or a service manager), and `--port <n>` to serve somewhere else.
 
+**Your settings live with your user, not beside the executable**, so they survive moving the app, reinstalling, and upgrading: `%LOCALAPPDATA%\projectMM` on Windows, `~/Library/Application Support/projectMM` on macOS, and `$XDG_DATA_HOME/projectMM` on Linux, falling back to `~/.local/share/projectMM` when that is unset. An uninstall leaves them in place; delete that folder to start clean. Set `MM_DATA_DIR` to put them somewhere else. Running from a source checkout keeps using `build/` instead, so a development tree stays self-contained.
+
 Once running, the UI lets you build a render pipeline visually (layouts → layers with effects + modifiers → drivers), preview the result in 3D, send it to Art-Net, and save it. The source tree also builds for Teensy, Raspberry Pi, and Linux from source (see [building.md](docs/building.md)), though currently only the macOS, Windows, Linux and ESP32 binaries ship as releases.
 
 ### From source
diff --git a/docs/MIGRATING.md b/docs/MIGRATING.md
index b5605a67..7713d1e1 100644
--- a/docs/MIGRATING.md
+++ b/docs/MIGRATING.md
@@ -22,6 +22,19 @@ projectMM ships **no migration code**: the persistence layer is robust by defaul
 
 ## Unreleased (`next-iteration`)
 
+### Desktop settings move to a per-user directory (2026-08-23)
+
+The desktop build wrote its configuration to `build/.config`, resolved against whatever directory the process happened to start in. That is a source-checkout layout, and it shipped: a downloaded binary either could not write there at all, failing every save and logging one line per save, or it wrote settings that belonged to that *folder* rather than to the user, so moving the executable lost them.
+
+Settings now live with the user: `%LOCALAPPDATA%\projectMM` on Windows, `~/Library/Application Support/projectMM` on macOS, and `$XDG_DATA_HOME/projectMM` on Linux, falling back to `~/.local/share/projectMM` when that is unset. `MM_DATA_DIR` overrides it. **A source checkout is unchanged** and still uses `build/.config`, so a development tree and every gate script behave exactly as before.
+
+**Action: *nothing*, unless your settings actually persisted before.** The old behavior had two modes, and only one of them leaves anything to move:
+
+- **Saves were failing.** The log showed `write failed for /.config/...` on every change and nothing survived a restart. Nothing to carry across.
+- **Saves were succeeding, per folder.** They are in a `build/.config` folder beside wherever you launched from: the folder you unzipped into on Windows and Linux, and `~/build/.config` on macOS, because the `.app` launcher starts in your home directory. **Action: *move a folder*.** Move the `.config` directory itself into the new per-user directory, so it lands as `<data directory>/.config` rather than spilling its files into the root. Or leave it and reconfigure from scratch.
+
+ESP32 is unaffected: LittleFS mounts at a fixed partition and never used this path.
+
 ### The `Layers` container is renamed to `Effects` (2026-08-08)
 
 The three top-level light containers are now **Layouts, Effects, Drivers** — L.E.D. The old name sat one character from its own child (`Layers` holding `Layer`s) and read as a near-twin of `Layouts`, which is the pair a newcomer actually has to tell apart. The tree is unchanged in shape: `Effects` → `Layer`s → effects and modifiers.
diff --git a/docs/assets/tutorials/windows-01-download.png b/docs/assets/tutorials/windows-01-download.png
new file mode 100644
index 00000000..f4a8c427
Binary files /dev/null and b/docs/assets/tutorials/windows-01-download.png differ
diff --git a/docs/assets/tutorials/windows-02-extract.png b/docs/assets/tutorials/windows-02-extract.png
new file mode 100644
index 00000000..2768c3e3
Binary files /dev/null and b/docs/assets/tutorials/windows-02-extract.png differ
diff --git a/docs/assets/tutorials/windows-03-smartscreen.png b/docs/assets/tutorials/windows-03-smartscreen.png
new file mode 100644
index 00000000..69b06a08
Binary files /dev/null and b/docs/assets/tutorials/windows-03-smartscreen.png differ
diff --git a/docs/assets/tutorials/windows-04-running.png b/docs/assets/tutorials/windows-04-running.png
new file mode 100644
index 00000000..6bc93cf6
Binary files /dev/null and b/docs/assets/tutorials/windows-04-running.png differ
diff --git a/docs/backlog/backlog-core.md b/docs/backlog/backlog-core.md
index 9ab3eb9e..2fcca1c2 100644
--- a/docs/backlog/backlog-core.md
+++ b/docs/backlog/backlog-core.md
@@ -940,6 +940,14 @@ The tool shells out to `c++` and `objdump` to build the per-ISA emitter and disa
 
 Closing it is a compiler/disassembler pair behind the two `subprocess.run` calls: `cl.exe` for the build, and for the disassembly either LLVM's `llvm-objdump` (which understands `-b binary` the way the tool already expects, and ships with the VS "C++ Clang tools" component) or a `.obj` wrapper around `dumpbin /disasm`, which does not. Prefer the former — the flags are already right, so it is a lookup rather than a second code path.
 
+## A non-ASCII Windows profile path defeats the desktop settings directory (2026-08-23)
+
+`std::getenv("LOCALAPPDATA")` returns the ANSI form of the path, so a Windows user whose profile name carries characters outside the system codepage (CJK and Cyrillic on a Western machine; most accented Latin survives cp1252) gets `?` where those characters were. `?` is not legal in a Windows filename, so `create_directories` fails, `fsMount` returns false, and the driver reports `cannot use ..., persistence disabled` naming the mangled path. It degrades visibly rather than corrupting anything, which is the standard Principle 5 asks for, but that user has no working persistence.
+
+Reading the variable wide is only half of it. `toFsPath` composes a `std::filesystem::path`, which stores wide on Windows, but every open in the layer goes back through `.string()` to reach `std::fopen` (fsRead, fsReadAt, fsWriteAtomic, fsWriteStream, and the mount probe), a narrowing the code comments on deliberately at `fsRead`. So a wide `LOCALAPPDATA` alone would produce a correct path that still cannot be opened: the fix is one `_wfopen`-on-Windows helper shared by all five sites, plus a test with a non-ASCII root.
+
+Not done with the per-user data directory because it reverses a documented decision across the whole desktop filesystem layer, four of whose five call sites predate that change. What the change did do is make the root capable of containing a username, where it was previously the literal `build`. Worth closing the next time this file is opened for other reasons.
+
 ## A driven GPIO the Pins map never sees: bus padding, and a hidden clockPin
 
 **Found:** 2026-08-21, on MM-S31, after a bench session that started as "the LED panel stopped working" and cost hours chasing a firmware regression that did not exist.
diff --git a/docs/building.md b/docs/building.md
index 18258c73..ff1bc548 100644
--- a/docs/building.md
+++ b/docs/building.md
@@ -65,6 +65,28 @@ Or use MoonDeck's Desktop tab for the same operations with a status dot per card
 
 Each host writes into its own build dir: `build/macos/`, `build/linux/`, `build/windows/`. The per-host layout mirrors the ESP32 side's `build/esp32-<board>/` shape — one directory per target, no cross-target clobbering on a multi-host dev machine.
 
+### Where the desktop keeps its settings
+
+A **source checkout writes to `build/.config/`**, recognized by `CMakeLists.txt` and `moondeck/` both being in the working directory, so a development tree stays self-contained and gitignored. Anywhere else, an installed or unzipped binary writes to the OS per-user data directory:
+
+| Platform | Directory |
+|---|---|
+| Windows | `%LOCALAPPDATA%\projectMM` |
+| macOS | `~/Library/Application Support/projectMM` |
+| Linux | `$XDG_DATA_HOME/projectMM`, else `~/.local/share/projectMM` |
+
+`MM_DATA_DIR` overrides both, which is how the test suite pins its root into the build tree rather than touching a developer's real settings.
+
+The distinction matters because a shipped binary is launched from a download folder or a Start-menu shortcut, where a path relative to the working directory is either unwritable or belongs to that folder rather than to the user. The root is created when the filesystem mounts, and a location that cannot be written to fails the mount and is reported once, rather than surfacing as a failed save on every change.
+
+### Packaging
+
+`uv run moondeck/ci/package_desktop.py` builds and packages for the host it runs on: a `.dmg` with a `.app` on macOS, a `.tar.gz` plus a `.deb` on Linux, and a `.zip` plus an NSIS `-setup.exe` on Windows. The Windows installer puts the program in `%LOCALAPPDATA%\Programs\projectMM` with a Start-menu shortcut and an uninstaller; it needs no elevation, and it never touches the settings directory, so an upgrade keeps the user's configuration.
+
+Both the Windows icon and the macOS `.icns` derive from `web-installer/favicon.png`, so the mark has one source. The `.ico` is generated during the CMake build (`moondeck/ci/make_ico.py`, which pulls Pillow on demand through uv) and embedded in the executable, so the binary carries its icon whether it was installed or just unzipped.
+
+Each packager skips its platform-specific format when the tool is missing (`dpkg-deb`, `makensis`) on a dev machine, and fails outright under CI, where a missing artifact would otherwise fail the release with an error naming a glob rather than the absent tool.
+
 ### Prerequisites
 
 Every host needs [uv](https://docs.astral.sh/uv/), CMake 3.20+, and a C++20 compiler.
diff --git a/docs/history/lessons.md b/docs/history/lessons.md
index bc4da662..95d5ed1a 100644
--- a/docs/history/lessons.md
+++ b/docs/history/lessons.md
@@ -574,3 +574,19 @@ evidence which *looks* most authoritative here is the evidence that lies.
   and one was rewritten. The habit that catches it is cheap: **sabotage the fix and confirm the test
   goes red before believing it.** Two of those three had also been failing for a reason unrelated to
   what they claimed to assert, which the control check surfaced immediately.
+
+- **A build script that does not build what the next command tests produces a confident false
+  green.** `build_desktop.py` builds `projectMM` but not `mm_tests`/`mm_scenarios` unless given
+  `--tests`, so `ctest` straight after it runs whatever binary was there before. It reported "1377
+  passed" against a test binary two hours old, on a change whose new option string was not even
+  present in it. The tell is cheap and worth the habit: **after changing code, confirm the test
+  binary actually contains the change** (a `grep` for a new string, or a run of just the new case)
+  before believing a green suite. The staleness guards in `run_scenario.py` exist for exactly this
+  and are why the scenario half never went unnoticed; the unit half has no such guard.
+
+- **A freshness guard keyed on mtime must exclude files the build itself rewrites.** The same guard
+  then cried wolf: `build_info.h` embeds a `+` when `git status` reports a dirty tree, and a gate run
+  dirties the tree by writing its own scenario baselines and metrics. So every gate run left the
+  next one reporting a stale runner, a self-inflicted loop that reads exactly like a real staleness
+  failure. **Generated build metadata is not source**, and a guard that cannot tell them apart
+  teaches people to ignore it.
diff --git a/docs/history/plans/Plan-20260823 - A Windows installer, and settings that persist.md b/docs/history/plans/Plan-20260823 - A Windows installer, and settings that persist.md
new file mode 100644
index 00000000..ffe06b01
--- /dev/null
+++ b/docs/history/plans/Plan-20260823 - A Windows installer, and settings that persist.md	
@@ -0,0 +1,82 @@
+# Plan, A Windows installer, and settings that persist
+
+## Context
+
+Two defects found on the Windows bench, both hit by the same user in the same session.
+
+**Settings do not persist.** The log fills with `FilesystemModule: write failed for /.config/NetworkModule.json`, one line per save, and every setting is lost on restart.
+
+The root cause is [platform_desktop.cpp:495](src/platform/desktop/platform_desktop.cpp#L495):
+
+```cpp
+std::filesystem::path fsRoot_{"build"};
+```
+
+A **relative** path, resolved against the process working directory. That is a developer-layout assumption shipped in the product. A double-clicked exe has no writable `build\` beside it, and even where the directory is writable the settings become per-folder: move the exe, re-extract the zip, or launch from elsewhere and they are gone. It also explains a stray instance seen on this bench that came up with no PanelCard driver at all: it simply could not read `build/.config/Drivers.json` from its working directory.
+
+Two things then hide the failure rather than reporting it. `FilesystemModule::setup()` ([FilesystemModule.cpp:39](src/core/FilesystemModule.cpp#L39)) discards the result of `fsMkdir(CONFIG_DIR)`, and desktop `fsMount()` returns `true` unconditionally, so the "mount failed, persistence disabled" path can never fire on desktop. The result is a stream of downstream write errors instead of one clear statement at startup that the location is unusable.
+
+**Windows is the only platform with no install experience.** `moondeck/ci/package_desktop.py` builds a signed `.app` with an icon for macOS and a `.deb` with an icon and menu entry for Linux. Windows gets a bare `.exe` and a `README.txt` in a zip: no icon, no Start-menu entry, no uninstaller.
+
+Outcome: a Windows user installs projectMM the way a macOS user does, and their settings survive both a restart and an update.
+
+## Approach
+
+### Part 1: settings that persist
+
+Default the desktop filesystem root to a per-user data directory, created at mount time:
+
+| Platform | Data directory |
+|---|---|
+| Windows | `%LOCALAPPDATA%\projectMM` |
+| macOS | `~/Library/Application Support/projectMM` |
+| Linux | `$XDG_DATA_HOME/projectMM`, else `~/.local/share/projectMM` |
+
+**A repo checkout keeps using `build/`**, detected by `CMakeLists.txt` AND `moondeck/` both being present in the working directory (`CMakeLists.txt` alone is true in the root of every CMake project). This is the non-destructive half of the change: the dev workflow, every gate script, and the existing tests are untouched, and nobody's local config silently relocates. `MM_DATA_DIR` overrides both cases, for tests and for anyone who wants the data somewhere specific.
+
+**Make the failure loud and singular.** Desktop `fsMount()` creates the root and returns `false` when it cannot, so `FilesystemModule::setup()`'s existing "persistence disabled" branch does its job. Check the `fsMkdir(CONFIG_DIR)` result there too. One error at startup naming the directory, instead of one per save forever.
+
+Reuse what exists rather than adding seams: `fsMkdir` ([platform_desktop.cpp:526](src/platform/desktop/platform_desktop.cpp#L526)) already wraps `create_directories`, `fsSetRoot` already exists for the override, and `toFsPath` already rejects paths escaping the root.
+
+### Part 2: the installer
+
+**NSIS**, producing `projectMM-windows-x64-vX.Y.Z-setup.exe` beside the existing zip, which stays for portable use.
+
+- **Program** installs to `%LOCALAPPDATA%\Programs\projectMM`, per-user, so no elevation prompt.
+- **Start-menu shortcut** with the icon, plus an uninstaller and an Add/Remove Programs entry.
+- **Icon**: generate a `.ico` from the existing `web-installer/favicon.png` (the macOS path already derives its `.icns` from the same source), and embed it in the exe through a Windows `.rc` resource so the binary carries its icon even outside the installer.
+- **Skip when `makensis` is absent on a dev machine, fail outright under CI**, matching the pattern the `.deb` path already uses for a missing `dpkg-deb`. The asymmetry is the point: the release uploads with `fail_on_unmatched_files`, so a silent skip there would fail the whole release, ESP32 firmware and all, with an error naming a glob rather than the absent tool.
+- **Close a running instance before overwriting.** A running `projectMM.exe` holds a lock on the file, which is exactly how three build attempts failed during this session's bench work. The installer must detect and stop it, or the upgrade fails with a file-in-use error.
+
+**Settings survive an update by construction**, because the program and the data live in separate directories:
+
+```text
+%LOCALAPPDATA%\Programs\projectMM\    program   - replaced on update, removed on uninstall
+%LOCALAPPDATA%\projectMM\.config\     settings  - never touched by the installer
+```
+
+The uninstaller removes the program only and leaves settings in place, which is standard Windows behavior and means a reinstall or an upgrade finds the user's configuration exactly where it was.
+
+Unsigned, so SmartScreen will warn on first run, the same trade-off already documented for the bare exe and for macOS Gatekeeper. Code signing is out of scope here.
+
+## Files
+
+- **`src/platform/desktop/platform_desktop.cpp`**, the data-directory resolution and the `MM_DATA_DIR` / checkout-detection rules; `fsMount()` creates the root and reports failure.
+- **`src/core/FilesystemModule.cpp`**, check the `fsMkdir(CONFIG_DIR)` result in `setup()` and `loadAll()`; report once, naming the directory.
+- **`CMakeLists.txt`**, a `WIN32`-guarded `.rc` resource so the exe carries the icon.
+- **`moondeck/ci/package_desktop.py`**, `.ico` generation from `web-installer/favicon.png`, the NSIS script, and the installer build with its skip-if-absent guard.
+- **`.github/workflows/release.yml`**, publish the installer alongside the zip from the existing `build-windows` job.
+- **`docs/building.md`, `README.md`**, the Windows install path, and where settings live per platform.
+
+## Verification
+
+1. **Unit tests** (`test/unit/core/`, alongside the existing `unit_FilesystemModule_persistence.cpp`): outside a checkout the default root is the per-user directory; inside one it stays `build`; `MM_DATA_DIR` wins over both; an unwritable root fails the mount rather than reporting a write error per save.
+2. `ctest --test-dir build/windows -C Release`, note `build_desktop.py --tests` is required first, or ctest silently runs a stale binary.
+3. **The bug, end to end**: run the exe from a directory with no `build\`, change a setting, restart, confirm it persists and that no `write failed` line appears.
+4. **The installer**: install, launch from the Start menu, change a setting, then install again over the top and confirm the setting survives the upgrade. Uninstall and confirm settings remain.
+5. **No regression for the other platforms**: macOS and Linux packaging still build, and a repo checkout still writes to `build/.config`.
+
+## Risks
+
+- **The macOS `.app` has the same latent bug**: its launcher runs `open -a Terminal`, which starts in `$HOME`, so its root is `~/build/.config`. If that works today it works by accident. This change fixes it as a side effect, but anyone relying on the accidental location will find their settings in the new directory. Worth a line in the release notes; no automatic migration, per the chosen option.
+- **NSIS on `windows-latest`** is confirmed present (3.10) in the runner image manifest, so no setup step is needed. The bench used 3.12; the script uses nothing version-specific, but the two are not identical, so the first release run is still worth a glance.
diff --git a/docs/metrics/repo-health.json b/docs/metrics/repo-health.json
index f0f22729..0ed7dc1b 100644
--- a/docs/metrics/repo-health.json
+++ b/docs/metrics/repo-health.json
@@ -1,10 +1,18 @@
 {
+<<<<<<< HEAD
+  "commit": "4c91f700",
+=======
   "commit": "ab508402",
+>>>>>>> main
   "flash": {
     "esp32": 1764416,
     "esp32p4rev1-eth": 1653696,
     "esp32p4rev1-eth-wifi": 1933472,
+<<<<<<< HEAD
+    "esp32s3-n16r8": 1804944,
+=======
     "esp32s3-n16r8": 1813456,
+>>>>>>> main
     "esp32s3-n8r8": 1753232,
     "esp32s31": 2079904,
     "esp32-16mb": 1714608,
@@ -12,12 +20,21 @@
     "esp32-wrover": 1765504,
     "qemu": 1318160,
     "esp32p4rev3-eth": 1643760,
+<<<<<<< HEAD
+    "desktop": 1214976
+  },
+  "perf": {
+    "desktop": {
+      "tick_us": 356,
+      "fps": 2808
+=======
     "desktop": 1230168
   },
   "perf": {
     "desktop": {
       "tick_us": 182,
       "fps": 5494
+>>>>>>> main
     },
     "esp32": {
       "tick_us": 2151,
@@ -25,6 +42,19 @@
     }
   },
   "loc": {
+<<<<<<< HEAD
+    "core": 19600,
+    "light": 25712,
+    "platform": 14900,
+    "ui": 7023,
+    "test": 45720,
+    "moondeck": 21801
+  },
+  "comments": {
+    "core": {
+      "lines": 7693,
+      "ratio": 0.425
+=======
     "core": 19684,
     "light": 25824,
     "platform": 14891,
@@ -36,12 +66,40 @@
     "core": {
       "lines": 7746,
       "ratio": 0.426
+>>>>>>> main
     },
     "light": {
       "lines": 10237,
       "ratio": 0.438
     },
     "platform": {
+<<<<<<< HEAD
+      "lines": 5306,
+      "ratio": 0.391
+    },
+    "ui": {
+      "lines": 1857,
+      "ratio": 0.281
+    },
+    "test": {
+      "lines": 8377,
+      "ratio": 0.21
+    },
+    "moondeck": {
+      "lines": 3507,
+      "ratio": 0.184
+    }
+  },
+  "tests": {
+    "cases": 1493,
+    "scenarios": 23
+  },
+  "docs": {
+    "md_files": 191,
+    "md_lines": 27684,
+    "plans_files": 97,
+    "backlog_lines": 4319,
+=======
       "lines": 5303,
       "ratio": 0.391
     },
@@ -67,6 +125,7 @@
     "md_lines": 27631,
     "plans_files": 96,
     "backlog_lines": 4341,
+>>>>>>> main
     "lessons_lines": 576,
     "claude_md_lines": 136
   },
diff --git a/docs/metrics/repo-health.md b/docs/metrics/repo-health.md
index 14cdf918..ad03a694 100644
--- a/docs/metrics/repo-health.md
+++ b/docs/metrics/repo-health.md
@@ -1,6 +1,10 @@
 # Repo health
 
+<<<<<<< HEAD
+Measured at `4c91f700`. Generated by [`moondeck/check/repo_health.py`](../../moondeck/check/repo_health.py) on every KPI-gate run. **Do not edit by hand.**
+=======
 Measured at `ab508402`. Generated by [`moondeck/check/repo_health.py`](../../moondeck/check/repo_health.py) on every KPI-gate run. **Do not edit by hand.**
+>>>>>>> main
 
 Current state only; the trend is this file's git history (`git log -p docs/metrics/repo-health.md`). Nothing here fails a build: the numbers make growth visible, the judgment stays human.
 
@@ -8,7 +12,11 @@ Current state only; the trend is this file's git history (`git log -p docs/metri
 
 | Target | Flash |
 |---|---:|
+<<<<<<< HEAD
+| desktop | 1,186 KB |
+=======
 | desktop | 1,201 KB |
+>>>>>>> main
 | esp32 | 1,723 KB |
 | esp32-16mb | 1,674 KB |
 | esp32-eth | 1,294 KB |
@@ -16,7 +24,11 @@ Current state only; the trend is this file's git history (`git log -p docs/metri
 | esp32p4rev1-eth | 1,615 KB |
 | esp32p4rev1-eth-wifi | 1,888 KB |
 | esp32p4rev3-eth | 1,605 KB |
+<<<<<<< HEAD
+| esp32s3-n16r8 | 1,763 KB |
+=======
 | esp32s3-n16r8 | 1,771 KB (+0 KB) ⚠ |
+>>>>>>> main
 | esp32s3-n8r8 | 1,712 KB |
 | esp32s31 | 2,031 KB |
 | qemu | 1,287 KB |
@@ -25,25 +37,42 @@ Current state only; the trend is this file's git history (`git log -p docs/metri
 
 | Target | Tick | FPS |
 |---|---:|---:|
+<<<<<<< HEAD
+| desktop | 356 µs (−40 µs) ✓ | 2,808 (+283) ✓ |
+=======
 | desktop | 182 µs (−309 µs) ✓ | 5,494 (+3,458) ✓ |
+>>>>>>> main
 | esp32 | 2,151 µs | 464 |
 
 ## Code
 
 | Area | Lines | Comments | Comment share |
 |---|---:|---:|---:|
+<<<<<<< HEAD
+| core | 19,600 | 7,693 | 42.5 % |
+| light | 25,712 | 10,161 | 43.6 % |
+| platform | 14,900 | 5,306 | 39.1 % |
+| ui | 7,023 | 1,857 | 28.1 % |
+| test | 45,720 (+24) ⚠ | 8,377 | 21.0 % |
+| moondeck | 21,801 (+47) ⚠ | 3,507 | 18.4 % |
+=======
 | core | 19,684 | 7,746 | 42.6 % |
 | light | 25,824 (+9) ⚠ | 10,237 | 43.8 % (+0.1 %) ⚠ |
 | platform | 14,891 | 5,303 | 39.1 % |
 | ui | 7,028 | 1,861 | 28.1 % |
 | test | 45,902 (+123) ⚠ | 8,438 | 21.1 % |
 | moondeck | 21,626 (+8) ⚠ | 3,504 | 18.5 % |
+>>>>>>> main
 
 ## Tests
 
 | Kind | Count |
 |---|---:|
+<<<<<<< HEAD
+| unit cases | 1,493 (+1) ✓ |
+=======
 | unit cases | 1,511 (+7) ✓ |
+>>>>>>> main
 | scenarios | 23 |
 
 ## Complexity
@@ -58,10 +87,17 @@ Current state only; the trend is this file's git history (`git log -p docs/metri
 
 | Metric | Value |
 |---|---:|
+<<<<<<< HEAD
+| markdown files | 191 (+2) ⚠ |
+| markdown lines | 27,684 (+177) ⚠ |
+| plan files | 97 (+1) ⚠ |
+| backlog lines | 4,319 (+8) ⚠ |
+=======
 | markdown files | 189 |
 | markdown lines | 27,631 (+1) ⚠ |
 | plan files | 96 |
 | backlog lines | 4,341 (−1) ✓ |
+>>>>>>> main
 | lessons lines | 576 |
 | CLAUDE.md lines | 136 |
 
diff --git a/docs/tutorials/installing-to-desktop.md b/docs/tutorials/installing-to-desktop.md
new file mode 100644
index 00000000..c0f060d6
--- /dev/null
+++ b/docs/tutorials/installing-to-desktop.md
@@ -0,0 +1,89 @@
+# Installing projectMM on a desktop
+
+projectMM does not need an ESP32. The same code runs as an ordinary application on your computer, rendering effects, serving the web UI, and driving Art-Net, DMX and LED panel cards over the network. It is the quickest way to see projectMM working, and on a real PC the effects have far more compute behind them than any microcontroller can offer.
+
+This page covers **Windows**. For macOS and Linux, the [README](https://github.com/MoonModules/projectMM#readme) has the download and first-run steps.
+
+> Looking to flash a device instead? That is [Install & first light](../gettingstarted.md). This page is about running projectMM *on the computer itself*.
+
+---
+
+## 1. Download it
+
+Open the [web installer](https://moonmodules.org/projectMM/install/) and set **Install to** to `This computer (Windows x64)`. The Release picker offers stable releases and `latest`, a build published on every merge to main; pick a stable one unless you want the newest unreleased changes.
+
+![The web installer with Windows x64 selected, and the downloaded zip in the browser's Downloads panel](../assets/tutorials/windows-01-download.png)
+
+**Download** gives you `projectMM-windows-x64-vX.Y.Z.zip`. There is nothing to sign up for and nothing else to install: the zip holds the application and a README, and that is all it needs.
+
+## 2. Extract it, do not run it from inside the zip
+
+Open the zip and Windows offers you **Extract all** or **Run**.
+
+![Windows offering Extract all or Run when opening the executable inside the zip](../assets/tutorials/windows-02-extract.png)
+
+**Choose Extract all.** Running straight from a zip makes Windows unpack the application into a temporary folder that it may clear at any time, so you end up running a copy that quietly disappears later. Extract it somewhere you would keep a program, then run it from there.
+
+## 3. Run it, and get past SmartScreen
+
+Double-click `projectMM.exe`. The first time, Windows stops you:
+
+![Microsoft Defender SmartScreen warning that it prevented an unrecognized app from starting](../assets/tutorials/windows-03-smartscreen.png)
+
+This is expected. SmartScreen warns about any application it has not seen signed by a paid, registered publisher, and projectMM is not code-signed. It is a statement about the certificate, not about the file.
+
+Click **More info**, then **Run anyway**. You only have to do this once for a given copy.
+
+## 4. That is it
+
+A console window opens showing what projectMM is doing, and your browser opens the interface at `http://localhost:8080/`.
+
+![projectMM running: the web interface with a live preview, alongside the console window showing the startup log](../assets/tutorials/windows-04-running.png)
+
+The console window **is** the application. It shows the log, and closing it stops projectMM. The line that matters on a first run is `projectMM is running: http://localhost:8080/`; the address just below it (`HTTP server -> http://192.168.1.245:8080` in the screenshot) is the same interface reachable from your phone or another machine on your network.
+
+Out of the box you get a 16x16 grid and a running effect, which is enough to confirm everything works. From here, [How projectMM works](how-projectmm-works.md) explains the Layouts, Effects and Drivers you see on the left.
+
+Two options worth knowing: `--no-browser` stops it opening a browser (for a headless machine), and `--port <n>` serves somewhere other than 8080.
+
+## 5. Where your settings live
+
+Everything you change is saved automatically, in a folder that belongs to **your Windows user** rather than to the application:
+
+```text
+%LOCALAPPDATA%\projectMM
+```
+
+This applies from the release that introduced it. On an older build, settings sat in a `build\.config` folder beside the executable instead, and the log said `write failed` for each save when that folder could not be created.
+
+The location is deliberate, and it has a consequence worth knowing: **your settings are not in the folder you extracted to**. Move the application, replace it with a newer version, or delete the extracted folder entirely, and your configuration is still there. To start completely fresh, delete that folder.
+
+Paste `%LOCALAPPDATA%\projectMM` into the Explorer address bar to open it.
+
+## 6. Or use the installer
+
+From the next release there is also `projectMM-windows-x64-vX.Y.Z-setup.exe`. It does the same thing as the steps above, with less clicking: it installs for your user, so there is no administrator prompt, and adds a **Start-menu entry with an icon** and a proper uninstaller.
+
+The zip stays available and is the right choice if you want to keep projectMM in a folder of your own, or run it from a USB stick.
+
+Both are unsigned, so SmartScreen warns for either. Installing a new version over an old one keeps your settings, because the program and the settings live in different places; uninstalling removes the program and leaves your settings behind.
+
+---
+
+## When it does not start
+
+| Symptom | Look at |
+|---|---|
+| SmartScreen has no **Run anyway** | Click **More info** first; the button is hidden until you do. |
+| It opened and closed immediately | Run it from a terminal (`cd` to the folder, then `.\projectMM.exe`) so the error stays on screen instead of vanishing with the window. |
+| The browser shows nothing at `localhost:8080` | Check the console window is still open. Closing it stops projectMM. If another program already uses port 8080, start with `--port 8081`. |
+| Another machine cannot reach it | Use the `HTTP server ->` address from the log, not `localhost`. Windows Firewall prompts on first run; it needs to be allowed on your private network. |
+| Settings do not survive a restart | The log will say `cannot use ... persistence disabled` and name the directory it tried. That is the fault, not the saving itself. |
+
+---
+
+## Where to go next
+
+- **[How projectMM works](how-projectmm-works.md)**: the interface, and the Layouts / Effects / Drivers model.
+- **[Driving LED panels with a receiving card](panel-cards.md)**: turn this desktop into the sending card for an LED wall.
+- **[Install & first light](../gettingstarted.md)**: flashing an ESP32, if you want the same thing on a device.
diff --git a/mkdocs.yml b/mkdocs.yml
index 79b37c43..a03a977f 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -128,6 +128,7 @@ nav:
   # this section and are being folded in gradually).
   - Tutorials:
       - How projectMM works: tutorials/how-projectmm-works.md
+      - Installing projectMM on a desktop: tutorials/installing-to-desktop.md
       - Driving LED panels with a receiving card: tutorials/panel-cards.md
       - Build your own MoonModules: usecases/build-your-own-moonmodules.md
       - Home automation: usecases/home-automation.md
diff --git a/moondeck/ci/make_ico.py b/moondeck/ci/make_ico.py
new file mode 100644
index 00000000..8e0a285c
--- /dev/null
+++ b/moondeck/ci/make_ico.py
@@ -0,0 +1,47 @@
+# /// script
+# requires-python = ">=3.9"
+# dependencies = ["pillow"]
+# ///
+"""Turn a PNG into a Windows .ico.
+
+Run: uv run moondeck/ci/make_ico.py <source.png> <out.ico>
+
+Pillow is declared inline (PEP 723) rather than added to the project, because this is the only
+thing in the tree that needs it and it runs at most once per build. uv fetches it on demand.
+
+The source is the same web-installer/favicon.png the macOS .icns is derived from, so the mark has
+one home. A resize is unavoidable: ICO stores each image's dimensions in a SINGLE byte (with 0
+meaning 256), so the 320x320 source cannot be embedded as-is at any size.
+"""
+import sys
+from pathlib import Path
+
+# Every size Windows picks between: the small ones appear in Explorer lists and the title bar, 256
+# in large-icon views and the installer. Shipping all of them beats letting Windows downscale one,
+# which it does badly at small sizes.
+SIZES = [16, 24, 32, 48, 64, 128, 256]
+
+
+def main() -> int:
+    if len(sys.argv) != 3:
+        print("usage: make_ico.py <source.png> <out.ico>", file=sys.stderr)
+        return 2
+
+    src, dst = Path(sys.argv[1]), Path(sys.argv[2])
+    if not src.is_file():
+        print(f"make_ico: no such file: {src}", file=sys.stderr)
+        return 1
+
+    from PIL import Image
+
+    # RGBA throughout: the source is palette-mode, and a palette image saved into an .ico loses
+    # its transparency to a black square behind the mark.
+    img = Image.open(src).convert("RGBA")
+    dst.parent.mkdir(parents=True, exist_ok=True)
+    img.save(dst, format="ICO", sizes=[(s, s) for s in SIZES])
+    print(f"make_ico: {src.name} {img.size[0]}x{img.size[1]} -> {dst} ({dst.stat().st_size} bytes)")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/moondeck/ci/package_desktop.py b/moondeck/ci/package_desktop.py
index f818b649..3bdede3a 100644
--- a/moondeck/ci/package_desktop.py
+++ b/moondeck/ci/package_desktop.py
@@ -363,6 +363,167 @@ def package_macos(binary: Path, version: str) -> Path:
     return out
 
 
+NSI_TEMPLATE = r'''Unicode true
+!define APPNAME "projectMM"
+!define PUBLISHER "MoonModules"
+!define HOMEPAGE "https://github.com/MoonModules/projectMM"
+!define UNINSTKEY "Software\Microsoft\Windows\CurrentVersion\Uninstall\projectMM"
+
+Name "${APPNAME} @VERSION@"
+OutFile "@OUT@"
+; Per-user, under Programs: no elevation prompt, and no chance of landing in a directory the user
+; cannot write to. The SETTINGS live in $LOCALAPPDATA\projectMM, deliberately NOT under here, so an
+; upgrade replaces the program and leaves the configuration untouched.
+InstallDir "$LOCALAPPDATA\Programs\projectMM"
+InstallDirRegKey HKCU "${UNINSTKEY}" "InstallLocation"
+RequestExecutionLevel user
+SetCompressor /SOLID lzma
+!include "MUI2.nsh"
+!define MUI_ICON "@ICON@"
+!define MUI_UNICON "@ICON@"
+!insertmacro MUI_PAGE_DIRECTORY
+!insertmacro MUI_PAGE_INSTFILES
+!insertmacro MUI_UNPAGE_CONFIRM
+!insertmacro MUI_UNPAGE_INSTFILES
+!insertmacro MUI_LANGUAGE "English"
+
+Section "install"
+  ; A running projectMM.exe holds a lock on the file and the install would fail with a
+  ; file-in-use error. taskkill is a Windows built-in, so this needs no NSIS plugin; it is
+  ; harmless when nothing is running. projectMM is a local server the user restarts from the
+  ; Start menu, so stopping it costs a reconnect, not work.
+  DetailPrint "Stopping any running ${APPNAME}..."
+  nsExec::Exec 'taskkill /F /IM projectMM.exe'
+  Pop $0
+
+  SetOutPath "$INSTDIR"
+  File "@BINARY@"
+  File /oname=projectMM.ico "@ICON@"
+  File /oname=README.txt "@README@"
+
+  CreateDirectory "$SMPROGRAMS\${APPNAME}"
+  CreateShortcut "$SMPROGRAMS\${APPNAME}\${APPNAME}.lnk" "$INSTDIR\projectMM.exe" "" "$INSTDIR\projectMM.ico"
+  CreateShortcut "$SMPROGRAMS\${APPNAME}\Uninstall ${APPNAME}.lnk" "$INSTDIR\uninstall.exe"
+
+  WriteUninstaller "$INSTDIR\uninstall.exe"
+  ; Add/Remove Programs. HKCU to match the per-user install: an HKLM entry would need elevation
+  ; and would advertise the app to users who do not have it.
+  WriteRegStr   HKCU "${UNINSTKEY}" "DisplayName"     "${APPNAME}"
+  WriteRegStr   HKCU "${UNINSTKEY}" "DisplayVersion"  "@VERSION@"
+  WriteRegStr   HKCU "${UNINSTKEY}" "Publisher"       "${PUBLISHER}"
+  WriteRegStr   HKCU "${UNINSTKEY}" "URLInfoAbout"    "${HOMEPAGE}"
+  WriteRegStr   HKCU "${UNINSTKEY}" "DisplayIcon"     "$INSTDIR\projectMM.ico"
+  WriteRegStr   HKCU "${UNINSTKEY}" "InstallLocation" "$INSTDIR"
+  WriteRegStr   HKCU "${UNINSTKEY}" "UninstallString" "$INSTDIR\uninstall.exe"
+  WriteRegDWORD HKCU "${UNINSTKEY}" "NoModify" 1
+  WriteRegDWORD HKCU "${UNINSTKEY}" "NoRepair" 1
+SectionEnd
+
+Section "uninstall"
+  nsExec::Exec 'taskkill /F /IM projectMM.exe'
+  Pop $0
+  Delete "$INSTDIR\projectMM.exe"
+  Delete "$INSTDIR\projectMM.ico"
+  Delete "$INSTDIR\README.txt"
+  Delete "$INSTDIR\uninstall.exe"
+  RMDir "$INSTDIR"
+  Delete "$SMPROGRAMS\${APPNAME}\${APPNAME}.lnk"
+  Delete "$SMPROGRAMS\${APPNAME}\Uninstall ${APPNAME}.lnk"
+  RMDir "$SMPROGRAMS\${APPNAME}"
+  DeleteRegKey HKCU "${UNINSTKEY}"
+  ; $LOCALAPPDATA\projectMM is NOT removed. Settings outlive the program on purpose: an uninstall
+  ; is often a step in a reinstall, and silently discarding a user's configuration is the kind of
+  ; thing they only discover afterwards. Removing that folder by hand is the documented way out.
+SectionEnd
+'''
+
+
+def windows_icon(version: str) -> Path | None:
+    """The .ico for the installer, its shortcut and Add/Remove Programs.
+
+    Prefers the one CMake already generated beside the binary, so the installer and the exe carry
+    the identical icon; regenerates it only when packaging a build that did not produce one.
+    """
+    built = BUILD_DIR_WIN / "projectMM.ico"
+    if built.exists():
+        return built
+    out = DIST_DIR / "projectMM.ico"
+    src = ROOT / "web-installer" / "favicon.png"
+    if not src.exists():
+        print("package_desktop: no favicon to generate an icon from")
+        return None
+    run(["uv", "run", str(ROOT / "moondeck" / "ci" / "make_ico.py"), str(src), str(out)])
+    return out if out.exists() else None
+
+
+def find_makensis() -> str | None:
+    """NSIS's compiler, on PATH or in its default install location.
+
+    The Windows NSIS installer does NOT put itself on PATH, so `which` alone reports it missing on
+    a developer machine that has it installed the ordinary way. CI's runner image does have it on
+    PATH; this is what makes a local packaging run behave the same as the release one.
+    """
+    exe = shutil.which("makensis")
+    if exe:
+        return exe
+    for base in (os.environ.get("ProgramFiles(x86)"), os.environ.get("ProgramFiles")):
+        if not base:
+            continue
+        candidate = Path(base) / "NSIS" / "makensis.exe"
+        if candidate.is_file():
+            return str(candidate)
+    return None
+
+
+def package_windows_installer(binary: Path, version: str) -> Path | None:
+    """A setup.exe, built with NSIS when the host has makensis (the windows-latest runner does).
+
+    The zip beside it stays the portable form: unpack anywhere, run, no install. This is for the
+    user who wants what macOS and Linux already get, an entry in the Start menu with an icon and a
+    working uninstall, rather than an executable loose in their Downloads folder.
+    """
+    makensis = find_makensis()
+    if makensis is None:
+        # Same reasoning as the .deb: on CI this is fatal, because the release uploads the
+        # installer with fail_on_unmatched_files and a skip would fail the whole release with an
+        # error naming a glob rather than the missing tool. On a dev machine it is a skip, and the
+        # zip beside it is what that developer uses.
+        if os.environ.get("CI"):
+            sys.exit("package_desktop: no makensis on this CI runner, cannot build the installer")
+        print("package_desktop: no makensis on this host, skipping the installer")
+        return None
+
+    icon = windows_icon(version)
+    if icon is None:
+        # CI-fatal for the same reason as the missing makensis above: the release uploads the
+        # installer with fail_on_unmatched_files, so skipping here would fail the whole release
+        # with an error naming a glob rather than the missing icon source.
+        if os.environ.get("CI"):
+            sys.exit("package_desktop: no icon for the installer, and no favicon to build one from")
+        print("package_desktop: no icon, skipping the installer")
+        return None
+
+    out = DIST_DIR / f"projectMM-windows-x64-v{version}-setup.exe"
+    readme = DIST_DIR / "_README.txt"
+    readme.write_text(readme_text(version, "Windows x64"), encoding="utf-8")
+    script = DIST_DIR / "projectMM.nsi"
+    script.write_text(
+        NSI_TEMPLATE
+        .replace("@VERSION@", version)
+        .replace("@OUT@", str(out))
+        .replace("@BINARY@", str(binary))
+        .replace("@ICON@", str(icon))
+        .replace("@README@", str(readme)),
+        encoding="utf-8")
+    try:
+        run([makensis, str(script)])
+    finally:
+        script.unlink(missing_ok=True)
+        readme.unlink(missing_ok=True)
+    print(f"package_desktop: wrote {out}")
+    return out
+
+
 def package_windows(binary: Path, version: str) -> Path:
     DIST_DIR.mkdir(exist_ok=True)
     out = DIST_DIR / f"projectMM-windows-x64-v{version}.zip"
@@ -375,6 +536,7 @@ def package_windows(binary: Path, version: str) -> Path:
     finally:
         readme.unlink(missing_ok=True)
     print(f"package_desktop: wrote {out}")
+    package_windows_installer(binary, version)
     return out
 
 
diff --git a/moondeck/scenario/run_scenario.py b/moondeck/scenario/run_scenario.py
index 27340cdd..a1a083e9 100644
--- a/moondeck/scenario/run_scenario.py
+++ b/moondeck/scenario/run_scenario.py
@@ -18,6 +18,7 @@
 import argparse
 import datetime
 import json
+import os
 import platform
 import re
 import subprocess
@@ -68,7 +69,12 @@ def _resolve_runner() -> Path:
 # rebuilding clears it only until the next firmware build. They are excluded because their mtime
 # carries no information about whether the runner is out of date; a real edit reaches them through
 # their INPUT (src/ui/app.js), which is watched.
-_RUNNER_GENERATED = {"src/ui/ui_embedded.h"}
+# build_info.h belongs here for the same reason and a sharper one: it embeds `git status
+# --porcelain` as a `+` dirty-suffix, so its CONTENT changes the moment the tree goes dirty. A gate
+# run writes scenario baselines and repo-health metrics, which dirties the tree, which flips the
+# suffix, which makes every binary look stale on the NEXT run. A build id is not code, so it cannot
+# make the runner "report on code that is no longer there", which is what this guard is for.
+_RUNNER_GENERATED = {"src/ui/ui_embedded.h", "src/core/build_info.h"}
 
 
 def _stale_runner_reason() -> str:
@@ -170,7 +176,12 @@ def _run_one(path: Path, update_contract: bool, update_reason: str | None) -> in
         print(f"  SKIP  {path.name} (skip_on {target})")
         return 0
     # Capture + tee: stream to stdout while collecting MEASURE lines.
-    proc = subprocess.Popen([str(RUNNER), str(path)], cwd=ROOT,
+    # Pin the runner's filesystem root into the build tree. The runner performs real writes, and
+    # its default root is the OS per-user data directory unless the working directory happens to be
+    # a checkout. Relying on cwd for that would put a test one wrong directory away from
+    # overwriting a developer's own installed-projectMM settings.
+    env = {**os.environ, "MM_DATA_DIR": str(ROOT / "build" / "scenario-fs")}
+    proc = subprocess.Popen([str(RUNNER), str(path)], cwd=ROOT, env=env,
                             stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
                             text=True, bufsize=1)
     observations: dict[str, dict] = {}  # step-name → {tick_us, free_heap, max_alloc_block}
diff --git a/src/core/FilesystemModule.cpp b/src/core/FilesystemModule.cpp
index 9a90a589..3e187369 100644
--- a/src/core/FilesystemModule.cpp
+++ b/src/core/FilesystemModule.cpp
@@ -31,12 +31,21 @@ void FilesystemModule::setScheduler(Scheduler* s) {
 }
 
 void FilesystemModule::setup() {
+    // Both failures below name the directory, because the useful question when settings do not
+    // persist is always "which location did it try". Reported ONCE here rather than as a write
+    // error per save: an unusable root produces one failed save per module per change, and that
+    // stream buries the one fact that explains it.
     if (!platform::fsMount()) {
-        std::printf("FilesystemModule: mount failed — persistence disabled\n");
+        std::printf("FilesystemModule: cannot use %s, persistence disabled\n",
+                    platform::fsRootPath());
+        return;
+    }
+    if (!platform::fsMkdir(CONFIG_DIR)) {
+        std::printf("FilesystemModule: cannot create %s%s, persistence disabled\n",
+                    platform::fsRootPath(), CONFIG_DIR);
         return;
     }
     mounted_ = true;
-    platform::fsMkdir(CONFIG_DIR);
     std::printf("FilesystemModule: mounted, %zu / %zu bytes used\n",
                 platform::filesystemUsed(), platform::filesystemTotal());
 }
@@ -122,8 +131,8 @@ void FilesystemModule::loadAll(Scheduler* s) {
         // setup() hasn't run yet (we're in phase 2, before phase 3 setup). Mount now
         // so we can read; setup() later calls fsMount again (idempotent).
         if (!platform::fsMount()) return;
+        if (!platform::fsMkdir(CONFIG_DIR)) return;   // setup() reports it; stay unmounted
         mounted_ = true;
-        platform::fsMkdir(CONFIG_DIR);
     }
     for (uint8_t i = 0; i < s->moduleCount(); i++) {
         MoonModule* m = s->module(i);
diff --git a/src/platform/desktop/platform_desktop.cpp b/src/platform/desktop/platform_desktop.cpp
index b205d806..4f88dc7c 100644
--- a/src/platform/desktop/platform_desktop.cpp
+++ b/src/platform/desktop/platform_desktop.cpp
@@ -486,13 +486,62 @@ size_t firmwareSize() { return 0; }
 size_t firmwarePartition() { return 0; }
 size_t flashChipSize() { return 0; }
 
-// Filesystem — std::filesystem rooted at fsRoot_ (default "build", overridable via fsSetRoot).
-// A leading '/' in the API path maps to root-relative. Default lives under build/ so the
-// desktop-created .config/ is gitignored (along with the rest of build/) and doesn't clutter
-// the repo root. Tests override this to a tmpdir via fsSetRoot for isolation.
+// Filesystem: std::filesystem rooted at fsRoot_. A leading '/' in the API path maps to
+// root-relative.
+//
+// The root is a PER-USER data directory, not a path relative to wherever the process happened to
+// start. A shipped binary is launched from a download folder, a Start-menu shortcut, or an
+// installer's program directory, and a relative root fails both ways: it lands somewhere
+// unwritable, so every save fails, or it makes the settings belong to that FOLDER rather than to
+// the user, so moving the exe loses them. Both were seen on a Windows bench.
+//
+// Three sources, in order:
+//   1. MM_DATA_DIR, for tests and for anyone who wants the data somewhere specific.
+//   2. "build", when the working directory is a repo checkout. Keeps the dev loop, the gate
+//      scripts, and a developer's existing .config exactly where they already are.
+//   3. The OS's per-user application-data directory.
 
 namespace {
-std::filesystem::path fsRoot_{"build"};
+
+// The OS convention for per-user application data. Empty when the environment names no home, which
+// is a real case in a bare service account; the caller falls back rather than writing to "/".
+std::filesystem::path userDataDir() {
+#ifdef _WIN32
+    // LOCALAPPDATA, not APPDATA: this is machine-local state and has no business roaming.
+    if (const char* base = std::getenv("LOCALAPPDATA"); base && *base)
+        return std::filesystem::path(base) / "projectMM";
+#elif defined(__APPLE__)
+    if (const char* home = std::getenv("HOME"); home && *home)
+        return std::filesystem::path(home) / "Library" / "Application Support" / "projectMM";
+#else
+    if (const char* xdg = std::getenv("XDG_DATA_HOME"); xdg && *xdg)
+        return std::filesystem::path(xdg) / "projectMM";
+    if (const char* home = std::getenv("HOME"); home && *home)
+        return std::filesystem::path(home) / ".local" / "share" / "projectMM";
+#endif
+    return {};
+}
+
+// A checkout is recognized by CMakeLists.txt AND moondeck/ in the working directory. Both, because
+// CMakeLists.txt alone is true in the root of every CMake project there is, and a developer whose
+// shell happens to sit in an unrelated one would get projectMM's settings written into THAT
+// project's build/, which is the per-folder loss this whole change removes.
+//
+// Deliberately the working directory and not the executable's location:
+// `./build/windows/Release/projectMM` run from the repo root is the dev loop this preserves, and an
+// installed copy is never launched that way.
+std::filesystem::path defaultRoot() {
+    if (const char* env = std::getenv("MM_DATA_DIR"); env && *env)
+        return std::filesystem::path(env);
+    std::error_code ec;
+    if (std::filesystem::exists("CMakeLists.txt", ec) && !ec
+        && std::filesystem::is_directory("moondeck", ec) && !ec)
+        return std::filesystem::path("build");
+    std::filesystem::path user = userDataDir();
+    return user.empty() ? std::filesystem::path("build") : user;
+}
+
+std::filesystem::path fsRoot_{defaultRoot()};
 
 // Map "/.config/foo.json" → "<root>/.config/foo.json". Strips leading '/'s, normalizes
 // the result, and rejects paths that escape fsRoot_ (e.g. "../../etc/passwd"). Returns
@@ -513,11 +562,34 @@ std::filesystem::path toFsPath(const char* path) {
 }
 
 void fsSetRoot(const char* path) {
-    fsRoot_ = (path && *path) ? std::filesystem::path(path) : std::filesystem::path("build");
+    fsRoot_ = (path && *path) ? std::filesystem::path(path) : defaultRoot();
+}
+
+const char* fsRootPath() {
+    // Refreshed per call rather than cached at set time, so it cannot go stale after fsSetRoot.
+    // Diagnostics only, and the desktop build reports it from one thread.
+    static std::string cached;
+    cached = fsRoot_.string();
+    return cached.c_str();
 }
 
 bool fsMount() {
-    // No mount needed on desktop; OS handles it.
+    // Desktop has no volume to mount, but it DOES have a root that may not exist yet and may not
+    // be writable. Establishing that here is what turns an unusable location into ONE line at
+    // startup instead of one write failure per save, forever.
+    std::error_code ec;
+    std::filesystem::create_directories(fsRoot_, ec);
+    if (!std::filesystem::is_directory(fsRoot_, ec)) return false;
+    // Existence does not imply writability: a read-only extraction, a protected folder, or a
+    // directory owned by another user all exist happily and reject the first write. create_
+    // directories is silent about all three, so probe with the operation that actually matters.
+    const auto probe = fsRoot_ / ".mm-write-probe";
+    std::error_code rm;
+    std::filesystem::remove(probe, rm);
+    FILE* f = std::fopen(probe.string().c_str(), "wb");
+    if (!f) return false;
+    std::fclose(f);
+    std::filesystem::remove(probe, rm);
     return true;
 }
 
diff --git a/src/platform/esp32/platform_esp32_fs.cpp b/src/platform/esp32/platform_esp32_fs.cpp
index 1be06f1b..24ee907f 100644
--- a/src/platform/esp32/platform_esp32_fs.cpp
+++ b/src/platform/esp32/platform_esp32_fs.cpp
@@ -44,6 +44,8 @@ void fsSetRoot(const char* /*path*/) {
     // prefix is hard-coded. Provided only so test code can call it portably.
 }
 
+const char* fsRootPath() { return FS_MOUNT_POINT; }
+
 bool fsMount() {
     if (fsMounted_) return true;
 
diff --git a/src/platform/platform.h b/src/platform/platform.h
index c1efe50e..78876962 100644
--- a/src/platform/platform.h
+++ b/src/platform/platform.h
@@ -315,11 +315,13 @@ size_t filesystemTotal();     // filesystem total bytes
 // Paths are absolute-looking (start with '/'); desktop strips the leading '/' so
 // "/.config/System.json" maps to "<root>/.config/System.json".
 //
-// fsSetRoot redirects the desktop root from CWD to an absolute path. Used by unit tests
-// to give each TEST_CASE an isolated working directory without chdir. No-op on ESP32
-// (LittleFS is mounted at a fixed partition). Must be called BEFORE fsMount; defaults
-// to ".".
+// fsSetRoot redirects the desktop root to an absolute path. Used by unit tests to give each
+// TEST_CASE an isolated working directory without chdir. No-op on ESP32 (LittleFS is mounted at a
+// fixed partition). Must be called BEFORE fsMount. Passing null or "" restores the default, which
+// on desktop is MM_DATA_DIR, else "build" inside a repo checkout, else the OS per-user data
+// directory (see platform_desktop.cpp).
 void fsSetRoot(const char* path);
+const char* fsRootPath();                                    // the resolved root, for diagnostics
 bool fsMount();                                              // idempotent; safe to call multiple times
 void fsUnmount();
 bool fsMkdir(const char* path);                              // mkdir -p; no error if exists
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index e368a5eb..efd700b0 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -175,6 +175,12 @@ add_dependencies(mm_tests effect_sweep_gen)
 
 add_test(NAME unit_tests COMMAND mm_tests)
 
+# Pin the desktop filesystem root into the build tree. ctest runs from the build directory, which
+# is not a repo checkout, so the default would resolve to the OS per-user data directory and any
+# test touching the default root would write into the developer's real settings.
+set_tests_properties(unit_tests PROPERTIES
+    ENVIRONMENT "MM_DATA_DIR=${CMAKE_CURRENT_BINARY_DIR}/fs-root")
+
 # Scenario runner (replays scenario JSON files in-process)
 add_executable(mm_scenarios scenario_runner.cpp)
 target_link_libraries(mm_scenarios PRIVATE mm_core mm_platform)
diff --git a/test/scenarios/light/scenario_Driver_mutation.json b/test/scenarios/light/scenario_Driver_mutation.json
index 71122031..dfc0faa3 100644
--- a/test/scenarios/light/scenario_Driver_mutation.json
+++ b/test/scenarios/light/scenario_Driver_mutation.json
@@ -280,7 +280,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            43,
+            42,
             87
           ],
           "free_heap": [
@@ -293,7 +293,7 @@
           ],
           "at": [
             "2026-07-08",
-            "2026-08-21"
+            "2026-08-23"
           ]
         },
         "esp32": {
diff --git a/test/scenarios/light/scenario_MoonLive_pipeline.json b/test/scenarios/light/scenario_MoonLive_pipeline.json
index 63cfb490..4b20f699 100644
--- a/test/scenarios/light/scenario_MoonLive_pipeline.json
+++ b/test/scenarios/light/scenario_MoonLive_pipeline.json
@@ -943,7 +943,7 @@
         "desktop-windows": {
           "tick_us": [
             0,
-            11
+            28
           ],
           "free_heap": [
             0,
@@ -955,7 +955,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
diff --git a/test/scenarios/light/scenario_MultiplyModifier_memory_lut.json b/test/scenarios/light/scenario_MultiplyModifier_memory_lut.json
index 1f704479..3f327500 100644
--- a/test/scenarios/light/scenario_MultiplyModifier_memory_lut.json
+++ b/test/scenarios/light/scenario_MultiplyModifier_memory_lut.json
@@ -108,7 +108,7 @@
         "desktop-windows": {
           "tick_us": [
             3,
-            10
+            14
           ],
           "free_heap": [
             0,
@@ -120,7 +120,7 @@
           ],
           "at": [
             "2026-06-07",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
diff --git a/test/scenarios/light/scenario_perf_full.json b/test/scenarios/light/scenario_perf_full.json
index 3c0923ce..ed9cad44 100644
--- a/test/scenarios/light/scenario_perf_full.json
+++ b/test/scenarios/light/scenario_perf_full.json
@@ -265,7 +265,7 @@
         "desktop-windows": {
           "tick_us": [
             3,
-            8
+            10
           ],
           "free_heap": [
             0,
@@ -277,7 +277,7 @@
           ],
           "at": [
             "2026-07-08",
-            "2026-08-21"
+            "2026-08-23"
           ]
         }
       }
@@ -589,7 +589,7 @@
         "desktop-windows": {
           "tick_us": [
             3,
-            10
+            17
           ],
           "free_heap": [
             0,
@@ -601,7 +601,7 @@
           ],
           "at": [
             "2026-07-08",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
@@ -979,7 +979,7 @@
         "desktop-windows": {
           "tick_us": [
             3,
-            12
+            15
           ],
           "free_heap": [
             0,
@@ -991,7 +991,7 @@
           ],
           "at": [
             "2026-07-08",
-            "2026-07-08"
+            "2026-08-23"
           ]
         }
       }
@@ -1439,7 +1439,7 @@
         "desktop-windows": {
           "tick_us": [
             196,
-            620
+            643
           ],
           "free_heap": [
             0,
diff --git a/test/scenarios/light/scenario_perf_light.json b/test/scenarios/light/scenario_perf_light.json
index f84c5d03..0478e943 100644
--- a/test/scenarios/light/scenario_perf_light.json
+++ b/test/scenarios/light/scenario_perf_light.json
@@ -280,7 +280,7 @@
         "desktop-windows": {
           "tick_us": [
             1,
-            4
+            5
           ],
           "free_heap": [
             0,
@@ -292,7 +292,7 @@
           ],
           "at": [
             "2026-07-08",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
diff --git a/test/scenarios/light/scenario_peripheral_grid_sweep.json b/test/scenarios/light/scenario_peripheral_grid_sweep.json
index d867b632..a9013f76 100644
--- a/test/scenarios/light/scenario_peripheral_grid_sweep.json
+++ b/test/scenarios/light/scenario_peripheral_grid_sweep.json
@@ -365,7 +365,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            161,
+            160,
             220
           ],
           "free_heap": [
@@ -378,7 +378,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
@@ -461,7 +461,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            658,
+            649,
             1143
           ],
           "free_heap": [
@@ -474,7 +474,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
@@ -579,7 +579,7 @@
         "desktop-windows": {
           "tick_us": [
             9,
-            21
+            71
           ],
           "free_heap": [
             0,
@@ -591,7 +591,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
@@ -770,7 +770,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            156,
+            152,
             282
           ],
           "free_heap": [
@@ -1271,7 +1271,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            648,
+            641,
             1339
           ],
           "free_heap": [
@@ -1284,7 +1284,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
@@ -1484,7 +1484,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            39,
+            37,
             105
           ],
           "free_heap": [
@@ -1497,7 +1497,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
@@ -1580,7 +1580,7 @@
         },
         "desktop-windows": {
           "tick_us": [
-            161,
+            159,
             344
           ],
           "free_heap": [
@@ -1593,7 +1593,7 @@
           ],
           "at": [
             "2026-08-21",
-            "2026-08-22"
+            "2026-08-23"
           ]
         }
       }
diff --git a/test/unit/core/unit_FileManagerModule.cpp b/test/unit/core/unit_FileManagerModule.cpp
index 98582904..4420e802 100644
--- a/test/unit/core/unit_FileManagerModule.cpp
+++ b/test/unit/core/unit_FileManagerModule.cpp
@@ -51,7 +51,8 @@ struct Rig {
         fm.defineControls();
         fm.setup();
     }
-    // Restore the DEFAULT root (fsSetRoot("") → "build"), not ".", so a later test in the same
+    // Restore the DEFAULT root (whatever platform.h's fsSetRoot contract resolves "" to; under
+    // ctest that is the pinned MM_DATA_DIR), not ".", so a later test in the same
     // binary starts from the same baseline this Rig assumed, never a leaked "." repo-root.
     // Teardown must never propagate: this Rig is destroyed while the stack unwinds from a failed
     // CHECK, and a throw there terminates the process, losing the very failure being reported.
diff --git a/test/unit/core/unit_FilesystemModule_persistence.cpp b/test/unit/core/unit_FilesystemModule_persistence.cpp
index 28d7997c..890ff6db 100644
--- a/test/unit/core/unit_FilesystemModule_persistence.cpp
+++ b/test/unit/core/unit_FilesystemModule_persistence.cpp
@@ -21,6 +21,106 @@
 #include <string>
 #include <fstream>
 
+// The settings directory is created when the filesystem mounts, not left for the first save to
+// discover. A shipped binary starts in a directory that has never held one, and before this the
+// first WRITE was what failed, then every write after it, once per save, forever.
+TEST_CASE("A settings directory that does not exist yet is created when the filesystem mounts") {
+    char root[256];
+    std::snprintf(root, sizeof(root), "/tmp/mm_root_new_%u",
+                  static_cast<unsigned>(mm::platform::millis()));
+    std::filesystem::remove_all(root);
+    REQUIRE_FALSE(std::filesystem::exists(root));
+
+    mm::platform::fsSetRoot(root);
+    CHECK(mm::platform::fsMount());
+    CHECK(std::filesystem::is_directory(root));
+    // Reported back, so a failure can name the directory it actually tried.
+    CHECK(std::string(mm::platform::fsRootPath()) == root);
+
+    mm::platform::fsSetRoot("");
+    std::filesystem::remove_all(root);
+}
+
+// A root that exists and is a directory can still reject writes, which is the case the probe
+// exists for and the one a read-only extraction produces. A DIRECTORY where the probe file belongs
+// blocks its creation while leaving the root itself perfectly valid, so this reaches the probe
+// instead of failing earlier at the is_directory check the case above covers.
+TEST_CASE("A settings directory that rejects a write fails the mount, not just a missing one") {
+    char root[256];
+    std::snprintf(root, sizeof(root), "/tmp/mm_root_probe_%u",
+                  static_cast<unsigned>(mm::platform::millis()));
+    std::filesystem::remove_all(root);
+    std::error_code ec;
+    const auto blocker = std::filesystem::path(root) / ".mm-write-probe";
+    std::filesystem::create_directories(blocker, ec);
+    // Non-empty, so the pre-remove cannot clear it out of the way either.
+    { std::ofstream f(blocker / "occupied.txt"); f << "x"; }
+    REQUIRE(std::filesystem::is_directory(root));
+    REQUIRE(std::filesystem::is_directory(blocker));
+
+    mm::platform::fsSetRoot(root);
+    CHECK_FALSE(mm::platform::fsMount());
+
+    mm::platform::fsSetRoot("");
+    std::filesystem::remove_all(root);
+}
+
+// MM_DATA_DIR wins over every other rule. This is the contract the test suite itself relies on:
+// ctest sets it so a test can never write into the developer's real settings directory.
+TEST_CASE("MM_DATA_DIR chooses the settings directory over any other rule") {
+    const char* prior = std::getenv("MM_DATA_DIR");
+    const std::string saved = prior ? prior : "";
+
+    char want[256];
+    std::snprintf(want, sizeof(want), "/tmp/mm_root_env_%u",
+                  static_cast<unsigned>(mm::platform::millis()));
+#ifdef _WIN32
+    _putenv_s("MM_DATA_DIR", want);
+#else
+    setenv("MM_DATA_DIR", want, 1);
+#endif
+    // Empty restores the DEFAULT, which is where the resolution rule is applied.
+    mm::platform::fsSetRoot("");
+    CHECK(std::string(mm::platform::fsRootPath()) == want);
+
+    // Restore what ctest pinned. Leaving this set would hand every later case a root of its own
+    // choosing, quietly undoing the isolation this very case exists to prove.
+#ifdef _WIN32
+    _putenv_s("MM_DATA_DIR", saved.c_str());
+#else
+    if (saved.empty()) unsetenv("MM_DATA_DIR");
+    else                setenv("MM_DATA_DIR", saved.c_str(), 1);
+#endif
+    mm::platform::fsSetRoot("");
+    // Not an equality check against `saved`: with the variable unset the root correctly falls
+    // through to the next rule, so the thing worth asserting is that the override is gone.
+    CHECK(std::string(mm::platform::fsRootPath()) != want);
+    std::filesystem::remove_all(want);
+}
+
+// An unusable location is refused at mount, which is what lets the caller say "persistence
+// disabled" once instead of emitting a failed save per module per change. A plain file where the
+// directory belongs stands in for the real cases (a read-only extraction, a protected folder, a
+// directory owned by someone else): every one of them accepts the path and rejects the writes.
+TEST_CASE("A settings location that cannot be written to fails the mount, not every later save") {
+    char root[256];
+    std::snprintf(root, sizeof(root), "/tmp/mm_root_blocked_%u",
+                  static_cast<unsigned>(mm::platform::millis()));
+    std::filesystem::remove_all(root);
+    // ofstream does not create parents, and on Windows "/tmp" is <drive>:\tmp, which need not
+    // exist. Without this the case depends on another test having created it first.
+    std::error_code ec;
+    std::filesystem::create_directories(std::filesystem::path(root).parent_path(), ec);
+    { std::ofstream f(root); f << "a file, not a directory"; }
+    REQUIRE(std::filesystem::is_regular_file(root));
+
+    mm::platform::fsSetRoot(root);
+    CHECK_FALSE(mm::platform::fsMount());
+
+    mm::platform::fsSetRoot("");
+    std::filesystem::remove_all(root);
+}
+
 // Persistence round-trip: set deviceName → save → recreate Scheduler+modules → load → assert.
 // Uses fsSetRoot to isolate the test from any real /.config/ on disk.
 // A control change (deviceName) saved with flush() reappears on the next boot once a fresh Scheduler loads the same path.