Sasedev/khadhroony-solana-project

Fork 0

Files

SinuS Von SifriduS d32299ea18 v0.3.15-pre.018

2026-09-19 12:40:04 +02:00

26 KiB

Raw Permalink Blame History

Prompt de démarrage `0.3.16` — RAW resilience, variantes, conflits et récupération

1. Identité de la release et base exacte requise

Ouvrir uniquement 0.3.16 depuis la release stable/taggée :

v0.3.15

Ne pas démarrer depuis une prerelease intermédiaire 0.3.15-pre.* ou depuis une archive de travail non taggée.

La première livraison attendue est :

0.3.16-pre.001

pre.001 est obligatoirement un gate de lecture + audit Store/Worker/Transport/Config/Store Desk + audit des sémantiques RPC de complétude + brainstorming + sizing + planification. Il est interdit de commencer directement par une migration PostgreSQL, par de nouvelles tables de conflit ou par l'UI Store Desk avant fermeture de ce gate.

2. Mission et résultat attendu

Faire évoluer KSP afin qu'une divergence RAW ou une indisponibilité locale récupérable ne soit plus confondue avec une panne irréversible d'acquisition.

Le résultat cible doit permettre :

plusieurs producteurs/routes observent la même identité RAW
    -> Store compare les représentations
    -> Exact
       ou CompatibleLessComplete
       ou CompatibleMoreComplete
       ou Conflict

Exact
    -> idempotence / observation supplémentaire

CompatibleLessComplete
    -> canonique plus complet conservé
    -> observation conservée
    -> acquisition continue

CompatibleMoreComplete
    -> promotion atomique vers la variante plus complète
    -> ancienne variante conservée
    -> historique réversible
    -> acquisition continue

Conflict
    -> canonique courant conservé
    -> variante entrante conservée intégralement
    -> dossier de conflit durable ouvert/complété
    -> Worker continue en état dégradé plutôt que Faulted

La release doit également introduire une politique explicite et bornée pour :

Store temporairement indisponible
Transport temporairement indisponible / reconnexion

et étendre ksp-app-store-desk avec les vues et actions nécessaires à l'inspection/résolution/restauration des conflits RAW.

3. Principe directeur acquis

La règle centrale est :

une divergence de données != une panne d'acquisition

Une provenance provider n'est jamais une autorité canonique en soi.

La décision canonique porte sur une qualité de représentation prouvée, indépendamment :

de l'ordre d'arrivée
du provider
de la route productrice
du fait qu'une représentation est arrivée en premier

Aucune règle first-provider-wins, majorité provider, liste de providers prioritaires ou « Solana public a toujours raison » n'est admise.

4. Sources de vérité internes obligatoires — ordre de lecture

4.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 présent 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
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
unit tests sous unit_tests/
integration tests sous tests/

4.2 Handoff stable `0.3.15`

Lire intégralement :

prompts/034-V0_3_15_START_PROMPT.md
docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
docs/plans/037-V0_3_16_RAW_RESILIENCE_CONFLICT_HANDOFF.md

deltas/0.3.15/pre.014.md
deltas/0.3.15/pre.014-fix.001.md
deltas/0.3.15/pre.015.md
deltas/0.3.15/pre.015-fix.001.md
deltas/0.3.15/pre.016.md
deltas/0.3.15/pre.017.md
deltas/0.3.15/pre.018.md
deltas/0.3.15/rel.001.md

Lorsque rel.001.md n'est pas encore présent dans l'archive fournie à l'ouverture de la session, ne pas l'inventer : vérifier d'abord que la base est bien le tag stable v0.3.15 et utiliser le commit/tag comme autorité.

4.3 Store RAW

Lire et auditer réellement :

crates/ksp-store-api/README.md
crates/ksp-store-api/USAGE.md
crates/ksp-store-api/src/
crates/ksp-store-api/tests/

crates/ksp-store-lib/README.md
crates/ksp-store-lib/USAGE.md
crates/ksp-store-lib/src/
crates/ksp-store-lib/tests/

crates/ksp-store-postgres-lib/README.md
crates/ksp-store-postgres-lib/USAGE.md
crates/ksp-store-postgres-lib/src/
crates/ksp-store-postgres-lib/tests/
crates/ksp-store-postgres-lib/unit_tests/
crates/ksp-store-postgres-lib/resources/

Auditer en particulier :

