# 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. ## 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. ## Cycle d'une release concrète Sauf raison explicitement documentée : - `pre.001` = brainstorming/audit si nécessaire + planification + découpage de la release ; - 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. ## Dimensionnement des prereleases 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. Cette durée est un budget de planification et non une promesse d'exécution. Si la complexité réelle augmente, la tranche est redécoupée plutôt que surchargée. ## Dimensionnement d'une release/session Avant de finaliser le prompt d'une release concrète, vérifier que son plan complet est compatible avec une session de qualité. 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. 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. Une série complète peut naturellement s'étendre sur de nombreuses sessions. ## Structure recommandée d'un prompt 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. ## 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.