34 KiB
Prompt de démarrage 0.3.7 — ksp-app-backfill-desk
1. Identité de la release et base exacte requise
Ouvrir cette session uniquement après publication et tag validés de :
v0.3.6
La base autoritaire est le dépôt stable v0.3.6 ou, si l'opérateur fournit une archive stable explicitement désignée comme base, cette archive exacte.
Vérifier avant tout travail :
workspace.package.version = 0.3.6
deltas/0.3.6/rel.001.md présent
ksp-job-api présent
ksp-job-backfill-lib présent
ksp-app-config-desk présent
ksp-app-wallet-desk présent
ksp-app-solprices-desk présent
La release à ouvrir est :
0.3.7
La première tranche est obligatoirement :
0.3.7-pre.001
pre.001 est un gate de lecture + audit + brainstorming + sizing + planification. Ne pas commencer par copier une application Tauri existante ni par écrire directement le frontend Backfill.
2. Mission et résultat attendu
Créer :
crates/ksp-app-backfill-desk
comme application Tauri KSP spécialisée pour lancer, observer, annuler et reprendre de manière contrôlée un ksp-job-backfill-lib, en composant les ressources nécessaires via ksp-config-lib.
L'application est un control/monitoring desk spécialisé. Elle ne réimplémente aucune logique Backfill et ne devient pas un navigateur Store généraliste.
Chaîne fonctionnelle attendue :
Config composite/profile
|
+--> Logging
+--> Transport HTTP settings
+--> Store settings
|
v
application backend
|
+--> HttpTransportPool
+--> Store
+--> BackfillRequest
+--> BackfillJobRuntime
|
+--> BackfillJobHandle.cancel()
+--> BackfillSnapshotSource latest-value
|
v
UI Tauri sûre
Résultat attendu à la clôture :
ksp-app-backfill-desk existe comme package Tauri Rust lib + bin
ports Vite/HMR dédiés 1436/1437
shell/splash/logging alignés sur le gabarit KSP courant
Config compose au minimum Logging + Transport + Store pour le Desk
un composite ksp-app-backfill-desk est packagé et validé
le backend construit HttpTransportPool + Store depuis Config
le backend construit BackfillRequest depuis des inputs UI bornés
le backend crée BackfillJobRuntime et conserve un BackfillJobHandle sûr
l'UI permet LatestAddress / BeforeAddress / AfterAddress / ExplicitSignatures
l'UI permet commitment, rôle HTTP logique, limites et concurrency dans les bornes publiques
l'UI affiche phase/lifecycle et snapshots latest-value sans parser les logs
l'UI affiche les compteurs sûrs réellement présents dans BackfillJobSnapshot
l'UI permet annulation coopérative
l'UI expose la frontier et le checkpoint de façon sûre
une reprise contrôlée est possible au moins dans la durée de vie de l'application
l'outcome terminal et le failure code sûr sont visibles
aucun payload RAW complet, secret, URL sensible, SQL ou backend physique n'est envoyé au frontend
aucun retry/rate-limit/provider dispatch n'est réimplémenté par l'application
aucune navigation générale RawTransaction/RawAccountState n'est ajoutée
tests Rust/desktop/security/composition verts
build Tauri final vert
README/USAGE/plan/validation réconciliés dans le couloir documentaire
3. Sources de vérité internes obligatoires — ordre de lecture
3.1 Gouvernance générale
Lire d'abord :
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 directement bloquants pour cette release :
Rust 2024
unsafe / 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 consommés via crate::Item
item seulement module-local => private
unit tests sous unit_tests/
integration tests sous tests/
ksp-logging-lib possède tracing KSP
ksp-config-lib possède documents/env/secrets
ksp-onchain-transport-lib possède réseau/providers/retries/rate limits
ksp-store-lib possède la façade Store backend-neutral
ksp-job-backfill-lib possède découverte/hydratation/frontier/checkpoint/runtime
application = composition + DTO/commands + UX
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/0.3.7
Une commande non exécutée n'est jamais déclarée PASS.
3.2 Architecture durable
Lire ensuite :
docs/architecture/000-README.md
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
Frontières acquises :
Job borné/terminable != Worker service continu
BackfillJobRuntime est single-run et composable
BackfillJobHandle suffit ; aucune ksp-job-control-lib générique
Transport possède les retries et le choix physique des endpoints
Store possède la persistance et l'idempotence physique
Config possède la composition de profils/documents/env/secrets
le Desk ne devient ni data plane ni source de vérité du backlog
applications spécialisées avant une future app globale
3.3 Clôture 0.3.6
Lire intégralement :
crates/ksp-job-api/README.md
crates/ksp-job-api/USAGE.md
crates/ksp-job-backfill-lib/README.md
crates/ksp-job-backfill-lib/USAGE.md
docs/plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md
docs/validation/023-V0_3_6_JOB_API_BACKFILL.md
deltas/0.3.6/rel.001.md
Puis inventorier le code réel :
crates/ksp-job-api/Cargo.toml
crates/ksp-job-api/src/lib.rs
crates/ksp-job-backfill-lib/Cargo.toml
crates/ksp-job-backfill-lib/src/lib.rs
crates/ksp-job-backfill-lib/src/request.rs
crates/ksp-job-backfill-lib/src/checkpoint.rs
crates/ksp-job-backfill-lib/src/discovery.rs
crates/ksp-job-backfill-lib/src/conversion.rs
crates/ksp-job-backfill-lib/src/persistence.rs
crates/ksp-job-backfill-lib/src/execution.rs
crates/ksp-job-backfill-lib/src/runtime.rs
crates/ksp-job-backfill-lib/tests/dependency_boundary.rs
crates/ksp-job-backfill-lib/tests/public_api.rs
crates/ksp-job-backfill-lib/tests/hardening.rs
crates/ksp-job-backfill-lib/tests/release_completeness.rs
Ne pas reconstruire les contrats depuis le souvenir du développement de 0.3.6. La surface stable réellement présente dans v0.3.6 est l'autorité.
3.4 Config et composition
Auditer :
crates/ksp-config-lib/src/lib.rs
crates/ksp-config-lib/src/composite.rs
crates/ksp-config-lib/src/registry.rs
crates/ksp-config-lib/src/packaging.rs
crates/ksp-config-lib/src/transport.rs
crates/ksp-config-lib/src/store.rs
config/std.logging.json
config/std.transport.json
config/std.store.json
config/schemas/std.logging.schema.json
config/schemas/std.transport.schema.json
config/schemas/std.store.schema.json
config/schemas/composite.schema.json
config/composite.ksp-app-wallet-desk.json
config/composite.ksp-app-solprices-desk.json
pre.001 doit déterminer le composite exact de Backfill Desk, attendu a priori sous la forme :
config/composite.ksp-app-backfill-desk.json
Le composite doit sélectionner les documents/profils nécessaires sans recopier leurs valeurs dans l'application.
Ne pas créer automatiquement un std.job_backfill.json. Les paramètres d'une campagne (scope, anchor, page size, max pages, max candidates, concurrency, etc.) sont d'abord des inputs opérationnels du Job. Un nouveau document Config n'est justifié que si pre.001 démontre un besoin durable de defaults/configuration partagé hors de l'état UI et sans déplacer l'ownership du contrat Backfill.
3.5 Gabarits desktop KSP actuels
Auditer au minimum :
crates/ksp-app-config-desk/Cargo.toml
crates/ksp-app-config-desk/tauri.conf.json
crates/ksp-app-config-desk/vite.config.ts
crates/ksp-app-config-desk/package.json
crates/ksp-app-config-desk/src/
crates/ksp-app-config-desk/frontend/
crates/ksp-app-config-desk/tests/
crates/ksp-app-wallet-desk/Cargo.toml
crates/ksp-app-wallet-desk/tauri.conf.json
crates/ksp-app-wallet-desk/vite.config.ts
crates/ksp-app-wallet-desk/package.json
crates/ksp-app-wallet-desk/src/
crates/ksp-app-wallet-desk/frontend/
crates/ksp-app-wallet-desk/tests/
crates/ksp-app-solprices-desk/Cargo.toml
crates/ksp-app-solprices-desk/tauri.conf.json
crates/ksp-app-solprices-desk/vite.config.ts
crates/ksp-app-solprices-desk/package.json
crates/ksp-app-solprices-desk/src/
crates/ksp-app-solprices-desk/frontend/
crates/ksp-app-solprices-desk/tests/
Déterminer le gabarit réellement courant à partir de la base stable, pas à partir d'un ancien prompt.
Ports réservés pour le nouveau Desk :
Vite 1436
HMR 1437
Ils doivent être stricts conformément à KSP-APP-024.
4. Référence historique kbot3 obligatoire — fonctionnelle uniquement
L'archive kbot3 fournie par l'opérateur doit être réauditée en pre.001 comme référence fonctionnelle et UX, jamais comme source de code.
Référence attendue :
khadhroony-bot3_v0.5.3-pre.005-fix010-thelatest1.zip
ou l'archive équivalente explicitement fournie par l'opérateur.
Inspecter en particulier :
kb-app-demo-desktop/src/demo_backfill.rs
kb-app-demo-desktop/frontend/demo_backfill.html
kb-app-demo-desktop/frontend/ts/demo_backfill.ts
kb-app-demo-desktop/README.md
kb-app-demo-desktop/USAGE.md
Fonctionnalités historiques à inventorier :
formulaire de campagne
mode adresse / signatures explicites
anchor + direction
commitment
rôle logique
page size / max pages / limit
concurrency
progression live
annulation
résumé terminal
compteurs inserted/existing/missing/failed/observations
cursor/reprise older-history
état single-run côté UI
Mais la matrice pre.001 doit classer chaque point :
REPRENDRE FONCTIONNELLEMENT
REDESSINER POUR KSP
REPORTER
REJETER
Exemples de divergences déjà connues à préserver :
kbot3 provider/endpoint UI -> ne pas recopier ; KSP Transport possède la source physique
kbot3 retry input -> ne pas recopier ; Transport KSP possède retry/pacing
kbot3 program/token/pool modes -> ne pas copier comme types ; KSP expose scopes génériques adresse/signatures
kbot3 resume_before string -> KSP possède BackfillCheckpoint opaque ; ne pas inventer un second cursor contract
kbot3 direct summary provenance -> n'exposer que ce que la façade KSP actuelle rend sûr et nécessaire
kbot3 Store browsing dans demo app -> hors scope ; futur ksp-app-store-desk 0.3.8
Interdictions :
copier le code Rust/TS/HTML kbot3
copier ses DTOs
copier ses commandes Tauri
copier ses anciennes abstractions Config/Store/Transport
copier les retry loops
copier ses IDs/defaults comme contrats KSP
faire du demo desktop monolithique la cible architecturale KSP
5. Sources externes à réauditer en pre.001
Cette release est une release desktop/Tauri. Réauditer les sources officielles actuelles avant toute mise à niveau ou choix de capability :
https://v2.tauri.app/
https://v2.tauri.app/reference/config/
https://v2.tauri.app/security/
https://v2.tauri.app/security/capabilities/
https://github.com/Aleph-Alpha/ts-rs
Réauditer les versions réellement courantes des dépendances utilisées par le gabarit :
tauri
tauri-build
tauri-plugin-tracing
ts-rs
@tauri-apps/api
@tauri-apps/cli
typescript
vite
bootstrap / datatables / simplebar / sass-embedded si réellement réutilisés
Ne pas mettre à niveau une dépendance parce qu'une version plus récente existe. Toute mise à niveau doit répondre à un besoin réel et être validée contre les Desks existants si elle touche un composant partagé.
Solana/provider/PostgreSQL n'ont pas à être réaudités pour dessiner l'UI tant que l'application consomme les façades stables. Un réaudit externe devient nécessaire uniquement si une contradiction réelle apparaît dans Transport/Store/Backfill.
6. État validé à préserver depuis v0.3.6
6.1 Job API
Conserver :
JobId / JobKindCode
JobState lifecycle
JobCancellationToken
JobNotificationSequence
JobNotification<S>
JobSnapshotSource
latest-value et terminal retained
Core-only dependency graph
aucun runtime Tokio dans ksp-job-api
6.2 Backfill
Conserver :
BackfillCommitment
BackfillSignature
BackfillScopeKind
BackfillScope
BackfillRequest
BackfillScopeFingerprint
BackfillCheckpoint
BackfillJobPhase
BackfillJobSnapshot
BackfillSnapshotSource
BackfillJobHandle
BackfillJobRuntime
Invariants :
identité logique transaction = network + signature
scope fingerprint indépendant provider/endpoint/rôle/JobId
checkpoint lié JobId + scope fingerprint
Latest/Before/After/Explicit ont des règles de reprise distinctes
Missing bloque frontier sans devenir conflit
Conflict reste distinct d'un succès idempotent
persistance déjà soumise toujours drainée
annulation coopérative pré-Store
snapshots sans payload RAW/secret/URL
6.3 Store / Transport / Config
Conserver :
Transport possède retry/reroute/rate-limit/provider/endpoint
Store possède backend/persistence/idempotence/tombstones
Config possède documents/env/secrets/composites
Backfill dépend de ksp-store-lib default-features=false
application ne dépend pas de ksp-store-postgres-lib ni ksp-store-api directement
7. Décisions acquises — ne pas redébattre sans contradiction réelle
Les décisions suivantes sont fermées :
nom exact : ksp-app-backfill-desk
application Tauri spécialisée
ports 1436/1437
package Rust lib + bin
tracing via gabarit KSP / tauri-plugin-tracing, jamais tauri-plugin-log
Config obligatoire pour composer les ressources runtime
composite Backfill Desk dédié
application mince ; logique Backfill reste dans ksp-job-backfill-lib
un premier Desk peut être single-active-run ; ne pas inventer un registry multi-job générique
BackfillJobHandle est la primitive de contrôle ; pas de ksp-job-control-lib en 0.3.7
latest-value snapshots sont la primitive d'observation ; ne pas parser les logs
aucun retry/rate-limit dans l'app
aucun SQL/backend physique
aucun provider SDK / reqwest direct
aucun Store browsing généraliste
aucun decode Program
aucun Worker API ou worker live
aucune application globale
Le futur ksp-app-store-desk de 0.3.8 possède la visualisation/requête détaillée des données Store.
Une future ksp-app-control-desk est encore plus tardive : elle sera une surface end-user résumée (actions essentielles, état global, recherche courante, erreurs importantes), jamais la copie exhaustive des fonctions avancées des Desk spécialisés.
8. Questions réellement ouvertes à trancher pendant pre.001
pre.001 doit répondre explicitement aux points suivants avant scaffold lourd.
8.1 Screen map
Définir la structure exacte entre :
sélection Config/composite
formulaire nouvelle campagne
état job actif
progression/compteurs
checkpoint/reprise
résumé terminal
erreurs/diagnostics sûrs
Ne pas multiplier les fenêtres/pages si un seul écran responsive suffit.
8.2 DTO / command map
Décider les DTO applicatifs nécessaires à Tauri.
Ils doivent être spécifiques à l'application et ne pas forcer serde/TS-RS dans ksp-job-api ou ksp-job-backfill-lib.
Déterminer notamment :
options/config summary DTO
request DTO
snapshot/progress DTO
terminal summary DTO
safe error DTO
cancel response
resume action
8.3 Rôle HTTP
BackfillRequest requiert un HttpRoleName logique.
pre.001 doit auditer le Transport résolu et décider comment présenter les rôles compatibles sans :
exposer URL/provider/secret
hardcoder history_backfill si la base Config ne le garantit pas
inventer un provider selector
8.4 Réseau
Le réseau du BackfillRequest doit rester cohérent avec le Store sélectionné et la composition Transport.
Décider comment projeter cette information en lecture seule à l'UI et comment rejeter une composition incohérente avant lancement.
8.5 Checkpoint/reprise
BackfillCheckpoint est opaque et non conçu comme document sérialisable public.
V1 doit au minimum permettre une reprise dans la durée de vie de l'application à partir du dernier checkpoint sûr détenu côté Rust.
Ne pas inventer un JSON de checkpoint, un fichier checkpoint ou une table Store sans évolution volontaire du contrat à la bonne couche. Si une persistance crash-safe devient nécessaire, la question doit être documentée/reportée ou faire l'objet d'une extension explicitement justifiée de Backfill dans une tranche dédiée, pas d'un hack DTO Tauri.
8.6 Single-run state
La base actuelle expose un runtime single-run et aucun registry Job global.
Le default attendu pour V1 est :
au plus une campagne active contrôlée par l'application
pre.001 doit confirmer le modèle de verrouillage/race : lancement concurrent, cancel pendant start/run/terminal, fermeture fenêtre/app et conservation du dernier snapshot.
8.7 Gate fonctionnel/live
Décider le gate réaliste :
tests déterministes obligatoires
cargo tauri build obligatoire en fermeture
smoke app + réseau/store opt-in seulement si un environnement dédié et sûr est disponible
Ne jamais rendre un accès payant ou un secret non disponible obligatoire pour clôturer l'application.
9. Objectifs et livrables de 0.3.7
9.1 Package application
Créer un package aligné sur les Desks actuels :
crates/ksp-app-backfill-desk/
Cargo.toml
build.rs si requis par le gabarit courant
src/lib.rs
src/main.rs
src/app_state.rs
src/bootstrap.rs
src/tauri.rs
frontend/
capabilities/
tauri.conf.json
package.json
vite.config.ts
tsconfig.json
Les noms de modules complémentaires sont décidés après le screen/DTO map de pre.001.
9.2 Config composite
Créer/packager le composite nécessaire, probablement :
config/composite.ksp-app-backfill-desk.json
Le composite doit référencer les documents existants utiles ; ne pas dupliquer leurs valeurs.
Le packaging runtime doit inclure les ressources réellement nécessaires selon le contrat Config stable.
9.3 Composition backend
Le backend Rust :
charge Config
résout composite
résout Logging
résout Transport
résout Store
construit HttpTransportPool
construit Store
valide cohérence réseau
construit BackfillRequest
crée BackfillJobRuntime
conserve handle + snapshot source
exécute le runtime sans bloquer la thread UI
Le mécanisme exact d'exécution asynchrone est à auditer contre le gabarit Tauri/Tokio courant. Ne pas introduire un second runtime global si Tauri fournit déjà le contexte nécessaire.
9.4 Formulaire Backfill
Surface minimale :
scope kind
address si scope adresse
anchor signature si Before/After
signatures multi-lignes si Explicit
commitment
rôle HTTP logique compatible
page size
max pages
max candidates
hydration concurrency
min_context_slot quand sémantiquement autorisé
Les bornes affichées/validées doivent provenir des constantes publiques de ksp-job-backfill-lib ou de DTOs backend calculés, pas d'une copie frontend divergente sans canari.
9.5 Monitoring
Afficher les champs réellement exposés par BackfillJobSnapshot :
phase
scope kind
discovery boundary
candidates selected/admitted/finished
entities inserted/existing/purged
missing
conflicts
observations inserted/existing
cancelled candidates
holes
maximum in-flight
contiguous completed
checkpoint present + completed prefix si projeté de manière sûre
failure code
Ne pas afficher de faux pourcentage si le dénominateur n'est pas sémantiquement connu.
9.6 Contrôle
Au minimum :
Start
Cancel
Resume from last safe checkpoint
Reset/new campaign lorsque terminal
Les boutons reflètent le lifecycle réel ; l'UI ne doit pas prétendre qu'une annulation est instantanée si le runtime draine encore une persistance Store déjà soumise.
9.7 UX et instrumentation
Respecter le gabarit KSP :
splash commun
header desk cohérent
responsive
états empty/ready/running/cancelling/completed/failed
messages d'erreur sûrs
instrumentation frontend systématique sans valeur sensible
aucun browser storage de secret
aucun native dialog non justifié
10. Hors périmètre explicite
Ne pas introduire dans 0.3.7 :
ksp-app-store-desk
navigation générale RawTransaction/RawAccountState
SQL/table names/backend diagnostics détaillés
ksp-worker-api
worker live
service daemon Backfill
generic Job registry / scheduler
ksp-job-control-lib
IPC remote Job générique
cron/scheduling de campagnes
retry Job
provider selection physique
provider SDK
nouveau protocole Transport
nouvelle migration Store
STRUCTURAL/DECODED/DOMAIN
Program decoding
materialization/replay N2/N3
application globale/control desk
persistence inventée du BackfillCheckpoint
historique durable multi-run sauf contrat existant réel
Une capacité utile mais hors scope est documentée, pas glissée dans l'application.
11. Contraintes sécurité, API et architecture spécifiques
11.1 IPC / DTO
Le frontend ne reçoit jamais :
Store connection URI
provider API key/token
URL secrète
environment secret
RawTransaction payload complet
RawTransactionObservation détaillée non nécessaire
objet Store/Transport/Runtime interne
Tokio sender/receiver
BackfillCancellationSignal interne
11.2 Logging
Le frontend peut logger :
action code
screen/control id
safe lifecycle state
safe error code
Il ne logge pas :
signature utilisateur complète si inutile
liste de signatures
adresse si la politique de l'app la considère comme payload métier non nécessaire au log
endpoint URL
provider credential
RAW bytes
11.3 Store
Le Desk ne fait pas :
read-before-write
ForceRehydrate
retention transition
SQL
backend feature selection directe
11.4 Transport
Le Desk ne fait pas :
retry loop
sleep/backoff
rate limit
automatic provider preference
endpoint URL parsing
request wire construction
11.5 Backfill
Le Desk ne recode pas :
discovery pagination
deduplication
canonical RAW conversion
observation key
frontier
checkpoint algorithm
terminal race
cancellation semantics
12. Première mission 0.3.7-pre.001 — gate obligatoire
pre.001 doit produire un audit et un plan, pas une application déjà figée.
12.1 Vérification base
Confirmer :
v0.3.6 / archive autoritaire
workspace version
gate stable précédent
surfaces publiques Job/Backfill
Config composites existants
gabarit Tauri actuel
ports déjà alloués
12.2 Audit dépendances
Construire la matrice envisagée :
ksp-app-backfill-desk
-> ksp-core-lib ? uniquement si DTO/app en a besoin réellement
-> ksp-logging-lib
-> ksp-config-lib
-> ksp-job-api ? seulement si l'app consomme directement ses types
-> ksp-job-backfill-lib
-> ksp-onchain-transport-lib ? uniquement pour composition runtime réellement nécessaire
-> ksp-store-lib ? uniquement pour composition runtime réellement nécessaire
Ne pas dépendre de :
ksp-store-api direct
ksp-store-postgres-lib
tokio-postgres
reqwest
tonic
yellowstone-grpc-proto
provider SDK
Le graphe exact doit être justifié par le code réel et les patterns des apps existantes.
12.3 Screen map
Produire un schéma écran/états explicite.
12.4 DTO/command map
Lister chaque commande Tauri, request DTO, response DTO et event/latest-value bridge envisagé.
Pour chacun :
owner
sensibilité
source de vérité
validation
raison d'existence
12.5 Config/composition map
Décrire :
composite file
logging profile
transport profile
store profile
network consistency
role inventory
resources packagées
startup failure behavior
12.6 Matrice kbot3
Produire la matrice :
capacité historique
preuve kbot3
équivalent KSP actuel
décision REPRENDRE/REDESSINER/REPORTER/REJETER
12.7 Threat model
Auditer :
secrets Config
endpoint URLs
Store URI
signatures/address payload
RAW transaction data
frontend logging
TS-RS DTOs
Tauri capabilities
race start/cancel/terminal
app close pendant run
12.8 Sizing
Chaque tranche intermédiaire doit viser environ 15–20 minutes de travail effectif. Si une tranche est manifestement trop large, la scinder avant implémentation.
12.9 Livrables pre.001
Créer au minimum :
docs/plans/<next>-V0_3_7_BACKFILL_DESK_PLAN.md
docs/validation/<next>-V0_3_7_BACKFILL_DESK.md
deltas/0.3.7/pre.001.md
Les numéros exacts de plan/validation sont déterminés depuis la base stable.
Critères de sortie de pre.001 :
lecture règles achevée
audit base réel achevé
audit kbot3 achevé
screen map explicite
DTO/command map explicite
Config/composition map explicite
dependency map explicite
threat model explicite
questions ouvertes tranchées ou reportées
forecast recalibré
aucune tranche > budget sans split
aucune implémentation Tauri lourde commencée
13. Prévision souple initiale des prereleases
Point de départ à recalibrer par pre.001 :
pre.001 audit/sizing + kbot3 matrix + screen map + DTO/commands + Config/composition + security
pre.002 scaffold ksp-app-backfill-desk + lib/bin + shell/splash/tracing + ports 1436/1437
pre.003 Config composite + packaging + bootstrap Logging/Transport/Store + network/role readiness
pre.004 DTOs/options + request form backend validation + four scopes + bounds
pre.005 runtime composition + single-active-run state + Start + latest-value snapshot bridge
pre.006 Cancel + terminal race UX + draining semantics + safe errors
pre.007 checkpoint/frontier projection + in-session Resume + scope-specific resume UX
pre.008 frontend polish/instrumentation/responsive + complete counters/status lifecycle
pre.009 integration/security/composition/hardening + release completeness
pre.010 gate technique final + cargo tauri build + smoke opt-in si environnement sûr disponible
pre.011 réconciliation documentaire finale
pre.012 prompt suivant + CHANGELOG + ROADMAP uniquement
rel.001 publication stable v0.3.7
Cette prévision est souple. Des fixes/tranches peuvent être insérés.
Les responsabilités finales restent séparées :
gate technique/Tauri
réconciliation documentaire
préparation minimale de publication
14. Versionnement, deltas, commits, archives et tags
Version Cargo :
0.3.7-pre.1
0.3.7-pre.2
...
0.3.7-pre.N.fix.M
Deltas :
deltas/0.3.7/pre.001.md
deltas/0.3.7/pre.002.md
...
deltas/0.3.7/pre.NNN-fix.MMM.md
deltas/0.3.7/rel.001.md
Commits :
v0.3.7-pre.001
v0.3.7-pre.002
v0.3.7-pre.NNN-fix.MMM
v0.3.7-rel.001
Aucun tag prerelease.
Publication stable uniquement :
v0.3.7
Archives :
ksp-general-<delivery-id>.zip
Le delta reste minimal. Toute modification réelle de fichier incrémente son header version.
Une correction strictement documentaire fix ne bump pas artificiellement workspace.package.version; une prerelease non-fix suit VER-ID-009.
15. Validation opérateur et commandes Tauri
Après chaque tranche Rust :
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.7
cargo check --workspace
cargo clippy --workspace --all-targets
Puis les tests ciblés de la tranche.
Application :
(cd crates/ksp-app-backfill-desk && cargo tauri dev)
(cd crates/ksp-app-backfill-desk && cargo tauri build)
Ne pas utiliser un -c crates/.../tauri.conf.json comme substitut au lancement depuis la crate ciblée.
Gates globaux de fermeture :
cargo test --workspace
Les cargo tree sont exécutés lorsque :
un Cargo.toml modifie dépendances/features
un cargo clean ponctuel justifie une revalidation du graphe
la tranche technique finale choisit explicitement le graphe comme gate
Ils ne sont pas ajoutés mécaniquement à chaque prerelease.
Au gate final Tauri :
(cd crates/ksp-app-backfill-desk && cargo tauri build)
Un build non exécuté n'est jamais déclaré PASS.
16. Tests attendus
16.1 Package / desktop contract
package lib + bin
ports 1436/1437 stricts
beforeDevCommand / beforeBuildCommand crate-local
splash/main lifecycle
header/backfill navigation
capabilities minimales
tracing ownership
public run entry point
resources packagées
16.2 Config/composition
composite Backfill Desk valide
Logging/Transport/Store profiles sélectionnés
secrets jamais projetés
wrong network rejected before run
missing/invalid role rejected safely
Store backend reste caché
16.3 Request mapping
LatestAddress
BeforeAddress + anchor
AfterAddress + anchor
ExplicitSignatures
empty/hostile signatures
page size bounds
max pages bounds
max candidates bounds
concurrency bounds
min_context_slot valid/invalid by scope
commitment mapping
role mapping
16.4 Runtime/control
single active run
concurrent start rejected
Created -> Running -> terminal projection
Cancel accepted before terminal
Cancel repeated idempotent
Cancel after terminal rejected
pre-Store cancellation visible
Store-drain semantics not misreported as immediate stop
snapshot latest-value coalescing
terminal snapshot retained
failure code safe
16.5 Checkpoint/resume
checkpoint presence projected without opaque internals
completed_prefix visible if safe
Resume uses backend-owned checkpoint object
Latest resume semantics
Before resume semantics
After prefix semantics
Explicit prefix semantics
no checkpoint serialization invented
reset/new campaign drops previous active control state safely
16.6 Frontend/security
no direct network fetch
no SQL
no Store URI
no provider URL/API key
no RAW payload
no secret browser storage
no native dialog unless justified
no parsing logs for progress
no hardcoded Backfill limits divergent from backend
safe frontend instrumentation
16.7 Tauri build
Gate final obligatoire :
(cd crates/ksp-app-backfill-desk && cargo tauri build)
Un smoke réel Config -> Transport -> Store -> Backfill peut être ajouté comme test ignoré/opt-in si pre.001 identifie un environnement sûr et reproductible. Il ne doit pas rendre une ressource payante obligatoire.
17. Critères de clôture de 0.3.7
La release devient stable seulement si :
ksp-app-backfill-desk existe et suit le gabarit KSP
ports 1436/1437 corrects
Config composite/backfill resources corrects
Transport et Store construits depuis Config
network consistency vérifiée
quatre scopes utilisables
bounds backend-owned respectées
Start fonctionne
latest-value monitoring fonctionne
Cancel fonctionne avec sémantique coopérative réelle
frontier/checkpoint visibles sans fuite interne
reprise in-session fonctionne
terminal outcome/failure sûrs
aucun provider/backend/SQL leak
aucun Store browsing généraliste
aucune logique retry/rate-limit dans l'app
aucun registry/scheduler Job générique inventé
security/dependency/completeness verts
workspace gate vert
cargo tauri build vert
smoke opt-in exécuté ou explicitement non requis selon décision pre.001
README/USAGE/plan/validation réconciliés dans la tranche documentaire dédiée
prompt 0.3.8 + CHANGELOG + ROADMAP finalisés seulement dans la dernière prerelease
aucun rattrapage dans rel.001
18. Release/session suivante envisagée
La release suivante décidée est :
0.3.8 — ksp-app-store-desk V1
Mission prévue :
application Tauri backend-agnostique
Config + ksp-store-lib
health/capabilities
RawTransaction
RawAccountState
observations
retention/tombstones
pagination/requêtes sûres
aucun SQL/backend direct
ksp-app-store-desk évoluera ensuite avec STRUCTURAL, DECODED, processing/materialization et DOMAIN.
Après elle :
0.3.9 ksp-worker-api
0.3.10 ksp-worker-raw-transaction-ingest-lib
0.3.11 ksp-app-raw-transaction-ingest-desk
La future ksp-app-control-desk reste différée jusqu'à un niveau N3/D3 exploitable et plusieurs decoders réels. Elle ne sera qu'une surface end-user simplifiée ; les détails avancés resteront dans les Desks spécialisés.
Ne pas anticiper 0.3.8 dans 0.3.7 en ajoutant un navigateur Store.
19. Instruction d'ouverture
Au début de la session 0.3.7 :
- confirmer la base stable
v0.3.6ou l'archive stable autoritaire ; - vérifier la version workspace et
deltas/0.3.6/rel.001.md; - lire les règles dans l'ordre de la section 3 ;
- relire architectures Jobs/Workers/Apps ;
- relire README/USAGE/plan/validation
0.3.6; - exécuter la baseline avant modification lourde ;
- inventorier les surfaces publiques réelles Job/Backfill ;
- auditer Config composite/Transport/Store ;
- auditer le gabarit Tauri courant et confirmer 1436/1437 ;
- auditer kbot3 uniquement comme référence fonctionnelle/UX ;
- produire la matrice kbot3 REPRENDRE/REDESSINER/REPORTER/REJETER ;
- produire le screen map ;
- produire le DTO/command map ;
- produire le Config/composition map ;
- produire le dependency map ;
- produire le threat model ;
- décider single-run lifecycle, role inventory, network validation et resume in-session ;
- décider le gate Tauri/live ;
- recalibrer chaque tranche au budget KSP ;
- créer plan, validation et
pre.001; - ne pas commencer le scaffold Tauri lourd ni copier le demo backfill kbot3 avant que ce gate soit cohérent.
La première réponse de travail de la nouvelle session doit être un audit/sizing 0.3.7-pre.001 complet avec matrice kbot3, screen map, DTO/commands, Config/composition, dépendances, sécurité et forecast recalibré — pas une application déjà scaffoldée.