copilot-instructions rework, new C++ coding guide for AI reviews

[softhack007]

Reworks AI instructions, to separate "coding agent" from "code review" instructions.
Adds C++ coding guidelines that were extracted from the WLED source code (mainly by AI). The new guides can be used both for contributor information, and as a "best practice" database in automated code reviews by the rabbit.

Update: I've moved the coding style guides into their own directory /docs, and "out of the way" for non-review agent tasks. It seems that AI agent tasks ("I need a new bus driver for my Daimler") work faster without the "code review" add-on guides - the agent will still find docs when it needs help. Code reviews (coderabbitAI) with detailed guides are still much better.

Details

• shortens previous instruction file, by removing duplicated information and shortening sentences
• moves agent instructions into a separate file
• adds coding conventions for C++, webUI, CI/CD (based on WLED-MM, needs adjustment for WLED)
• adds .coderabbit.yaml so the rabbit uses the same instructions for reviews that copilot sees.
• Introduces a HUMAN_ONLY mechanism that hides generic information from the AI, to increase "attention layer excitement"

Example for a coderabbit review with the new instructions: MoonModules#324 (comment)
(notice that recommendations refer to the new guidelines, and there is a "things done well" section, too)

This is a request for discussions

The new instructions already work well in WLED-MM, but we need to adjust them for WLED. Most importantly, optimization guides for ESP8266 still need to be added.

more information:

• Revise copilot-instructions.md: consolidate, shorten, and extract language-specific rules, take 2 MoonModules/WLED-MM#353
• Revise *.instructions.md: separate AI-relevant special knowledge from background information for contributors  MoonModules/WLED-MM#354

---

Revising AI review instructions:

• Reduce context window use for AI review tools, by avoiding repeating common knowledge and API information that is (usually) part of the AI training datasets any way.
• Introduce a mechanism to maintain both parts in single files, to avoid "silent diversion" over time
• Adding a coderabbit path instruction that ensures cross-checking of both parts whenever a PR modifies instruction files
• Primary Goal: only inject content in AI-visible areas that are WLED–specific or which deviate from general knowledge (the context window "token cost" of true false-positive suppressors is always worth it).
• Soft goal: keep each file's AI-facing section lean enough that the signal-to-noise ratio in the attention layer stays high — around 1,500–2,000 words per file type is a reasonable practical ceiling for current models.
• Aspirational: 500 words per file if achievable without sacrificing review quality.

---

Guiding Principles for Efficient AI Instruction Files

1. Only document what can't be inferred from the code or from general training.
   If the AI would get it right without instruction 95% of the time, the instruction probably isn't worth the extra space in context memory.

2. Prefer short, actionable rules over explanations.
   "Do not flag uint8_t x = int(f) as a bug when the comment says // float→int wrapping" is more useful than a paragraph explaining why. The paragraph is for humans; the rule is for AI.

3. Keep the total injected instruction size per file type low (<1000 lines, best under ~500 words).
   With lots of instructions, the value of additional instructions drops rapidly and the distraction cost rises.

4. Encode "false positive suppressors" first, feature guidance second.
   "Don't flag pattern X as a bug" is more impactful than "always do Y" because it directly prevents noise.

5. Treat instruction files like tests — they need maintenance when the code changes.
   If you wouldn't update the instruction file when refactoring the relevant code, don't write the instruction.

Large language models already have extensive general knowledge about C++, ESP-IDF, GitHub Actions, etc. The genuine value of instruction files is narrow but real:

What AI genuinely doesn't know without you telling it	What AI already knows well enough
Your project's intentional deviations from general best practice	General C++ / ESP-IDF / GitHub Actions patterns
Decisions that look like bugs but aren't (e.g. a float→int→uint8_t wrapping pattern)	Standard style rules
Which files/patterns to ignore or treat as deprecated	Common security practices
Your PR process expectations	How delay() works in FreeRTOS
Project-specific macro semantics (WLED_DISABLE_2D, d_malloc)	Memory allocation tradeoffs
Which reviewer comments are out of scope for this PR	Naming conventions

The key insight: instruction files are most valuable when they prevent false positives (AI flagging intentional patterns as bugs) and encode decisions that can't be inferred from the code alone.

---

Summary by CodeRabbit

• Documentation

  • Added comprehensive C++, Web UI, and CI/CD coding conventions; condensed setup/build guide; new agent-mode build/test workflow with ordered commands, timeouts, required validation gates, manual web validation guidance, and troubleshooting.

• Chores

  • Introduced repository-level AI review/configuration rules, workflow best-practices, safeguards to detect/flag edits to generated web assets, and alignment checks between AI-facing rules and human-only reference sections.