Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.2.9-pre.012-fix.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-24 20:56:04 +02:00
parent 813a45385a
commit 5b30bb9948
5 changed files with 260 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/rules/PROMPT_STRUCTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/PROMPT_STRUCTURE.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Structure des prompts KSP
@@ -19,8 +19,42 @@ Sauf raison explicitement documentée :
- `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 + prompt de la release suivante ;
- une `fix` corrige l'étape réellement livrée sans réécrire l'historique.
- la fermeture réserve des prereleases distinctes pour le gate technique/live, la réconciliation documentaire puis la préparation de publication ;
- la dernière prerelease avant `rel.NNN` est une tranche de publication minimale, distincte de la réconciliation documentaire et des smokes ;
- une `fix` corrige uniquement la responsabilité de la tranche à laquelle il est rattaché et ne sert pas à absorber un autre couloir de fermeture.
## Séparation obligatoire des dernières prereleases
La queue de fermeture d'une release est structurée de manière à empêcher qu'un correctif de dernière minute mélange tests réseau, documentation durable et préparation de publication.
Lorsqu'un smoke final ou un autre gate live est pertinent, les trois dernières responsabilités sont ordonnées ainsi :
```text
pre.N-2 gate technique/live : smoke(s), graphes ou vérifications finales directement liées au runtime
pre.N-1 réconciliation documentaire : plan, validation, README, USAGE et autres références durables concernées
pre.N préparation de publication : prompt suivant + CHANGELOG + ROADMAP uniquement
rel.001 mécanique de publication stable
```
Les numéros `N-2`, `N-1` et `N` sont relatifs : l'insertion d'une tranche ou d'une correction décale la numérotation réelle sans affaiblir cette séparation.
Si aucun smoke/gate live final n'existe, le couloir `pre.N-2` est omis ; les deux dernières prereleases restent néanmoins séparées entre réconciliation documentaire et préparation de publication.
La dernière prerelease ne modifie fonctionnellement que :
```text
prompt de démarrage de la release suivante
CHANGELOG.md
ROADMAP.md
```
Les fichiers mécaniques imposés par le workflow restent autorisés : `Cargo.toml` pour la version d'une prerelease non-fix et `deltas/<X.Y.Z>/pre.NNN.md` pour sa traçabilité. Aucun README, USAGE, plan, validation, code, test, schema, config ou règle normative ne doit être introduit ou corrigé dans cette dernière tranche.
La prerelease documentaire immédiatement précédente possède la réconciliation finale des documents durables de la release : README/USAGE, plan, validation, architecture/référence concernée et cohérence documentaire globale. Elle ne finalise ni `CHANGELOG.md`, ni `ROADMAP.md`, ni le prompt de la release suivante.
Le gate technique/live, lorsqu'il existe, précède cette réconciliation documentaire. Les smokes et leurs corrections restent donc isolés avant que les documents finaux soient figés.
Un `fix` reste local à son couloir. Si un défaut d'une responsabilité antérieure est découvert après avoir avancé, il ne doit pas être glissé dans le `fix` de la tranche courante : une nouvelle tranche dédiée à la responsabilité concernée est ouverte, puis les couloirs de fermeture postérieurs sont rejoués si nécessaire. La livraison `rel.NNN` ne sert jamais à absorber un correctif fonctionnel ou documentaire qui aurait dû être traité en prerelease.
## Dimensionnement
@@ -28,6 +62,8 @@ Lors de `pre.001`, une prerelease intermédiaire estimée à plus d'environ **15
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.
La prévision `pre.001` réserve explicitement les couloirs de fermeture applicables : gate technique/live éventuel, réconciliation documentaire, puis préparation de publication minimale. Leur numérotation peut dériver, mais leur ordre et leur séparation de responsabilités restent normatifs.
## Structure obligatoire d'un prompt de démarrage
Un prompt de nouvelle session contient explicitement, dans un ordre facile à retrouver :