0.0.3-beta.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# Documentation SaseDev Knowledge
|
||||
|
||||
@@ -32,6 +32,7 @@
|
||||
- [`studies/004-V0_0_2_GIT_IMPLEMENTATION_STUDY.md`](studies/004-V0_0_2_GIT_IMPLEMENTATION_STUDY.md) — étude comparative Git de démarrage `0.0.2`, décision process et ownership du backend.
|
||||
- [`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.
|
||||
|
||||
## Plans
|
||||
|
||||
@@ -49,3 +50,4 @@ Les deltas et histories sont des artefacts de workflow, pas des substituts à ce
|
||||
|
||||
- [`../prompts/002-V0_0_2_START_PROMPT.md`](../prompts/002-V0_0_2_START_PROMPT.md) — handoff historique exécuté pour ouvrir `0.0.2` depuis `v0.0.1` publiée et vérifiée.
|
||||
- [`../prompts/003-V0_0_3_START_PROMPT.md`](../prompts/003-V0_0_3_START_PROMPT.md) — prompt local de reprise de `0.0.3` depuis `v0.0.2` publiée et vérifiée.
|
||||
- [`../prompts/004-V0_0_4_START_PROMPT.md`](../prompts/004-V0_0_4_START_PROMPT.md) — handoff préparé pendant `0.0.3-beta.1` pour ouvrir `0.0.4` depuis la future stable `v0.0.3` réellement publiée.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
|
||||
<!-- version: 17 -->
|
||||
<!-- version: 18 -->
|
||||
|
||||
# Profil du projet Knowledge
|
||||
|
||||
@@ -174,4 +174,6 @@ Elles justifient de conserver séparées l'identité/authentification partagée,
|
||||
|
||||
Restent différés après `0.0.2` : adapter Gitea, PostgreSQL/migrations, moteur de recherche, auth/admin complète, quatrième application d'administration, modèle détaillé rôles/capabilities, formats finaux HOWTO/snippet, scheduler concret, support explicite submodules/LFS, politique de nettoyage/rétention des snapshots et partage concurrent de la même racine Git entre plusieurs processus.
|
||||
|
||||
La revue d'horizon beta n'avait réservé aucune release suivante. L'ouverture explicite de `0.0.3` consomme 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 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.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
|
||||
<!-- version: 17 -->
|
||||
<!-- version: 18 -->
|
||||
|
||||
# Architecture de fondation Knowledge
|
||||
|
||||
@@ -498,3 +498,33 @@ candidat retenu sous refs/knowledge/candidates/<revision>
|
||||
Pour `GitRemoteState::Absent`, la lease utilise une attente vide et autorise donc uniquement la création d'une branche encore absente. Pour `GitRemoteState::Revision(r)`, la mise à jour distante n'est acceptée que si la branche pointe encore exactement sur `r`. L'observation préalable fournit un conflit rapide ; `--force-with-lease` reste la garde autoritaire contre une course entre observation et push. Après un rejet de push, le backend observe à nouveau la branche afin de traduire une divergence concurrente en conflit récupérable.
|
||||
|
||||
Cette capacité ne fait aucun rebase/merge automatique et ne publie aucune pull/merge request. Elle utilise uniquement le remote `origin` possédé par le mirror contrôlé et conserve la forge hors du contrat.
|
||||
|
||||
## Réconciliation `0.0.3-beta.1` et trajectoire produit
|
||||
|
||||
Le chemin Git générique est maintenant complet pour la responsabilité de `0.0.3` : lecture/snapshot par `GitRepository`, création locale de candidat puis push gardé par `GitRepositoryWriter`, sans API de forge. Les deux contrats restent séparés et les conflits distants sont des résultats récupérables plutôt que des rebase/merge implicites.
|
||||
|
||||
La prochaine dépendance structurante commune aux trois produits n'est plus l'écriture Git mais l'état applicatif persistant partagé. `0.0.4` est donc retenue comme prochaine mission pour matérialiser PostgreSQL, son premier schéma et ses migrations, la configuration logique des sources et l'état minimal de synchronisation/indexation. Le choix concret du driver/ORM, du pooling et de la stratégie de test PostgreSQL reste à décider dans l'étude de démarrage `0.0.4` ; il n'est pas anticipé par `0.0.3`.
|
||||
|
||||
La trajectoire des façades Web est désormais explicitement séparée en étapes afin de ne pas confondre design, rendu et logique serveur :
|
||||
|
||||
```text
|
||||
PostgreSQL partagé
|
||||
-> modèles/projections PGR + HOWTO + snippet
|
||||
-> templates publics des trois sites dans le template lab
|
||||
-> templates d'administration des trois sites dans le template lab
|
||||
-> routes publiques Actix + adaptation Maud des templates publics
|
||||
-> auth/autorisation + routes admin Actix + adaptation Maud des templates admin
|
||||
-> gestion/proposition/revue/publication appuyée sur Git + PostgreSQL
|
||||
```
|
||||
|
||||
Les pages de garde, listes, détails, navigation et états de recherche/filtrage visibles sont donc conçus d'abord comme templates Web de référence. Les dashboards, formulaires et états de proposition/revue suivent le même principe côté administration. Une phase ultérieure adapte le markup validé en composants Maud servis par les trois launchers Actix, plutôt que de développer simultanément deux interfaces indépendantes.
|
||||
|
||||
Cette trajectoire concerne les trois sites :
|
||||
|
||||
```text
|
||||
pgr.sasedev.com consultation et gestion du référentiel PGR
|
||||
howtos.sasedev.com consultation et gestion des HOWTOs
|
||||
snippets.sasedev.com consultation et gestion des snippets
|
||||
```
|
||||
|
||||
Git reste la vérité éditoriale publiée ; PostgreSQL porte l'état transversal et les projections reconstructibles. Un contenu accepté n'est publié qu'après production d'une révision Git autoritaire, puis la projection locale est réconciliée depuis cette révision.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Plan 0.0.3 — écriture Git contrôlée et push gardé
|
||||
|
||||
@@ -19,7 +19,7 @@ Knowledge start prompt prompts/003-V0_0_3_START_PROMPT.md
|
||||
|
||||
PGR `v0.1.3` reste une provenance historique de l'adoption fermée pendant `0.0.2`. Aucune version PGR plus récente n'est une source de cette release et aucune réévaluation PGR n'est engagée.
|
||||
|
||||
`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion et sa gate opérateur est `PASS`. `alpha.4` ferme maintenant le scope fonctionnel alpha avec le push gardé et les conflits explicites.
|
||||
`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion en `PASS`. `alpha.4` a fermé le scope fonctionnel alpha en `PASS` avec push gardé, création de branche sous attente d'absence et conflit concurrent sans écrasement. `beta.1` réconcilie maintenant l'état acquis, prépare le changelog candidat, rejoue la non-régression de stabilisation et effectue la revue d'horizon produit.
|
||||
|
||||
## Mission
|
||||
|
||||
@@ -199,12 +199,16 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
|
||||
|
||||
### beta.1 — réconciliation et revue d'horizon
|
||||
|
||||
- réconcilier contrats, implémentation et documentation durable ;
|
||||
- vérifier les `DEFER` encore valides ;
|
||||
- rejouer la non-régression utile, y compris runtime global si nécessaire à la stabilisation ;
|
||||
- réévaluer `0.0.4` comme prochaine mission potentielle et l'horizon `0.0.5` / `0.0.6` / `0.0.7` ;
|
||||
- réordonner, scinder ou dénuméroter ces horizons si les preuves de `0.0.3` le justifient ;
|
||||
- si `0.0.4` est suffisamment décidée, préparer son prompt de démarrage avant la clôture stable de `0.0.3`.
|
||||
- partir de `alpha.4 = PASS` historisé et committé ;
|
||||
- réconcilier contrats, implémentation et documentation durable sans modifier `crates/` ni `Web/` ;
|
||||
- préparer `CHANGELOG.md` en état `0.0.3 (candidate)` à partir des capacités réellement acquises ;
|
||||
- vérifier les `DEFER` encore valides et reclasser la prochaine dépendance structurante ;
|
||||
- retenir `0.0.4` comme fondation PostgreSQL partagée, sans préchoisir driver/ORM avant son étude de démarrage ;
|
||||
- étendre l'horizon jusqu'aux phases de modèles/projections, templates publics, templates admin, intégration Actix/Maud et workflow de gestion/proposition/publication des trois sites ;
|
||||
- produire l'étude durable `007-V0_0_3_GIT_WRITE_RECONCILIATION.md` ;
|
||||
- préparer `prompts/004-V0_0_4_START_PROMPT.md` pendant cette stabilisation, sans inventer commit/tag/SHA postérieurs de `v0.0.3` ;
|
||||
- rejouer la non-régression Rust et Web utile à la stabilisation ;
|
||||
- n'introduire aucune fonctionnalité PostgreSQL, Web, auth, forge ou proposition dans `0.0.3`.
|
||||
|
||||
### rc.1 — candidate stable
|
||||
|
||||
@@ -251,17 +255,29 @@ La release est fermable lorsque :
|
||||
- les règles/architecture décrivent l'état effectivement obtenu ;
|
||||
- beta et RC ont fermé les non-régressions prévues.
|
||||
|
||||
Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a ensuite matérialisé le contrat d'écriture provider-neutral avec une gate `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` corrige uniquement le test et sa gate opérateur est `PASS`. `alpha.4` peut donc fermer le scope fonctionnel alpha par le push gardé et les conflits explicites.
|
||||
Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` a corrigé uniquement le test en `PASS`. `alpha.4` a ensuite fermé le scope fonctionnel alpha en `PASS`. La beta doit maintenant stabiliser et réconcilier cet état sans nouveau code produit.
|
||||
|
||||
## Revue d'horizon
|
||||
|
||||
`alpha.1.fix.1` établit un horizon prévisionnel afin que `0.0.3` ne soit pas développée isolément :
|
||||
La revue `0.0.3-beta.1` remplace l'horizon initial trop centré sur les seules briques backend. La prochaine mission suffisamment définie est :
|
||||
|
||||
```text
|
||||
0.0.4 PostgreSQL partagé et migrations
|
||||
0.0.5 contenu structuré et lecture publique
|
||||
0.0.6 identité / autorisation / administration locale
|
||||
0.0.7 propositions / revue / publication
|
||||
0.0.4 fondation PostgreSQL partagée et migrations
|
||||
```
|
||||
|
||||
Ces numéros sont des horizons, pas encore des missions engagées. `beta.1` doit les réévaluer à la lumière de l'implémentation réelle de `0.0.3`, confirmer ou modifier la prochaine mission et préparer le prompt de cette mission pendant la fin de `0.0.3` si elle est suffisamment définie. Recherche avancée, adapters de forge, scheduler, administration transverse, opérations multi-domaines et autres `DEFER` restent reclassables ultérieurement.
|
||||
L'horizon produit devient ensuite :
|
||||
|
||||
```text
|
||||
0.0.5 modèles de contenu et projections PGR/HOWTO/snippet
|
||||
0.0.6 templates publics des trois sites, pages de garde incluses
|
||||
0.0.7 templates d'administration des trois sites
|
||||
0.0.8 routes publiques Actix Web + adaptation Maud
|
||||
0.0.9 auth/autorisation + routes admin Actix Web + adaptation Maud
|
||||
0.0.10 gestion/proposition/revue/publication Git + PostgreSQL
|
||||
```
|
||||
|
||||
Ces versions après `0.0.4` restent des horizons révisables. Elles rendent cependant explicite l'objectif produit : trois sites distincts PGR, HOWTOs et snippets, chacun avec lecture publique et gestion, partageant Git comme vérité éditoriale, PostgreSQL comme état/projection applicative et un pipeline de templates Web validés avant adaptation runtime en Maud.
|
||||
|
||||
Recherche avancée, adapters de forge, webhooks forge-only, scheduler, administration transverse, opérations multi-domaines, Git LFS/submodules et partage multi-processus restent non numérotés tant qu'un besoin réel ne les engage pas.
|
||||
|
||||
`prompts/004-V0_0_4_START_PROMPT.md` est préparé pendant `beta.1` conformément au cycle normal de handoff. Il exige au prochain démarrage l'archive taggée réelle `v0.0.3` et son rapport post-tag, sans inventer à l'avance le commit stable ou le SHA-256 qui n'existent pas encore.
|
||||
|
||||
178
docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
Normal file
178
docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
Normal file
@@ -0,0 +1,178 @@
|
||||
<!-- file: docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Réconciliation 0.0.3 — écriture Git et horizon produit
|
||||
|
||||
## Objet
|
||||
|
||||
Cette étude de `0.0.3-beta.1` réconcilie la mission d'écriture Git avec ce qui est réellement matérialisé par les alphas, puis réévalue l'horizon produit de SaseDev Knowledge avant la release candidate.
|
||||
|
||||
Elle n'ajoute aucune fonctionnalité. Elle sert de baseline durable pour stabiliser `0.0.3` et préparer la prochaine release sans consulter ni réadopter automatiquement une nouvelle version de PGR.
|
||||
|
||||
## Chemin Git réellement obtenu
|
||||
|
||||
La lecture et l'écriture restent deux capacités provider-neutral distinctes :
|
||||
|
||||
```text
|
||||
GitRepository
|
||||
refresh
|
||||
resolve_revision
|
||||
prepare_snapshot
|
||||
|
||||
GitRepositoryWriter
|
||||
create_candidate
|
||||
push_candidate
|
||||
```
|
||||
|
||||
Le chemin d'écriture réellement validé est :
|
||||
|
||||
```text
|
||||
GitRevision de base explicite
|
||||
-> worktree d'écriture isolé
|
||||
-> mutations create/update/delete confinées
|
||||
-> commit avec identité explicite et hooks/config ambiante neutralisés
|
||||
-> vérification du parent exact
|
||||
-> référence interne refs/knowledge/candidates/<revision>
|
||||
-> observation distante de refs/heads/...
|
||||
-> push --force-with-lease contre l'état attendu
|
||||
-> Updated(candidate) ou Conflict { actual }
|
||||
```
|
||||
|
||||
Aucun adapter de forge, rebase/merge automatique ou force-push non gardé n'est nécessaire pour cette primitive.
|
||||
|
||||
## Invariants acquis
|
||||
|
||||
`0.0.3` acquiert les propriétés suivantes :
|
||||
|
||||
- chemins de mutation relatifs et normalisés, avec `.git`, traversées et doublons refusés ;
|
||||
- vérification filesystem empêchant une traversée par symlink hors du worktree contrôlé ;
|
||||
- auteur et committer fournis explicitement ;
|
||||
- hooks Git désactivés pour le commit candidat ;
|
||||
- configuration Git système/globale pertinente neutralisée ;
|
||||
- candidat enfant direct de la base demandée ;
|
||||
- candidat retenu par une ref backend interne avant nettoyage du worktree ;
|
||||
- branche distante limitée à `refs/heads/...` ;
|
||||
- création de branche uniquement lorsque son absence est attendue ;
|
||||
- mise à jour d'une branche existante uniquement contre sa révision attendue ;
|
||||
- `--force-with-lease` comme garde autoritaire contre la course concurrente ;
|
||||
- divergence représentée comme conflit récupérable sans écrasement.
|
||||
|
||||
Ces invariants sont démontrés par des tests d'intégration utilisant uniquement des repositories et remotes bare locaux.
|
||||
|
||||
## DEFER reclassés
|
||||
|
||||
### Reclassé comme prochaine mission
|
||||
|
||||
La persistance PostgreSQL partagée est désormais le prochain axe structurant. Le chemin Git de lecture et d'écriture étant disponible, les futures façades ont besoin d'un état durable commun pour la configuration logique, la dernière révision synchronisée/indexée, les projections et les futurs workflows transversaux.
|
||||
|
||||
`0.0.4` est donc retenue comme prochaine mission :
|
||||
|
||||
```text
|
||||
fondation PostgreSQL partagée + premier schéma + migrations
|
||||
```
|
||||
|
||||
Cette décision n'impose pas encore :
|
||||
|
||||
- un driver/ORM particulier ;
|
||||
- un pool particulier ;
|
||||
- une stratégie Docker/service système particulière pour les tests ;
|
||||
- un schéma de contenu final PGR/HOWTO/snippet ;
|
||||
- auth, propositions ou moteur de recherche complet.
|
||||
|
||||
Ces points appartiennent à l'étude de démarrage de `0.0.4`.
|
||||
|
||||
### Toujours différés
|
||||
|
||||
Restent `DEFER` ou hors horizon numéroté tant que leur déclencheur n'est pas réel :
|
||||
|
||||
- rebase/merge automatique ;
|
||||
- adapter Gitea ou autre forge et webhooks forge-only ;
|
||||
- scheduler/jobs concrets ;
|
||||
- moteur de recherche avancé au-delà des besoins de projection réellement observés ;
|
||||
- quatrième application d'administration transverse ;
|
||||
- partage simultané d'une même racine Git par plusieurs processus ;
|
||||
- Git LFS/submodules ;
|
||||
- politique avancée de rétention/cleanup ;
|
||||
- observabilité ou service supplémentaire sans owner démontré.
|
||||
|
||||
## Horizon produit des trois sites
|
||||
|
||||
L'objectif produit n'est pas une succession de seules briques backend. Knowledge vise trois façades distinctes utilisant le même socle Git/PostgreSQL :
|
||||
|
||||
```text
|
||||
pgr.sasedev.com affichage et gestion de PGR
|
||||
howtos.sasedev.com affichage et gestion des HOWTOs
|
||||
snippets.sasedev.com affichage et gestion des snippets
|
||||
```
|
||||
|
||||
La revue beta distingue donc les phases suivantes.
|
||||
|
||||
### 0.0.4 — PostgreSQL partagé
|
||||
|
||||
Matérialiser la base logique commune, ses migrations et l'état minimal transversal/reconstructible sans déplacer l'autorité éditoriale hors de Git.
|
||||
|
||||
### 0.0.5 — modèles de contenu et projections
|
||||
|
||||
Travailler sur des corpus réels PGR/HOWTO/snippet, définir parsing/validation, métadonnées et relations nécessaires, puis produire les projections locales consommables par les façades.
|
||||
|
||||
### 0.0.6 — templates publics
|
||||
|
||||
Développer dans `Web/knowledge-template-lab` les références visuelles des trois sites : pages de garde, navigation, listes, détails, composants communs et états de recherche/filtrage visibles.
|
||||
|
||||
Cette phase valide le design et les contrats de markup/assets indépendamment du runtime Rust.
|
||||
|
||||
### 0.0.7 — templates d'administration
|
||||
|
||||
Développer les surfaces de gestion propres aux trois sites : dashboards, formulaires d'édition, listes d'objets, états de proposition/revue et retours d'erreur utiles.
|
||||
|
||||
Ces templates restent une référence de conception ; ils ne constituent pas encore une UI runtime complète.
|
||||
|
||||
### 0.0.8 — Actix Web / Maud public
|
||||
|
||||
Matérialiser les routes publiques réelles dans les trois launchers et adapter en Maud les templates publics validés. Les pages sont alimentées par les sources Git/projections locales et conservent le pipeline Vite/assets commun.
|
||||
|
||||
### 0.0.9 — Actix Web / Maud admin et autorisation
|
||||
|
||||
Matérialiser les besoins réels d'identité/session/capabilities, protéger les routes d'administration par façade et adapter en Maud les templates admin validés.
|
||||
|
||||
### 0.0.10 — gestion, proposition, revue et publication
|
||||
|
||||
Relier les interfaces d'administration aux cas d'usage applicatifs : édition/proposition basée sur une révision Git connue, revue, conflit explicite, création/push de la révision Git autoritaire, puis réconciliation PostgreSQL.
|
||||
|
||||
## Pourquoi séparer templates et Maud
|
||||
|
||||
Le laboratoire Web existe précisément pour concevoir et valider les références statiques sans lier chaque décision visuelle au cycle de compilation serveur.
|
||||
|
||||
La trajectoire retenue est donc :
|
||||
|
||||
```text
|
||||
conception/validation template
|
||||
-> contrat de composants/classes/assets utile
|
||||
-> adaptation Maud
|
||||
-> routes et données runtime
|
||||
```
|
||||
|
||||
Cela évite deux écueils :
|
||||
|
||||
- concevoir l'interface directement dans le code Maud avant validation visuelle ;
|
||||
- maintenir durablement deux produits UI indépendants, l'un statique et l'autre runtime.
|
||||
|
||||
La future phase d'intégration doit définir des invariants ciblés permettant de détecter une dérive significative entre les références validées et leur adaptation Maud, sans imposer une duplication exhaustive.
|
||||
|
||||
## Changelog et handoff
|
||||
|
||||
`beta.1` est la première phase où l'implémentation de `0.0.3` est suffisamment acquise pour préparer une entrée `## 0.0.3 (candidate)` décrivant les capacités réelles plutôt que les intentions alpha.
|
||||
|
||||
La mission `0.0.4` est également suffisamment définie pour préparer maintenant :
|
||||
|
||||
```text
|
||||
prompts/004-V0_0_4_START_PROMPT.md
|
||||
```
|
||||
|
||||
Le prompt ne contient pas de commit stable, SHA-256 d'archive ou résultat post-tag inventé pour `v0.0.3`. Ces preuves devront être fournies et vérifiées après publication réelle de la stable.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Le scope fonctionnel de `0.0.3` est cohérent avec sa mission et peut entrer en stabilisation sans nouveau code produit. La release candidate doit geler ce résultat et rejouer la preuve complète applicable.
|
||||
|
||||
La trajectoire suivante est désormais lisible à l'échelle du produit : Git lecture/écriture acquis, PostgreSQL ensuite, puis contenu/projections, conception des interfaces publiques et admin, adaptation Actix/Maud et enfin workflows de gestion/publication.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||
<!-- version: 36 -->
|
||||
<!-- version: 37 -->
|
||||
|
||||
# Matrice de validation Knowledge
|
||||
|
||||
@@ -177,6 +177,27 @@ La tranche de push gardé et concurrence doit prouver :
|
||||
- `knowledge-git-api`, `knowledge-app-lib`, `Web/`, `CHANGELOG.md` et `ROADMAP.md` sans diff ;
|
||||
- `Cargo.lock` ignoré/non suivi et staging final propre.
|
||||
|
||||
## Gate de `0.0.3-beta.1`
|
||||
|
||||
La tranche de réconciliation/stabilisation doit prouver :
|
||||
|
||||
- `VERSION = 0.0.3-beta.1` et version workspace identique ;
|
||||
- history `history/0.0.3/alpha.4.md` présent avec statut `PASS` et committé avant application ;
|
||||
- aucun diff sous `crates/` ou `Web/` : la beta ne change pas le produit ;
|
||||
- `CHANGELOG.md` contient `## 0.0.3 (candidate)` construit à partir des capacités réellement acquises ;
|
||||
- étude `007-V0_0_3_GIT_WRITE_RECONCILIATION.md` présente et cohérente avec l'architecture ;
|
||||
- `ROADMAP.md` retient `0.0.4` comme prochaine mission potentielle et explicite les phases templates publics/admin puis Actix/Maud pour les trois sites ;
|
||||
- `prompts/004-V0_0_4_START_PROMPT.md` présent sans commit stable, SHA d'archive ou rapport post-tag `v0.0.3` inventé ;
|
||||
- `0.0.4` n'introduit encore aucun driver/ORM, crate PostgreSQL, migration ou dépendance pendant la gate `0.0.3` ;
|
||||
- rebase/merge automatique, forge, scheduler, recherche avancée, quatrième admin et partage multi-processus restent différés ;
|
||||
- `cargo fmt --all`, audits Rust, metadata/check, Clippy strict, tests Git ciblés et tests workspace passent ;
|
||||
- baseline Web `npm ci`, typecheck et build Vite passent ;
|
||||
- manifest Vite de production reste parsable avec l'entrée stable `src/main.ts` ;
|
||||
- les trois launchers restent compilables et la RC devra au minimum rejouer les smokes HTTP complets ;
|
||||
- `Cargo.lock` local reste ignoré/non suivi, package-lock Web versionné et staging final propre.
|
||||
|
||||
Un `PASS` autorise uniquement `0.0.3-rc.1`. Toute régression produit exige un fix beta borné ou un retour de phase ; la beta ne doit pas masquer un défaut sous une réécriture documentaire.
|
||||
|
||||
## PostgreSQL
|
||||
|
||||
Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.
|
||||
|
||||
Reference in New Issue
Block a user