v0.2.5-pre.010.fix.001

docs/rules/PROMPT_STRUCTURE.md

@@ -1,74 +1,108 @@
 <!-- file: docs/rules/PROMPT_STRUCTURE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Structure des prompts KSP
 
 ## Portée
 
-Ce document définit le contrat normatif des prompts de reprise KSP, leur cycle de vie et les règles de dimensionnement des releases/sessions qu'ils préparent.
+Ce document définit le contrat normatif des prompts de reprise KSP, leur cycle de vie et les règles de dimensionnement des releases/sessions qu'ils préparent. Un prompt de démarrage est un **contrat opératoire autonome** : une nouvelle session ne doit pas dépendre d'une mémoire implicite pour retrouver les règles déjà acquises.
 
 ## Série, release concrète et session
 
 Une notation de série telle que `0.1.x` regroupe des fonctionnalités apparentées. Elle n'est pas une unité de session et n'a pas à être réalisable en une seule session.
 
-Exemple : `0.1.x` peut regrouper plusieurs releases concrètes comme `0.1.1`, `0.1.2`, `0.1.3`, chacune avec son propre cycle de prereleases et, en principe, sa propre session de travail principale.
-
-Le contrôle de charge s'applique donc d'abord à **la release concrète préparée** et à ses prereleases, pas à toute la série fonctionnelle.
+Le contrôle de charge s'applique d'abord à **la release concrète préparée** et à ses prereleases. Une release concrète doit être planifiée pour être ouverte et clôturée dans une seule session de chat ; si cette clôture paraît incertaine, elle est scindée avant l'implémentation lourde.
 
 ## Cycle d'une release concrète
 
 Sauf raison explicitement documentée :
 
-- `pre.001` = brainstorming/audit si nécessaire + planification + découpage de la release ;
+- `pre.001` = lectures obligatoires + audit interne/externe + brainstorming + sizing + planification ;
 - les prereleases intermédiaires = tranches bornées de développement/validation ;
-- la dernière prerelease = validation finale + documentation + nettoyage/archivage + préparation du prompt/release suivante.
+- la dernière prerelease = validation finale + documentation + nettoyage/archivage + prompt de la release suivante ;
+- une `fix` corrige l'étape réellement livrée sans réécrire l'historique.
 
-## Dimensionnement des prereleases
+## Dimensionnement
 
-Lors de `pre.001`, une prerelease intermédiaire estimée à plus d'environ **15 à 20 minutes de travail effectif de session** doit être scindée.
+Lors de `pre.001`, une prerelease intermédiaire estimée à plus d'environ **15 à 20 minutes de travail effectif** est scindée. Cette durée est un budget de planification, jamais une promesse temporelle.
 
-Cette durée est un budget de planification et non une promesse d'exécution.
+La trajectoire initiale est **souple** : elle indique un nombre prévisionnel de prereleases, leur objectif et leur ordre, mais autorise l'insertion de tranches/fixes lorsqu'un audit ou une validation révèle un besoin réel. La fermeture ne doit jamais être forcée pour respecter un numéro prévu.
 
-Si la complexité réelle augmente, la tranche est redécoupée plutôt que surchargée.
+## Structure obligatoire d'un prompt de démarrage
 
-## Dimensionnement d'une release/session
+Un prompt de nouvelle session contient explicitement, dans un ordre facile à retrouver :
 
-Avant de finaliser le prompt d'une release concrète, vérifier que son plan complet est compatible avec une session de qualité.
+1. identité de la release et base exacte requise ;
+2. mission et résultat attendu ;
+3. **sources de vérité internes obligatoires et ordre de lecture** ;
+4. sources externes normatives à réauditer lorsque la fraîcheur importe ;
+5. état validé à préserver, y compris règles de dépendances et frontières ;
+6. décisions acquises et questions réellement ouvertes ;
+7. objectifs/livrables et hors périmètre ;
+8. contraintes sécurité/API/architecture spécifiques ;
+9. **première mission `pre.001` détaillée et critères de sortie de ce gate** ;
+10. **prévision souple initiale des prereleases**, visible et détaillée ;
+11. règles de versionnement, deltas, commits et tags ;
+12. procédure d'application/validation opérateur ;
+13. validations Rust/frontend/Tauri/réseau pertinentes ;
+14. critères de clôture de la release ;
+15. release/session suivante envisagée ;
+16. **instruction d'ouverture** indiquant ce que la prochaine session doit faire en premier et ce qu'elle ne doit pas commencer avant le gate.
 
-Si une release concrète paraît trop lourde, la scinder en plusieurs releases de la même série lorsque les fonctions restent du même groupe, ou changer de série si une frontière fonctionnelle différente le justifie.
+## Sources de vérité et reprise
 