RawTransaction / RawTransactionObservation
identité (network, signature)
content_hash et payload canonique
atomic insert canonical + observation
additional observation
content_conflict actuel
rétention Full / Archived / Purged / ForceRehydrate
inspection random-access Store Desk
migration registry V000/V001/V002 et règles de checksum
verrous / transactions / concurrence / cancellation
projection des erreurs backend vers store-lib/store-api

Ne pas casser les checksums des migrations stables existantes. Toute évolution physique est additive via une nouvelle migration/resource versionnée.

4.4 Common RAW et sémantique de comparaison

Lire :

crates/ksp-raw-transaction-lib/README.md
crates/ksp-raw-transaction-lib/USAGE.md
crates/ksp-raw-transaction-lib/src/
crates/ksp-raw-transaction-lib/tests/

Le RAW v1 canonique et ses golden bytes/hash restent des contrats acquis. 0.3.16 ne doit pas redéfinir arbitrairement la canonicalisation pour faire disparaître les conflits.

Le moteur de qualité doit comparer des représentations réelles et conserver leurs variantes. Il ne doit pas masquer une contradiction en normalisant deux payloads réellement distincts vers une valeur artificielle.

4.5 Worker live et acquisition

Lire :

crates/ksp-worker-api/
crates/ksp-worker-raw-transaction-ingest-lib/README.md
crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md
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/

docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md

Préserver les cinq familles live et le pipeline unique :

Yellowstone hydrated
Standard Logs hydrated
Standard Block direct
Helius Transaction hydrated
HTTP Block Polling direct

Transport
  -> Worker
  -> ksp-raw-transaction-lib
  -> ksp-store-lib

Le Worker et le Job Backfill restent des producteurs indépendants. 0.3.16 ne crée aucun edge Worker -> Job ni Job -> Worker.

4.6 Transport et Config

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-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

Auditer les politiques de retry/reconnect déjà existantes avant d'ajouter de nouveaux réglages. Ne pas introduire une seconde politique concurrente si un contrat Transport peut être étendu proprement.

4.7 Store Desk

Lire :

crates/ksp-app-store-desk/README.md
crates/ksp-app-store-desk/USAGE.md
crates/ksp-app-store-desk/src/
crates/ksp-app-store-desk/src/frontend/
crates/ksp-app-store-desk/tests/
crates/ksp-app-store-desk/package.json

Préserver les règles du gabarit Desk KSP :

même architecture lib.rs exports-only / tauri.rs bridge / modules spécialisés
frontend Vite + TypeScript
tracing frontend des actions sans valeurs sensibles
DataTables serverSide lorsque pertinent
aucun SQL / backend PostgreSQL / endpoint / secret dans l'application
ksp-store-lib = seule façade Store consommée par la Desk
pas de npm run build comme gate manuel ; utiliser le workflow Tauri/Vite du projet

5. Sources externes normatives à réauditer en `pre.001`

La fraîcheur et la sémantique exacte importent. Réauditer les sources officielles actuelles avant de généraliser les règles de complétude :

Solana / Agave RPC getTransaction et getBlock
TransactionStatusMeta / UiTransactionStatusMeta
sémantique de logMessages et du marqueur Log truncated
innerInstructions
loadedAddresses
returnData
computeUnitsConsumed
costUnits
preTokenBalances / postTokenBalances
rewards
champ absent vs null vs liste vide vs valeur présente
maxSupportedTransactionVersion

Lorsque nécessaire, vérifier aussi la source Agave/runtime responsable de la troncature des logs afin de prouver la relation exacte au lieu de déduire une règle à partir d'un seul provider.

Pour PostgreSQL, réauditer la documentation officielle des mécanismes réellement retenus pour :

transactions
SELECT ... FOR UPDATE
UPSERT / ON CONFLICT
contraintes d'unicité
indexation
isolation / concurrence
DDL/migrations additives

Toute conclusion externe doit être traduite en canari KSP et documentée. Une hypothèse non prouvée reste fail-closed.

6. État validé de `0.3.15` à préserver

0.3.15 fournit déjà :

Raw Transaction Ingest Desk multi-route
1 Worker indépendant par route sélectionnée
Store partagé par plusieurs routes du même réseau
inventaire capability-driven
Start/Stop ciblé
monitoring lifecycle/health/activity/backpressure/reconnect/replay/gaps/repair
cinq familles live

