v0.2.9-pre.015

prompts/015-V0_2_10_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/015-V0_2_10_START_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Prompt de démarrage `0.2.10` — OrbitFlare Yellowstone gRPC
 
@@ -55,7 +55,9 @@ Yellowstone Subscribe            accounts/slots/transactions/status/blocks/meta/
 Yellowstone updates              9 variantes standard retenues
 Yellowstone lifecycle            bidi/backpressure/half-close/shutdown bornés
 Yellowstone reconnect/replay     KSP-owned, prudent, non lossless
-PublicNode N3                    premier provider standard sans divergence wire
+PublicNode N3                    Mainnet + Testnet validés sur le standard N2
+PublicNode auth                  metadata secrète x-token via Config
+PublicNode live                  Subscribe -> Slot 2/2 PASS
 
 Config Transport                 V1 HTTP + V2 WS + V3 gRPC backward-readable
 Config -> Transport              autorisé
@@ -399,9 +401,21 @@ Une policy OrbitFlare supplémentaire doit s'ajouter sans casser ces garanties.
 
 ### 5.4 PublicNode N3
 
-PublicNode constitue le premier témoin provider : lorsqu'aucune divergence n'existe, KSP réutilise directement le standard N2 avec un `provider` descriptif.
+PublicNode constitue le premier témoin provider et réutilise directement le standard N2 avec un `provider` descriptif. Les faits stabilisés à préserver sont :
 
-OrbitFlare ne reçoit donc une façade publique spécifique que si `pre.001` démontre qu'un comportement doit être exposé au consumer KSP.
+```text
+Mainnet endpoint  = https://solana-yellowstone-grpc.publicnode.com:443
+Testnet endpoint  = https://solana-testnet-yellowstone-grpc.publicnode.com:443
+auth wire         = metadata x-token secrète
+Config secret     = deux variables KSP_SECRET_* distinctes
+live gate         = Subscribe -> Slot, Mainnet PASS + Testnet PASS
+```
+
+Le même personal token opérateur a été validé sur les deux réseaux ; les deux variables Config restent distinctes uniquement pour conserver de la flexibilité opérationnelle. Ne pas transformer ce constat en règle générale sur la portée des tokens PublicNode.
+
+Les essais live ont aussi montré qu'un endpoint provider peut restreindre certaines unary indépendamment du streaming. Une unary standard disponible dans N2 n'est donc pas une garantie d'entitlement chez chaque provider.
+
+OrbitFlare ne reçoit une façade publique spécifique que si `pre.001` démontre qu'un comportement doit être exposé au consumer KSP.
 
 ### 5.5 Config V3
 
@@ -878,23 +892,34 @@ pre.002  provider descriptor/capabilities et settings/policy minimale réellemen
 pre.003  heartbeat/auth/lifecycle OrbitFlare seulement si divergence confirmée
          preuve : fixture déterministe + cancellation/reconnect + redaction + aucun second actor
 
-pre.004  Config V3 OrbitFlare + profils retenus + smoke live opt-in architecture-safe
-         preuve : provenance secret correcte + endpoint réel opérateur + standard surface réutilisée
+pre.004  Config V3 OrbitFlare + profils retenus + déterministe/adversarial/compliance
+         preuve : provenance secret correcte + standard N2 réutilisé + non-régressions ciblées
 
-pre.005  adversarial/compliance + non-régressions PublicNode/standard + README/USAGE + cargo tree + prompt 0.2.11
-         preuve : workspace final vert + docs/validation fermées + prompt suivant autonome
+pre.005  gate technique/live final si applicable
+         preuve : smoke OrbitFlare opt-in ou bloc externe qualifié + workspace + graphes Cargo finaux
 
-rel.001  publication stable stricte
+pre.006  réconciliation documentaire finale
+         preuve : plan + validation + README/USAGE + références durables synchronisés, aucun runtime modifié
+
+pre.007  préparation de publication minimale
+         preuve : prompt 0.2.11 + CHANGELOG.md + ROADMAP.md uniquement, hors Cargo.toml/delta mécaniques
+
+rel.001  publication stable stricte, sans rattrapage technique ou documentaire
 ```
 
 Règles :
 
 ```text
 chaque tranche vise nominalement 15–20 min de travail effectif
-pre.001 peut fusionner/scinder/déplacer/ajouter des prereleases
-si OrbitFlare est purement standard, réduire le nombre de tranches
+pre.001 peut fusionner/scinder/déplacer/ajouter des prereleases de développement
+si OrbitFlare est purement standard, réduire les tranches intermédiaires
 si auth/heartbeat implique une extension moteur importante, scinder avant implémentation
-un fix peut être inséré après toute tranche
+le gate technique/live final peut être omis si aucun smoke/live n'est pertinent
+réconciliation documentaire et préparation de publication restent toujours deux prereleases distinctes
+la dernière prerelease ne finalise que prompt suivant + CHANGELOG + ROADMAP, hors Cargo.toml/delta mécaniques
+un fix reste local à la responsabilité de sa prerelease
+un défaut découvert dans un couloir antérieur ouvre une nouvelle prerelease dédiée puis rejoue les couloirs suivants
+rel.001 ne sert jamais de tranche de rattrapage
 le numéro final n'est jamais un critère de clôture
 ```
 
@@ -945,6 +970,17 @@ v0.2.10
 
 Les deltas publiés sont immuables.
 
+La fermeture respecte `docs/rules/PROMPT_STRUCTURE.md` et `docs/rules/VERSION_WORKFLOW.md` :
+
+```text
+gate technique/live final éventuel
+-> réconciliation documentaire finale
+-> préparation de publication minimale
+-> rel.001
+```
+
+La dernière prerelease avant `rel.001` ne modifie fonctionnellement que le prompt suivant, `CHANGELOG.md` et `ROADMAP.md`, en plus de `Cargo.toml` et de son delta mécanique.
+
 ---
 
 ## 14. Validation opérateur et application
@@ -1052,12 +1088,14 @@ Standard WS 18/18 non régressé
 Helius WS non régressé
 firewall dépendances vert
 workspace complet vert
-README/USAGE synchronisés
-matrice OrbitFlare fermée
-prompt 0.2.11 préparé
+README/USAGE synchronisés dans la prerelease documentaire dédiée
+matrice OrbitFlare fermée avant la prerelease de publication
+prompt 0.2.11 préparé uniquement dans la dernière prerelease
+CHANGELOG/ROADMAP finalisés uniquement dans la dernière prerelease
+aucun rattrapage technique/documentaire dans rel.001
 ```
 
-Le numéro de prerelease n'est jamais un critère de clôture.
+Le numéro de prerelease n'est jamais un critère de clôture. Les numéros de la prévision peuvent dériver, mais l'ordre des couloirs de fermeture ne dérive pas.
 
 ---