ESP-046: per-output LED dispatcher foundation (inc 1) [WIP]

.github/workflows/release-pages.yml

@@ -0,0 +1,108 @@
+# GitHub Pages web flasher — build every board variant on a tag and publish a page that
+# flashes them straight from Chrome/Edge over WebSerial. Design:
+# docs/plans/2026-07-10-github-pages-web-flasher-design.md
+#
+# Why this exists at all: a partition table can ONLY be written over USB. It cannot be
+# changed over OTA. So this is not merely a convenience over `arduino-cli` -- it is the
+# only delivery path that can fix a device's partition layout, or recover one that will
+# not boot. That is also why it must exist before hardware reaches a customer.
+#
+# Tag-triggered ONLY, deliberately: it can never fail or block the required checks on the
+# protected master branch.
+name: Release — web flasher (GitHub Pages)
+
+on:
+  push:
+    tags: ['v*']
+  workflow_dispatch:   # let a release be re-published without re-tagging
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: pages
+  cancel-in-progress: false
+
+jobs:
+  build:
+    name: Build firmware + assemble site
+    runs-on: ubuntu-latest
+    env:
+      # X32Link's 4 variants: same FQBN, differing only by build_opt.h -- exactly as
+      # ci.yml already compiles them. min_spiffs so every flashed image lands on an
+      # OTA-capable table and can use /update afterwards without a second USB trip.
+      X32_FQBN: esp32:esp32:esp32s3:USBMode=hwcdc,CDCOnBoot=cdc,FlashSize=16M,PSRAM=opi,PartitionScheme=min_spiffs
+      # KitchenSync Touch ships its own partitions.csv (16MB, dual-OTA, 4MB app slots).
+      # PartitionScheme=custom is what makes the core USE that file -- without it the core
+      # silently falls back to its 4MB default table and the app slot is 1.25MB.
+      TOUCH_FQBN: esp32:esp32:esp32s3:USBMode=hwcdc,CDCOnBoot=cdc,FlashSize=16M,PSRAM=opi,PartitionScheme=custom
+      CORE_CACHE: ${{ github.workspace }}/.arduino-core-cache
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Cache arduino-cli data (ESP32 core + libraries)
+        uses: actions/cache@v4
+        with:
+          path: |
+            ~/.arduino15
+            ~/Arduino
+          key: arduino-esp32-${{ runner.os }}-x32link-v1
+          restore-keys: |
+            arduino-esp32-${{ runner.os }}-
+
+      - name: Cache arduino compiled core
+        uses: actions/cache@v4
+        with:
+          path: ${{ env.CORE_CACHE }}
+          key: arduino-core-${{ runner.os }}-x32link-v1
+          restore-keys: |
+            arduino-core-${{ runner.os }}-
+
+      - name: Install arduino-cli
+        run: curl -fsSL https://raw.githubusercontent.com/arduino/arduino-cli/master/install.sh | sh -s
+
+      - name: Add arduino-cli to PATH
+        run: echo "$GITHUB_WORKSPACE/bin" >> "$GITHUB_PATH"
+
+      - name: Install ESP32 core + LovyanGFX
+        run: |
+          arduino-cli config init --overwrite --additional-urls https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
+          arduino-cli core update-index
+          arduino-cli core install esp32:esp32
+          arduino-cli lib install LovyanGFX
+
+      # The version a release publishes is the TAG. One source of truth -- no second
+      # place to forget to bump.
+      - name: Resolve version
+        id: ver
+        run: echo "version=${GITHUB_REF_NAME#v}" >> "$GITHUB_OUTPUT"
+
+      - name: Build every variant
+        env:
+          VERSION: ${{ steps.ver.outputs.version }}
+        run: |
+          set -euo pipefail
+          bash tools/build-flasher-site.sh
+
+      # Catch a broken release BEFORE it is published, not after someone's device is
+      # halfway through a flash.
+      - name: Validate manifests
+        run: python3 tools/validate_manifests.py site/firmware
+
+      - uses: actions/configure-pages@v5
+      - uses: actions/upload-pages-artifact@v3
+        with:
+          path: site
+
+  deploy:
+    name: Deploy to GitHub Pages
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - id: deployment
+        uses: actions/deploy-pages@v4

