c5381b7112
Major updates: - Complete Rust rewrite (pilot-v2/) with working MQTT client - Fixed MQTT event loop deadlock (background task pattern) - Battery telemetry for Linux (auto-detected via /sys/class/power_supply) - Home Assistant auto-discovery for all sensors and switches - Comprehensive documentation (AVANCEMENT.md, CLAUDE.md, roadmap) - Docker test environment with Mosquitto broker - Helper scripts for development and testing Features working: ✅ MQTT connectivity with LWT ✅ YAML configuration with validation ✅ Telemetry: CPU, memory, IP, battery (Linux) ✅ Commands: shutdown, reboot, sleep, screen (dry-run tested) ✅ HA discovery and integration ✅ Allowlist and cooldown protection Ready for testing on real hardware. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
172 lines
6.1 KiB
Markdown
172 lines
6.1 KiB
Markdown
# PROMPT CODEX — Redev V2 : Agent MQTT de pilotage PC + Analyse V1
|
||
|
||
## 0) Rôle et objectif
|
||
Tu es **Codex**, expert senior **Python / Windows+Linux / MQTT / packaging / sécurité**.
|
||
Tu dois **analyser un projet existant** (application de pilotage d’un ordinateur via messages MQTT), en comprendre l’architecture et produire une **documentation d’état des lieux**.
|
||
|
||
Ensuite, tu dois préparer une **méthode de re-développement / re-déploiement** sous forme de **consignes de prompts** (itératives), afin que l’utilisateur puisse compléter les besoins supplémentaires avant de lancer l’implémentation.
|
||
|
||
Contraintes :
|
||
- Ne modifie rien tant que l’analyse n’est pas terminée.
|
||
- Sois factuel : si une info n’est pas trouvée dans le projet, indique “Non trouvé”.
|
||
- Structure claire, utilisable comme base de refonte.
|
||
|
||
Livrables attendus :
|
||
1) `analyse_version_1.md` (créé à la racine du repo)
|
||
2) `prompt_method_redev.md` (créé à la racine du repo)
|
||
|
||
---
|
||
|
||
## 1) Étape A — Scan & compréhension du projet
|
||
### 1.1 Cartographie
|
||
- Liste l’arborescence (équivalent `tree -a -I "node_modules|.git|__pycache__|dist|build"`).
|
||
- Identifie :
|
||
- langage(s), frameworks, dépendances
|
||
- points d’entrée (main, service, CLI, daemon)
|
||
- modules clés (mqtt, commandes système, sécurité, config, logs, UI éventuelle)
|
||
|
||
### 1.2 Exécution et cycle de vie
|
||
Déduis et documente :
|
||
- comment l’app se lance (commande, service systemd, tâche planifiée Windows, docker ?)
|
||
- comment elle s’arrête proprement
|
||
- gestion de l’état (retained, availability, LWT, reconnexion, QoS)
|
||
- compatibilité OS (Windows/Linux), permissions nécessaires
|
||
|
||
### 1.3 MQTT : topics & payloads
|
||
Reconstitue précisément (si présent) :
|
||
- broker, auth (user/pass, TLS), client_id
|
||
- topics (commandes / état / availability / logs / télémétrie)
|
||
- structure des messages (JSON ? champs, valeurs possibles)
|
||
- mapping “topic → action exécutée”
|
||
- sécurité : validation d’input, allowlist, anti-injection
|
||
|
||
### 1.4 Configuration
|
||
- Où sont les configs ? (`.env`, yaml, json, ini, registry, args CLI)
|
||
- paramètres supportés, valeurs par défaut, variables d’environnement
|
||
- secrets : comment sont-ils stockés ?
|
||
|
||
### 1.5 Dépendances & packaging
|
||
- `requirements.txt`, `pyproject.toml`, `package.json`, etc.
|
||
- version Python/Node/Go
|
||
- build : exe (pyinstaller), wheel, docker image, service
|
||
- fichiers docs existants (README, CHANGELOG, etc.)
|
||
|
||
### 1.6 Journalisation & observabilité
|
||
- logs (format, rotation)
|
||
- niveaux de logs
|
||
- métriques éventuelles
|
||
- gestion erreurs / retries / backoff
|
||
|
||
---
|
||
|
||
## 2) Étape B — Générer `analyse_version_1.md`
|
||
Crée un fichier `analyse_version_1.md` structuré comme suit (remplis avec ce que tu trouves) :
|
||
|
||
## 2.1 Résumé exécutif
|
||
- Objectif de l’app
|
||
- OS supportés
|
||
- Dépendances majeures
|
||
- Mode d’exécution (service/cli/etc.)
|
||
|
||
## 2.2 Architecture
|
||
- Diagramme textuel (ASCII) des composants
|
||
- Points d’entrée, modules, flux de données
|
||
|
||
## 2.3 MQTT
|
||
### 2.3.1 Connexion
|
||
- Broker, auth, TLS, client_id, keepalive, LWT
|
||
|
||
### 2.3.2 Topics
|
||
- Tableau : Topic | Direction (in/out) | QoS | Retain | Payload | Action/usage
|
||
|
||
### 2.3.3 Commandes supportées
|
||
- Liste exhaustive + exemples de payloads si trouvés
|
||
|
||
## 2.4 Commandes système exécutées
|
||
- actions (shutdown/reboot/sleep/commands) + méthode utilisée
|
||
- risques sécurité + mitigations actuelles
|
||
|
||
## 2.5 Configuration
|
||
- sources (env/files/args)
|
||
- paramètres et defaults (tableau)
|
||
|
||
## 2.6 Stockage / état
|
||
- fichiers, DB, mémoire, cache
|
||
- persistence (oui/non)
|
||
|
||
## 2.7 Déploiement actuel
|
||
- comment installer
|
||
- comment lancer
|
||
- comment update
|
||
- comment rollback
|
||
|
||
## 2.8 Points faibles / dettes techniques
|
||
- liste priorisée (P0/P1/P2)
|
||
- éléments manquants / non trouvés
|
||
|
||
## 2.9 Suggestions de refonte (sans coder)
|
||
- “quick wins”
|
||
- architecture cible probable (optionnelle)
|
||
- axes sécurité
|
||
|
||
---
|
||
|
||
## 3) Étape C — Générer `prompt_method_redev.md` (méthode de redev)
|
||
Crée un fichier `prompt_method_redev.md` qui explique **comment on va re-développer** en itérations, sous forme de “prompts à donner à Codex”, avec checkpoints.
|
||
|
||
Format attendu :
|
||
|
||
# Méthode de re-développement / re-déploiement (V2)
|
||
## 1) Pré-requis
|
||
- outils, versions, conventions repo, structure attendue
|
||
|
||
## 2) Liste des informations que l’utilisateur doit compléter
|
||
Crée une section “À compléter par l’utilisateur” avec des champs vides, par exemple :
|
||
- OS cibles : [ ]
|
||
- Broker MQTT : [ ]
|
||
- Auth/TLS : [ ]
|
||
- Liste commandes à supporter : [ ]
|
||
- Politique de sécurité (allowlist, signature, ACL broker) : [ ]
|
||
- Packaging désiré (exe windows, systemd linux, docker) : [ ]
|
||
- Intégration Home Assistant autodiscovery : [oui/non] + détails : [ ]
|
||
- Availability / birth / will : [ ]
|
||
- Fréquence télémétrie : [ ]
|
||
- etc.
|
||
|
||
## 3) Plan itératif (prompts)
|
||
Donne une séquence de prompts “copier-coller” :
|
||
- Prompt 1 : “Génère l’architecture cible + conventions”
|
||
- Prompt 2 : “Implémente le noyau MQTT + config + logs”
|
||
- Prompt 3 : “Implémente le moteur de commandes avec allowlist”
|
||
- Prompt 4 : “Ajoute availability/LWT + heartbeat”
|
||
- Prompt 5 : “Ajoute autodiscovery Home Assistant (si demandé)”
|
||
- Prompt 6 : “Packaging Windows (service/tâche)”
|
||
- Prompt 7 : “Packaging Linux (systemd)”
|
||
- Prompt 8 : “Tests + harness MQTT + doc + exemples”
|
||
|
||
Chaque prompt doit :
|
||
- préciser les fichiers à créer/modifier
|
||
- imposer une checklist de validation (tests, lint, doc)
|
||
- définir une sortie attendue (ex: `docs/deploy_windows.md`, `docker-compose.yml`, etc.)
|
||
|
||
## 4) Procédure de re-déploiement
|
||
- stratégie : in-place vs nouveau dossier
|
||
- migration config
|
||
- compatibilité topics (versioning)
|
||
- rollback
|
||
|
||
---
|
||
|
||
## 4) Règles de sortie
|
||
- Crée uniquement les 2 fichiers demandés.
|
||
- Si tu dois exécuter des commandes pour comprendre (ex: grep), fais-le localement dans ton environnement.
|
||
- Termine en affichant :
|
||
- un résumé de 10 lignes
|
||
- le chemin des fichiers créés
|
||
- 5 questions “À compléter par l’utilisateur” (copiées depuis la section correspondante)
|
||
|
||
---
|
||
|
||
## 5) Action immédiate
|
||
Commence maintenant l’analyse du projet présent dans le dossier courant.
|