Revise copilot-instructions.md: consolidate, shorten, and extract language-specific rules, take 2

.coderabbit.yaml

@@ -0,0 +1,68 @@
+# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
+#
+# CodeRabbit configuration — references existing guideline files to avoid
+# duplicating conventions.  See:
+#   .github/copilot-instructions.md   — project overview & general rules
+#   .github/cpp.instructions.md       — C++ coding conventions
+#   .github/web.instructions.md       — Web UI coding conventions
+#   .github/cicd.instructions.md      — GitHub Actions / CI-CD conventions
+#   .github/esp-idf.instructions.md   — ESP-IDF / chip-specific coding guidelines
+#                                       (apply when code directly uses ESP-IDF APIs:
+#                                        esp_idf_*, I2S, RMT, ADC, GPIO, heap_caps, etc.)
+#
+# NOTE: This file must be committed (tracked by git) for CodeRabbit to read
+# it from the repository.  If it is listed in .gitignore, CodeRabbit will
+# not see it and these settings will have no effect.
+
+language: en-US
+
+reviews:
+  path_instructions:
+    - path: "**/*.{cpp,h,hpp,ino}"
+      instructions: >
+        Follow the C++ coding conventions documented in .github/cpp.instructions.md
+        and the general project guidelines in .github/copilot-instructions.md.
+        If the code under review directly uses ESP-IDF APIs (e.g. heap_caps_malloc,
+        I2S, RMT, ADC, GPIO, esp_timer, or any esp_idf_* / soc_* symbols), also
+        apply the guidelines in .github/esp-idf.instructions.md.
+
+        Key rules: 2-space indentation (no tabs), camelCase functions/variables,
+        PascalCase classes, UPPER_CASE macros. Mark WLED-MM-specific changes with
+        `// WLEDMM` comments. No C++ exceptions — use return codes and debug macros.
+
+        Hot-path optimization guidelines (attributes, uint_fast types, caching,
+        unsigned range checks) apply from pixel set/get operations downward —
+        NOT to effect functions in FX.cpp, which have diverse contributor styles.
+
+    - path: "wled00/data/**"
+      instructions: >
+        Follow the web UI conventions documented in .github/web.instructions.md.
+
+        Key rules: indent HTML and JavaScript with tabs, CSS with tabs or spaces.
+        Files here are built into wled00/html_*.h by tools/cdata.js — never
+        edit those generated headers directly.
+
+    - path: "wled00/html_*.h"
+      instructions: >
+        These files are auto-generated from wled00/data/ by tools/cdata.js.
+        They must never be manually edited or committed. Flag any PR that
+        includes changes to these files.
+
+    - path: "usermods/**"
+      instructions: >
+        Usermods are community add-ons following the upstream WLED 0.15.x style.
+        Each usermod lives in its own directory under usermods/ and is implemented
+        as a .h file that is pulled in by wled00/usermods_list.cpp (guarded by
+        #ifdef). Usermods do not use library.json. Follow the same C++ conventions
+        as the core firmware (.github/cpp.instructions.md).
+
+    - path: ".github/workflows/*.{yml,yaml}"
+      instructions: >
+        Follow the CI/CD conventions documented in .github/cicd.instructions.md.
+
+        Key rules: 2-space indentation, descriptive name: on every workflow/job/step.
+        Third-party actions must be pinned to a specific version tag — branch pins
+        such as @main or @master are not allowed. Declare explicit permissions: blocks
+        scoped to least privilege. Never interpolate github.event.* values directly
+        into run: steps — pass them through an env: variable to prevent script
+        injection. Do not use pull_request_target unless fully justified.

.github/agent-build-instructions.md

@@ -0,0 +1,109 @@
+# Agent-Mode Build & Test Instructions
+
+Detailed build workflow, timeouts, and troubleshooting for making code changes in agent mode. Always reference these instructions first when running builds or validating changes.
+
+## Build Timing and Timeouts
+
+Use these timeout values when running builds:
+
+| Command | Typical Time | Minimum Timeout | Notes |
+|---|---|---|---|
+| `npm run build` | ~3 s | 30 s | Web UI → `wled00/html_*.h` headers |
+| `npm test` | ~40 s | 2 min | Validates build system |
+| `npm run dev` | continuous | — | Watch mode, auto-rebuilds on changes |
+| `pio run -e <env>` | 15–20 min | 30 min | First build downloads toolchains; subsequent builds are faster |
+
+**NEVER cancel long-running builds.** PlatformIO downloads and compilation require patience.
+
+## Development Workflow
+
+### Web UI Changes
+
+1. Edit files in `wled00/data/`
+2. Run `npm run build` to regenerate `wled00/html_*.h` headers
+3. Test with local HTTP server (see Manual Testing below)
+4. Run `npm test` to validate
+
+### Firmware Changes
+
+1. Edit files in `wled00/` (but **never** `html_*.h` files)
+2. Ensure web UI is built first: `npm run build`
+3. Build firmware: `pio run -e esp32_4MB_V4_M` (set timeout ≥ 30 min)
+4. Flash to device: `pio run -e [target] --target upload`
+
+### Combined Web + Firmware Changes
+
+1. Always build web UI first
+2. Test web interface manually
+3. Then build and test firmware
+
+
+## Before Finishing Work
+
+**You MUST complete ALL of these before marking work as done:**
+
+1. **Run tests**: `npm test` — must pass
+2. **Build firmware**: `pio run -e esp32_4MB_V4_M` — must succeed
+   - Set timeout to 30+ minutes, **never cancel**
+   - Choose `esp32_4MB_V4_M` as a common, representative environment
+   - If the build fails, fix the issue before proceeding
+3. **For web UI changes**: manually test the interface (see below)
+
+If any step fails, fix the issue. **Do NOT mark work complete with failing builds or tests.**
+
+## Manual Web UI Testing
+
+Start a local server:
+
+```sh
+cd wled00/data && python3 -m http.server 8080
+# Open http://localhost:8080/index.htm
+```
+
+Test these scenarios after every web UI change:
+
+- **Load**: `index.htm` loads without JavaScript errors (check browser console)
+- **Navigation**: switching between main page and settings pages works
+- **Color controls**: color picker and brightness controls function correctly
+- **Effects**: effect selection and parameter changes work
+- **Settings**: form submission and validation work
+
+## Troubleshooting
+
+### Common Build Issues
+
+| Problem | Solution |
+|---|---|
+| Missing `html_*.h` | Run `npm ci; npm run build` |
+| Web UI looks broken | Check browser console for JS errors |
+| PlatformIO network errors | Retry — downloads can be flaky |
+| Node.js version mismatch | Ensure Node.js 20+ (check `.nvmrc`) |
+
+### Recovery Steps
+
+- **Force web UI rebuild**: `npm run build -- -f`
+- **Clear generated files**: `rm -f wled00/html_*.h` then `npm run build`
+- **Clean PlatformIO cache**: `pio run --target clean`
+- **Reinstall Node deps**: `rm -rf node_modules && npm ci`
+
+## CI/CD Validation
+
+The GitHub Actions CI workflow will:
+1. Install Node.js and Python dependencies
+2. Run `npm test`
+3. Build web UI (automatic via PlatformIO)
+4. Compile firmware for **all** `default_envs` targets
+
+**To ensure CI success, always validate locally:**
+- Run `npm test` and ensure it passes
+- Run `pio run -e esp32_4MB_V4_M` (or another common firmware environment, see next section) and ensure it completes successfully
+- If either fails locally, it WILL fail in CI
+
+Match this workflow in local development to catch failures before pushing.
+
+## Important Reminders
+
+- **Never edit or commit** `wled00/html_*.h` — auto-generated from `wled00/data/`
+- Web UI rebuild is part of the PlatformIO firmware compilation pipeline
+- Common firmware environments: `esp32_4MB_V4_M`, `esp32_16MB_V4_S_HUB75`, `esp32S3_8MB_PSRAM_M_qspi`, `esp32_16MB_V4_M_eth`, `esp8266_4MB_S` (deprecated), `esp32dev_compat`
+- List all PlatformIO targets: `pio run --list-targets`

.github/cicd.instructions.md

@@ -0,0 +1,153 @@
+---
+applyTo: ".github/workflows/*.yml,.github/workflows/*.yaml"
+---
+# CI/CD Conventions — GitHub Actions Workflows
+
+## YAML Style
+
+- Indent with **2 spaces** (no tabs)
+- Every workflow, job, and step must have a `name:` field that clearly describes its purpose
+- Group related steps logically; separate unrelated groups with a blank line
+- Comments (`#`) are encouraged for non-obvious decisions (e.g., why `fail-fast: false` is set, what a cron expression means)
+
+## Workflow Structure
+
+### Triggers
+
+- Declare `on:` triggers explicitly; avoid bare `on: push` without branch filters on long-running or expensive jobs
+- Prefer `workflow_call` for shared build logic (see `build.yml`) to avoid duplicating steps across workflows
+- Document scheduled triggers (`cron:`) with a human-readable comment:
+
+```yaml
+schedule:
+  - cron: '0 2 * * *'  # run at 2 AM UTC daily
+```
+
+### Jobs
+
+- Express all inter-job dependencies with `needs:` — never rely on implicit ordering
+- Use job `outputs:` + step `id:` to pass structured data between jobs (see `get_default_envs` in `build.yml`)
+- Set `fail-fast: false` on matrix builds so that a single failing environment does not cancel others
+
+### Runners
+
+- Pin to a specific Ubuntu version (`ubuntu-22.04`, `ubuntu-24.04`) rather than `ubuntu-latest` for reproducible builds
+- Only use `ubuntu-latest` in jobs where exact environment reproducibility is not required (e.g., trivial download/publish steps)
+
+### Tool and Language Versions
+
+- Pin tool versions explicitly:
+  ```yaml
+  python-version: '3.12'
+  ```
+- Do not rely on the runner's pre-installed tool versions — always install via a versioned setup action
+
+### Caching
+
+- Always cache package managers and build tool directories when the job installs dependencies:
+  ```yaml
+  - uses: actions/cache@v4
+    with:
+      path: ~/.cache/pip
+      key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
+      restore-keys: |
+        ${{ runner.os }}-pip-
+  ```
+- Include the environment name or a relevant identifier in cache keys when building multiple targets
+
+### Artifacts
+
+- Name artifacts with enough context to be unambiguous (e.g., `firmware-${{ matrix.environment }}`)
+- Avoid uploading artifacts that will never be consumed downstream
+
+---
+
+## Security
+
+### Permissions — Least Privilege
+
+Declare explicit `permissions:` blocks. The default token permissions are broad; scope them to the minimum required:
+
+```yaml
+permissions:
+  contents: read       # for checkout
+```
+
+For jobs that publish releases or write to the repository:
+
+```yaml
+permissions:
+  contents: write      # create/update releases
+```
+
+A common safe baseline for build-only jobs:
+
+```yaml
+permissions:
+  contents: read
+```
+
+### Supply Chain — Action Pinning
+
+**Third-party actions** (anything outside the `actions/` and `github/` namespaces) should be pinned to a specific release tag. Branch pins (`@main`, `@master`) are **not allowed** — they can be updated by the action author at any time without notice:
+
+```yaml
+# ✅ Acceptable — specific version tag. SHA pinning recommended for more security, as @v2 is still a mutable tag.
+uses: softprops/action-gh-release@v2
+
+# ❌ Not acceptable — mutable branch reference
+uses: andelf/nightly-release@main
+```
+
+SHA pinning (e.g., `uses: someorg/some-action@abc1234`) is the most secure option for third-party actions; it is recommended when auditing supply-chain risk is a priority. At minimum, always use a specific version tag.
+
+**First-party actions** (`actions/checkout`, `actions/cache`, `actions/upload-artifact`, etc.) pinned to a major version tag (e.g., `@v4`) are acceptable because GitHub maintains and audits these.
+
+When adding a new third-party action:
+1. Check that the action's repository is actively maintained
+2. Review the action's source before adding it
+3. Prefer well-known, widely-used actions over obscure ones
+
+### Credentials and Secrets
+
+- Use `${{ secrets.GITHUB_TOKEN }}` for operations within the same repository — it is automatically scoped and rotated
+- Never commit secrets, tokens, or passwords into workflow files or any tracked file
+- Never print secrets in `run:` steps, even with `echo` — GitHub masks known secrets but derived values are not automatically masked
+- Scope secrets to the narrowest step that needs them using `env:` at the step level, not at the workflow level:
+
+```yaml
+# ✅ Scoped to the step that needs it
+- name: Create release
+  uses: softprops/action-gh-release@v2
+  with:
+    token: ${{ secrets.GITHUB_TOKEN }}
+
+# ❌ Unnecessarily broad
+env:
+  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+- Personal Access Tokens (PATs, stored as repository secrets) should have the minimum required scopes and should be rotated periodically
+
+### Script Injection
+
+`${{ }}` expressions are evaluated before the shell script runs. If an expression comes from untrusted input (PR titles, issue bodies, branch names from forks), it can inject arbitrary shell commands.
+
+**Never** interpolate `github.event.*` values directly into a `run:` step:
+
+```yaml
+# ❌ Injection risk — PR title is attacker-controlled
+- run: echo "${{ github.event.pull_request.title }}"
+
+# ✅ Safe — value passed through an environment variable
+- env:
+    PR_TITLE: ${{ github.event.pull_request.title }}
+  run: echo "$PR_TITLE"
+```
+
+This rule applies to any value that originates outside the repository (issue bodies, labels, comments, commit messages from forks).
+
+### Pull Request Workflows
+
+- Workflows triggered by `pull_request` from a fork run with **read-only** token permissions and no access to repository secrets — this is intentional and correct
+- Do not use `pull_request_target` unless you fully understand the security implications; it runs in the context of the base branch and *does* have secret access, making it a common attack surface