Le live Mainnet de référence a validé Yellowstone + HTTP Block Polling environ dix-neuf minutes en parallèle, sans grpc_backpressure_overflow, sans route Faulted, puis avec Stop propre Stopped/Healthy pour les deux routes.

Yellowstone Block final :

gRPC Block = trigger
include_transactions = false
HTTP getBlock = Full/Base64
maxSupportedTransactionVersion = 1
rewards = false

La saturation de la queue d'updates Yellowstone applique une backpressure bornée/asynchrone vers le stream au lieu d'un overflow local terminal. Un Status reçu après half-close local pendant un Stop explicite est traité comme fermeture coopérative ; le même grpc_status observé pendant une session active reste une vraie faute/reconnexion.

Store sait déjà accepter le cas étroit :

canonique complet déjà stocké
+
incoming dont seule la liste logMessages est explicitement tronquée
+
relation de troncature strictement prouvée
=> observation acceptée
=> canonique inchangé
=> pas de content_conflict terminal

Le sens inverse n'est pas encore implémenté.

7. Décisions acquises pour les variantes RAW

Le modèle conceptuel cible est :

RawTransaction identity (network, signature)
    |
    +-- Variant A  <- canonical current
    |      +-- observations/provenances
    |
    +-- Variant B
    |      +-- observations/provenances
    |
    +-- Variant C
           +-- observations/provenances

Conflict case
    +-- status
    +-- canonical variant
    +-- classification
    +-- resolution history

Les noms physiques exacts sont à décider après audit pre.001, pas avant.

Une variante doit représenter une représentation effectivement reçue ou une variante synthétique explicitement marquée comme telle. Une promotion ne détruit jamais la variante précédemment canonique.

Exemple :

A canonical
B alternate

promote B
=> A conservé
=> B devient canonical
=> historique A -> B

restore A plus tard
=> historique B -> A
=> aucune reconstruction externe nécessaire

8. Classification de convergence cible

Le comparateur partagé vise au minimum :

Exact
CompatibleLessComplete
CompatibleMoreComplete
Conflict

Règles :

Exact
    -> contenu équivalent
    -> observation idempotente ou supplémentaire

CompatibleLessComplete
    -> incoming prouvé moins complet
    -> canonique conservé
    -> incoming/observation conservés selon le modèle retenu

CompatibleMoreComplete
    -> incoming domine le canonique sans contradiction
    -> promotion atomique
    -> ancien canonique conservé comme variante

Conflict
    -> aucun ordre de qualité sûr
    -> canonique courant conservé
    -> incoming conservé comme variante
    -> dossier conflict durable

La qualité est une relation partielle, pas nécessairement un ordre total.

Si une représentation est plus complète sur un champ mais moins complète sur un autre, elle peut être Incomparable conceptuellement et doit rester fail-closed tant qu'aucune règle de fusion sûre n'existe.

Il est interdit de fabriquer automatiquement une représentation « best-of-fields » qui n'a été retournée par aucune source, sauf mécanisme de fusion explicitement défini, audité et marqué comme synthétique.

9. Politique champ par champ — prudence obligatoire

logMessages est le seul premier cas déjà démontré en live.

Pour tout autre champ, pre.001 doit distinguer :

absence informationnelle
absence structurelle / mode de sérialisation
null métier
liste vide métier
champ non disponible historiquement
champ dépendant de la version transaction/node
contradiction réelle

Ne jamais considérer automatiquement :

absent == null
null == []
[] == valeur tronquée
valeur la plus longue == meilleure
provider X == vérité

Les scalaires présents avec deux valeurs différentes restent Conflict sauf contrat normatif contraire explicitement prouvé.

Les listes différentes restent Conflict sans relation formelle de préfixe/troncature/complétude propre à ce champ.

10. Conflits durables et santé Worker

Un conflit durablement stocké ne doit plus arrêter le Worker :

content conflict
    -> variant persisted
    -> conflict case unresolved
    -> acquisition continue
    -> Worker Running
    -> health Degraded

Le health model et les snapshots doivent rester source-neutral et redacted. Évaluer au minimum les compteurs conceptuels :

unresolved_content_conflict_count
auto_resolved_conflict_count
canonical_promotion_count

Le nom final de chaque compteur appartient à l'audit/API design pre.001.

La complétude doit pouvoir distinguer :

