v0.3.16-pre.001-fix.001

docs/plans/038-V0_3_16_RAW_RESILIENCE_CONFLICT_PLAN.md

@@ -1,7 +1,7 @@
 <!-- file: docs/plans/038-V0_3_16_RAW_RESILIENCE_CONFLICT_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
-# Plan `0.3.16` — résilience RAW, variantes, conflits et récupération
+# Plan `0.3.16` -> `0.3.18` — résilience RAW, variantes, conflits et récupération
 
 ## 1. Statut du document
 
@@ -16,6 +16,8 @@ commit 7328be6997399c513306f2f4c8cdf00bd8b22367
 
 `pre.001` reste volontairement documentaire. Il ne crée aucune migration finale, aucune table SQL, aucun contrat Rust définitif et aucune UI de conflit. Les décisions ci-dessous fixent les invariants à respecter par les tranches d'implémentation suivantes.
 
+Le fix documentaire `0.3.16-pre.001-fix.001` conserve toutes ces décisions techniques mais corrige le sizing : le programme est réparti sur trois releases stables, `0.3.16`, `0.3.17` et `0.3.18`, afin qu'aucune version ne nécessite plus d'une session de développement normale. Ce fix ne modifie pas `workspace.package.version` et ne change aucun contrat Rust ou SQL.
+
 ## 2. Contraintes normatives confirmées
 
 Les règles KSP restent cumulatives. `0.3.16` ne crée aucune exception implicite.
@@ -937,110 +939,145 @@ Mitigation : `Incomparable` fail-closed pour tous les champs sans preuve normati
 
 Mitigation : ne jamais prétendre reconstruire une variante pré-V003 non stockée ; qualifier explicitement l'observation comme legacy/unknown.
 
-## 20. Découpage recalibré
+## 20. Découpage recalibré du programme `0.3.16` -> `0.3.18`
 
-La prévision initiale du prompt est trop dense pour plusieurs tranches qui combinent contrat, SQL, concurrence et rétention. Le découpage souple est donc étendu afin de respecter le budget KSP d'environ 15–20 minutes par tranche de travail effectif.
+Le découpage initial de `pre.001` jusqu'à `pre.022` est abandonné. Même si chaque tranche restait petite isolément, plus de vingt prereleases auxquelles s'ajouteraient les `fix.*` ne constituent pas une cible réaliste pour la règle KSP « une version = au maximum une session ».
 
-### `pre.001`
+Le programme conserve les mêmes invariants techniques, mais il est réparti en trois vertical slices stables. La cible est de rester autour de sept à huit prereleases par version, avec une marge réelle pour les fixes. Une release ne doit pas être artificiellement maintenue ouverte pour absorber le scope de la suivante.
 
-Audit stable/règles, réaudit externe, modèles physiques, décisions d'ownership, sizing, plan et validation.
+### 20.1 `0.3.16` — fondations RAW multi-variantes et ingestion non terminale
 
-### `pre.002`
+Objectif de fermeture : disposer d'une persistance durable des variantes et conflits, d'une promotion automatique strictement prouvée, et permettre au Worker live de continuer lorsqu'une divergence conservable est enregistrée.
 
-Contrats Store API backend-neutral : variant identity, relation de qualité, outcomes de persistance et reason codes.
+#### `0.3.16-pre.001`
 
-### `pre.003`
+Gate d'audit, architecture, sizing, plan et validation. Cette tranche est déjà appliquée.
 
-Contrats Store API d'inspection/résolution + classification d'erreurs Store transient/terminal + tests de contrats.
+#### `0.3.16-pre.002`
 
-### `pre.004`
+Contrats Store API backend-neutral : variant identity, relation de qualité, outcomes de persistance, reason codes et contrats minimaux nécessaires au conflit durable.
 
-Migration V003 : registre/resources/schema uniquement, sans moteur de convergence lourd ; canaris checksum V000/V001/V002.
+#### `0.3.16-pre.003`
 
-### `pre.005`
+Migration V003 : registre, resources et schéma multi-variantes/selector/conflict minimal ; canaris garantissant l'immuabilité byte/checksum de V000/V001/V002.
 
-Backend PostgreSQL : bootstrap V003, variant ledger, observation exacte par variante, concurrence d'insertion.
+#### `0.3.16-pre.004`
 
-### `pre.006`
+Backend PostgreSQL : bootstrap V003, variant ledger, rattachement exact des nouvelles observations à leur variante, idempotence et concurrence d'insertion.
 
-Comparateur partagé : `Exact/Less/More/Conflict/Incomparable`, canaris `logMessages` bidirectionnels, autres champs fail-closed.
+#### `0.3.16-pre.005`
 
-### `pre.007`
+Comparateur partagé : `Exact`, `CompatibleLessComplete`, `CompatibleMoreComplete`, `Conflict`, `Incomparable` ; canaris `logMessages` bidirectionnels et politique fail-closed sur les autres champs.
 
