28 KiB
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 :
v0.3.1
La release à ouvrir est :
0.3.2 — Store/PostgreSQL runtime foundation
La première tranche est :
0.3.2-pre.001
Deux archives sont requises au démarrage :
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é :
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 :
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 :
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 :
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 :
ksp-store-lib
ksp-store-postgres-lib
mais uniquement comme fondation runtime/backend PostgreSQL.
La séparation durable est :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md
Préserver notamment :
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 :
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 :
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 :
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 :
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 :
driver PostgreSQL KSP = tokio-postgres
Ne pas rouvrir SQLx comme choix principal sauf contradiction technique nouvelle et documentée.
Questions externes encore ouvertes à auditer :
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 :
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 :
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
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
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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
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
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 :
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 :
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 :
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 :
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 :
REPRENDRE
REDESSINER
REPORTER
REJETER
Porter l'attention sur :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
0.3.3 — Store/PostgreSQL RawTransaction vertical slice
Elle doit réutiliser les mêmes :
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 :
- vérifier la base exacte ;
- lire les règles/architecture/plan/validation dans l'ordre indiqué ;
- réauditer les versions et sources PostgreSQL/tokio-postgres actuelles ;
- réauditer kbot3 uniquement sur la fondation physique pertinente ;
- produire brainstorming, threat model, graphe Cargo, décisions pool/TLS/migrations/Config et sizing ;
- créer le plan
023et la validation019; - ne pas commencer l'implémentation lourde avant validation cohérente du gate
pre.001; - ne pas implémenter RawTransaction ou RawAccountState PostgreSQL dans
0.3.2.