acquisition_complete
    = les données attendues ont été durablement capturées, variantes comprises

canonical_complete
    = aucune obligation de réconciliation canonique n'est ouverte

Un conflit sur une identité ne doit pas bloquer l'acquisition des autres identités.

Le futur RAW -> STRUCTURAL décidera séparément si une identité canonical_complete=false peut être matérialisée ; ne pas implémenter STRUCTURAL dans 0.3.16.

11. Store retry et backpressure

Un Store indisponible n'est pas équivalent à un content conflict.

Le Worker ne doit jamais :

continuer à consommer indéfiniment sans durabilité
jeter silencieusement les RAW
présenter une persistence échouée comme acquisition réussie

Auditer puis définir une politique Store bornée :

classification transient / terminale
pause ou backpressure admission
retry borné ou illimité seulement si explicitement configuré
délai initial
backoff
max delay
budget/tentatives
reset après stabilité si pertinent
observabilité Degraded / Blocked
terminal uniquement sur politique épuisée ou erreur structurelle

La propriété essentielle est :

pas de perte silencieuse

Si le Store bloque suffisamment longtemps pour saturer l'acquisition, la pression doit remonter de manière bornée/cohérente au lieu de créer une queue non bornée.

12. Reconnexion Transport configurable

La politique Transport est distincte de la politique Store.

Auditer les réglages existants pour HTTP, WebSocket et Yellowstone avant d'ajouter une surface commune ou spécialisée.

Paramètres conceptuels à étudier :

initial_delay
max_delay
backoff_multiplier
max_attempts
reset_after_stable_duration
jitter borné

Une perte de connexion ne doit pas rendre le Worker terminal immédiatement tant que la politique de reconnexion autorise une reprise.

Inversement, une reconnexion n'est jamais une preuve de coverage : les gaps/replay/repair 0.3.14 restent responsables de la continuité.

13. `ksp-app-store-desk` — conflits et historique

Étendre Store Desk via ksp-store-lib uniquement.

Prévoir au minimum des surfaces autour de :

RAW Conflicts
RAW Conflict History / Resolution History

Pour une identité conflictuelle, l'UI doit pouvoir présenter de manière bornée :

variante canonique actuelle
variantes alternatives
différences structurées
provenances/observations
statut du conflit
historique des promotions/résolutions
origine native ou synthétique d'une variante

Actions visées, après audit des contrats :

Promote variant
Keep current canonical + Resolve
Restore previous canonical
Reopen conflict
Assisted merge pour champs explicitement compatibles

Une fusion manuelle doit créer une nouvelle variante explicitement manual/synthetic avec ses parents. Elle ne modifie pas silencieusement une variante provider existante et ne prétend pas être une observation provider native.

Éviter un éditeur JSON libre comme mécanisme principal de résolution. Les actions doivent être structurées et typées autant que possible.

14. Frontières de crates et sécurité

Responsabilités cibles :

ksp-store-api
    DTO/contrats backend-neutral variantes, conflits, résolution, inspection

ksp-store-lib
    façade unique consommée par Worker/Job/Desk
    moteur de convergence backend-neutral seulement si cela respecte l'ownership audité

ksp-store-postgres-lib
    schema/migrations/SQL/transactions/verrous/indexes
    atomicité physique variantes/promotions/résolutions

ksp-worker-raw-transaction-ingest-lib
    pipeline live
    ne fault plus sur conflit durable correctement persisté
    health/compteurs/retry orchestration selon ownership réel

ksp-onchain-transport-lib
    reconnexion réseau et backpressure Transport

ksp-config-lib
    configuration typée des politiques retenues

ksp-app-store-desk
    inspection/résolution via ksp-store-lib uniquement

Interdictions :

aucun SQL dans Worker/Desk
aucun backend PostgreSQL direct dans Worker/Job/Desk
aucune dépendance Job <-> Worker
aucun endpoint/token/signature/payload dans logs sûrs
aucune queue non bornée
aucun overwrite destructif d'une ancienne variante
aucune décision canonique par nom de provider
aucune baisse de qualité canonique automatique

Les opérations manuelles doivent être auditables. Une résolution doit conserver l'identité de l'action et son résultat sans exiger d'exposer de secret ou de payload arbitraire dans les logs.

15. Première mission `pre.001` — audit, brainstorming et sizing

Avant toute implémentation :

