Files
khadhroony-solana-project/deltas/0.3.5/pre.001-fix.001.md

192 lines
5.3 KiB
Markdown

<!-- file: deltas/0.3.5/pre.001-fix.001.md -->
<!-- version: 1 -->
# Delta `0.3.5-pre.001-fix.001` — correction du gate Interface acquisition events
## Base requise
```text
0.3.5-pre.001
workspace.package.version = 0.3.5-pre.1
```
Ce fix est strictement documentaire. Conformément au workflow KSP, il ne modifie pas `workspace.package.version` et ne touche aucun fichier Cargo/Rust/runtime/config.
## Motif du fix
Le brainstorming post-gate a identifié deux décisions trop conservatrices dans `pre.001` :
1. `OptimisticConfirmation <-> Yellowstone Confirmed` et `Root <-> Yellowstone Finalized` représentent bien les mêmes faits de lifecycle lorsqu'ils sont normalisés avec des noms KSP qui conservent la sémantique source ;
2. la catégorie générique « transaction status » mélangeait snapshot, commitment et exécution, masquant un candidat event-only transversal possible.
## Corrections de conception
### Slot lifecycle
L'intersection admise devient :
```text
SlotLifecycleStage
+ Processed
+ FirstShredReceived
+ Completed
+ CreatedBank
+ Dead
+ OptimisticallyConfirmed
+ Rooted
```
Mappings corrigés :
```text
Solana slotsUpdates::OptimisticConfirmation
-> SlotLifecycleStage::OptimisticallyConfirmed
<- Yellowstone SlotStatus::Confirmed
Solana rootSubscribe / slotsUpdates::Root
-> SlotLifecycleStage::Rooted
<- Yellowstone SlotStatus::Finalized
```
Les noms `OptimisticallyConfirmed` et `Rooted` évitent de promouvoir les labels Yellowstone `Confirmed`/`Finalized` en terminologie KSP universelle. `Frozen` reste hors intersection.
### Transaction execution
`TransactionExecutionEvent` est rouvert comme **candidat actif de `0.3.5`**, conceptuellement :
```text
TransactionExecutionEvent {
slot,
signature,
outcome = Succeeded | Failed,
}
```
Producers candidats :
```text
Solana logsSubscribe
Yellowstone TransactionStatus
Helius transactionSubscribe
```
Le type n'est pas encore admis. `pre.003` doit d'abord auditer la représentation KSP de signature, les mappings exacts, l'anti-duplication Store et le consumer concret. Aucun type partiel ne doit être créé si ce gate échoue.
### Logs et commitment
Les familles sont désormais explicitement séparées :
```text
TransactionLogEvent
-> idée différée ; bornes/consumer/multi-producer à démontrer
getSignatureStatuses
-> snapshot Transport
signatureSubscribe
-> transition one-shot de commitment Transport
TransactionCommitmentEvent
-> non admis ; ne jamais fusionner avec TransactionExecutionEvent par Option soup
```
### Extensions provider/protocol
La règle d'ownership est clarifiée :
```text
DTO provider/protocol spécifique
-> Transport
fait passif provider-neutral réellement commun
-> Interface après gate sémantique
```
Ainsi `Helius transactionSubscribe` et Yellowstone `Entry` restent Transport-owned comme DTOs. Leur caractère non standard n'interdit pas qu'un futur fait commun qu'ils permettent d'observer soit Interface-owned.
## Traçabilité TODO/IDEAS
Le fix ne crée pas artificiellement une entrée durable séparée pendant que le gate `0.3.5` est encore actif :
```text
TransactionExecutionEvent -> suivi actif dans plan/validation 0.3.5
TransactionLogEvent -> idée différée explicitement tracée dans plan/validation
```
Si `TransactionLogEvent` reste hors scope à la réconciliation documentaire finale, il devra être transféré dans le TODO/IDEAS durable approprié.
## Plan de prereleases corrigé
```text
pre.002 implémentation SlotLifecycleEvent/Stage à 7 stages
pre.003 gate TransactionExecutionEvent + implémentation seulement si gate complet
pre.004 canaris externes + complétude API
pre.005 hardening final
pre.006 gate technique final
pre.007 réconciliation documentaire finale
pre.008 préparation de publication
rel.001 stable 0.3.5
```
## Gate opérateur reçu pour `pre.001`
Avant ce fix, l'opérateur a rejoué :
```text
cargo clean
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.3.5
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-interface-lib
```
Résultat fourni :
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Markdown table audit: clean (251 table(s), 137 file(s))
cargo check --workspace: PASS
cargo clippy --workspace --all-targets: PASS
cargo test -p ksp-interface-lib: PASS
```
Les tests Interface détaillés fournis sont tous propres : 10 unitaires, 4 dependency-boundary, 1 external-consumer, 5 public-api, 3 release-completeness, aucun échec de doc-test.
## Fichiers modifiés
```text
docs/plans/026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md
docs/validation/022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md
```
## Fichiers ajoutés
```text
deltas/0.3.5/pre.001-fix.001.md
```
## Fichiers explicitement inchangés
```text
Cargo.toml
crates/**
README.md
ROADMAP.md
CHANGELOG.md
```
## Gate demandé après application du fix
Le fix ne change que Markdown. Rejouer :
```text
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.3.5
```
Aucun rerun Cargo n'est requis par le contenu du fix lui-même.