-Promotion canonique atomique, selector revision et journal des transitions.
+#### `0.3.16-pre.006`
 
-### `pre.008`
+Sélecteur canonique et promotion atomique : revision, projection V001 cohérente, conservation de l'ancien canonique et journal minimal des transitions.
 
-Conflict case durable, participants, résolution/reopen et races ingestion/résolution.
+#### `0.3.16-pre.007`
 
-### `pre.009`
+Conflit durable minimal + intégration Worker : variante conservée, case ouverte, outcome non terminal, suppression/restriction de l'arbitrage run-local plus fort que le Store et health `Degraded` lorsque requis.
 
-Rétention/archives/ForceRehydrate des variantes + règles de pin/rollback.
+#### `0.3.16-pre.008`
 
-### `pre.010`
+Hardening ciblé de la vertical slice : concurrence, rollback transactionnel, régression Job Backfill/Store, gates workspace, validation documentaire et préparation de `0.3.16-rel.001`.
 
-Store-lib : inspection, historique et actions backend-neutral ; compatibilité Job Backfill existant.
+#### `0.3.16-rel.001`
 
-### `pre.011`
+Publication stable mécanique après gates propres. Aucun Store Desk ni retry Store complet n'est requis pour fermer cette release.
 
-Worker : conflit durable non terminal, suppression/restriction de l'arbitrage run-local, health Degraded et métriques.
+### 20.2 `0.3.17` — résilience opérationnelle et cycle de vie des variantes
 
-### `pre.012`
+Objectif de fermeture : rendre l'acquisition résiliente aux indisponibilités Store/Transport et fournir les contrats backend-neutral d'inspection/résolution nécessaires aux opérateurs et à la future UI.
 
-Worker : Store retry/backpressure/Blocked, calibration des defaults et cancellation/drain.
+#### `0.3.17-pre.001`
 
-### `pre.013`
+Contrats Store API d'inspection/résolution, revisions attendues et classification backend-neutral des erreurs Store `Transient/Terminal`.
 
-Transport : reconnexion configurable WebSocket/Yellowstone + Config ; conservation de la séparation HTTP/coverage.
+#### `0.3.17-pre.002`
 
-### `pre.014`
+Cycle de vie complet des conflict cases : participants, résolution, reopen, historique append-only et races ingestion/résolution.
 
-Store Desk backend/Tauri : queries et actions typées via `ksp-store-lib`.
+#### `0.3.17-pre.003`
 
-### `pre.015`
+Rétention des variantes : archive, pins, purge guards, rollback local et `ForceRehydrate` exact/différent.
 
-Store Desk frontend : conflicts/history/variant detail, pagination serverSide et tracing redacted.
+#### `0.3.17-pre.004`
 
-### `pre.016`
+`ksp-store-lib` : inspection, historique et actions backend-neutral ; maintien explicite de la compatibilité du Job Backfill existant.
 
-Actions UI promote/keep/restore/reopen avec protections stale revision.
+#### `0.3.17-pre.005`
 
-### `pre.017`
+Worker : Store retry/backpressure/`Blocked`, exhaustion explicite, cancellation et drain pendant backoff.
 
-Fusion assistée/synthétique strictement bornée, uniquement si les règles de fusion disponibles sont réellement prouvées ; sinon tranche documentaire qui ferme explicitement le non-support.
+#### `0.3.17-pre.006`
 
-### `pre.018`
+Transport/Config : reconnexion WebSocket/Yellowstone configurable en étendant les mécanismes propriétaires existants, sans confondre reconnexion et coverage et sans réimplémenter le retry HTTP.
 
-Hardening cross-layer : concurrence, cancellation, retention, rollback, redaction et dependency boundaries.
+#### `0.3.17-pre.007`
 
-### `pre.019`
+Hardening cross-layer et preuves live ciblées : conflits concurrents, outage/recovery Store, retry, reconnect et invariants de queue bornée.
 
-Preuves live PostgreSQL/Store + Worker sous conflits, Store outage/recovery et reconnect réellement testables.
+#### `0.3.17-pre.008`
 
-### `pre.020`
+Gate technique final, réconciliation documentaire et préparation de `0.3.17-rel.001` ainsi que du prompt `0.3.18`.
 
-Gate technique/live final : workspace, tests, graphes Cargo, Tauri build/smokes pertinents.
+#### `0.3.17-rel.001`
 
-### `pre.021`
+Publication stable mécanique après gates propres.
 
-Réconciliation documentaire finale de la release.
+### 20.3 `0.3.18` — inspection et résolution opérateur Store Desk
 
-### `pre.022`
+Objectif de fermeture : exposer les variantes/conflits/résolutions déjà stabilisés par Store API/lib dans une UI Desk sûre, paginée, traçable et sans dépendance backend directe.
 