reconstruire/auditer la base stable v0.3.15 et confirmer les gates de fermeture ;
inventorier exactement les APIs Store RawTransaction actuelles et les outcomes d'écriture ;
inventorier les tables/migrations PostgreSQL actuelles, clés, FK, index, contraintes, rétention et transactions ;
tracer le chemin actuel Worker -> Store lorsqu'un content_conflict survient ;
tracer les chemins d'erreur Store temporaire/terminal et la façon dont ils affectent admission/drain/health ;
inventorier toutes les politiques retry/reconnect Transport existantes et leurs propriétaires ;
inventorier les DTOs/queries Store Desk disponibles pour ajouter conflits/variantes sans bypass ;
réauditer les sémantiques officielles des champs TransactionStatusMeta avant toute règle de complétude hors logMessages ;
proposer au moins deux modèles physiques raisonnables pour variantes/conflits/résolutions, avec analyse atomicité/rétention/concurrence ;
décider si l'identité physique d'une variante repose sur content_hash, un id surrogate, ou une combinaison, sans confondre hash et preuve d'égalité ;
décider comment les observations se rattachent à la variante réellement reçue ;
décider comment Full/Archived/Purged/ForceRehydrate interagit avec les variantes et conflits ;
définir la machine d'état d'un conflict case et l'historique de résolution ;
définir le modèle de dominance/qualité et les cas Exact/Less/More/Conflict/Incomparable internes nécessaires ;
définir les métriques/health source-neutral ;
définir la politique Store retry et la politique Transport reconnect sans les mélanger ;
découper la release en prereleases réellement tenables dans le budget KSP ;
créer/réviser un plan dédié 0.3.16 et un document de validation avant l'implémentation lourde.

Le gate pre.001 ne doit pas créer une migration finale « pour avancer ». Il peut créer des documents, tests de caractérisation et POC strictement nécessaires au choix architectural, conformément aux règles de la base.

Critères de sortie pre.001 :

modèle conceptuel validé
frontières de crates validées
migration strategy validée sans casser V000/V001/V002
sémantique de qualité logMessages prouvée
politique pour les autres champs explicitement conservative
Store retry ownership décidé
Transport reconnect ownership décidé
Store Desk scope décidé
risques/races/rétention identifiés
prévision souple des prereleases publiée
hors-périmètre explicite

16. Prévision souple initiale des prereleases

Cette prévision est un point de départ, à recalibrer en pre.001. Ne jamais fusionner artificiellement des tranches pour respecter ces numéros.

pre.001  audit complet, sémantiques externes, modèles physiques, sizing et plan
pre.002  contrats Store API backend-neutral pour variantes/conflits/résolutions
pre.003  migration PostgreSQL additive + mapping backend des variantes/conflits
pre.004  moteur de comparaison/dominance, logMessages bidirectionnel et atomicité promotion
pre.005  persistence Conflict : quarantine durable, observations par variante, races/concurrence
pre.006  inspection Store API/lib des variants/conflicts/history + rétention/rehydration hardening
pre.007  Worker : conflit durable non terminal, health Degraded et compteurs source-neutral
pre.008  Store transient failure : retry/backpressure/blocked health sans perte silencieuse
pre.009  Transport reconnect configurable et Config associée, sans inventer de coverage
pre.010  Store Desk backend : queries/actions de conflits et résolutions
pre.011  Store Desk frontend : vues conflicts/history, promote/keep/restore/reopen
pre.012  fusion assistée/synthétique strictement bornée si les règles prouvées la permettent
pre.013  hardening cross-layer : concurrence, cancellation, retention, rollback, security/redaction
pre.014  preuves live PostgreSQL/Store + routes Worker sous conflits/retry/reconnect réellement testables
pre.015  gate technique/live final : workspace, graphes, bundles/smokes pertinents
pre.016  réconciliation documentaire finale
pre.017  préparation de publication : CHANGELOG + ROADMAP + prompt 0.3.17
rel.001  publication stable mécanique

Si pre.001 démontre qu'une tranche intermédiaire dépasse le budget d'environ 15–20 minutes de travail effectif, elle doit être scindée et les numéros suivants décalés. Les trois responsabilités finales restent dans l'ordre : technique/live -> documentation -> publication.

17. Hors périmètre de `0.3.16`

Ne pas inclure :

