31 KiB
Prompt de démarrage 0.3.15 — Raw Transaction Ingest Desk / composition et supervision de routes live
1. Identité de la release et base exacte requise
Ouvrir uniquement 0.3.15 depuis la release stable/taggée :
v0.3.14
La base fournie par l'opérateur est autoritaire sur les souvenirs, snippets, anciennes archives et deltas intermédiaires. Avant toute modification, vérifier au minimum :
workspace.package.version = 0.3.14
deltas/0.3.14/rel.001.md présent
ksp-worker-raw-transaction-ingest-lib stable et consommable depuis sa crate root
ksp-config-lib possède la résolution Transport HTTP / WS / Yellowstone gRPC
ksp-onchain-transport-lib possède les façades réellement utilisées par le Worker
ksp-store-lib reste l'unique façade Store du consumer
cinq familles live Worker préservées : Yellowstone / Standard Logs / Standard Block / Helius Transaction / HTTP Block Polling
gaps run-local, TargetCoverage, health, fairness et shutdown 0.3.14 présents
snapshots publics gap/repair source-neutral présents
aucun edge Worker -> Config / Job Backfill / backend Store physique
Release ouverte :
0.3.15
Première livraison attendue :
0.3.15-pre.001
pre.001 est obligatoirement un gate de lecture + audit de composition Config/Transport/Store/Worker + audit du gabarit Desk KSP + brainstorming + sizing + planification. Il est interdit de commencer directement par l'UI, par des commandes Tauri Start/Stop ou par la copie d'une application Desk existante avant fermeture de ce gate.
2. Mission et résultat attendu
Créer :
crates/ksp-app-raw-transaction-ingest-desk
comme application Tauri KSP spécialisée dans la composition, le démarrage, l'arrêt et la supervision de routes live RawTransaction réellement supportées par la configuration et le Worker finalisé.
Le Desk doit permettre à l'opérateur de :
charger/utiliser la configuration KSP
choisir le réseau logique disponible
voir les routes live composables pour ce réseau
comprendre pourquoi une route non composable est désactivée
sélectionner une ou plusieurs routes composables
démarrer une instance Worker par route sélectionnée
arrêter chaque Worker proprement
observer lifecycle / health / activité / backpressure / reconnect / replay / gaps / repair via les snapshots Worker
vérifier que les données convergent réellement vers le même Store RawTransaction
Le Desk ne devient pas une seconde implémentation de l'acquisition. La chaîne d'ownership cible est :
Frontend Tauri
-> route_id / action Start-Stop / DTO sûrs
-> backend Rust de ksp-app-raw-transaction-ingest-desk
-> ksp-config-lib
-> ksp-onchain-transport-lib
-> ksp-store-lib
-> ksp-worker-raw-transaction-ingest-lib
-> ksp-raw-transaction-lib
-> même Store RawTransaction
2.1 Règle fondamentale : route != source != endpoint
Une route est une stratégie d'acquisition complète. Elle peut nécessiter plusieurs ressources/capacités techniques pour devenir exécutable.
Exemples conceptuels, à réauditer contre la base réelle :
Yellowstone transaction stream + HTTP getTransaction hydration
Standard WS logsSubscribe + HTTP getTransaction hydration
Standard WS blockSubscribe RAW-direct
Helius transactionSubscribe + HTTP getTransaction hydration
HTTP Block Polling RAW-direct
Une route n'est pas sélectionnable parce qu'un seul endpoint portant le bon provider existe. Elle est sélectionnable uniquement si toutes ses capacités obligatoires peuvent être composées depuis la Config pour le même réseau logique.
Exemple :
route exige Yellowstone gRPC + HTTP getTransaction
gRPC disponible = oui
HTTP compatible = non
=> route NON SÉLECTIONNABLE
Autre exemple :
endpoint Helius disponible uniquement comme WS standard
route Standard WS Logs compatible = potentiellement sélectionnable
route exigeant Helius transactionSubscribe = NON sélectionnable si cette capability spécifique n'est pas disponible
Il est interdit de déduire une capability uniquement à partir du nom du provider.
2.2 Une instance Worker par route sélectionnée
Décision acquise :
1 route sélectionnée = 1 instance ksp-worker-raw-transaction-ingest-lib
N routes sélectionnées = N Workers indépendants
Ce n'est pas un Worker par source physique.
Une même route peut composer plusieurs ressources internes nécessaires à sa stratégie : gRPC + HTTP, WS + HTTP, ou d'autres ressources réellement requises par les contrats Worker. Toutes ces ressources appartiennent au Worker de cette route.
Plusieurs Workers de routes différentes peuvent écrire vers le même Store RawTransaction. Ils restent indépendants pour :
lifecycle
gaps / TargetCoverage
health
repair
shutdown
Aucun partage implicite de gap ledger ou de preuve de coverage entre Workers distincts n'est introduit. La convergence durable passe par les contrats Store/idempotence/observations existants.
2.3 Composable avant Start, opérationnelle après Start
Deux niveaux sont obligatoirement distingués :
COMPOSABLE
toutes les capacités/configurations requises existent et sont cohérentes
décision déterministe à partir de Config et des contrats connus
OPÉRATIONNELLE
les ressources sélectionnées fonctionnent réellement au runtime
preuve obtenue lors du Start / runtime Worker-Transport-Store
La liste des routes ne doit pas lancer des probes réseau arbitraires pour fabriquer artificiellement une disponibilité. Le backend Desk détermine d'abord la composabilité à partir de la configuration résolue. Au Start, le Worker et les façades Transport/Store valident réellement les ressources, les réseaux, les connexions et les capacités runtime nécessaires.
Une route peut donc rester visible comme Configured/Composable puis passer Starting -> Running ou Starting -> Faulted selon le runtime réel.
3. Sources de vérité internes obligatoires — ordre de lecture
3.1 Gouvernance générale
Lire intégralement, dans cet ordre :
RULES.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
Le prompt complète ces règles ; il ne les remplace pas.
Rappels bloquants :
Rust 2024
unsafe interdit
unwrap / expect / panic interdits selon les règles KSP
? interdit en production
retours explicites ; clippy::implicit_return deny
#![warn(missing_docs)]
#![deny(unreachable_pub)]
#![forbid(unsafe_code)]
pas de pub mod
pub/pub(crate) partagés reexportés via crate root
accès partagés via crate::Item, y compris intra-crate
item strictement module-local => private
unit tests sous unit_tests/
integration tests sous tests/
Après toute modification Rust :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
Pour tout Markdown touché :
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
Une commande non exécutée n'est jamais déclarée PASS.
3.2 Handoff stable 0.3.14
Lire intégralement :
prompts/033-V0_3_14_START_PROMPT.md
docs/plans/035-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING_PLAN.md
docs/validation/031-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING.md
deltas/0.3.14/pre.014.md
deltas/0.3.14/pre.015.md
deltas/0.3.14/pre.016.md
deltas/0.3.14/rel.001.md
crates/ksp-worker-raw-transaction-ingest-lib/README.md
crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md
Puis auditer le code réel de :
crates/ksp-worker-raw-transaction-ingest-lib/src/
crates/ksp-worker-raw-transaction-ingest-lib/tests/
crates/ksp-worker-raw-transaction-ingest-lib/unit_tests/
0.3.15 consomme le Worker finalisé ; il ne le recode pas dans l'application.
3.3 Config et composition
Lire :
crates/ksp-config-lib/README.md
crates/ksp-config-lib/USAGE.md
crates/ksp-config-lib/src/
config/std.transport.json
config/examples/std.transport.example.json
config/schemas/std.transport.schema.json
config/std.store.json
config/schemas/std.store.schema.json
config/composite.ksp-app-backfill-desk.json
config/composite.ksp-app-store-desk.json
.env.example
Inventorier réellement :
profils HTTP configurés
rôles HTTP et request_kinds
profils WS et protocol kind
profils Yellowstone gRPC
réseaux logiques
credentials/secrets requis
Store targets et réseau associé
mécanismes de composite/profil sélectionné
Ne pas confondre un exemple sous config/examples/ avec un profil réellement actif dans config/std.transport.json.
3.4 Transport et Worker runtime resources
Lire :
crates/ksp-onchain-transport-lib/README.md
crates/ksp-onchain-transport-lib/USAGE.md
crates/ksp-onchain-transport-lib/src/
crates/ksp-onchain-transport-lib/tests/
crates/ksp-worker-raw-transaction-ingest-lib/src/runtime.rs
crates/ksp-worker-raw-transaction-ingest-lib/src/runtime_resources.rs
crates/ksp-worker-raw-transaction-ingest-lib/src/snapshot.rs
Auditer précisément les constructeurs publics actuellement disponibles :
RawTransactionIngestRuntimeResources
RawTransactionIngestYellowstoneSource
RawTransactionIngestStandardLogsSource
RawTransactionIngestStandardBlockSource
RawTransactionIngestHeliusTransactionSource
RawTransactionIngestHttpBlockPollingSource
RawTransactionIngestWorker::start_with_runtime_resources
RawTransactionIngestHandle
RawTransactionIngestSnapshotSource
Le résultat de cet audit doit montrer, route par route, quelles capacités Transport/Config sont nécessaires pour construire le Worker sans bypass.
3.5 Store
Lire :
crates/ksp-store-lib/README.md
crates/ksp-store-lib/USAGE.md
crates/ksp-store-lib/src/
crates/ksp-store-api/src/
Le Desk dépend de ksp-store-lib, jamais de ksp-store-postgres-lib ni d'un client SQL.
Un run Worker et le Store doivent porter exactement le même réseau logique. mainnet reste l'identité KSP canonique ; mainnet-beta est uniquement un alias historique/externe lorsqu'il est accepté par une lower-layer.
3.6 Gabarit Desktop KSP
Le Desk doit reprendre le gabarit KSP actuel, jamais une application historique externe.
Lire au minimum :
crates/ksp-app-config-desk/
crates/ksp-app-wallet-desk/
crates/ksp-app-solprices-desk/
crates/ksp-app-backfill-desk/
crates/ksp-app-store-desk/
Préserver le pattern déjà décidé :
même splash KSP, seul le titre change
mêmes fonts
même style général
même discipline frontend/backend Tauri
tracing TypeScript des clics, boutons, tabs, filtres, refresh et IPC
aucun secret/endpoints sensibles dans les logs frontend
Le package.json doit au minimum partir du socle courant des Desk KSP, incluant lorsque toujours présent après audit :
@fltsci/tauri-plugin-tracing
@fortawesome/fontawesome-free
@tauri-apps/api
bootstrap
resize-observer-polyfill
simplebar
et les mêmes devDependencies de base compatibles que les Desk KSP actuelles. Ne pas lancer une mise à niveau opportuniste du workspace frontend sans justification de pre.001.
4. Sources externes à réauditer en pre.001
La Desk elle-même ne doit pas dépendre de connaissances provider codées depuis une page marketing. Néanmoins, si la construction d'une route dépend d'une capability Transport/provider dont la sémantique ou la disponibilité a changé, réauditer les sources primaires réellement actuelles :
Solana JSON-RPC / WebSocket pour méthodes/subscriptions utilisées
Yellowstone gRPC upstream pour Subscribe / replay réellement exposé
Helius pour la distinction standard WS vs transactionSubscribe/provider-specific lorsque nécessaire
PublicNode / OrbitFlare uniquement si un profil actif et un smoke réel les utilisent
Tauri 2 / plugins réellement employés si une adaptation desktop est nécessaire
Les résultats externes servent à qualifier les capabilities. Ils ne doivent jamais rendre sélectionnable une route que la Config locale ne peut pas composer.
5. État validé à préserver depuis v0.3.14
5.1 Worker
Préserver :
une admission/persistence Common RAW unique par Worker
five live source families existantes
hydratation globale/coalescence interne au Worker
idempotence et content conflict explicite
processing frontier distinct de continuity frontier
gaps run-local bornés
TargetCoverage conservative
reconnect != replay_attempt != replay_covered != repaired
fairness nominal/repair
shutdown/drain/abort+join borné
snapshots source-neutral avec gap observability
aucun Backfill automatique
5.2 Ownership
Préserver :
Config possède profiles/endpoints/secrets
Transport possède clients/sessions/retry/reconnect/resubscribe/replay natif
Worker possède logique continue RawTransaction, continuity et repair du run
Store possède persistence/idempotence/observations
Desk compose et supervise ; il ne réimplémente aucune de ces couches
5.3 Producteurs indépendants
Préserver :
ksp-worker-raw-transaction-ingest-lib = acquisition continue
ksp-job-backfill-lib = acquisition historique bornée/paramétrée
Worker -X-> Backfill
Backfill -X-> Worker
0.3.15 n'introduit aucune orchestration Backfill automatique depuis la Desk ingest.
6. Décisions acquises — ne pas redébattre sans contradiction réelle
release : 0.3.15
application : ksp-app-raw-transaction-ingest-desk
gabarit : Desk KSP courant
frontend : UI/DTO/actions sûres uniquement
backend Rust Tauri : composition Config + Transport + Store + Worker
route != source != endpoint
route = stratégie complète + ensemble de capabilities obligatoires
route sélectionnable uniquement si toutes ses requirements sont composables depuis Config
provider name seul != capability
composabilité Config != opérabilité runtime
validation réseau/connexion/capabilities réelles au Start
1 route sélectionnée = 1 Worker
pas 1 Worker par source physique
une route peut nécessiter plusieurs ressources Transport internes
plusieurs Workers/Routes peuvent écrire dans le même Store
pas de partage implicite des gaps/TargetCoverage entre Workers distincts
endpoints/secrets/handles restent Rust-only et hors IPC
Store via ksp-store-lib uniquement
aucun SQL/backend physique
aucune logique Backfill
7. Questions réellement ouvertes à trancher pendant pre.001
7.1 Catalogue exact des routes V1
Construire une matrice à partir des contrats réellement existants :
route_id stable
objectif de la route
network admissible
capabilities obligatoires
capabilities optionnelles
ressources Worker construites
source family interne
RAW-direct ou reference-bearing
hydration requirement
repair capabilities internes
raison de non-composabilité projetable en DTO sûr
Le catalogue V1 doit être borné aux routes réellement constructibles sans bypass.
7.2 Lieu du catalogue de routes
Auditer si le catalogue reste légitimement app-owned dans le backend Desk ou si un petit contrat réutilisable manque dans une lower-layer existante.
Règle :
ne pas créer une nouvelle crate intermédiaire par défaut
ne pas déplacer de logique d'ingestion vers l'app
si une extension lower-layer minimale est indispensable, la faire dans la crate propriétaire pendant 0.3.15 avec tests dédiés
7.3 Projection de capabilities Config
Décider comment obtenir une vue déterministe et sûre des capabilities configurées sans exposer :
URL
credential
secret metadata
header sensible
client Transport
Store URI
Si les APIs publiques Config/Transport ne permettent pas de déterminer proprement la composabilité d'une route, identifier l'extension minimale backend-neutral au lieu de parser arbitrairement le JSON Config depuis le frontend.
7.4 Sélection réseau
Décider l'UX exacte : réseau explicitement choisi parmi les configurations disponibles, ou réseau dérivé d'un composite/Store target sélectionné.
Dans tous les cas :
route.network == Worker.settings.network == Store.network
est obligatoire avant Start.
7.5 Multiples compositions pour une même route
Si plusieurs endpoints/rôles peuvent satisfaire une même route, décider avant UI lourde si :
Config/Transport choisit automatiquement selon priorités existantes
ou
le Desk expose plusieurs compositions logiques sûres
Le frontend ne doit pas devenir un éditeur de connexions physiques et ne reçoit pas les URLs.
7.6 Lifecycle de plusieurs Workers
Définir l'état applicatif pour :
0..N routes sélectionnées
0..N Workers actifs
Start individuel / Stop individuel
Start sélection globale éventuellement
fermeture application
route déjà Running
Start concurrent de deux routes
fault d'une route sans arrêt implicite des autres
Store partagé
Chaque handle doit rester associé de façon non ambiguë à un route_id applicatif sûr.
7.7 Validation finale réelle
Planifier les scénarios live réellement accessibles. Le Desk doit servir de validation système des couches existantes, mais aucun provider non provisionné ne reçoit un faux PASS.
8. Objectifs et livrables de 0.3.15
À la clôture, viser :
crate Tauri ksp-app-raw-transaction-ingest-desk intégrée au workspace
composite/config app dédié si réellement nécessaire
inventaire de routes source-neutral et borné
projection selectable / unavailable + raison sûre
sélection réseau cohérente
sélection d'une ou plusieurs routes
1 Worker réel par route sélectionnée
construction réelle des RawTransactionIngestRuntimeResources nécessaires
Start / Stop réels via ksp-worker-raw-transaction-ingest-lib
Store partagé via ksp-store-lib
snapshots Worker projetés vers l'UI sans données sensibles
lifecycle/health/activity/backpressure/reconnect/replay/gaps/repair visibles
fermeture application arrêtant/joinant proprement les Workers détenus
tracing frontend KSP
README/USAGE de l'application
plan + validation de release
gates Rust/frontend/Tauri complets
smokes live accessibles documentés
Une route marquée sélectionnable par l'UI doit être réellement constructible depuis la Config résolue ; une route incomplète reste désactivée avec une raison sûre.
9. Hors périmètre explicite
nouveau moteur Worker
nouvelle campagne historique
extension multi-stratégie Backfill 0.3.16
Worker par endpoint/source physique
partage de gap ledger entre Workers distincts
orchestrateur global de failover cross-Worker
scheduler durable de Workers
persistance des sélections/runs au-delà de ce que pre.001 décide explicitement
SQL/backend Store direct
lecture directe .env depuis l'app
saisie/édition de secrets dans le frontend
éditeur arbitraire d'endpoints provider
exposition URL/token/header/client handle via IPC
réimplémentation retry/reconnect/replay/hydration/discovery/persistence dans la Desk
nouveau provider SDK sans besoin prouvé
10. Contraintes sécurité, API et architecture spécifiques
10.1 IPC
Le frontend peut connaître des identifiants logiques sûrs, par exemple :
route_id
network
label
route family
selectable
unavailable reason code
Worker lifecycle/health
compteurs/snapshots déjà source-neutral
Il ne doit pas recevoir :
endpoint URL
API key/token
secret metadata
Store URI
Transport client/session
source key privée
transaction payload brut par simple monitoring
error text provider arbitraire
10.2 Availability
La disponibilité affichée doit distinguer clairement :
Unavailable / Not composable
Configured / Composable
Starting
Running
Stopping
Stopped
Faulted
Ne pas afficher Running ou Ready à partir de la seule présence d'une configuration.
10.3 Composition et validation
La composition affichée peut être calculée sans I/O réseau. Avant démarrage, le backend doit revalider la Config et reconstruire les ressources ; il ne fait jamais confiance à une sélection frontend obsolète.
Le Start doit échouer proprement si la configuration a changé ou si une ressource n'est plus valide.
10.4 Plusieurs Workers, même Store
Les routes actives écrivent dans le même Store logique lorsque leur réseau correspond. Les règles existantes de canonical identity, idempotence, observation et content conflict restent autoritaires.
Le Desk ne choisit jamais un « provider gagnant » et ne fusionne pas lui-même des RawTransactions.
11. Première mission 0.3.15-pre.001 — gate obligatoire
pre.001 doit rester essentiellement audit/planification. Produire avant tout scaffold lourd :
11.1 Inventaire réel
API publique Worker exacte
constructeurs RuntimeResources exacts
capabilities exigées par chaque famille Worker
APIs Config disponibles pour HTTP/WS/gRPC/Store
profils réellement committed vs exemples uniquement
mécanismes de rôles/priorités HTTP
kinds WS et protocoles gRPC
pattern de composition du Backfill Desk
pattern lifecycle/handle/snapshot dans les apps existantes
socle Tauri/TS/npm courant des Desk
11.2 Matrice route/capability
Produire une table complète :
Route
Network
Required capability
Optional capability
Config evidence
Worker constructor/resource
Composable aujourd'hui ?
Missing contract éventuel
Live-testable ?
Exiger au moins l'analyse de :
Yellowstone + HTTP hydration
Standard Logs + HTTP hydration
Standard Block direct
Helius transactionSubscribe + HTTP hydration
HTTP Block Polling
et distinguer explicitement une utilisation Helius en WS standard d'une route Helius transactionSubscribe provider-specific.
11.3 Audit gap
Classer chaque gap :
aucun gap
adaptation app seulement
extension Config minimale
extension Transport minimale
extension Worker minimale
split de release nécessaire
Une extension lower-layer réellement nécessaire peut appartenir à 0.3.15, mais elle doit rester minimale, propriétaire de sa sémantique et testée avant l'UI qui la consomme.
11.4 Gabarit et UX
Produire :
screen map
route list mock contract
states selectable/unavailable/running/faulted
Start/Stop flow
snapshot mapping UI
IPC DTO matrix
frontend tracing matrix
sans encore implémenter toutes les vues.
11.5 Sizing
Chaque tranche intermédiaire doit viser environ 15–20 minutes de travail effectif. Si une extension Config/Transport/Worker ou l'UI prévue rend la session trop grande, rescinder 0.3.15 avant l'implémentation lourde.
11.6 Livrables pre.001
Préparer au minimum :
docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
deltas/0.3.15/pre.001.md
Le plan doit fixer la prévision souple réelle après audit, et non recopier mécaniquement celle du présent prompt.
12. Prévision souple initiale des prereleases
Prévision de départ, à recalibrer en pre.001 :
pre.001 — audit / route model / sizing
Audit complet Config/Transport/Store/Worker/Desk, matrice route-capability, gaps, UX et plan.
pre.002 — contrats applicatifs de route et scaffold Desk
Créer la crate/app Tauri sur le gabarit KSP, DTO sûrs, route IDs/states et composite minimal sans Start Worker.
pre.003 — Config -> route inventory
Résoudre réseau/profils/capabilities et produire les routes composables/non composables avec raisons sûres ; aucune sonde réseau arbitraire.
pre.004 — composition RuntimeResources
Mapper chaque route réellement supportée vers ses ressources Worker/Transport sans bypass et revalider au Start.
pre.005 — Store + Start/Stop mono-route
Ouvrir Store via façade, lancer/arrêter un Worker réel pour une route et fermer proprement les ressources.
pre.006 — multi-route / un Worker par route
Gérer plusieurs routes sélectionnées, handles indépendants et Store partagé sans cross-Worker gap coordination.
pre.007 — snapshots / monitoring
Projeter lifecycle, health, activity, backpressure, reconnect/replay, gap/repair et compteurs sûrs.
pre.008 — frontend fonctionnel / tracing
Finaliser choix réseau/routes, Start/Stop, états, feedback, tracing frontend et ergonomie KSP.
pre.009 — races/security/hardening
Config change entre inventory et Start, double Start/Stop, fermeture app, fault isolé, secrets/IPC/redaction et bornes.
pre.010 — completeness / validation end-to-end
Canaris cross-layer Desk -> Config/Transport/Worker/Store, routes V1 complètes et scénarios système sans fake provider success.
pre.011 — gate technique/live/Tauri
Workspace complet, Clippy strict, tests all-targets/all-features, npm/tsc/vite/Tauri build et smokes live réellement accessibles.
pre.012 — réconciliation documentaire
README/USAGE, plan, validation, architectures réellement affectées. Pas de CHANGELOG/ROADMAP/prompt suivant.
pre.013 — préparation publication
Prompt 0.3.16, CHANGELOG, ROADMAP et mécanique de version/delta uniquement.
rel.001
Publication stable mécanique après gate validé.
Cette numérotation est une prévision, pas une contrainte. Insérer/séparer des tranches si pre.001 montre qu'un élément dépasse le budget ou appartient à une lower-layer.
13. Versionnement, deltas, commits, archives et tags
Appliquer docs/rules/VERSION_WORKFLOW.md.
Rappels :
prerelease Cargo : 0.3.15-pre.N
livraison : 0.3.15-pre.NNN
fix livraison : 0.3.15-pre.NNN-fix.NNN
fix Cargo code/runtime : 0.3.15-pre.N.fix.N
archive générale : ksp-general-<delivery-id>.zip
archive doc-only : ksp-doc-<delivery-id>.zip seulement si réellement limitée à docs/prompts
À partir de 0.1.x, chaque delta est commité. Aucun tag n'est requis pour prerelease/fix/rel. Après rel.001 validée :
commit : v0.3.15-rel.001
tag : v0.3.15
Le delta ZIP contient uniquement les fichiers ajoutés/modifiés de la livraison plus son delta ; aucun lockfile/cache/build output.
14. Procédure d'application et validation opérateur
Pour chaque delta :
partir exactement de la base requise
appliquer le ZIP à la racine du dépôt
vérifier le diff avant exécution
ne jamais recopier un worktree complet à la place du delta
ne jamais modifier silencieusement un delta déjà livré
Gate Rust minimal après modification :
cargo fmt --all
cargo fmt --all -- --check
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
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
Les tests ciblés suivent selon les crates modifiées.
15. Validations frontend/Tauri/réseau attendues
15.1 Rust/workspace
Avant fermeture technique :
cargo test --workspace --all-targets --all-features
cargo tree -p ksp-app-raw-transaction-ingest-desk --edges normal
cargo tree -p ksp-app-raw-transaction-ingest-desk -e features
cargo tree -p ksp-worker-raw-transaction-ingest-lib --edges normal
cargo tree --duplicates
15.2 Frontend
Depuis la crate Desk, exécuter réellement les commandes correspondant au package courant, typiquement :
npm run build
ou les commandes workspace réellement retenues après audit.
Le build frontend doit démontrer tsc/Vite sans réseau direct frontend, storage secret ou imports hors gabarit.
15.3 Tauri
Le gate final inclut :
cargo tauri build
pour la nouvelle Desk, avec bundles réellement supportés par l'environnement opérateur.
15.4 Live/system
Prévoir des scénarios réellement accessibles, par exemple :
route composable -> Start -> Running -> RawTransaction/observations progressent -> Stop propre
route Config incomplète -> non sélectionnable sans I/O
route composable mais endpoint runtime indisponible -> Start fault propre
plusieurs routes -> plusieurs Workers -> même Store -> observations/idempotence cohérentes
Les profils/provider-gated ne sont PASS que si les credentials et capacités correspondantes sont réellement disponibles et le test a été exécuté.
Un exemple PublicNode Mainnet ou Helius Devnet n'est jamais considéré prouvé uniquement parce qu'un profil/exemple Config existe.
16. Critères de clôture de 0.3.15
0.3.15 est clôturable seulement si :
ksp-app-raw-transaction-ingest-desk existe et build
route/source/endpoint sont distingués dans le modèle
catalogue V1 borné et documenté
toute route sélectionnable possède toutes ses capabilities Config obligatoires
aucune capability n'est déduite du seul provider
composabilité et opérabilité runtime sont distinguées
Config est revalidée au Start
1 route active = 1 Worker
aucun Worker par source physique imposé par la Desk
une route peut assembler plusieurs ressources Transport nécessaires
plusieurs Workers peuvent partager le même Store sans coordination de gaps cross-Worker
Start/Stop réel utilise ksp-worker-raw-transaction-ingest-lib
Transport/Config/Store ownership restent respectés
aucun endpoint/secret/Store URI ne traverse l'IPC
snapshots Worker utiles sont visibles sans source key privée
fault d'une route n'impose pas arbitrairement le fault des autres
fermeture app draine/arrête proprement tous les Workers détenus
aucun Backfill automatique
aucune persistence/RAW canonicalization réimplémentée dans la Desk
workspace/Clippy/tests/frontend/Tauri gates verts
smokes accessibles exécutés ou explicitement NON EXÉCUTÉ
README/USAGE/plan/validation réconciliés
prompt 0.3.16 produit dans la dernière prerelease
17. Release/session suivante envisagée
La trajectoire actuelle prévoit :
0.3.16
étendre ksp-job-backfill-lib et ksp-app-backfill-desk vers les stratégies historiques/catch-up multi-source réellement pertinentes
0.3.15 ne doit pas préimplémenter ce backfill. Le Desk ingest reste un gestionnaire de routes live continues.
18. Instruction d'ouverture
La prochaine session doit commencer par :
1. vérifier la base stable v0.3.14 et workspace.package.version = 0.3.14
2. lire les règles normatives dans l'ordre demandé
3. lire le handoff 0.3.14 et le Worker final
4. auditer Config HTTP/WS/gRPC + Store réellement committed
5. auditer les constructeurs RuntimeResources Worker et le pattern Backfill Desk
6. construire la matrice route -> capabilities -> Config evidence -> Worker resources
7. vérifier les Desk KSP servant de gabarit
8. brainstormer les gaps/frontières/risques
9. recalibrer la prévision des prereleases
10. produire plan 036 + validation 032 + delta pre.001
Ne pas commencer avant ce gate :
scaffold UI lourd
Start/Stop Worker
nouvelle API Config/Transport/Worker
nouveau provider
nouvelle logique de retry/hydration/repair
sauf correction triviale indispensable pour rendre l'audit lui-même exécutable.