MoonCloud: opt-in usage stats and a public message board

CLAUDE.md

@@ -98,7 +98,9 @@ product owner triggers it; say in one line what was picked and why.
 
 Docs land with the code, not at merge time: the module's spec and catalog card describe what actually shipped ([coding-standards § Documentation model](docs/coding-standards.md#documentation-model)); a breaking change gets its entry in [docs/MIGRATING.md](docs/MIGRATING.md); a shipped backlog item or spec draft is deleted. The merge gate only verifies this happened.
 
-**How the writing looks: American spelling, no em-dashes.** `color`, `serialize`, `behavior`, `analyze`; a comma, colon or full stop where an em-dash wants to go. In comments, docs, commit messages and chat replies alike. Both rules are enforced mechanically by `check_prose.py` (a write-time hook, and again at the commit gate), because they are exactly the kind of habit that stays invisible to its own author. Full rationale: [coding-standards § Writing](docs/coding-standards.md).
+**How the writing looks: American spelling, no em-dashes.** `color`, `serialize`, `behavior`, `analyze`; a comma, colon or full stop where an em-dash wants to go. In comments, docs, commit messages and chat replies alike. Both rules are enforced mechanically by `check_prose.py` (a write-time hook, and again at the commit gate), because they are exactly the kind of habit that stays invisible to its own author.
+
+**And how much of it there is: minimal, dense, straight to the point.** A comment or a doc paragraph says what the code cannot (the reason, the constraint, the failure it prevents) in the fewest words that carry it. Restating the code is noise; so is a paragraph where a clause would do. Nothing is stripped wholesale, and a reason still true is shortened rather than dropped: **condense, don't delete**. No check catches this one, so it is judgment, applied when writing and again when reviewing. Full rationale: [coding-standards § Conventions](docs/coding-standards.md#conventions).
 
 ### Commit
 

CMakeLists.txt