.gitignore

@@ -1,9 +1,28 @@
 # Arduino build output
 **/build/
 
-# Host unit-test binaries
-test/test_app_config
-test/test_bpm_tracker
-test/test_link_protocol
-test/test_osc_out
-test/test_midi_bpm_calc
+# Host unit-test binaries (test/test_foo executables; keep test_foo.c sources)
+test/test_*
+!test/test_*.c
+test/*.dSYM/
+
+# macOS / editor cruft
+.DS_Store
+
+# LoraLink WiFi credentials (copy lora_secrets.h.example -> lora_secrets.h)
+LoraLink/lora_secrets.h
+
+# ESP-IDF (KitchenSync)
+sdkconfig
+sdkconfig.old
+managed_components/
+dependencies.lock
+.worktrees/
+.gstack/
+tests/test_x32_port
+*.dSYM/
+KitchenSyncTouch/secrets.h
+
+# Web-flasher site: built by tools/build-flasher-site.sh, published by the release
+# workflow. Firmware binaries are release artifacts, never repo contents.
+site/

.ordna/config.yaml

@@ -1,5 +1,5 @@
-# Task prefixes in use: ESP (emulator), LNK (X32Link), MCK (MidiClock), TSV (ToastSaver-HW),
-#                       FDR (X32FaderDisp), MUT (X32SafeMutes), ITT (MidiOscIttt)
+# Task prefixes in use: LNK (X32Link), MCK (MidiClock, legacy), ESP (emulator),
+#                       ARC (firmware architecture), P4 (ESP32-P4 hub tier)
 tasksDir: tasks
 idPrefix: ESP
 zeroPaddedIds: 3

.out-of-scope/behringer-wing-support.md

@@ -0,0 +1,42 @@
+# Behringer Wing Support
+
+This project does not target the Behringer Wing as a mixer for tempo/FX
+control. Supported mixer targets are the X32 family (X32, XR18/X-Air).
+
+## Why this is out of scope
+
+The Wing is not an X32-family device. It speaks its own control protocol — an
+OSC-style layer plus a text/`$`-style node command channel — with a different
+address tree, a name-addressed node/param model instead of numeric
+`/fx/N/par/MM` indices, and different value encodings. None of the X32-dialect
+OSC layer (`osc_out`/`osc_in`, the model table mapping `MODEL_X32`/`MODEL_XR18`
+to ports 10023/10024 and slot counts) carries over; Wing support means either
+parameterizing that layer or writing a second dialect module behind the
+tempo-source→OSC seam.
+
+Two durable reasons to decline rather than defer:
+
+1. **The project's scope is gear on the bench.** Every mixer feature shipped so
+   far was validated against a real XR18 with live OSC dumps. Nobody involved
+   owns a Wing, so the core research deliverables — real protocol dumps, FX
+   topology confirmation, tempo-param encodings — cannot be produced, only
+   transcribed from third-party docs and shipped unverified. That conflicts
+   with the project's measure-before-building discipline.
+2. **A second protocol stack is a real architectural cost.** Carrying a Wing
+   dialect module means a second address model, second introspection path, and
+   second unit-conversion table to keep correct, for hardware no user of this
+   project has asked about since filing.
+
+## What would change this
+
+A Wing on the bench (or a collaborator supplying real control-channel dumps).
+If that happens: delete this file and re-file the research ticket. The X32/XR18
+FX research (LNK-029) is deliberately structured as the reusable template —
+introspect FX type → map tempo param + encoding → fan out to N targets with
+per-target note division — so the Wing track would re-answer those questions
+rather than start from scratch.
+
+## Prior requests
+
+- LNK-030 — "Research: Behringer Wing support (different OSC protocol) for
+  tempo/FX control" (filed 2026-07-04, declined in triage 2026-07-11)