Les évolutions WebUI + réseau (WiFi/ESP-NOW/MQTT) avancent vite sur audit/telephony-webserver et le risque de divergence frontend/backend augmente à chaque ajout de route.
Impact utilisateur
Quand la WebUI appelle une route absente côté firmware, l'opérateur voit des erreurs HTTP côté navigateur et perd des actions de test (pilotage WiFi/ESP-NOW/MQTT) sans alerte claire en CI.
Root cause
Aucun garde-fou automatique ne vérifiait que les appels requestJson('/api/...') du frontend correspondent à des routes server_.on('/api/...', HTTP_...) déclarées dans WebServerManager.
Correctif
Ajout de scripts/check_web_route_parity.py:
extrait les routes backend (src/web/WebServerManager.cpp),
extrait les appels frontend (data/webui/script.js),
échoue si une route frontend n'existe pas côté backend,
signale les routes backend non utilisées par la WebUI (warning non bloquant).
Intégration du check dans la CI (.github/workflows/ci.yml).
Intégration du check dans le test terminal local (scripts/test_terminal.sh).
Extension du trigger CI pour inclure la branche active audit/**.
Relates #10 (couverture WebUI des routes backend restantes)
## Contexte
Les évolutions WebUI + réseau (WiFi/ESP-NOW/MQTT) avancent vite sur `audit/telephony-webserver` et le risque de divergence frontend/backend augmente à chaque ajout de route.
## Impact utilisateur
Quand la WebUI appelle une route absente côté firmware, l'opérateur voit des erreurs HTTP côté navigateur et perd des actions de test (pilotage WiFi/ESP-NOW/MQTT) sans alerte claire en CI.
## Root cause
Aucun garde-fou automatique ne vérifiait que les appels `requestJson('/api/...')` du frontend correspondent à des routes `server_.on('/api/...', HTTP_...)` déclarées dans `WebServerManager`.
## Correctif
- Ajout de `scripts/check_web_route_parity.py`:
- extrait les routes backend (`src/web/WebServerManager.cpp`),
- extrait les appels frontend (`data/webui/script.js`),
- échoue si une route frontend n'existe pas côté backend,
- signale les routes backend non utilisées par la WebUI (warning non bloquant).
- Intégration du check dans la CI (`.github/workflows/ci.yml`).
- Intégration du check dans le test terminal local (`scripts/test_terminal.sh`).
- Extension du trigger CI pour inclure la branche active `audit/**`.
## Validation
- `python3 scripts/check_web_route_parity.py` ✅
- `bash scripts/test_terminal.sh` ✅
## Suivi
- Closes #11
- Relates #10 (couverture WebUI des routes backend restantes)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Contexte
Les évolutions WebUI + réseau (WiFi/ESP-NOW/MQTT) avancent vite sur
audit/telephony-webserveret le risque de divergence frontend/backend augmente à chaque ajout de route.Impact utilisateur
Quand la WebUI appelle une route absente côté firmware, l'opérateur voit des erreurs HTTP côté navigateur et perd des actions de test (pilotage WiFi/ESP-NOW/MQTT) sans alerte claire en CI.
Root cause
Aucun garde-fou automatique ne vérifiait que les appels
requestJson('/api/...')du frontend correspondent à des routesserver_.on('/api/...', HTTP_...)déclarées dansWebServerManager.Correctif
scripts/check_web_route_parity.py:src/web/WebServerManager.cpp),data/webui/script.js),.github/workflows/ci.yml).scripts/test_terminal.sh).audit/**.Validation
python3 scripts/check_web_route_parity.py✅bash scripts/test_terminal.sh✅Suivi
Codex review (self-check):
python3 scripts/check_web_route_parity.py,bash scripts/test_terminal.sh, GitHub Actionsbuild-and-test✅.Je recommande merge.