@@ -128,6 +128,7 @@ add_library(mm_core STATIC
     src/core/FilesystemModule.cpp
     src/core/FileManagerModule.cpp
     src/core/MqttModule.cpp
+    src/core/sha256.cpp
     src/core/Scheduler.cpp
     src/core/moonlive/MoonLive.cpp
     src/core/moonlive/MoonLiveCompiler.cpp
@@ -175,6 +176,31 @@ target_link_libraries(mm_platform PUBLIC $<$<PLATFORM_ID:Windows>:ws2_32> $<$<PL
 # link line until the symbols resolve. Apple's linker and MSVC search archives repeatedly and
 # never noticed; GNU ld makes ONE left-to-right pass, so the reference from mm_platform back into
 # mm_core is unresolved unless the cycle is declared.
+# libcurl for the one outbound HTTPS call (MoonCloud Stats). The OS's own TLS rather than a
+# vendored stack: present on macOS and every Linux distribution, and carrying its own certificate
+# verification, so nothing about TLS lives in this repository.
+#
+# OPTIONAL on purpose. A machine without it still builds and MM_HAVE_CURL stays undefined, in which
+# case httpsPost returns false and a report is simply not sent: a build must never fail over an
+# opt-in statistic. The build prints which way it went, since "why did my device never report"
+# would otherwise be invisible.
+find_package(CURL QUIET)
+if(CURL_FOUND)
+    message(STATUS "libcurl ${CURL_VERSION_STRING}: MoonCloud reporting enabled")
+    target_compile_definitions(mm_platform PRIVATE MM_HAVE_CURL)
+    target_link_libraries(mm_platform PUBLIC CURL::libcurl)
+elseif(DEFINED ENV{MM_RELEASE})
+    # A RELEASE build is the one case where absent is not acceptable: the binary would ask for
+    # consent and then be structurally unable to honor it, and nobody would find out. Optional
+    # stays optional for a contributor's machine; a published artifact must be able to report.
+    message(FATAL_ERROR
+        "libcurl not found, and MM_RELEASE is set. A released build with reporting compiled out "
+        "asks for consent it can never honor. Install libcurl (Windows: vcpkg install curl) or "
+        "unset MM_RELEASE for a local build.")
+else()
+    message(STATUS "libcurl not found: MoonCloud reporting disabled (install libcurl to enable)")
+endif()
+
 target_link_libraries(mm_platform PUBLIC mm_core)
 set_target_properties(mm_core     PROPERTIES LINK_INTERFACE_MULTIPLICITY 3)
 set_target_properties(mm_platform PROPERTIES LINK_INTERFACE_MULTIPLICITY 3)
@@ -247,7 +273,7 @@ if(WIN32)
     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.
+        # Pillow inline (PEP 723), and only the script form makes uv honor that declaration.
         COMMAND ${UV_EXECUTABLE} run "${CMAKE_SOURCE_DIR}/moondeck/ci/make_ico.py"
                 "${CMAKE_SOURCE_DIR}/mooninstaller/favicon.png" "${MM_ICON}"
         DEPENDS "${CMAKE_SOURCE_DIR}/mooninstaller/favicon.png"

docs/backlog/backlog-core.md

@@ -1791,3 +1791,23 @@ The fix has to keep the value readable by another image (that is why it is persi
 making the compile-time constant win: re-assert `kFirmwareName` after the config load rather than
 only at `defineControls()`, and pin it with a test that loads a config naming a DIFFERENT variant
 and checks the control still reads the compiled one.
+
+## MoonCloud: share a MoonLive script over MoonTalk (2026-09-10)
+
+Sketched 2026-09-10 while Talk was built. **The unique feature nobody else has**: projectMM ships a scripting language whose programs are about a kilobyte of text, and a message board between devices. Together they mean a script someone wrote on their wall is one tap from running on yours.
+
+**What makes it plausible.** The scripts are tiny: the shipped `.mle` files run 780 to 1907 bytes and the whole library of twenty-odd is 36 KB. A script is self-contained by design, so the text is the artifact. And the device already compiles and runs arbitrary script text safely, which is the hard half and is done.
+
+**The design work is that a script is five to seven times a message.** Talk caps a message at 280 characters, deliberately: a chat message is a sentence, and one caller must not fill the table. Three options:
+
+- **A second endpoint** (`/api/script`) with its own size cap and table, and a message that references it by id. The chat table stays a chat table, a script is fetched when someone wants it, and a board read stays small. Most work, cleanest shape, and the recommendation.
+- **An attachment column on the message**, capped separately. One table and one post, at the cost of every board read carrying script text unless the query is careful.
+- **Share a URL.** A script already lives in the user's File Manager and a device could serve it over the LAN. Free, and limited to one network, which is the case that makes the feature interesting.
+
+**A shared script is code from a stranger**, in a way chat text is not. Three questions the design answers rather than discovers:
+
+1. **Loading is explicit and reversible.** A script arrives as something to look at, and taking it leaves what the user already has intact. `/moonlive` (user) shadowing `/.moonlive` (factory) is the existing trap.
+2. **The device is the sandbox.** MoonLive reaches no filesystem and no network, so the blast radius of a hostile script is the LEDs and the render budget. Worth confirming rather than assuming: a script that never yields is a watchdog reset, which is a denial of service on someone's wall.
+3. **Attribution and removal.** Any sender id can be claimed, and a message stays once posted. Fine for chat, weaker for code.
+
+Depends on Talk shipping and on the server being deployed.

docs/coding-standards.md

@@ -18,7 +18,7 @@ Decided once; not re-derived per file.
 - **American English spelling, everywhere.** Code identifiers, JSON/wire keys, comments, docs, and UI strings all use US spelling: `color` (not the British form), `serialize`, `optimize`, `initialize`, `normalize`, `behavior`, `center`, `gray`, `canceled`, `analyze`. Two reasons: (1) it's the dominant technical-project convention (LLVM, Chromium, the Linux kernel are American throughout), and (2) the graphics/LED ecosystem we interop with is uniformly American (`CRGB`, `color`, `colorFromPalette`, CSS `color`), so a British identifier fights the whole toolchain. The real hazard mixing creates: a grep for one dialect silently misses the other, and a wire key that drifts between dialects breaks a cross-device contract without a compile error. So one dialect, chosen to match the ecosystem. Watch-outs: `analysis` is already US (keep it; only `analyse`→`analyze`); a proper noun keeps its own spelling (`Travelrouter`, a product name). Existing British spellings in older prose get converted **opportunistically when a file is touched**, not in one big sweep (same as the em-dash rule above); a code identifier or wire key in the wrong dialect is the higher-priority fix, since it's a correctness hazard, not just style.
 - **All Python through `uv run`.** Never bare `python`/`python3`: not in shell commands, not in CMake, not in docs. uv manages the project venv and is the project standard ([moondeck/MoonDeck.md](../moondeck/MoonDeck.md)); bare `python3` isn't on PATH on Windows, and the macOS Python launcher pops a Store prompt. In CMake, resolve `find_program(UV_EXECUTABLE NAMES uv REQUIRED HINTS "$ENV{USERPROFILE}/.local/bin" "$ENV{HOME}/.local/bin")` once and use `${UV_EXECUTABLE} run python …` thereafter; the shared `src/ui/embed_ui.cmake` takes a `PYTHON_CMD` parameter (desktop passes uv; ESP32 passes IDF's Python). The one exception is `esp32/main/CMakeLists.txt`: ESP-IDF builds use IDF's own bundled Python venv via `find_package(Python3)`, since IDF manages that environment itself.
 - **Consider extending before creating.** When adding a feature, check whether an existing module extends cleanly; a new file is fine if genuinely cleaner, but justify it.
-- **Do not remove comments** unless they are outdated or factually wrong. Comments document intent and context; removing them silently loses knowledge.
+- **Comments are minimal, dense, and about WHY.** A comment earns its place by saying something the code cannot: the reason for a choice, the constraint behind it, the failure it prevents. Restating what the line already says is noise, and so is a paragraph where a clause would do. Write the shortest version that still carries the reason. **Removing a comment needs the same justification as removing code**: it is outdated, factually wrong, or it only restated the code. Never strip comments wholesale to hit a length target, and never delete a reason you cannot reconstruct: if the *why* is still true, keep it and shorten it. **Condense, don't delete.**
 - **Reference, don't copy.** Prior art (friend repos, datasheets, our own prototype branches) holds proven approaches: study it, take the ideas, write our own code, never copy or trace the structure. Credits live in the [friend-repo digests](friend-repos/README.md) and per-module prior-art sections.
 - **Minimal comments in MoonLive scripts, in exactly three places.** A `.mle`/`.mll`/`.mlm`/`.mls`/`.mlp` is a user-facing artifact shown in an editor on the device's own card, not a C++ source file: the reader is looking at the effect, and a comment block longer than the code buries it. So the budget is fixed, and it is one line each: