0.0.4-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Documentation SaseDev Knowledge
|
||||
|
||||
@@ -33,12 +33,14 @@
|
||||
- [`studies/005-V0_0_2_GIT_SYNC_RECONCILIATION.md`](studies/005-V0_0_2_GIT_SYNC_RECONCILIATION.md) — réconciliation beta du chemin Git/synchronisation, `DEFER` conservés et revue d'horizon sans prochaine release réservée.
|
||||
- [`studies/006-V0_0_3_GIT_WRITE_STUDY.md`](studies/006-V0_0_3_GIT_WRITE_STUDY.md) — décision d'engager l'écriture Git contrôlée, stratégie de worktree et invariants de concurrence.
|
||||
- [`studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md`](studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md) — réconciliation beta du chemin Git d'écriture, DEFER reclassés et horizon produit des trois sites.
|
||||
- [`studies/008-V0_0_4_POSTGRES_FOUNDATION_STUDY.md`](studies/008-V0_0_4_POSTGRES_FOUNDATION_STUDY.md) — comparaison PostgreSQL de démarrage `0.0.4`, décision `tokio-postgres`/Deadpool/Refinery, ownership, schéma minimal, migrations et tests éphémères.
|
||||
|
||||
## Plans
|
||||
|
||||
- [`plans/001-V0_0_1_FOUNDATION_PLAN.md`](plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan historique de la stable de fondation `0.0.1`.
|
||||
- [`plans/002-V0_0_2_GIT_SYNC_PLAN.md`](plans/002-V0_0_2_GIT_SYNC_PLAN.md) — plan historique de la stable Git générique et synchronisation de lecture `0.0.2`.
|
||||
- [`plans/003-V0_0_3_GIT_WRITE_PLAN.md`](plans/003-V0_0_3_GIT_WRITE_PLAN.md) — plan historique de la stable `0.0.3`, écriture Git contrôlée et push gardé.
|
||||
- [`plans/004-V0_0_4_POSTGRES_FOUNDATION_PLAN.md`](plans/004-V0_0_4_POSTGRES_FOUNDATION_PLAN.md) — plan actif de la fondation PostgreSQL partagée `0.0.4`.
|
||||
|
||||
## Validation
|
||||
|
||||
|
||||
@@ -1,20 +1,22 @@
|
||||
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
|
||||
<!-- version: 18 -->
|
||||
<!-- version: 19 -->
|
||||
|
||||
# Profil du projet Knowledge
|
||||
|
||||
## Baseline autoritaire
|
||||
|
||||
La stable produit depuis laquelle `0.0.3` est ouverte est :
|
||||
La stable produit depuis laquelle `0.0.4` est ouverte est :
|
||||
|
||||
```text
|
||||
Knowledge stable tag v0.0.2
|
||||
Knowledge stable commit 183d354a67bec6d2d512c4898f5189759a6120b0
|
||||
Knowledge archive SHA-256 0e518c7eaad115811cccc8fb2b38a1e68150ec985c2ca72ec08a9ca5bbb202ce
|
||||
Knowledge publish report sasedev-knowledge-0.0.2-publish.001-report.md = PASS
|
||||
Knowledge start prompt prompts/003-V0_0_3_START_PROMPT.md
|
||||
Knowledge stable tag v0.0.3
|
||||
Knowledge stable commit b3823972449150b72905930b806d4d15471cddce
|
||||
Knowledge archive SHA-256 82407dc2a83be878daa65692f975681428d0adc721ff249c3c9020e3a9d1f29d
|
||||
Knowledge publish report sasedev-knowledge-0.0.3-publish.001-report.md = PASS
|
||||
Knowledge start prompt prompts/004-V0_0_4_START_PROMPT.md
|
||||
```
|
||||
|
||||
L'archive taggée `v0.0.3` a été vérifiée avant le cadrage `0.0.4-alpha.1` : `VERSION` et le workspace Cargo valent `0.0.3`, les douze deltas et douze histories `0.0.3` sont appariés, `rel.1.fix.1 = PASS` clôt la release et le commentaire ZIP contient le commit stable ci-dessus.
|
||||
|
||||
La fondation `0.0.1` a été construite sous PGR `v0.1.1`. Cette identité reste historique dans les artefacts `0.0.1`.
|
||||
|
||||
Le démarrage explicite de `0.0.2` a réévalué PGR et a retenu la stable suivante comme source d'adoption :
|
||||
@@ -91,7 +93,7 @@ Le détail de la migration depuis les owners PGR `v0.1.3`, y compris les décisi
|
||||
| Synchronisation sans webhook | `KEEP-LOCAL` | explicite/périodique convergent vers le même cas d'usage ; hooks/webhooks restent accélérateurs |
|
||||
| Scheduler périodique concret | `DEFER` | créer seulement lorsque son owner runtime/lifecycle est démontré |
|
||||
| Dernière révision observée en `0.0.2` | `KEEP-LOCAL` | fournie par l'appelant et retournée par le cas d'usage ; pas de pseudo-persistance locale |
|
||||
| PostgreSQL | `KEEP-LOCAL` | une base logique partagée future pour état transversal/projections ; jamais vérité du contenu Git publié |
|
||||
| PostgreSQL | `KEEP-LOCAL` | une base logique partagée ; `0.0.4` matérialise sa première fondation sans déplacer la vérité éditoriale de Git |
|
||||
| Rust stable / édition 2024 | `ADOPT` | owner local `docs/rules/510-RUST_CARGO.md` |
|
||||
| Workspace Cargo | `ADOPT` | configuration locale + owner `510-RUST_CARGO.md` |
|
||||
| `Cargo.lock` | `KEEP-LOCAL` | généré localement et ignoré ; manifests Cargo versionnés |
|
||||
@@ -105,8 +107,8 @@ Le détail de la migration depuis les owners PGR `v0.1.3`, y compris les décisi
|
||||
| Racine frontend | `KEEP-LOCAL` | package partagé `Web/knowledge-template-lab/` |
|
||||
| Templates statiques Web | `KEEP-LOCAL` | harness de conception/validation ; rendu runtime Maud |
|
||||
| Intégration manifest Vite / Maud | `KEEP-LOCAL` | matérialisée dans `knowledge-web-lib` |
|
||||
| Driver/ORM PostgreSQL | `DEFER` | reprendre à la première implémentation persistante réelle |
|
||||
| Migrations PostgreSQL | `DEFER` | reprendre avec le premier schéma réel |
|
||||
| Toolkit PostgreSQL | `KEEP-LOCAL` | `tokio-postgres` + `deadpool-postgres`, async/Tokio et SQL explicite ; aucun ORM sélectionné |
|
||||
| Migrations PostgreSQL | `KEEP-LOCAL` | SQL versionné possédé par `knowledge-store-postgres-lib`, appliqué explicitement via Refinery |
|
||||
| Moteur de recherche | `DEFER` | commencer par capacités PostgreSQL/index applicatif lorsque ce scope sera engagé |
|
||||
| Fournisseur d'auth externe | `DEFER` | reprendre lorsque le workflow utilisateur l'exige |
|
||||
| Surface admin par application | `KEEP-LOCAL` | chaque serveur protège ses opérations privilégiées ; URL exacte différée |
|
||||
@@ -133,12 +135,17 @@ knowledge-snippets-server launcher snippets mince
|
||||
|
||||
`knowledge-git-lib` devient réelle en `0.0.2-alpha.2` puis implémente le chemin de lecture Git dans `alpha.3`. `knowledge-app-lib` devient réelle en `0.0.2-alpha.5` : l'orchestration refresh / résolution / comparaison / snapshot confirme une responsabilité application partagée distincte du backend Git et des launchers.
|
||||
|
||||
`0.0.4-alpha.1` retient comme prochaine responsabilité réelle, sans encore la matérialiser dans cette tranche :
|
||||
|
||||
```text
|
||||
knowledge-store-postgres-lib pool, migrations et état applicatif PostgreSQL partagé
|
||||
```
|
||||
|
||||
Les responsabilités suivantes restent candidates et non matérialisées :
|
||||
|
||||
```text
|
||||
knowledge-store-postgres-lib état applicatif PostgreSQL partagé
|
||||
knowledge-forge-gitea-lib adapter Gitea optionnel
|
||||
knowledge-logging-lib diagnostics partagés, seulement sur besoin multi-runtime réel
|
||||
knowledge-forge-gitea-lib adapter Gitea optionnel
|
||||
knowledge-logging-lib diagnostics partagés, seulement sur besoin multi-runtime réel
|
||||
```
|
||||
|
||||
Règles de création :
|
||||
@@ -177,3 +184,25 @@ Restent différés après `0.0.2` : adapter Gitea, PostgreSQL/migrations, moteur
|
||||
La revue d'horizon `0.0.2-beta.1` n'avait réservé aucune release suivante. L'ouverture explicite de `0.0.3` a consommé uniquement le `DEFER` d'écriture Git contrôlée : worktree d'écriture isolé, commit candidat et push de branche gardé. Rebase/merge automatique et workflow complet de proposition restent différés.
|
||||
|
||||
La revue `0.0.3-beta.1` sélectionne désormais la fondation PostgreSQL partagée comme prochaine mission `0.0.4`, sans préchoisir son driver/ORM avant l'étude de démarrage. Elle réordonne ensuite l'horizon produit pour rendre visibles les phases de modèles/projections, templates publics, templates admin, intégration Actix/Maud puis workflow de gestion/publication. Gitea, scheduler, recherche avancée, quatrième application admin et partage multi-processus restent différés tant que leurs déclencheurs ne sont pas matérialisés.
|
||||
|
||||
## Ouverture `0.0.4` — fondation PostgreSQL partagée
|
||||
|
||||
Après publication vérifiée de `v0.0.3`, `0.0.4-alpha.1` consomme les `DEFER` portant sur le toolkit PostgreSQL et les migrations.
|
||||
|
||||
La décision locale est :
|
||||
|
||||
```text
|
||||
owner prévu knowledge-store-postgres-lib
|
||||
driver tokio-postgres 0.7
|
||||
modèle SQL explicite, sans ORM
|
||||
pool deadpool-postgres 0.14
|
||||
migrations SQL versionné + Refinery 0.9
|
||||
premier état source logique + dernière révision synchronisée
|
||||
autorité contenu Git
|
||||
```
|
||||
|
||||
Aucune crate n'est créée pendant `alpha.1`. La tranche établit seulement l'étude et le plan qui autoriseront `alpha.2` après gate opérateur `PASS`.
|
||||
|
||||
La configuration physique Git reste possédée par `knowledge-git-lib`. Le premier schéma PostgreSQL ne stocke pas de credentials Git et ne transforme pas les URLs/paths physiques en vérité métier. La configuration de connexion PostgreSQL est injectée par la composition, non lue implicitement par la future crate de stockage.
|
||||
|
||||
Les `DEFER` Gitea/forge, scheduler, recherche avancée, auth/capabilities, formats finaux de contenu, quatrième application admin, partage multi-processus de racine Git, LFS/submodules et rétention avancée restent inchangés. L'horizon `0.0.5` à `0.0.10` reste cohérent et n'est pas replanifié par cette étude.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
|
||||
<!-- version: 18 -->
|
||||
<!-- version: 19 -->
|
||||
|
||||
# Architecture de fondation Knowledge
|
||||
|
||||
@@ -36,6 +36,8 @@ knowledge-app-lib cas d'usage partagé de synchronisation Changed/Unchanged
|
||||
|
||||
Les deux crates `-api` sont justifiées par des implémentations réellement remplaçables ou multiples. Elles restent sans runtime, sans logging propre et sans dépendance à Actix, Gitea ou PostgreSQL.
|
||||
|
||||
`0.0.4-alpha.1` retient `knowledge-store-postgres-lib` comme prochain owner concret du pool, des migrations et de l'état PostgreSQL partagé. Cette crate n'est pas encore créée dans la tranche de cadrage et aucun `knowledge-store-api` symétrique n'est introduit sans besoin de substitution démontré.
|
||||
|
||||
Les tests unitaires Rust sont désormais placés hors de `src/` sous `unit_tests/`, conformément à la convention locale Knowledge sélectionnée sur l'option permise par PGR.
|
||||
|
||||
Le workspace est une application déployable à train de release unique. Knowledge choisit néanmoins de conserver `Cargo.lock` comme état généré local et ignoré par Git ; les manifests Cargo portent le contrat versionné des dépendances. Les artefacts Cargo sont dirigés hors du dépôt vers `../builds/sasedev-knowledge/target/`.
|
||||
@@ -300,7 +302,30 @@ La baseline retient **une base PostgreSQL logique partagée** par les trois appl
|
||||
|
||||
Ce choix est justifié par l'état transversal : identités, sessions, propositions, synchronisation, relations entre familles, index et recherche. Il évite trois bases divergentes pour des concepts qui appartiennent à la même plateforme.
|
||||
|
||||
PostgreSQL MAY contenir des documents/index/métadonnées dérivés et assurer une première capacité de recherche. Aucun moteur de recherche externe n'est sélectionné en `0.0.1`.
|
||||
### Fondation sélectionnée pour `0.0.4`
|
||||
|
||||
`0.0.4-alpha.1` sélectionne `tokio-postgres` comme driver PostgreSQL async natif, `deadpool-postgres` comme pool et Refinery comme mécanisme de migrations. La future crate `knowledge-store-postgres-lib` possédera la composition de ces trois responsabilités, la conversion de leurs erreurs en erreurs publiques récupérables et les opérations PostgreSQL concrètes. Knowledge ne sélectionne pas d'ORM, ne recherche pas d'abstraction multi-SGBD et n'introduit pas de `knowledge-store-api` tant qu'une seconde implémentation de stockage ou une frontière passive réellement indépendante n'est pas démontrée.
|
||||
|
||||
La configuration est injectée par la composition : la crate de stockage reçoit une URL/options de connexion et des paramètres de pool. Elle ne lit pas directement les variables d'environnement du processus et ne journalise jamais l'URL ou les credentials. Une connexion ou migration impossible retourne une erreur ; aucun fallback fichier/mémoire ne masque l'indisponibilité PostgreSQL.
|
||||
|
||||
Le premier schéma utile est volontairement borné :
|
||||
|
||||
```text
|
||||
knowledge_sources
|
||||
source_id TEXT PRIMARY KEY
|
||||
family TEXT NOT NULL
|
||||
git_reference TEXT NOT NULL
|
||||
|
||||
knowledge_source_sync_state
|
||||
source_id TEXT PRIMARY KEY REFERENCES knowledge_sources(source_id)
|
||||
last_synchronized_revision TEXT NOT NULL
|
||||
```
|
||||
|
||||
`family` reste aligné sur `ContentFamily` et sera contraint aux valeurs supportées par le domaine. `git_reference` est la référence Git logique à suivre ; la localisation physique locale/remote et les credentials restent hors de cette table et sous les frontières de configuration appropriées. La dernière révision synchronisée est un état applicatif, pas une nouvelle autorité de contenu : elle peut être reconstruite/réconciliée à partir de Git et une valeur obsolète provoque au pire une resynchronisation.
|
||||
|
||||
Les migrations sont des fichiers SQL versionnés placés sous l'owner de stockage et appliqués explicitement par Refinery. La stratégie de test utilise une URL PostgreSQL de test fournie explicitement et un schéma unique éphémère par exécution ; la gate doit être `BLOCKED` si le service PostgreSQL requis n'est pas disponible, jamais convertir cette absence en test artificiellement passé. Le même mécanisme peut cibler un PostgreSQL local ou un service PostgreSQL éphémère de CI sans rendre Docker obligatoire pour la bibliothèque.
|
||||
|
||||
PostgreSQL MAY contenir ultérieurement des documents/index/métadonnées dérivés et assurer une première capacité de recherche. Le corps publié et ses métadonnées éditoriales autoritaires restent dans Git. `0.0.4` ne matérialise pas encore le parsing/projection final prévu par l'horizon `0.0.5`.
|
||||
|
||||
Les enregistrements dérivés doivent porter au minimum l'identité de famille/source et la révision Git afin de savoir exactement quel contenu ils représentent.
|
||||
|
||||
@@ -399,6 +424,23 @@ Le push distant gardé reste réservé à `alpha.4`. `alpha.3` ne met à jour au
|
||||
|
||||
PostgreSQL, workflow complet de proposition, auth/admin, parsing final et adapter Gitea restent des missions distinctes.
|
||||
|
||||
## Ouverture `0.0.4` — persistance partagée
|
||||
|
||||
La stable `v0.0.3` ayant fermé le chemin Git générique, `0.0.4` matérialise la première persistance partagée nécessaire aux prochains cas d'usage sans déplacer l'autorité éditoriale.
|
||||
|
||||
La trajectoire retenue est :
|
||||
|
||||
```text
|
||||
alpha.1 étude, ownership, schéma, migrations et tests
|
||||
alpha.2 crate PostgreSQL + pool + première migration
|
||||
alpha.3 persistance source logique + état de synchronisation
|
||||
alpha.4 raccord applicatif de la révision précédente persistée
|
||||
beta réconciliation + horizon
|
||||
rc/rel stabilisation et publication
|
||||
```
|
||||
|
||||
Le raccord applicatif futur doit conserver la primitive `synchronize_repository` provider-neutral : la persistance fournit la révision précédente et reçoit la révision observée, mais ne devient ni un backend Git ni une condition pour interpréter l'identité du commit.
|
||||
|
||||
## 10. Administration
|
||||
|
||||
L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité.
|
||||
|
||||
215
docs/plans/004-V0_0_4_POSTGRES_FOUNDATION_PLAN.md
Normal file
215
docs/plans/004-V0_0_4_POSTGRES_FOUNDATION_PLAN.md
Normal file
@@ -0,0 +1,215 @@
|
||||
<!-- file: docs/plans/004-V0_0_4_POSTGRES_FOUNDATION_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.0.4 — fondation PostgreSQL partagée
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Release ouverte depuis la stable autoritaire :
|
||||
|
||||
```text
|
||||
Knowledge tag v0.0.3
|
||||
Knowledge commit b3823972449150b72905930b806d4d15471cddce
|
||||
Knowledge SHA-256 82407dc2a83be878daa65692f975681428d0adc721ff249c3c9020e3a9d1f29d
|
||||
publish report sasedev-knowledge-0.0.3-publish.001-report.md = PASS
|
||||
start prompt prompts/004-V0_0_4_START_PROMPT.md
|
||||
```
|
||||
|
||||
Le plan est actif à partir de `0.0.4-alpha.1`. PGR `v0.1.3` reste une provenance historique et aucune adoption PGR nouvelle n'est engagée.
|
||||
|
||||
## Mission
|
||||
|
||||
Matérialiser la première fondation PostgreSQL partagée de Knowledge afin de conserver un état transversal minimal pour les sources et la synchronisation, avec migrations reproductibles et tests PostgreSQL réels, sans déplacer la vérité éditoriale hors de Git.
|
||||
|
||||
À la clôture de `0.0.4`, le workspace doit posséder un owner PostgreSQL concret et partagé, un premier schéma versionné, un pool/configuration injectables et un chemin persistant pour la dernière révision synchronisée utilisable par l'orchestration applicative.
|
||||
|
||||
## État acquis et questions ouvertes
|
||||
|
||||
Acquis depuis `0.0.3` :
|
||||
|
||||
- Git générique de lecture et snapshot ;
|
||||
- écriture Git contrôlée et push gardé ;
|
||||
- `knowledge-app-lib` pour la synchronisation provider-neutral ;
|
||||
- trois launchers Web et composition Maud/Vite ;
|
||||
- base PostgreSQL logique partagée déjà retenue par l'architecture ;
|
||||
- horizon produit `0.0.5` à `0.0.10` révisable.
|
||||
|
||||
Décisions de `alpha.1` :
|
||||
|
||||
- `tokio-postgres` sélectionné comme driver, `deadpool-postgres` comme pool et Refinery comme migrator, sans ORM ;
|
||||
- `knowledge-store-postgres-lib` retenu comme owner ;
|
||||
- migrations SQL versionnées possédées par la crate ;
|
||||
- premier schéma limité aux sources logiques et à la dernière révision synchronisée ;
|
||||
- test PostgreSQL via URL explicitement fournie et schéma éphémère isolé ;
|
||||
- aucune lecture implicite de secrets par la crate et aucun fallback de stockage.
|
||||
|
||||
Questions laissées aux tranches d'implémentation :
|
||||
|
||||
- surface publique minimale exacte de `PostgresStore` et de sa configuration ;
|
||||
- paramètres de pool utiles au produit sans exposer les types Deadpool ;
|
||||
- besoin réel d'un contrat passif de persistance dans `knowledge-app-lib` pour le raccord `alpha.4` ;
|
||||
- backend TLS à sélectionner uniquement si le déploiement visé l'exige.
|
||||
|
||||
## Scope
|
||||
|
||||
`0.0.4` couvre :
|
||||
|
||||
- une crate PostgreSQL partagée réelle ;
|
||||
- `tokio-postgres` PostgreSQL/Tokio avec pool `deadpool-postgres` ;
|
||||
- première migration reproductible ;
|
||||
- persistance de `SourceId`, `ContentFamily`, référence Git logique et dernière révision synchronisée ;
|
||||
- erreurs récupérables sans fuite de credentials ;
|
||||
- tests unitaires ciblés et intégration PostgreSQL réelle ;
|
||||
- raccord applicatif minimal permettant d'utiliser l'état persistant sans modifier le contrat Git ;
|
||||
- documentation durable, beta, RC et fermeture stable.
|
||||
|
||||
## Hors scope
|
||||
|
||||
Restent hors `0.0.4` :
|
||||
|
||||
- corps/métadonnées éditoriales publiées en PostgreSQL comme vérité ;
|
||||
- modèles de contenu finaux et parsing complet ;
|
||||
- projections finales/indexation détaillée ;
|
||||
- recherche avancée ;
|
||||
- Gitea/forge et webhooks spécifiques ;
|
||||
- scheduler/jobs ;
|
||||
- auth/session/rôles/capabilities ;
|
||||
- propositions/revues/publication produit ;
|
||||
- templates publics/admin et routes finales ;
|
||||
- quatrième application admin ;
|
||||
- rebase/merge automatique ;
|
||||
- partage multi-processus de la racine Git ;
|
||||
- LFS/submodules et rétention avancée.
|
||||
|
||||
## Stratégie de validation
|
||||
|
||||
La validation reste proportionnée à chaque tranche.
|
||||
|
||||
Les invariants documentaires et Rust continuent d'utiliser :
|
||||
|
||||
```text
|
||||
Markdown + hygiène texte
|
||||
cargo fmt --all
|
||||
cargo fmt --all -- --check
|
||||
audits Rust locaux
|
||||
cargo metadata / cargo check
|
||||
Clippy strict
|
||||
tests ciblés puis workspace lorsque le contrat devient transverse
|
||||
git diff --check / git diff --cached --check
|
||||
```
|
||||
|
||||
À partir de la première migration, une gate PostgreSQL réelle devient obligatoire. Elle utilise `KNOWLEDGE_POSTGRES_TEST_URL`, isole chaque exécution dans un schéma temporaire et nettoie cet état après test. Si la tranche requiert cette preuve et qu'aucun PostgreSQL n'est disponible, le statut est `BLOCKED`.
|
||||
|
||||
Les gates Web/npm ne sont pas rejouées pour les alphas sans diff `Web/` ou contrat Web. Les phases de stabilisation peuvent imposer une non-régression runtime globale.
|
||||
|
||||
## Trajectoire prévisionnelle
|
||||
|
||||
### alpha.1 — baseline, étude et cadrage
|
||||
|
||||
- vérifier intégralement `v0.0.3` et `publish.001` ;
|
||||
- relire owners, architecture, deltas/histories, `DEFER` et horizon ;
|
||||
- confirmer l'autonomie normative Knowledge ;
|
||||
- comparer les options PostgreSQL actuelles ;
|
||||
- décider le driver `tokio-postgres`, le pool `deadpool-postgres`, Refinery, l'owner, le schéma, la configuration et la stratégie de test ;
|
||||
- créer l'étude `008`, le présent plan et le delta ;
|
||||
- ne modifier aucun code produit, dépendance ou migration ;
|
||||
- autoriser `alpha.2` seulement après `PASS` opérateur.
|
||||
|
||||
### alpha.2 — owner PostgreSQL, pool et première migration
|
||||
|
||||
- créer `knowledge-store-postgres-lib` avec façade crate-root conforme ;
|
||||
- ajouter uniquement les dépendances/features nécessaires de `tokio-postgres`, `deadpool-postgres`, Refinery et Tokio ;
|
||||
- matérialiser la configuration explicite de connexion/pool et les erreurs publiques sans fuite de secret ;
|
||||
- ajouter `migrations/` sous la crate et la migration initiale `knowledge_sources` + `knowledge_source_sync_state` ;
|
||||
- exposer une opération explicite d'application des migrations ;
|
||||
- prouver la migration sur PostgreSQL réel avec schéma de test isolé ;
|
||||
- ne raccorder encore aucun launcher si aucun use case runtime ne l'exige.
|
||||
|
||||
### alpha.3 — persistance de source et état de synchronisation
|
||||
|
||||
- matérialiser les opérations minimales de création/mise à jour/lecture de configuration logique ;
|
||||
- convertir `ContentFamily`, `SourceId`, référence logique et `GitRevision` sans faire remonter les types PostgreSQL/Deadpool/Refinery au domaine ;
|
||||
- lire et enregistrer `last_synchronized_revision` ;
|
||||
- tester insertion, mise à jour, absence d'état, contraintes et isolation des sources sur PostgreSQL réel ;
|
||||
- prouver qu'aucun corps de contenu ou credential Git n'est persisté par ce schéma.
|
||||
|
||||
### alpha.4 — raccord applicatif persistant
|
||||
|
||||
- conserver `synchronize_repository` comme primitive provider-neutral ;
|
||||
- ajouter seulement le contrat applicatif nécessaire pour charger/enregistrer la révision précédente sans dépendance au driver/pool/migrator dans `knowledge-app-lib` ;
|
||||
- implémenter ce contrat côté `knowledge-store-postgres-lib` ;
|
||||
- composer un cas d'usage persistant qui charge l'état, synchronise via Git et enregistre la révision uniquement après succès ;
|
||||
- tester Changed/Unchanged, première synchronisation et absence d'écriture après erreur Git/store ;
|
||||
- ne pas ajouter scheduler, projection de contenu ou route Web.
|
||||
|
||||
### beta.1 — réconciliation et revue d'horizon
|
||||
|
||||
- réconcilier le schéma, l'API, le lifecycle et les tests réellement obtenus ;
|
||||
- vérifier que Git reste l'autorité du contenu et que le state PostgreSQL est reconstructible ;
|
||||
- préparer `CHANGELOG.md` en `0.0.4 (candidate)` seulement à ce stade ;
|
||||
- réévaluer `0.0.5` modèles/projections et au moins `0.0.6` / `0.0.7` ;
|
||||
- préparer `prompts/005-V0_0_5_START_PROMPT.md` uniquement si la prochaine mission reste suffisamment décidée ;
|
||||
- rejouer les preuves PostgreSQL et non-régression workspace nécessaires à la stabilisation.
|
||||
|
||||
### rc.1 — candidate stable
|
||||
|
||||
- geler le scope ;
|
||||
- rejouer la gate complète Rust/PostgreSQL applicable ;
|
||||
- vérifier migrations depuis un schéma vide, persistance source/state et raccord applicatif ;
|
||||
- vérifier deltas/histories, hors-scope et hygiène de livraison ;
|
||||
- rejouer la non-régression Web/runtime exigée par la phase de stabilisation ;
|
||||
- n'introduire aucune fonctionnalité nouvelle.
|
||||
|
||||
### rel.1 — promotion stable pré-tag
|
||||
|
||||
- promouvoir mécaniquement `VERSION` et workspace vers `0.0.4` ;
|
||||
- finaliser changelog, README, roadmap et plan depuis le résultat réellement acquis ;
|
||||
- vérifier le handoff `0.0.5` seulement s'il a été autorisé par la revue beta ;
|
||||
- rejouer la gate stable complète ;
|
||||
- produire le history observé avant commit stable/tag ;
|
||||
- ne fabriquer aucun rapport post-tag avant publication réelle.
|
||||
|
||||
## Déclencheurs de REPLAN
|
||||
|
||||
REPLAN avant de poursuivre si :
|
||||
|
||||
- les versions retenues de `tokio-postgres`, `deadpool-postgres` ou Refinery sont incompatibles avec la toolchain stable réellement utilisée ou les lints locaux ;
|
||||
- le premier schéma exige déjà de stocker le corps éditorial publié pour fonctionner ;
|
||||
- une seconde implémentation de store rend une frontière `-api` réellement nécessaire ;
|
||||
- le raccord applicatif crée une dépendance cyclique ou oblige le domaine à dépendre du driver, du pool ou du migrator ;
|
||||
- la stratégie de test par schéma isolé ne peut pas prouver les migrations de manière fiable ;
|
||||
- une connexion PostgreSQL devient une dépendance obligatoire de tous les launchers sans cas d'usage qui la justifie ;
|
||||
- un scheduler, worker ou service réseau supplémentaire devient nécessaire pour fermer la mission ;
|
||||
- une tranche atteint `.fix.3`.
|
||||
|
||||
La conclusion du REPLAN utilise `CONTINUE`, `SPLIT`, `CONTINUE-NEXT-SESSION` ou `ABANDON`.
|
||||
|
||||
## Clôture et transition
|
||||
|
||||
`0.0.4` est fermable lorsque :
|
||||
|
||||
- `knowledge-store-postgres-lib` est un owner réel et testé ;
|
||||
- une base PostgreSQL vide peut être migrée de manière reproductible ;
|
||||
- les sources logiques et leur dernière révision synchronisée sont persistées ;
|
||||
- le pool et les erreurs ne fuient aucun secret ;
|
||||
- l'indisponibilité PostgreSQL n'est jamais masquée par un fallback ;
|
||||
- l'orchestration peut utiliser la révision persistée sans coupler le domaine à SQL ;
|
||||
- Git reste l'autorité de toute donnée éditoriale publiée ;
|
||||
- beta/RC ont fermé les non-régressions et l'horizon.
|
||||
|
||||
À l'ouverture, seule `alpha.1` est matérialisée. Aucun history `0.0.4` n'existe avant la gate opérateur de cette tranche.
|
||||
|
||||
## Revue d'horizon
|
||||
|
||||
L'étude `alpha.1` ne modifie pas l'horizon issu de `0.0.3-beta.1` :
|
||||
|
||||
```text
|
||||
0.0.5 modèles de contenu et projections PGR/HOWTO/snippet
|
||||
0.0.6 templates publics des trois sites
|
||||
0.0.7 templates d'administration des trois sites
|
||||
0.0.8 lecture publique Actix Web / Maud
|
||||
0.0.9 administration Actix Web / Maud et autorisation
|
||||
0.0.10 gestion, proposition, revue et publication
|
||||
```
|
||||
|
||||
La revue beta de `0.0.4` devra confirmer ou replanifier au minimum `0.0.5`, `0.0.6` et `0.0.7` à partir de la persistance réellement obtenue.
|
||||
255
docs/studies/008-V0_0_4_POSTGRES_FOUNDATION_STUDY.md
Normal file
255
docs/studies/008-V0_0_4_POSTGRES_FOUNDATION_STUDY.md
Normal file
@@ -0,0 +1,255 @@
|
||||
<!-- file: docs/studies/008-V0_0_4_POSTGRES_FOUNDATION_STUDY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Étude 0.0.4 — fondation PostgreSQL partagée
|
||||
|
||||
## Objet
|
||||
|
||||
Cette étude de `0.0.4-alpha.1` décide l'ownership et la première architecture PostgreSQL de SaseDev Knowledge avant toute implémentation de stockage.
|
||||
|
||||
Elle part exclusivement de la stable Knowledge `v0.0.3` publiée et vérifiée. Elle ne consulte ni n'adopte une nouvelle version de PGR.
|
||||
|
||||
## Baseline autoritaire vérifiée
|
||||
|
||||
La baseline reçue au démarrage est :
|
||||
|
||||
```text
|
||||
tag v0.0.3
|
||||
commit b3823972449150b72905930b806d4d15471cddce
|
||||
archive sasedev-knowledge-v0.0.3.zip
|
||||
SHA-256 82407dc2a83be878daa65692f975681428d0adc721ff249c3c9020e3a9d1f29d
|
||||
report sasedev-knowledge-0.0.3-publish.001-report.md = PASS
|
||||
```
|
||||
|
||||
La vérification de démarrage confirme :
|
||||
|
||||
- `VERSION = 0.0.3` et `[workspace.package].version = 0.0.3` dans l'archive ;
|
||||
- neuf packages Cargo et aucune crate PostgreSQL déjà matérialisée ;
|
||||
- douze deltas et douze histories `0.0.3`, appariés jusqu'à `rel.1.fix.1 = PASS` ;
|
||||
- Git lecture/écriture contrôlée stable et provider-neutral ;
|
||||
- `ROADMAP.md` engage déjà `0.0.4` comme fondation PostgreSQL partagée ;
|
||||
- `prompts/004-V0_0_4_START_PROMPT.md` est présent dans la stable ;
|
||||
- PGR `v0.1.3` reste uniquement une provenance historique de l'adoption fermée en `0.0.2`.
|
||||
|
||||
## Contraintes acquises
|
||||
|
||||
La fondation doit préserver simultanément :
|
||||
|
||||
```text
|
||||
Git vérité du contenu publié
|
||||
PostgreSQL état applicatif transversal et projections reconstructibles
|
||||
knowledge-domain-lib aucun type SQL/Actix/Gitea
|
||||
knowledge-git-api contrats Git provider-neutral
|
||||
knowledge-git-lib configuration physique et opérations Git
|
||||
knowledge-app-lib orchestration applicative
|
||||
knowledge-web-lib composition Web partagée
|
||||
```
|
||||
|
||||
La première implémentation PostgreSQL ne doit pas entraîner par symétrie une nouvelle crate `-api`, un service réseau, trois bases séparées, un ORM complet, un scheduler ou un modèle de contenu final.
|
||||
|
||||
## Sources techniques consultées
|
||||
|
||||
Consultation effectuée le `2026-09-30` sur les documentations publiées des crates comparées :
|
||||
|
||||
- SQLx `0.9.0` et ses features/MSRV : <https://docs.rs/crate/sqlx/0.9.0/source/Cargo.toml.orig> ;
|
||||
- `PgPool` SQLx : <https://docs.rs/sqlx/0.9.0/sqlx/postgres/type.PgPool.html> ;
|
||||
- migrations et `migrate!` SQLx : <https://docs.rs/sqlx/0.9.0/sqlx/migrate/index.html> et <https://docs.rs/sqlx/0.9.0/sqlx/macro.migrate.html> ;
|
||||
- `tokio-postgres` `0.7.18` : <https://docs.rs/tokio-postgres/0.7.18/tokio_postgres/> ;
|
||||
- `deadpool-postgres` `0.14.2` : <https://docs.rs/deadpool-postgres/0.14.2/deadpool_postgres/> ;
|
||||
- Diesel `2.3.13` : <https://docs.rs/crate/diesel/2.3.13> ;
|
||||
- `diesel-async` `0.9.2` : <https://docs.rs/crate/diesel-async/0.9.2> ;
|
||||
- SeaORM `2.0.4` : <https://docs.rs/crate/sea-orm/2.0.4> ;
|
||||
- Refinery `0.9.2` : <https://docs.rs/crate/refinery/0.9.2>.
|
||||
|
||||
## Comparaison des options Rust
|
||||
|
||||
État des versions consultées le `2026-09-30` : SQLx `0.9.0`, `tokio-postgres` `0.7.18`, `deadpool-postgres` `0.14.2`, Diesel `2.3.13`, `diesel-async` `0.9.2`, SeaORM `2.0.4` et Refinery `0.9.2`.
|
||||
|
||||
| Option | Atouts pour Knowledge | Coûts / inadéquations | Décision |
|
||||
|----------------------------------------|---------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|----------|
|
||||
| `tokio-postgres` + Deadpool + Refinery | driver PostgreSQL async natif, responsabilités séparées, SQL explicite, pool spécialisé et migrations SQL intégrées | trois briques à versionner et intégrer ; la façade Knowledge doit normaliser leurs erreurs | `SELECT` |
|
||||
| SQLx `0.9` | async/Tokio, PostgreSQL natif, pool et migrations intégrés, SQL explicite | toolkit multi-SGBD plus large que le besoin ; MSRV `1.94`; ses macros de requêtes ne sont pas nécessaires ici | `REJECT` |
|
||||
| Diesel + `diesel-async` | typage/DSL fort, écosystème migrations, pooling disponible | modèle ORM/query-builder plus large que le premier schéma et davantage de surface de génération/traits | `REJECT` |
|
||||
| SeaORM | ORM async complet, migrations, relations et modèles riches | surdimensionné avant les modèles/projections `0.0.5`; risque de faire remonter l'ORM dans les contrats | `REJECT` |
|
||||
|
||||
La sélection privilégie des responsabilités explicitement bornées plutôt qu'un toolkit généraliste. Knowledge cible PostgreSQL comme choix de produit : l'abstraction multi-SGBD de SQLx n'apporte donc pas de valeur attendue pour cette fondation. Le coût de composition de trois briques reste acceptable parce que chacune possède une responsabilité unique et vérifiable.
|
||||
|
||||
## Décision de dépendance
|
||||
|
||||
La première implémentation utilisera `tokio-postgres` comme driver PostgreSQL asynchrone natif, `deadpool-postgres` comme pool et `refinery` comme owner technique des migrations SQL. Aucun ORM n'est sélectionné et aucune abstraction multi-SGBD n'est recherchée.
|
||||
|
||||
Les versions observées pendant l'étude sont `tokio-postgres 0.7.18`, `deadpool-postgres 0.14.2` et `refinery 0.9.2`. `tokio-postgres` et `deadpool-postgres` déclarent actuellement Rust 2024 avec un MSRV `1.85`; Refinery vise les Rust stable récents. `alpha.2` doit néanmoins revalider les versions stables compatibles au moment exact de leur ajout au manifest, conformément à la politique locale de dépendances, sans downgrade silencieux.
|
||||
|
||||
La séparation est volontaire :
|
||||
|
||||
```text
|
||||
tokio-postgres protocole, connexion, requêtes et transactions PostgreSQL
|
||||
deadpool-postgres cycle de vie et mutualisation des connexions
|
||||
refinery découverte, historique et application des migrations SQL
|
||||
```
|
||||
|
||||
La façade publique de `knowledge-store-postgres-lib` masque ces dépendances et normalise leurs erreurs dans le type d'erreur de la crate. Les types `tokio-postgres`, Deadpool ou Refinery ne doivent pas remonter dans `knowledge-domain-lib` ni dans les contrats applicatifs.
|
||||
|
||||
Un backend TLS n'est pas figé par `alpha.1`. Si la cible de déploiement PostgreSQL exige TLS, la tranche qui matérialise la connexion doit sélectionner explicitement l'intégration TLS minimale compatible avec `tokio-postgres` au lieu d'hériter d'un défaut implicite.
|
||||
|
||||
## Ownership
|
||||
|
||||
La responsabilité est suffisamment concrète pour justifier :
|
||||
|
||||
```text
|
||||
knowledge-store-postgres-lib
|
||||
```
|
||||
|
||||
Cette crate possédera :
|
||||
|
||||
- construction et lifecycle du pool `deadpool-postgres` ;
|
||||
- migrations SQL de Knowledge ;
|
||||
- mapping SQL des types nécessaires ;
|
||||
- persistance de configuration logique de source ;
|
||||
- persistance de l'état de synchronisation ;
|
||||
- erreurs publiques récupérables de cette frontière.
|
||||
|
||||
Elle dépendra des types domaine/Git strictement nécessaires, jamais l'inverse.
|
||||
|
||||
Aucun `knowledge-store-api` n'est créé en `0.0.4-alpha.1`. Si une deuxième implémentation réelle ou un besoin de fake transverse rend plus tard une frontière passive utile, cette décision sera réévaluée à partir d'un usage concret.
|
||||
|
||||
## Connexion, pool et secrets
|
||||
|
||||
La crate de stockage ne lit pas l'environnement. La composition lui fournit une configuration contenant au minimum l'URL PostgreSQL et les paramètres de pool retenus.
|
||||
|
||||
L'URL peut contenir un secret et respecte donc les invariants suivants :
|
||||
|
||||
- aucune valeur réelle versionnée ;
|
||||
- aucune URL complète dans les erreurs publiques ou logs ;
|
||||
- aucune valeur par défaut de production codée en dur ;
|
||||
- aucune tentative de fallback vers un fichier, SQLite ou un stockage mémoire si PostgreSQL est indisponible.
|
||||
|
||||
Le pool est partagé par l'instance applicative qui compose le store. Les trois produits peuvent pointer vers la même base logique sans que chaque launcher réimplémente sa propre couche SQL.
|
||||
|
||||
## Premier schéma utile
|
||||
|
||||
Le premier schéma est volontairement plus petit que l'état futur décrit dans l'architecture.
|
||||
|
||||
### `knowledge_sources`
|
||||
|
||||
```text
|
||||
source_id TEXT PRIMARY KEY
|
||||
family TEXT NOT NULL
|
||||
git_reference TEXT NOT NULL
|
||||
```
|
||||
|
||||
`source_id` correspond à `SourceId`. `family` représente `ContentFamily` avec une contrainte SQL sur les valeurs supportées. `git_reference` est la référence Git logique à résoudre, pas une URL remote ni un credential. Les valeurs `family` persistées sont `pgr`, `howto`, `snippet` et `project_local`; la migration doit les contraindre explicitement.
|
||||
|
||||
### `knowledge_source_sync_state`
|
||||
|
||||
```text
|
||||
source_id TEXT PRIMARY KEY REFERENCES knowledge_sources(source_id) ON DELETE CASCADE
|
||||
last_synchronized_revision TEXT NOT NULL
|
||||
```
|
||||
|
||||
La révision stockée représente la dernière révision effectivement acceptée par le cas d'usage de synchronisation. Elle est un état applicatif de comparaison. Git reste capable de fournir l'identité autoritaire et une valeur PostgreSQL perdue ou obsolète conduit à une nouvelle réconciliation, pas à une perte du contenu publié.
|
||||
|
||||
Le schéma n'ajoute pas encore :
|
||||
|
||||
- corps ou métadonnées éditoriales de contenu ;
|
||||
- révision indexée séparée avant l'implémentation réelle des projections ;
|
||||
- utilisateurs/sessions ;
|
||||
- propositions/revues ;
|
||||
- jobs ;
|
||||
- audit applicatif ;
|
||||
- moteur de recherche.
|
||||
|
||||
## Migrations
|
||||
|
||||
Les migrations sont des fichiers SQL versionnés sous :
|
||||
|
||||
```text
|
||||
crates/knowledge-store-postgres-lib/migrations/
|
||||
```
|
||||
|
||||
La crate embarque le jeu de migrations au build et expose une opération explicite d'application. Le schéma n'est pas créé implicitement à chaque requête.
|
||||
|
||||
Les migrations sont forward-only pour cette fondation : une correction de schéma publiée utilise une nouvelle migration. Un rollback destructif automatique n'est pas requis pour fermer `0.0.4`.
|
||||
|
||||
## Stratégie de test PostgreSQL
|
||||
|
||||
Le test réel doit prouver PostgreSQL, pas une imitation en mémoire.
|
||||
|
||||
La stratégie retenue est :
|
||||
|
||||
```text
|
||||
KNOWLEDGE_POSTGRES_TEST_URL
|
||||
-> PostgreSQL local ou service CI explicitement fourni
|
||||
-> création d'un schéma de test unique
|
||||
-> search_path borné à ce schéma
|
||||
-> application des migrations
|
||||
-> tests CRUD / état de synchronisation
|
||||
-> suppression du schéma
|
||||
```
|
||||
|
||||
Cette stratégie évite d'imposer Docker dans la bibliothèque tout en autorisant un service container en CI. L'absence du service requis pendant une gate qui exige le test PostgreSQL est `BLOCKED`, pas `PASS`.
|
||||
|
||||
Les tests unitaires sans PostgreSQL restent utiles pour les validations de types/configuration qui n'ont pas besoin d'un serveur réel, mais ils ne remplacent pas l'intégration PostgreSQL de migration et persistance.
|
||||
|
||||
## Raccord au cas d'usage de synchronisation
|
||||
|
||||
Le cas d'usage existant `synchronize_repository` reçoit actuellement `previous_revision` de son appelant. `0.0.4` doit conserver cette primitive provider-neutral.
|
||||
|
||||
Le raccord prévu est une orchestration supplémentaire qui :
|
||||
|
||||
```text
|
||||
charge last_synchronized_revision
|
||||
-> appelle synchronize_repository
|
||||
-> enregistre la révision observée après succès
|
||||
```
|
||||
|
||||
Un contrat passif de persistance peut vivre dans `knowledge-app-lib` si `alpha.4` démontre qu'il est nécessaire pour tester cette orchestration sans coupler l'application au driver PostgreSQL. Cette possibilité ne justifie pas à elle seule une crate `knowledge-store-api`.
|
||||
|
||||
## Indisponibilité PostgreSQL
|
||||
|
||||
Les erreurs de connexion, acquisition de pool, migration ou requête sont récupérables et typées à la frontière store.
|
||||
|
||||
Il n'existe pas de mode où une écriture est annoncée persistée alors que PostgreSQL ne l'est pas. Une future façade publique pourra continuer à servir un contenu Git déjà matérialisé seulement si son cas d'usage n'exige pas le store ; cette politique appartient à la composition de la façade, pas à un fallback interne de la crate de stockage.
|
||||
|
||||
## Impact sur les trois applications
|
||||
|
||||
`0.0.4` ne crée pas trois implémentations ou trois schémas par façade. `knowledge-store-postgres-lib` est le propriétaire partagé et la base logique est commune.
|
||||
|
||||
Les launchers ne seront modifiés que lorsqu'un cas d'usage runtime exige réellement la connexion. La fondation peut donc être testée indépendamment avant d'ajouter une dépendance de démarrage PostgreSQL à `/` et `/healthz`.
|
||||
|
||||
## DEFER conservés
|
||||
|
||||
Restent explicitement hors scope de `0.0.4` :
|
||||
|
||||
- formats finaux et parsing PGR/HOWTO/snippet ;
|
||||
- projections de contenu finales et révision indexée détaillée ;
|
||||
- recherche avancée ;
|
||||
- Gitea/forge et webhooks forge-only ;
|
||||
- scheduler/jobs ;
|
||||
- auth, sessions et rôles/capabilities ;
|
||||
- propositions/revues/publication produit ;
|
||||
- templates publics/admin et routes finales ;
|
||||
- quatrième application admin ;
|
||||
- partage multi-processus de la racine Git ;
|
||||
- Git LFS/submodules et rétention avancée.
|
||||
|
||||
## Horizon
|
||||
|
||||
L'étude ne révèle aucune dépendance fausse dans la revue `0.0.3-beta.1`.
|
||||
|
||||
L'horizon reste donc :
|
||||
|
||||
```text
|
||||
0.0.5 modèles de contenu et projections
|
||||
0.0.6 templates publics
|
||||
0.0.7 templates d'administration
|
||||
0.0.8 lecture publique Actix Web / Maud
|
||||
0.0.9 administration Actix Web / Maud et autorisation
|
||||
0.0.10 gestion, proposition, revue et publication
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
|
||||
`0.0.4` peut progresser sans REPLAN : l'owner PostgreSQL est démontré, `tokio-postgres`, `deadpool-postgres` et `refinery` couvrent respectivement le driver, le pool et les migrations nécessaires, le premier schéma est borné et reconstructible par rapport à Git, et une stratégie de test PostgreSQL réelle est définie sans imposer un outil de provisioning unique.
|
||||
|
||||
`alpha.1` ne crée encore aucune crate, dépendance ou migration. Après son `PASS` opérateur, `alpha.2` peut matérialiser `knowledge-store-postgres-lib`, le trio `tokio-postgres` / `deadpool-postgres` / `refinery` et la première migration.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||
<!-- version: 41 -->
|
||||
<!-- version: 42 -->
|
||||
|
||||
# Matrice de validation Knowledge
|
||||
|
||||
@@ -1017,3 +1017,27 @@ La première tranche de `0.0.3` est une gate de cadrage sans code produit. Elle
|
||||
La baseline Web n'est pas rejouée automatiquement dans cette tranche, car aucun fichier sous `Web/` ni contrat runtime Web n'est modifié et la stable `0.0.2` a déjà acquis sa gate complète.
|
||||
|
||||
Un `PASS` de `0.0.3-alpha.1` autorise uniquement la préparation de `0.0.3-alpha.2`. Un autre statut doit d'abord être conservé dans son history puis conduire à un fix borné ou à un REPLAN.
|
||||
|
||||
## Gate de `0.0.4-alpha.1`
|
||||
|
||||
La première tranche de `0.0.4` est une gate de cadrage sans code produit, dépendance PostgreSQL Rust ni migration. Elle doit prouver :
|
||||
|
||||
- `VERSION = 0.0.4-alpha.1` et `[workspace.package].version` identique ;
|
||||
- baseline `v0.0.3` identifiée par commit `b3823972449150b72905930b806d4d15471cddce`, SHA-256 `82407dc2a83be878daa65692f975681428d0adc721ff249c3c9020e3a9d1f29d` et `publish.001 = PASS` ;
|
||||
- douze deltas et douze histories `0.0.3` appariés, avec `rel.1.fix.1 = PASS` ;
|
||||
- aucun chargement/adoption PGR nouveau ;
|
||||
- étude `008` et plan `004` présents ;
|
||||
- `tokio-postgres`, `deadpool-postgres`, Refinery, `knowledge-store-postgres-lib`, le schéma minimal et la stratégie de test explicitement décidés ;
|
||||
- aucun `knowledge-store-postgres-lib`, aucune migration et aucune nouvelle dépendance réellement ajoutés dans `alpha.1` ;
|
||||
- aucun diff sous `crates/` ou `Web/` et aucun changement du changelog stable `0.0.3` ;
|
||||
- roadmap/horizon `0.0.5` à `0.0.10` inchangés parce que l'étude ne révèle aucune dépendance fausse ;
|
||||
- audits Markdown et hygiène texte propres ;
|
||||
- `cargo fmt --all` puis `cargo fmt --all -- --check` exécutés avant les audits Rust ;
|
||||
- audits Rust locaux propres ;
|
||||
- `cargo metadata` et `cargo check --workspace` propres ;
|
||||
- `Cargo.lock` local ignoré/non suivi et `package-lock.json` Web inchangé/versionné ;
|
||||
- `git diff --cached --check` propre avant commit.
|
||||
|
||||
Clippy, tests workspace, npm/Vite et smokes HTTP ne sont pas requis par cette tranche : elle ne modifie ni source Rust, ni dépendance, ni frontend, ni runtime. La gate vérifie néanmoins `cargo check --workspace` après la promotion de version du manifest.
|
||||
|
||||
Un `PASS` autorise uniquement `0.0.4-alpha.2`. Un autre statut est historisé puis conduit à un fix borné ou à un REPLAN.
|
||||
|
||||
Reference in New Issue
Block a user