# Delta `0.3.1-pre.010` — Redécoupage documentaire des slices Store/PostgreSQL ## Base requise ```text 0.3.1-pre.009 ``` Le gate opérateur ciblé de `pre.009` est propre : audits Rust/Markdown, `cargo check --workspace`, Clippy et `cargo test -p ksp-store-api` passent. Le gate lourd `pre.008`, reconstruit après `cargo clean`, reste la preuve technique de référence pour le workspace et les bundles Tauri. ## Objectif Réduire avant publication le scope de la future implémentation Store/PostgreSQL afin que chaque release concrète reste clôturable dans une session sans sacrifier migrations, concurrence, atomicité, idempotence ou validation PostgreSQL réelle. La décision opérateur est : ```text ksp-store-lib et ksp-store-postgres-lib restent développées ensemble mais l'ancien scope unique 0.3.2 est découpé en trois releases ``` Nouvelle trajectoire : ```text 0.3.2 fondation runtime/backend PostgreSQL 0.3.3 vertical slice PostgreSQL RawTransaction complète 0.3.4 vertical slice PostgreSQL RawAccountState + complétude Store RAW 0.3.5 Interface events/acquisitions partagés si consumer réel 0.3.6 ksp-job-api + premier backfill RAW 0.3.7 application backfill/inspection RAW ``` ## Fichiers ajoutés ```text deltas/0.3.1/pre.010.md ``` ## Fichiers modifiés ```text Cargo.toml docs/architecture/004-COMPONENT_INVENTORY.md docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md docs/plans/022-V0_3_1_STORE_RAW_PLAN.md docs/validation/018-V0_3_1_STORE_RAW.md ``` ## Fichiers supprimés Aucun. ## Décisions figées - `workspace.package.version` passe à `0.3.1-pre.10` : nouvelle prerelease non-fix, même si la tranche est documentaire. - `ksp-store-lib` et `ksp-store-postgres-lib` ne sont **jamais** séparées en deux releases où l'une existerait sans l'autre ; elles avancent de pair sur `0.3.2`, `0.3.3` et `0.3.4`. - `0.3.2` est limité à la fondation runtime/backend : crates, features, Config `std.store`, sélection backend, erreur backend connu non compilé, connexion/TLS/pooling à auditer, migrations/bootstrap privés, health/readiness portable si le gate `pre.001` le confirme. - `0.3.2` n'implémente pas artificiellement les capabilities `RawTransaction` ou `RawAccountState` uniquement pour augmenter le scope. - `0.3.3` implémente la conformance PostgreSQL complète de `RawTransaction` : observation, get/list cursorisé, atomicité RAW + observation, idempotence/conflit, rétention/tombstone/force-rehydrate et races/rollback réels. - `0.3.4` implémente `RawAccountState` + observation, puis la complétude/conformance cross-family, les migrations/indexes finaux et le gate PostgreSQL réel final de la couche RAW. - La pagination Store reste une primitive de navigation/cursorisation ; batch-size, priorité et policy appartiennent aux workers/jobs/executors. Une limitation physique backend peut être reflétée sans devenir un plafond métier global imposé par Store. - Les anciennes étapes Interface/backfill/app sont renumérotées `0.3.5`, `0.3.6`, `0.3.7`. - La préparation de publication minimale est décalée de `pre.010` à `pre.011` afin de ne pas mélanger cette correction de trajectoire avec `CHANGELOG.md`, `ROADMAP.md` et le prompt `0.3.2`. - `ROADMAP.md`, `CHANGELOG.md` et `prompts/021-V0_3_2_START_PROMPT.md` restent donc inchangés dans `pre.010`; ils seront réconciliés uniquement dans `pre.011` conformément à `PROMPT_STRUCTURE.md`. ## Pourquoi trois slices L'ancien `0.3.2` cumulait au minimum : ```text création de deux crates feature/backend dispatch Config et secrets connexion/pool/TLS PostgreSQL migrations/bootstrap RawTransaction RawAccountState queries/pagination atomicité/idempotence/races rétention/tombstones/rehydration health/readiness validation PostgreSQL réelle ``` Deux slices auraient encore concentré la fondation runtime/backend et une famille RAW lourde dans la même session. Trois slices réduisent le risque de saturation tout en conservant une progression architecturale cohérente et testable. ## Validations exécutées pendant la génération ```text python3 scripts/audit_rust_workspace_rules.py -> General Rust rule audit: clean -> Rust export completeness audit: 0 candidate(s) -> KSP workspace Rust rule audit: clean python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.3.1 -> Markdown table audit: clean (186 table(s), 136 file(s)) ``` Les tableaux touchés ont été réalignés selon le format RustRover attendu par l'audit Markdown. ## Validations non exécutées pendant la génération L'environnement de génération ne dispose pas de la toolchain Cargo/Rust utilisée par l'opérateur ; aucun `cargo check`, Clippy ou test Cargo n'est revendiqué pour cette archive. Aucun code Rust, manifest de crate, schema Config, migration ou runtime n'est modifié dans cette tranche. ## Gate opérateur demandé ```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.1 cargo check --workspace cargo clippy --workspace --all-targets cargo test -p ksp-store-api ``` Le gate lourd workspace/Tauri n'a pas besoin d'être rejoué pour cette tranche documentaire si ce gate ciblé reste vert. ## Suite Si `pre.010` est propre, `pre.011` est la préparation de publication minimale : ```text Cargo.toml CHANGELOG.md ROADMAP.md prompts/021-V0_3_2_START_PROMPT.md deltas/0.3.1/pre.011.md ``` Le prompt `0.3.2` devra être strictement dimensionné sur la **fondation runtime/backend PostgreSQL** et annoncer explicitement `0.3.3`/`0.3.4` comme slices suivantes, sans commencer leur implémentation.