0.3.17 : transformation de ksp-job-backfill-lib en moteur multi-route/multi-stratégie
0.3.18 : adaptation de ksp-app-backfill-desk au Backfill multi-route
RAW -> STRUCTURAL / persistence STRUCTURAL
DECODED / DOMAIN
majority voting provider
priorité canonique codée par provider
fusion libre de JSON arbitraire
reconstruction d'une variante perdue depuis Internet comme mécanisme normal de rollback
nouveau second pipeline d'acquisition
nouvelle dépendance Worker <-> Backfill

Le Job Backfill continue cependant à utiliser les contrats Store communs existants. Si la migration de schéma 0.3.16 exige une compatibilité mécanique pour que le Job actuel continue de fonctionner, cette compatibilité appartient naturellement à 0.3.16; elle ne doit pas être confondue avec le multi-route 0.3.17.

18. Versionnement, deltas, validation et instruction d'ouverture

Respecter strictement docs/rules/VERSION_WORKFLOW.md.

Chaque changement code/build/runtime/config bump la version workspace. Les deltas sont livrés comme archives minimales :

ksp-general-0.3.16-pre.NNN.zip
ksp-general-0.3.16-pre.NNN-fix.NNN.zip

Les commandes de validation doivent être choisies selon la tranche et enregistrées dans son delta. Après toute modification Rust :

cargo fmt --all
cargo fmt --all -- --check
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings

Pour tout Markdown touché :

python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas

Les tests ciblés doivent être préférés pendant le développement ; le workspace complet appartient aux gates appropriés. Les smokes/live PostgreSQL/provider sont uniquement revendiqués lorsqu'ils sont réellement exécutés avec les ressources correspondantes.

Pour les applications Desk, ne pas utiliser npm run build comme gate manuel. Le workflow Tauri/Vite du projet reste l'autorité, par exemple :

(cd crates/ksp-app-store-desk && cargo tauri dev)
(cd crates/ksp-app-store-desk && cargo tauri build)

Une commande non exécutée n'est jamais déclarée PASS.

Instruction d'ouverture de la prochaine session

Commencer par :

1. vérifier que la base est exactement le tag stable v0.3.15 ;
2. lire toutes les sources internes de la section 4 dans l'ordre ;
3. réauditer les sources externes de la section 5 ;
4. exécuter la mission pre.001 de la section 15 ;
5. publier le plan/sizing avant toute migration ou développement lourd.

Ne pas commencer par créer les tables conflicts/variants, modifier le Worker ou dessiner l'UI Store Desk avant d'avoir fermé le gate pre.001.

La release suivante envisagée après fermeture stable de 0.3.16 est :

0.3.17 — ksp-job-backfill-lib multi-route / multi-stratégie

26 KiB Raw Permalink Blame History Unescape Escape

Prompt de démarrage 0.3.16 — RAW resilience, variantes, conflits et récupération

1. Identité de la release et base exacte requise

2. Mission et résultat attendu

3. Principe directeur acquis

4. Sources de vérité internes obligatoires — ordre de lecture

4.1 Gouvernance générale

4.2 Handoff stable 0.3.15

4.3 Store RAW

4.4 Common RAW et sémantique de comparaison

4.5 Worker live et acquisition

4.6 Transport et Config

4.7 Store Desk

5. Sources externes normatives à réauditer en pre.001

6. État validé de 0.3.15 à préserver

7. Décisions acquises pour les variantes RAW

8. Classification de convergence cible

9. Politique champ par champ — prudence obligatoire

10. Conflits durables et santé Worker

11. Store retry et backpressure

12. Reconnexion Transport configurable

13. ksp-app-store-desk — conflits et historique

14. Frontières de crates et sécurité

15. Première mission pre.001 — audit, brainstorming et sizing

16. Prévision souple initiale des prereleases

17. Hors périmètre de 0.3.16

18. Versionnement, deltas, validation et instruction d'ouverture

Instruction d'ouverture de la prochaine session

26 KiB

Raw Permalink Blame History

Prompt de démarrage `0.3.16` — RAW resilience, variantes, conflits et récupération

4.2 Handoff stable `0.3.15`

5. Sources externes normatives à réauditer en `pre.001`

6. État validé de `0.3.15` à préserver

13. `ksp-app-store-desk` — conflits et historique

15. Première mission `pre.001` — audit, brainstorming et sizing

17. Hors périmètre de `0.3.16`