# Prompt de démarrage `0.3.2` — Store/PostgreSQL runtime foundation ## 1. Identité de la release et bases exactes requises La base KSP attendue est **exclusivement** la release stable : ```text v0.3.1 ``` La release à ouvrir est : ```text 0.3.2 — Store/PostgreSQL runtime foundation ``` La première tranche est : ```text 0.3.2-pre.001 ``` Deux archives sont requises au démarrage : ```text 1. archive opérateur correspondant exactement à KSP v0.3.1 2. archive historique khadhroony-bot3_v0.5.3-pre.005-fix010.zip ``` Ordre d'autorité : ```text v0.3.1 réelle / archive opérateur autorité KSP actuelle règles + architecture de v0.3.1 autorité normative et architecturale plan + validation 0.3.1 autorité sur les contrats Store API acquis PostgreSQL/tokio-postgres actuels autorité externe sur les comportements présents khadhroony-bot3 historique source d'audit/héritage uniquement anciens prompts / snippets / mémoire auxiliaires seulement ``` L'archive kbot3 reste obligatoire pour `pre.001`, mais l'audit n'a pas à répéter mécaniquement tout `0.3.1`. Il doit rouvrir les parties physiques pertinentes : ancien runtime Store, configuration, connexion PostgreSQL, migrations, schema/versioning, health/readiness, erreurs, pool et stratégie d'intégration. Si l'archive historique n'est pas disponible : ```text ne pas inventer son contenu depuis la mémoire ne pas déclarer l'audit d'héritage physique terminé ne pas figer le mécanisme final de migrations/bootstrap ``` Ne pas ouvrir `0.3.2` depuis : ```text 0.3.1-pre.* 0.3.1-pre.*-fix.* 0.3.1-rel.* non encore validé stable une archive intermédiaire de travail khadhroony-bot3 comme base de code un souvenir de session ``` À l'ouverture, vérifier au minimum : ```text tag Git v0.3.1 si metadata Git disponible workspace.package.version = 0.3.1 deltas/0.3.1/rel.001.md présent prompts/021-V0_3_2_START_PROMPT.md présent ksp-store-api présent ksp-store-lib absent sauf contradiction de la base réelle ksp-store-postgres-lib absent sauf contradiction de la base réelle archive khadhroony-bot3_v0.5.3-pre.005-fix010.zip disponible ``` Si une divergence existe entre ce prompt et la base stable réelle, **la base stable réelle gagne** et la divergence devient une sortie explicite de `pre.001`. `pre.001` est obligatoirement une tranche de **lecture + audit + brainstorming + threat model + dependency graph + sizing + planification**. Aucune implémentation lourde de connexion, pool, TLS, migration ou Config Store ne commence avant la sortie cohérente de ce gate. --- ## 2. Mission et résultat attendu `0.3.2` introduit ensemble : ```text ksp-store-lib ksp-store-postgres-lib ``` mais **uniquement comme fondation runtime/backend PostgreSQL**. La séparation durable est : ```text ksp-store-api contrats backend-agnostic persistants ksp-store-lib façade/runtime Store commune sélectionne uniquement les backends compilés feature postgres activée par défaut ksp-store-postgres-lib backend PostgreSQL officiel de référence dépend de ksp-store-api ne dépend jamais de ksp-store-lib possède seul driver / pool / TLS / SQL / migrations physiques ``` Le résultat attendu à la clôture est une fondation réelle capable de : ```text construire des Store settings indépendants de Config sélectionner explicitement un backend compilé ouvrir et fermer proprement le runtime Store ouvrir une connexion/pool PostgreSQL réellement fonctionnel initialiser et vérifier la fondation de migrations/schema sans tables RAW métier rejeter proprement un backend connu mais non compilé recevoir la Config effective uniquement depuis ksp-config-lib ne lire directement aucun .env / KSP_* / KSPB_* / PG* / .pgpass dans Store/backend fournir des erreurs et diagnostics sans URI/credential/SQL parameter sensible prouver la fondation sur un PostgreSQL réel dans un test opt-in isolé et non destructif ``` `0.3.2` **ne doit pas** implémenter les vertical slices persistence de : ```text RawTransaction réservé à 0.3.3 RawAccountState réservé à 0.3.4 ``` La release peut créer les structures privées nécessaires au runtime et au moteur de migrations, mais aucun schéma/table/index métier `RawTransaction` ou `RawAccountState` n'est ajouté uniquement pour « tester » PostgreSQL. --- ## 3. Sources de vérité internes obligatoires — ordre de lecture ### 3.1 Règles globales Lire d'abord : ```text RULES.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 ``` Relire particulièrement : ```text KSP-API-001..007 KSP-CONFIG-001..018 KSP-STORE-001..002 KSP-NOTIFY-001..006 KSP-PROC-001..008 KSP-REL-001..016 DEP-KSP-001..005 DEP-CARGO-001..007 DEP-LOG-001..012 DEP-STORE-001..010 DEP-WORKER-001..003 DEP-JOB-001..003 ``` Rappels directement structurants : ```text ksp-store-lib -> ksp-store-api ksp-store-lib[postgres] -> ksp-store-postgres-lib ksp-store-postgres-lib -> ksp-store-api ksp-store-postgres-lib -X-> ksp-store-lib Config -> Store autorisé Store -X-> Config Transport -X-> Store Program/Materializer -X-> Store workers/jobs/apps futurs -> ksp-store-lib workers/jobs/apps futurs -X-> ksp-store-postgres-lib ``` ### 3.2 Architecture durable Lire ensuite : ```text docs/architecture/000-README.md docs/architecture/001-PROJECT_OBJECTIVES.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/007-EXECUTION_AND_POLICY.md docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md ``` Références centrales de cette release : ```text docs/architecture/003-COMPONENT_CONTRACTS.md docs/architecture/005-DEPENDENCY_GRAPH.md docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md ``` Préserver notamment : ```text Store persiste et sert des contrats ; il ne possède pas les policies d'exécution la pagination/cursorisation Store n'impose aucun plafond métier global arbitraire batch-size/priorité/stratégie appartiennent aux futurs workers/jobs/executors Config possède documents/placeholders/.env/secrets backend PostgreSQL possède son driver et ses objets physiques aucun type SQL/backend ne traverse la façade publique ``` ### 3.3 État `0.3.1` à relire intégralement Lire : ```text docs/plans/022-V0_3_1_STORE_RAW_PLAN.md docs/validation/018-V0_3_1_STORE_RAW.md crates/ksp-store-api/Cargo.toml crates/ksp-store-api/src/** crates/ksp-store-api/tests/** CHANGELOG.md ROADMAP.md ``` Créer en `pre.001` : ```text docs/plans/023-V0_3_2_STORE_POSTGRES_FOUNDATION_PLAN.md docs/validation/019-V0_3_2_STORE_POSTGRES_FOUNDATION.md ``` Le plan doit contenir la prévision souple recalibrée de la release et rester la référence détaillée des prereleases. --- ## 4. Sources externes normatives à réauditer La fraîcheur importe pour cette release. Réauditer au début de `pre.001` avec les sources primaires actuelles : ```text PostgreSQL documentation/release notes courantes tokio-postgres docs.rs / crates.io / repository upstream runtime Tokio réellement requis par tokio-postgres connecteurs TLS réellement compatibles et maintenus solutions de pooling candidates si un pool externe est retenu ``` Référence connue lors de la préparation de ce prompt, le **29 août 2026** : ```text PostgreSQL stable courant : 18.6 tokio-postgres courant : 0.7.18 ``` Ces versions sont des **points de départ d'audit**, pas des pins automatiques. `pre.001` doit vérifier qu'elles sont toujours les versions stables pertinentes au moment réel de l'implémentation. Décision déjà acquise : ```text driver PostgreSQL KSP = tokio-postgres ``` Ne pas rouvrir SQLx comme choix principal sauf contradiction technique nouvelle et documentée. Questions externes encore ouvertes à auditer : ```text pooling : pool externe maintenu vs abstraction KSP minimale TLS : connecteur exact, root store, modes supportés, absence de fuite de secrets PostgreSQL major minimal supporté/testé migrations : mécanisme KSP privé vs crate externe réellement justifiée checksums/versioning/locking de migrations timeouts et shutdown propre ``` Aucune dépendance additionnelle n'est ajoutée seulement parce qu'elle est habituelle dans l'écosystème. --- ## 5. État validé de `0.3.1` à préserver `ksp-store-api` est une fondation stable candidate et ne doit pas être redessinée pour simplifier PostgreSQL. Surface acquise : ```text 60 exports crate-root 10 capabilities fines object-safe RawTransaction + RawTransactionObservation RawAccountState + RawAccountObservation RawPayload / RawContentHash / RawObservationKey provenance/timestamps/codes bornés queries cursorisées outcomes idempotence/conflit RawRetentionState / tombstone / force-rehydrate ExpectedStateMismatch pour race de rétention ``` Propriétés acquises : ```text ksp-store-api -> ksp-core-lib uniquement aucun pub mod public aucun SQL / row / pool / runtime DB aucun serde/tokio/config/transport/program/logging aucun modèle event-only aucune surface STRUCTURAL / DECODED / DOMAIN backend externe implémentable sans ksp-store-lib ``` `0.3.2` ne modifie `ksp-store-api` que si un **gap backend-agnostic concret et bloquant** est démontré par l'implémentation de fondation. Une préférence PostgreSQL, un type de pool ou un besoin SQL n'est jamais une raison suffisante. --- ## 6. Décisions acquises et questions réellement ouvertes ### 6.1 Décisions acquises ```text ksp-store-lib et ksp-store-postgres-lib sont ouvertes ensemble postgres est la feature backend par défaut de ksp-store-lib tokio-postgres est le driver PostgreSQL retenu ksp-store-postgres-lib dépend de ksp-store-api, jamais de ksp-store-lib ksp-store-lib ne contient aucun SQL/backend physique Config sélectionne le backend parmi ceux compilés backend connu mais non compilé -> erreur explicite, aucun fallback silencieux Config possède URI/secrets/.env ; Store/backend ne lisent aucun environnement directement RawTransaction PostgreSQL est hors 0.3.2 RawAccountState PostgreSQL est hors 0.3.2 pagination Store != policy de batch executor ``` ### 6.2 Questions ouvertes à fermer par `pre.001` ```text forme exacte de StoreSettings et StoreBackendKind forme exacte du lifecycle Store open/close reexports API nécessaires depuis ksp-store-lib pool : bibliothèque externe ou implémentation KSP minimale TLS : connecteur/features/modes réellement retenus support PostgreSQL major minimal mécanisme de migration/version/checksum verrouillage concurrent du bootstrap/migrations schema/namespace privé de migration stratégie de rollback après migration échouée health/readiness portable : nécessaire maintenant ou reporté stratégie de test PostgreSQL réel isolé/non destructif forme exacte de std.store et de ses profils/secrets impacts de packaging Config/Tauri lorsque le registre Config gagne std.store ``` Une question ouverte ne doit pas être résolue par imitation de kbot3 ou par habitude ecosystem sans audit. --- ## 7. Objectifs et livrables de `0.3.2` ### 7.1 `ksp-store-lib` À la clôture, la crate doit au minimum : ```text exister comme bibliothèque Rust 2024 avoir ksp-store-api comme dépendance normale avoir la feature postgres activée par défaut lier ksp-store-postgres-lib uniquement sous feature postgres rester compilable --no-default-features exposer une façade Store/runtime commune accepter des settings déjà résolus sélectionner un backend compilé explicitement rejeter un backend connu non compilé avec erreur stable ne jamais exposer un handle/type PostgreSQL public réexporter uniquement la surface ksp-store-api réellement utile aux consumers posséder README.md + USAGE.md durables avant fermeture ``` ### 7.2 `ksp-store-postgres-lib` À la clôture, la crate doit au minimum : ```text exister comme backend officiel avoir ksp-store-api comme dépendance KSP ne jamais dépendre de ksp-store-lib posséder tokio-postgres en interne posséder connexion/pool/TLS retenus posséder bootstrap/migrations privés ouvrir/fermer proprement ses ressources sanitiser erreurs/Debug/logs ne lire aucun Config/env directement ne créer aucune table RAW métier de 0.3.3/0.3.4 posséder README.md + USAGE.md durables avant fermeture ``` Une table/namespace interne de suivi des migrations peut être créée si elle est réellement nécessaire au moteur de migration ; elle reste une primitive d'infrastructure, pas une première table RAW métier. ### 7.3 Config `std.store` La release doit ajouter une Config Store seulement après design `pre.001` : ```text config/std.store.json config/examples/std.store.example.json config/schemas/std.store.schema.json registry Config + file IDs adapter typed ksp-config-lib -> StoreSettings provenance/sensibilité/redaction conformes aux règles Config ``` Les secrets PostgreSQL passent par Config. Ne jamais introduire dans Store/backend : ```text std::env .env parsing KSP_* / KSPB_* lookup PGHOST / PGPORT / PGUSER / PGPASSWORD / PGDATABASE .pgpass implicite ``` Auditer les bundles/resources Tauri existants : ne modifier les apps que si leur contrat de packaging Config exige réellement la nouvelle ressource. Aucun nouvel écran Store n'est ajouté. ### 7.4 Migrations et bootstrap Le mécanisme retenu doit au minimum couvrir : ```text ordre déterministe identité/version de migration checksum ou preuve équivalente contre modification silencieuse application transactionnelle lorsque PostgreSQL le permet verrouillage/concurrence de bootstrap reprise sûre après échec mismatch explicite aucun SQL dynamique construit depuis input non fiable introspection/version observable sans exposer les SQL internes publiquement ``` Les migrations sont privées à `ksp-store-postgres-lib`. Aucune migration `RawTransaction` ou `RawAccountState` n'est créée dans cette release. --- ## 8. Hors périmètre strict Ne pas ouvrir dans `0.3.2` : ```text persistence PostgreSQL RawTransaction persistence PostgreSQL RawTransactionObservation queries RawTransaction PostgreSQL retention/tombstone RawTransaction PostgreSQL persistence PostgreSQL RawAccountState persistence PostgreSQL RawAccountObservation queries RawAccountState PostgreSQL processing ledger claims/leases de processing compression/archive RAW physique worker/job/backfill application Store/inspection notification event bus LISTEN/NOTIFY comme mécanisme requis N2 STRUCTURAL N3 DECODED N4 DOMAIN Program/Materializer/Execution backend MySQL/SQLite/Oracle/RocksDB/ClickHouse ``` Ne pas créer un faux repository CRUD « exemple » sur une table générique seulement pour démontrer le driver. La preuve PostgreSQL de `0.3.2` porte sur la **fondation runtime/migrations**, pas sur une pseudo-entité temporaire qui deviendrait de la dette. --- ## 9. Contraintes sécurité/API/architecture spécifiques ### 9.1 Secrets et diagnostics Aucune surface `Debug`, erreur publique, log ou snapshot ne doit révéler : ```text URI PostgreSQL complète password userinfo secret placeholder résolu TLS private material SQL parameter sensible contenu brut d'une erreur distante pouvant reproduire une valeur secrète ``` Les erreurs KSP utilisent le contrat Core et un contexte sûr, stable et borné. ### 9.2 SQL et migrations ```text requêtes statiques ou paramètres bindés aucune interpolation de valeurs métier dans SQL identifiants physiques non contrôlés par un input utilisateur migrations embarquées/possédées par le backend concurrence de migration sérialisée explicitement checksum mismatch = erreur, jamais réécriture silencieuse ``` ### 9.3 Runtime async ```text async-first aucun runtime global Store imposé aucun spawn orphelin shutdown borné connection-driving futures correctement possédées aucun mutex sync gardé à travers await ``` ### 9.4 Logging Si `ksp-store-lib` ou `ksp-store-postgres-lib` émettent des événements/spans runtime : ```text utiliser ksp-logging-lib pas de tracing direct hors façade KSP ajouter constants.rs avec TRACING_TARGET selon les règles KSP aucun credential/URI/SQL parameter dans les champs ``` Une crate qui n'émet aucun log n'ajoute pas Logging artificiellement. ### 9.5 Backend features Le minimum à valider est : ```text cargo check -p ksp-store-lib cargo check -p ksp-store-lib --no-default-features cargo tree -p ksp-store-lib --edges normal cargo tree -p ksp-store-lib -e features cargo tree -p ksp-store-postgres-lib --edges normal ``` `--no-default-features` doit produire un runtime Store sans backend disponible mais compilable ; tenter d'ouvrir `postgres` dans cet état doit produire l'erreur explicite retenue, pas un panic ni un fallback. --- ## 10. Première mission `0.3.2-pre.001` `pre.001` ne code pas le runtime lourd. Il doit produire un dossier de décision exploitable. ### 10.1 Vérifier la base réelle Inventorier : ```text workspace members workspace dependencies ksp-store-api exact ksp-config-lib registry/adapters Config Desk/resource packaging Logging ownership architecture Store roadmap 0.3.2/0.3.3/0.3.4 ``` ### 10.2 Réauditer l'héritage kbot3 ciblé Relire au minimum dans l'archive historique : ```text ks-store/Cargo.toml ks-store/src/store.rs ks-store/src/postgres/** ks-store/migrations/postgres/** config/store.config.json config/schemas/store.config.schema.json ks-config/src/store.rs docs/architecture/STORAGE_ARCHITECTURE.md docs/guides/POSTGRES_STORAGE.md ``` Classer sous : ```text REPRENDRE REDESSINER REPORTER REJETER ``` Porter l'attention sur : ```text open options pool/lifecycle TLS migrations/schema version/checksum locking health/readiness redaction/error mapping Config ownership maintenance SQL naming ``` ### 10.3 Réauditer PostgreSQL et dependencies actuelles Vérifier : ```text PostgreSQL stable/current support policy tokio-postgres version/features/MSRV Tokio features réellement nécessaires pool candidates TLS connector candidates migration helper candidates si utile licences versions transitives/doublons ``` Ne pas décider un pool ou TLS connector uniquement parce qu'il est populaire. ### 10.4 Produire le design de fondation Le gate doit proposer puis figer : ```text graphe Cargo exact features exactes de ksp-store-lib StoreSettings / backend identity Store open/close lifecycle backend dispatch known-but-not-compiled error Postgres backend construction pool/lifecycle TLS policy migration/bootstrap architecture Config std.store shape redaction/error codes real PostgreSQL test strategy ``` ### 10.5 Threat model Couvrir au minimum : ```text credential leak URI/Debug/error/log implicit PG* / .pgpass bypassing Config malicious/invalid connection string connection storm / unbounded pool hung connect / migration / shutdown concurrent migration runners modified historical migration partial migration SQL injection / dynamic identifier injection backend feature/config mismatch connection task dropped/leaked schema incompatible/newer than runtime PostgreSQL server error echoing values ``` ### 10.6 Sizing Le gate doit vérifier que `0.3.2` reste clôturable dans une session avec **fondation uniquement**. Si pooling + TLS + Config + migrations + integration réelle dépassent encore la capacité raisonnable d'une session, redécouper **avant** l'implémentation lourde. Ne jamais absorber `RawTransaction` pour « rentabiliser » la release. ### 10.7 Critères de sortie de `pre.001` `pre.001` est terminé seulement si : ```text sources obligatoires lues base stable vérifiée audit kbot3 ciblé documenté audit PostgreSQL/tokio-postgres actuel documenté pool/TLS/migrations questions tranchées ou explicitement réservées à une tranche précise graphe Cargo exact proposé Config shape candidate bornée threat model complet stratégie de PostgreSQL integration test définie plan 023 créé validation 019 créée prévision souple recalibrée aucun RawTransaction/RawAccountState PostgreSQL tiré dans 0.3.2 ``` --- ## 11. Prévision souple initiale des prereleases Cette prévision est volontairement fine. `pre.001` peut la scinder/réordonner si l'audit le justifie. ### `pre.001` — Audit, threat model, dependencies et sizing Lecture complète, audit kbot3 ciblé, audit PostgreSQL/tokio-postgres/pool/TLS/migrations, design Config/runtime/backend, graphe exact, tests et plan. ### `pre.002` — Scaffold des deux crates + feature graph Créer `ksp-store-lib` et `ksp-store-postgres-lib`, manifests, modules privés minimaux, dépendances retenues, feature `postgres` par défaut, compilation `--no-default-features`, canaris de direction de dépendances. Pas encore de connexion réelle lourde. ### `pre.003` — Store settings + backend selection/lifecycle contract Matérialiser les settings backend-neutral, identité backend, erreurs stable known/not-compiled, façade `Store` minimale et reexports API utiles. Aucun SQL métier. ### `pre.004` — Config `std.store` Ajouter document/schema/example/registry/adaptor Config, secrets/provenance/redaction et impacts de packaging strictement nécessaires. Store/backend restent incapables de lire l'environnement. ### `pre.005` — PostgreSQL connection + pool + TLS Implémenter la construction backend PostgreSQL, connect/open/close, pool retenu, timeouts et TLS retenu, avec tests déterministes sans table RAW métier. ### `pre.006` — Migration/bootstrap foundation Implémenter ownership des migrations, version/checksum, serialization/locking, transaction/recovery et introspection minimale. Une table/namespace interne de migration est autorisée ; aucune table `RawTransaction`/`RawAccountState`. ### `pre.007` — Composition façade/backend + diagnostics/health si retenu Fermer l'ouverture end-to-end `StoreSettings -> Store -> backend`, shutdown, error mapping, snapshots/health portable seulement si le gate `pre.001` l'a justifié, et feature mismatch. ### `pre.008` — PostgreSQL integration réelle Test opt-in non destructif sur PostgreSQL réel : connexion, bootstrap initial, re-run idempotent, concurrence migration, mismatch/checksum/recovery selon stratégie retenue, close propre. Aucun test ne doit exiger une table RAW métier. ### `pre.009` — Hardening, completeness et dependency matrix Inputs hostiles, redaction, no-env, no-SQL-leak, exact exports/modules, `--no-default-features`, external backend compatibility, graphes/features Cargo et non-régression de `ksp-store-api`. ### `pre.010` — Gate technique final Workspace, tests ciblés, ownership Logging, PostgreSQL integration gate retenu et graphes Cargo. Aucun développement fonctionnel nouveau. ### `pre.011` — Réconciliation documentaire finale README/USAGE des deux crates, plan, validation, architecture/indexes réellement impactés. Ne pas toucher `CHANGELOG.md`, `ROADMAP.md` ni au prompt suivant. ### `pre.012` — Préparation de publication minimale Uniquement : ```text Cargo.toml CHANGELOG.md ROADMAP.md prompts/022-V0_3_3_START_PROMPT.md delta pre.012 ``` ### `rel.001` — Publication stable Version finale + delta uniquement. --- ## 12. Versionnement, deltas, commits et tags Respecter `docs/rules/VERSION_WORKFLOW.md`. Rappels : ```text workspace.package.version prérelease : 0.3.2-pre.N livraison : 0.3.2-pre.NNN fix de code/runtime : Cargo 0.3.2-pre.N.fix.M fix doc-only : version Cargo inchangée chaque delta commité à partir de 0.1.x aucun tag prerelease requis tag stable final : v0.3.2 ``` Chaque delta contient : ```text base requise objectif fichiers ajoutés/modifiés/supprimés validations exécutées validations non exécutées décisions questions ouvertes ``` Une commande non exécutée n'est jamais déclarée PASS. --- ## 13. Procédure d'application et validation opérateur Après chaque overlay : ```bash 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.2 cargo check --workspace cargo clippy --workspace --all-targets ``` Puis tests ciblés selon la tranche, typiquement : ```bash cargo test -p ksp-store-api cargo test -p ksp-store-lib cargo test -p ksp-store-postgres-lib cargo test -p ksp-config-lib ``` Lorsque le graphe/features change : ```bash cargo check -p ksp-store-lib --no-default-features cargo tree -p ksp-store-lib --edges normal cargo tree -p ksp-store-lib -e features cargo tree -p ksp-store-postgres-lib --edges normal cargo tree --duplicates ``` Le gate technique final inclut `cargo test --workspace`. Ne pas refaire systématiquement les builds Tauri à chaque tranche. Les exécuter uniquement si les resources/configs desktop ou le packaging réellement touché le justifient, et lors d'un gate final où cette preuve est pertinente. --- ## 14. Validations PostgreSQL spécifiques La release doit disposer avant fermeture d'un test PostgreSQL réel, opt-in et sûr. Le design exact appartient à `pre.001`, mais les invariants sont : ```text aucun credential commité aucune lecture directe env par Store/backend input opérateur explicite ou fixture locale dédiée aucune destruction d'une base/schema non créé par le test cleanup best-effort borné bootstrap initial prouvé second bootstrap idempotent prouvé concurrence de bootstrap/migration prouvée failure/mismatch safe selon stratégie retenue close/shutdown prouvé ``` Si le test utilise stdin comme les smokes credentials KSP existants, ne jamais afficher la valeur fournie. Aucune connexion live n'est exigée pour les prereleases purement documentaires. --- ## 15. Critères de clôture de `0.3.2` La release stable est prête seulement si : ```text ksp-store-lib existe et dépend de ksp-store-api ksp-store-postgres-lib existe et dépend de ksp-store-api ksp-store-postgres-lib ne dépend pas de ksp-store-lib feature postgres de ksp-store-lib activée par défaut --no-default-features compile backend postgres connu mais non compilé est rejeté explicitement StoreSettings ne dépend pas de Config ksp-config-lib possède std.store + schema/example/adaptor retenus Store/backend ne lisent aucun env/.env/PG*/.pgpass connexion/pool/TLS PostgreSQL sont bornés et redacted migrations/bootstrap privés sont versionnés et concurrency-safe aucune table RAW métier n'est ajoutée aucune capability RawTransaction n'est implémentée par PostgreSQL aucune capability RawAccountState n'est implémentée par PostgreSQL aucune policy batch/backlog n'entre dans Store aucun type PostgreSQL/SQL/pool ne fuit dans la façade publique ksp-store-api reste compatible et sans dépendance backend README/USAGE des deux crates sont durables PostgreSQL integration réelle est verte workspace/clippy/tests/graphes sont verts prompt 0.3.3 réserve clairement la vertical slice RawTransaction ``` --- ## 16. Release suivante et instruction d'ouverture La release suivante envisagée est : ```text 0.3.3 — Store/PostgreSQL RawTransaction vertical slice ``` Elle doit réutiliser les **mêmes** : ```text ksp-store-lib ksp-store-postgres-lib Store settings backend dispatch pool/TLS migration engine ``` et ajouter seulement la conformance PostgreSQL `RawTransaction`/observation/query/rétention définie par `ksp-store-api`. `0.3.4` restera propriétaire de `RawAccountState` + complétude RAW. ### Instruction d'ouverture À réception de la base stable `v0.3.1` et de l'archive historique requise : 1. vérifier la base exacte ; 2. lire les règles/architecture/plan/validation dans l'ordre indiqué ; 3. réauditer les versions et sources PostgreSQL/tokio-postgres actuelles ; 4. réauditer kbot3 uniquement sur la fondation physique pertinente ; 5. produire brainstorming, threat model, graphe Cargo, décisions pool/TLS/migrations/Config et sizing ; 6. créer le plan `023` et la validation `019` ; 7. **ne pas commencer l'implémentation lourde avant validation cohérente du gate `pre.001`** ; 8. **ne pas implémenter RawTransaction ou RawAccountState PostgreSQL dans `0.3.2`**.