-Exemple : si `0.1.1` devient trop large, créer `0.1.2` plutôt que forcer tout `0.1.x` dans une seule session.
+- Le prompt ordonne explicitement la lecture de `RULES.md`, `docs/000-README.md`, règles spécialisées, architecture, plan/validation de la release précédente et sources métier pertinentes.
+- Lorsqu'une archive/base opérateur est fournie, elle est déclarée autoritaire par rapport aux souvenirs, snippets ou artefacts anciens.
+- Le prompt ne recopie pas toutes les règles, mais rappelle les règles qui conditionnent directement la session et exige la lecture des fichiers normatifs.
+- Les décisions historiques ne sont pas réinventées lors de la nouvelle session ; une divergence avec la base réelle déclenche un audit, pas une supposition.
 
-Une série complète peut naturellement s'étendre sur de nombreuses sessions.
+## Force opératoire du `pre.001`
 
-Une **release concrète**, en revanche, doit être planifiée pour être ouverte et clôturée dans une seule session de chat. Une version volontairement laissée ouverte pour être reprise dans une autre session n'est pas un découpage acceptable.
+Le prompt doit rendre impossible une interprétation « commencer à coder immédiatement ». La première tranche exige au minimum :
 
-Si `pre.001` révèle qu'une clôture dans la session est incertaine, la release est scindée **avant l'implémentation fonctionnelle lourde**. Cette contrainte s'ajoute au budget de 15–20 minutes par prerelease ; elle ne le remplace pas.
+```text
+lecture des sources internes obligatoires
+inventaire de l'état réel de la base
+récupération des dépendances/versions actuelles si concernées
+comparaison avec les références historiques utiles
+brainstorming des risques/frontières
+sizing de la release et de chaque tranche
+prévision souple recalibrée
+liste des validations/gates
+```
 
-## Structure recommandée d'un prompt
+L'implémentation fonctionnelle lourde commence seulement lorsque ce gate est cohérent. Les corrections triviales nécessaires pour rendre l'audit lui-même exécutable restent autorisées.
 
-1. Identité de la série et de la release concrète visée ;
-2. Mission ;
-3. Base requise ;
-4. État validé à préserver ;
-5. Sources de vérité internes ;
-6. Sources externes normatives ;
-7. Décisions acquises ;
-8. Objectifs et livrables ;
-9. Hors périmètre ;
-10. Méthode de travail ;
-11. Versionnement/deltas/commits ;
-12. Contraintes techniques spécifiques ;
-13. Plan initial souple et prereleases bornées ;
-14. Validations attendues ;
-15. Critères de sortie ;
-16. Préparation de la release/session suivante.
+## Validation Rust obligatoire dans les prompts
+
+Toute release susceptible de modifier du Rust rappelle explicitement la séquence KSP :
+
+```bash
+cargo fmt --all
+python3 scripts/audit_rust_workspace_rules.py
+cargo check --workspace
+cargo clippy --workspace --all-targets
+```
+
+Pendant le développement, les tests ciblés suivent ces contrôles. La fermeture d'une prerelease technique/release inclut `cargo test --workspace` et les `cargo tree` pertinents lorsque le graphe de dépendances a changé ou constitue un gate de la tranche.
+
+Un prompt interdit de déclarer réussie une commande qui n'a pas réellement été exécutée. Il rappelle que `rustfmt` et Clippy ne remplacent pas l'audit structurel KSP.
+
+## Dépendances et fraîcheur
+
+Lorsqu'une tranche ajoute, met à jour ou dépend fortement d'une bibliothèque externe :
+
+- vérifier la version stable réellement courante au début de la tranche ;
+- préférer les sources primaires de la crate/projet ;
+- vérifier les features réellement nécessaires et les contraintes de versions transitives ;
+- documenter les doublons transitifs acceptés plutôt que forcer artificiellement une unification incompatible ;
+- ne pas conserver dans un prompt une version historique comme si elle était nécessairement toujours actuelle.
 
 ## Règles de rédaction
 
-- Le prompt référence les sources canoniques au lieu de recopier inutilement leur contenu.
-- Une règle normative appartient à `docs/rules/`.
-- Une décision durable appartient à `docs/architecture/`.
-- Une idée non décidée appartient à `docs/IDEAS.md`.
-- Un prompt doit signaler les questions ouvertes plutôt que les résoudre arbitrairement.
-- Une release concrète manifestement surdimensionnée doit être redécoupée avant ouverture de sa session principale.
+- Le prompt doit être autoportant sans devenir une copie intégrale des règles.
+- Les titres `Première mission`, `Prévision souple`, `Validation` et `Instruction d'ouverture` doivent être immédiatement repérables.
+- Une règle normative appartient à `docs/rules/`, une décision durable à `docs/architecture/`, une idée non décidée à `docs/IDEAS.md`.
+- Le prompt signale les questions ouvertes au lieu de les résoudre arbitrairement.
+- Une release surdimensionnée est redécoupée avant ouverture de son développement lourd.
+- Le prompt conserve les conventions KSP de delta minimal, version de fichiers, Cargo version technique, commits et tags stables.