-Préparation publication : `CHANGELOG.md`, `ROADMAP.md`, prompt `0.3.17`.
+#### `0.3.18-pre.001`
 
-### `rel.001`
+Store Desk backend/Tauri : queries typées, pagination server-side et actions via `ksp-store-lib` uniquement.
 
-Publication stable mécanique.
+#### `0.3.18-pre.002`
 
-Le nombre exact reste souple : aucune tranche ne doit être fusionnée artificiellement si son scope dépasse le budget.
+Frontend Vite/TypeScript : listes de conflits, historique, détail de variantes et transitions canoniques.
 
-## 21. Hors périmètre confirmé
+#### `0.3.18-pre.003`
 
-`0.3.16` n'implémente pas :
+Actions opérateur `promote/keep/restore/reopen` avec revision attendue, stale-action explicite et rafraîchissement cohérent.
 
-- multi-route/multi-stratégie du Job Backfill (`0.3.17`) ;
-- adaptation Backfill Desk correspondante (`0.3.18`) ;
+#### `0.3.18-pre.004`
+
+Fusion assistée/synthétique strictement bornée uniquement si les règles de fusion sont réellement prouvées ; sinon fermeture documentaire explicite du non-support, sans heuristique libre.
+
+#### `0.3.18-pre.005`
+
+Hardening UI/backend : redaction, pagination bornée, concurrence, cancellation, dependency boundaries et régressions Store Desk.
+
+#### `0.3.18-pre.006`
+
+Preuves end-to-end et gate technique/live final : PostgreSQL/Store/Worker/Desk, Tauri build/smokes pertinents et graphes Cargo lorsque requis par les règles.
+
+#### `0.3.18-pre.007`
+
+Réconciliation documentaire, `CHANGELOG.md`, `ROADMAP.md`, prompt de reprise suivant et préparation de `0.3.18-rel.001`.
+
+#### `0.3.18-rel.001`
+
+Publication stable mécanique après gates propres.
+
+### 20.4 Règles de sizing pour les trois releases
+
+Le nombre exact de prereleases reste souple, mais les règles suivantes sont désormais normatives pour ce programme :
+
+- une version ne doit pas dépasser une session normale ;
+- une tranche peut être subdivisée si sa validation devient trop lourde ;
+- un `fix.*` corrige la tranche concernée sans obliger à compresser la suite ;
+- un scope non indispensable à la vertical slice de la release est reporté à la release suivante ;
+- aucune fusion artificielle de migration, concurrence, Worker, Transport et UI n'est autorisée pour « économiser » un numéro de prerelease ;
+- la fermeture stable de chaque release doit laisser le workspace dans un état cohérent et exploitable indépendamment du développement de la suivante.
+
+## 21. Hors périmètre confirmé et déplacement des scopes réservés
+
+Le programme `0.3.16` -> `0.3.18` n'implémente pas :
+
+- multi-route/multi-stratégie du Job Backfill, désormais reporté après `0.3.18` et ciblé par défaut sur `0.3.19` ;
+- adaptation Backfill Desk correspondante, ciblée par défaut sur `0.3.20` ;
 - RAW -> STRUCTURAL ;
 - persistence STRUCTURAL ;
 - DECODED/DOMAIN ;
@@ -1051,7 +1088,9 @@ Le nombre exact reste souple : aucune tranche ne doit être fusionnée artificie
 - second pipeline d'acquisition ;
 - dépendance Worker <-> Job Backfill.
 
-Le Job Backfill actuel doit seulement rester compatible avec les contrats Store communs.
+Les anciennes réservations `0.3.17 = Backfill multi-route` et `0.3.18 = Backfill Desk` sont donc explicitement annulées par `0.3.16-pre.001-fix.001`. Ce déplacement évite deux scopes concurrents sur les mêmes numéros de version.
+
+Le Job Backfill actuel doit seulement rester compatible avec les contrats Store communs pendant `0.3.16` -> `0.3.18`. Les numéros `0.3.19`/`0.3.20` restent des cibles de planning et pourront être réévalués par le gate d'ouverture correspondant sans réouvrir le programme RAW résilience déjà fermé.
 
 ## 22. Questions non bloquantes reportées aux tranches d'implémentation
 
@@ -1093,4 +1132,4 @@ Le gate est architecturalement fermé lorsque :
 - Transport reconnect reste propriété Transport ;
 - Store Desk passe exclusivement par Store-lib ;
 - les risques de concurrence, rétention, stale action et migration volumique ont un mécanisme de contrôle explicite ;
-- le découpage souple ci-dessus remplace la prévision initiale trop compacte.
+- le découpage multi-version `0.3.16` -> `0.3.18` remplace la prévision initiale `0.3.16-pre.001` -> `pre.022` trop longue pour une seule session.