v0.3.14-pre.016
This commit is contained in:
972
prompts/034-V0_3_15_START_PROMPT.md
Normal file
972
prompts/034-V0_3_15_START_PROMPT.md
Normal file
@@ -0,0 +1,972 @@
|
||||
<!-- file: prompts/034-V0_3_15_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
0.3.15
|
||||
```
|
||||
|
||||
Première livraison attendue :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
route exige Yellowstone gRPC + HTTP getTransaction
|
||||
gRPC disponible = oui
|
||||
HTTP compatible = non
|
||||
=> route NON SÉLECTIONNABLE
|
||||
```
|
||||
|
||||
Autre exemple :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets
|
||||
```
|
||||
|
||||
Pour tout Markdown touché :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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é :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
@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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
route_id
|
||||
network
|
||||
label
|
||||
route family
|
||||
selectable
|
||||
unavailable reason code
|
||||
Worker lifecycle/health
|
||||
compteurs/snapshots déjà source-neutral
|
||||
```
|
||||
|
||||
Il ne doit pas recevoir :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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 :
|
||||
|
||||
```text
|
||||
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.
|
||||
Reference in New Issue
Block a user