# 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.