0.0.3-beta.1
This commit is contained in:
13
CHANGELOG.md
13
CHANGELOG.md
@@ -1,10 +1,21 @@
|
||||
<!-- file: CHANGELOG.md -->
|
||||
<!-- version: 16 -->
|
||||
<!-- version: 17 -->
|
||||
|
||||
# Changelog SaseDev Knowledge
|
||||
|
||||
Ce fichier décrit les changements utiles des releases publiées. Les détails de tranches et preuves opérateur appartiennent aux plans, deltas et histories.
|
||||
|
||||
## 0.0.3 (candidate)
|
||||
|
||||
- ajoute un contrat Git d'écriture provider-neutral distinct de `GitRepository`, afin que les consommateurs lecture seule n'acquièrent aucune obligation d'écriture ;
|
||||
- valide les chemins de mutation, l'identité de commit, les branches `refs/heads/...` et l'état distant attendu avant toute opération backend ;
|
||||
- matérialise un worktree d'écriture isolé, applique create/update/delete sous confinement et refuse les traversées par symlink vers l'extérieur ;
|
||||
- crée un commit candidat avec auteur/committer explicites, hooks/configuration Git ambiante neutralisés et parent vérifié exactement égal à la révision de base ;
|
||||
- conserve les candidats sous une référence backend interne puis nettoie les worktrees temporaires contrôlés ;
|
||||
- pousse une branche distante uniquement sous garde compare-and-exchange `--force-with-lease` correspondant à une révision attendue ou à une absence attendue ;
|
||||
- traduit une divergence distante, y compris concurrente entre observation et push, en conflit récupérable sans écrasement silencieux ;
|
||||
- conserve la forge optionnelle et laisse hors de cette release PostgreSQL, rebase/merge automatique, auth/admin, routes Web d'édition et workflow complet de proposition/revue/publication.
|
||||
|
||||
## 0.0.2
|
||||
|
||||
- matérialise un backend Git générique de lecture derrière `knowledge-git-api`, sans dépendance obligatoire à une forge ;
|
||||
|
||||
@@ -16,7 +16,7 @@ members = [
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.0.3-alpha.4"
|
||||
version = "0.0.3-beta.1"
|
||||
edition = "2024"
|
||||
publish = false
|
||||
repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge"
|
||||
|
||||
10
README.md
10
README.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 21 -->
|
||||
<!-- version: 22 -->
|
||||
|
||||
# SaseDev Knowledge
|
||||
|
||||
@@ -13,7 +13,7 @@ La version courante est définie par [`VERSION`](VERSION).
|
||||
|
||||
`0.0.1` est la première stable de fondation de SaseDev Knowledge. `0.0.2` est la stable du chemin Git générique de lecture, de l'autonomie normative locale et du cas d'usage partagé de synchronisation `Changed` / `Unchanged`.
|
||||
|
||||
`0.0.3-alpha.4` ferme maintenant le chemin Git générique d'écriture : après création locale d'un commit candidat isolé, `knowledge-git-lib` observe l'état réel de la branche distante puis effectue un push compare-and-exchange protégé par `--force-with-lease` contre l'état explicitement attendu. Une branche peut être créée uniquement lorsque son absence est attendue ; toute divergence devient un conflit récupérable avec l'état distant réellement observé et aucun écrasement silencieux. PostgreSQL, forge, workflow complet de proposition, rebase/merge automatique et auth/admin restent hors scope.
|
||||
`0.0.3-beta.1` réconcilie maintenant le chemin Git générique complet avant la release candidate : lecture/snapshot, création d'un commit candidat isolé, puis push compare-and-exchange protégé par `--force-with-lease` contre l'état distant explicitement attendu. Une branche peut être créée uniquement lorsque son absence est attendue ; toute divergence devient un conflit récupérable sans écrasement silencieux. La beta n'ajoute pas de fonctionnalité Git : elle stabilise l'état acquis, prépare le changelog candidat et réévalue la trajectoire produit au-delà de `0.0.3`.
|
||||
|
||||
`knowledge-git-lib` implémente `knowledge-git-api::GitRepository` pour des sources physiques enregistrées : mirror contrôlé, refresh avec pruning, résolution d'une référence vers un commit et snapshot/worktree détaché adressé par révision. La création locale du candidat d'`alpha.3` reste séparée de cette sémantique de lecture. Les règles nécessaires au développement courant sont désormais possédées localement sous `docs/rules/`, et les futurs prompts Knowledge ne chargent pas PGR sauf réévaluation explicitement engagée. `knowledge-app-lib` compose maintenant refresh, résolution, comparaison avec la révision précédente et préparation de snapshot en un résultat explicite `Changed` / `Unchanged`, sans persister la dernière révision ni matérialiser de scheduler.
|
||||
|
||||
@@ -51,6 +51,8 @@ La stable `0.0.1` matérialise `knowledge-web-lib` et les trois launchers `knowl
|
||||
|
||||
Le runtime exige un bind configuré par launcher et l'une des deux sources d'assets suivantes : `KNOWLEDGE_VITE_DEV_ORIGIN` en développement ou `KNOWLEDGE_VITE_MANIFEST_PATH` en production. `KNOWLEDGE_ASSET_BASE_PATH` peut remplacer le préfixe `/` de production. Aucune route admin/login n'est matérialisée à ce stade.
|
||||
|
||||
La revue d'horizon de `0.0.3-beta.1` sépare désormais explicitement la construction produit des trois façades : fondation PostgreSQL partagée, modèles/projections de contenu, templates publics (dont pages de garde) pour PGR/HOWTOs/snippets, templates d'administration, intégration Actix Web et adaptation Maud des templates validés, puis workflow de gestion/proposition/revue/publication. Les templates restent d'abord développés et validés dans le laboratoire Web avant adaptation runtime en Maud ; cette trajectoire n'implémente encore aucune de ces phases pendant `0.0.3`.
|
||||
|
||||
## Invariants de fondation
|
||||
|
||||
- Git est la source autoritaire du contenu versionné.
|
||||
@@ -78,7 +80,8 @@ Le runtime exige un bind configuré par launcher et l'une des deux sources d'ass
|
||||
- [`docs/studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md`](docs/studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md) — étude ciblée du pattern Vite manifest / Actix / Maud à adapter pour Knowledge ;
|
||||
- [`docs/studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md`](docs/studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md) — réconciliation `beta.1`, état matérialisé, DEFER conservés et revue d'horizon ;
|
||||
- [`docs/studies/004-V0_0_2_GIT_IMPLEMENTATION_STUDY.md`](docs/studies/004-V0_0_2_GIT_IMPLEMENTATION_STUDY.md) — comparaison processus Git / `gix` / `git2` et décision d'implémentation de lecture ;
|
||||
- [`docs/studies/006-V0_0_3_GIT_WRITE_STUDY.md`](docs/studies/006-V0_0_3_GIT_WRITE_STUDY.md) — choix de la prochaine mission, stratégie de worktree d'écriture et invariants de push gardé ;
|
||||
- [`docs/studies/006-V0_0_3_GIT_WRITE_STUDY.md`](docs/studies/006-V0_0_3_GIT_WRITE_STUDY.md) — choix de la mission, stratégie de worktree d'écriture et invariants de push gardé ;
|
||||
- [`docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md`](docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md) — réconciliation beta du chemin Git d'écriture et revue d'horizon produit PGR/HOWTOs/snippets ;
|
||||
- [`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md`](docs/plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan historique de la fondation stable `0.0.1` ;
|
||||
- [`docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md`](docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md) — plan historique de la stable `0.0.2`, gates et décisions de fermeture ;
|
||||
- [`docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md`](docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md) — plan actif de l'écriture Git contrôlée et du push gardé ;
|
||||
@@ -86,6 +89,7 @@ Le runtime exige un bind configuré par launcher et l'une des deux sources d'ass
|
||||
- [`prompts/001-V0_0_1_START_PROMPT.md`](prompts/001-V0_0_1_START_PROMPT.md) — prompt de démarrage autoritaire de la release.
|
||||
- [`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 la stable `v0.0.1` 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 la stable `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 la stabilisation de `0.0.3` pour ouvrir la fondation PostgreSQL partagée après publication réelle de `v0.0.3`.
|
||||
|
||||
## Langue et nomenclature
|
||||
|
||||
|
||||
36
ROADMAP.md
36
ROADMAP.md
@@ -1,43 +1,47 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# Roadmap SaseDev Knowledge
|
||||
|
||||
La roadmap montre la release effectivement en cours et un horizon borné des releases suivantes. Une release d'horizon reste prévisionnelle tant qu'une revue d'horizon ne l'a pas engagée comme prochaine mission ; son numéro, son ordre ou son scope peuvent encore être replanifiés.
|
||||
La roadmap montre la release effectivement en cours et un horizon borné des releases suivantes. Une release d'horizon reste prévisionnelle tant qu'elle n'est pas ouverte : son numéro, son ordre ou son scope peuvent encore être replanifiés par une revue d'horizon ultérieure.
|
||||
|
||||
Statuts : `( )` engagée/planifiée, `(x)` terminée, `(h)` horizon prévisionnel, `(d)` différée, `(c)` annulée.
|
||||
|
||||
## Fondation
|
||||
|
||||
- `(x) 0.0.1` — fondation Knowledge : gouvernance PGR, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, contrat d'administration locale protégée sans UI/auth complète, workspace Rust, premiers contrats, baseline Web reproductible, rendu Maud et intégration réelle du manifest Vite, sans implémentation métier disproportionnée.
|
||||
- `(x) 0.0.1` — fondation Knowledge : gouvernance locale, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, baseline Web reproductible, rendu Maud et intégration réelle du manifest Vite, sans implémentation métier disproportionnée.
|
||||
|
||||
## Releases livrées
|
||||
|
||||
- `(x) 0.0.2` — implémentation Git générique et synchronisation de lecture : backend provider-neutral derrière `knowledge-git-api`, configuration de sources locales/remotes, matérialisation locale reproductible, refresh/résolution de révision, snapshot/worktree de lecture et convergence des déclencheurs explicite/périodique vers un même cas d'usage, sans API de forge obligatoire, écriture/publication Git, PostgreSQL ni format final HOWTO/snippet.
|
||||
- `(x) 0.0.2` — Git générique et synchronisation de lecture : backend provider-neutral, sources locales/remotes, mirror contrôlé, refresh/résolution de révision, snapshot/worktree de lecture et cas d'usage partagé `Changed` / `Unchanged`, sans forge obligatoire ni persistance PostgreSQL.
|
||||
|
||||
## Release en cours
|
||||
|
||||
- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture provider-neutral distinct de la lecture, worktree d'écriture isolé, mutations confinées, commit avec identité explicite et mise à jour d'une branche `refs/heads/...` seulement lorsque son état distant correspond à l'attente fournie ; sans forge obligatoire, rebase/merge automatique, PostgreSQL ni workflow complet de proposition.
|
||||
- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture séparé de la lecture, worktree candidat isolé, mutations confinées, commit à identité explicite et mise à jour d'une branche `refs/heads/...` uniquement lorsque son état distant correspond à l'attente fournie ; divergence = conflit récupérable, sans rebase/merge automatique ni forge obligatoire.
|
||||
|
||||
## Horizon prévisionnel
|
||||
## Horizon produit après 0.0.3
|
||||
|
||||
L'ordre ci-dessous exprime l'horizon de travail actuel. Il sert à préparer les dépendances et éviter qu'une release soit décidée isolément ; il n'engage pas ces releases avant leur revue d'horizon dédiée.
|
||||
La revue `0.0.3-beta.1` retient `0.0.4` comme prochaine mission si `0.0.3` ferme sa RC/stable sans découverte bloquante. Les versions suivantes restent des horizons : elles explicitent la trajectoire des trois produits Web sans figer prématurément leurs détails.
|
||||
|
||||
- `(h) 0.0.4` — persistance PostgreSQL partagée : premier schéma réel, migrations, configuration logique persistante des sources et état de synchronisation nécessaire aux futurs cas d'usage transversaux, sans déplacer le contenu publié hors de Git.
|
||||
- `(h) 0.0.5` — contenu structuré et lecture publique : formats/corpus réels PGR, HOWTO et snippet, normalisation/parsing, relations utiles et rendu public depuis la révision Git/index local, sans workflow complet de contribution.
|
||||
- `(h) 0.0.6` — identité, autorisation et administration locale : comptes/sessions, rôles ou capabilities réellement nécessaires et surfaces d'administration protégées par façade, sans créer une quatrième application sans ownership démontré.
|
||||
- `(h) 0.0.7` — propositions, revue et publication : proposition basée sur une révision Git, revue/audit applicatif, détection de conflit et publication produisant une révision Git autoritaire avant exposition comme contenu publié.
|
||||
- `(h) 0.0.4` — fondation PostgreSQL partagée : premier schéma réel et migrations, configuration logique persistante des sources, dernière révision synchronisée/indexée et état transversal minimal reconstructible ; Git reste autoritaire pour le contenu publié.
|
||||
- `(h) 0.0.5` — modèles de contenu et projections : corpus réels PGR/HOWTO/snippet, parsing/validation, métadonnées et relations utiles, projection locale lisible depuis Git + PostgreSQL et contrats de lecture nécessaires aux trois façades.
|
||||
- `(h) 0.0.6` — templates publics des trois sites : développer et valider dans `Web/knowledge-template-lab` les pages de garde, navigation, listes, détails, recherche/filtrage visible et composants partagés pour PGR, HOWTOs et snippets, sans encore faire de ces templates le rendu runtime définitif.
|
||||
- `(h) 0.0.7` — templates d'administration des trois sites : dashboards et surfaces de gestion propres à PGR, HOWTOs et snippets, formulaires/états de proposition et revue nécessaires au produit, toujours comme références Web validables avant adaptation serveur.
|
||||
- `(h) 0.0.8` — lecture publique Actix Web / Maud : matérialiser les routes publiques réelles des trois serveurs, alimentées par Git/projections locales, et adapter en Maud les templates publics validés tout en conservant le pipeline Vite/assets commun.
|
||||
- `(h) 0.0.9` — administration Actix Web / Maud et autorisation : matérialiser identité/session/capabilities réellement nécessaires, routes admin protégées par façade et adaptation Maud des templates d'administration validés.
|
||||
- `(h) 0.0.10` — gestion, proposition, revue et publication : relier les interfaces d'administration aux cas d'usage d'édition, conserver la révision Git de base, gérer les conflits, produire/pousser la révision Git autoritaire puis réconcilier les projections PostgreSQL.
|
||||
|
||||
## Domaines ultérieurs à reclasser
|
||||
|
||||
Les thèmes suivants restent volontairement non numérotés tant que l'horizon ci-dessus n'a pas été réévalué ou qu'un besoin plus prioritaire ne les engage pas :
|
||||
Les thèmes suivants restent volontairement non numérotés ou peuvent être absorbés dans une release d'horizon seulement lorsqu'un besoin mesuré le justifie :
|
||||
|
||||
- recherche/indexation avancée au-delà des capacités PostgreSQL/locales réellement nécessaires ;
|
||||
- recherche/indexation avancée au-delà des capacités PostgreSQL et des projections réellement nécessaires aux façades ;
|
||||
- adapter Gitea puis autres forges et webhooks forge-only ;
|
||||
- scheduler/jobs de synchronisation ou publication ;
|
||||
- scheduler/jobs de synchronisation, indexation ou publication ;
|
||||
- quatrième application d'administration transverse ;
|
||||
- déploiement/opérations multi-domaines ;
|
||||
- partage concurrent d'une même racine Git entre plusieurs processus ;
|
||||
- support explicite Git LFS/submodules et politiques de rétention/cleanup avancées.
|
||||
- support explicite Git LFS/submodules et politiques de rétention/cleanup avancées ;
|
||||
- observabilité transversale ou service réseau supplémentaire sans ownership démontré.
|
||||
|
||||
La revue d'horizon de chaque release doit vérifier la release suivante et réévaluer au moins les deux releases qui la suivent. Elle peut conserver, réordonner, fusionner, scinder ou dénuméroter un élément d'horizon lorsque les preuves produit ou techniques le justifient.
|
||||
Chaque revue d'horizon doit vérifier la prochaine mission et réévaluer au moins les deux releases qui la suivent. Elle peut conserver, réordonner, fusionner, scinder ou dénuméroter un horizon lorsque les preuves produit ou techniques le justifient.
|
||||
|
||||
207
deltas/0.0.3/beta.1.md
Normal file
207
deltas/0.0.3/beta.1.md
Normal file
@@ -0,0 +1,207 @@
|
||||
<!-- file: deltas/0.0.3/beta.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.3-beta.1 — réconciliation, changelog candidat et horizon produit
|
||||
|
||||
## Baseline requise
|
||||
|
||||
Partir de `0.0.3-alpha.4` après application, commit et push de son history :
|
||||
|
||||
```text
|
||||
history/0.0.3/alpha.4.md = PASS
|
||||
```
|
||||
|
||||
La version devient :
|
||||
|
||||
```text
|
||||
0.0.3-beta.1
|
||||
```
|
||||
|
||||
## Nature de la tranche
|
||||
|
||||
`beta.1` est une tranche de stabilisation documentaire et de réconciliation. Elle n'ajoute aucun comportement Rust/Web, aucune crate, aucune dépendance et aucune migration.
|
||||
|
||||
Elle :
|
||||
|
||||
- réconcilie le chemin Git de lecture/écriture réellement obtenu ;
|
||||
- prépare le changelog `0.0.3 (candidate)` à partir des capacités validées ;
|
||||
- reclassifie la persistance PostgreSQL comme prochaine mission `0.0.4` ;
|
||||
- étend l'horizon afin de représenter les trois produits PGR/HOWTOs/snippets et leurs phases de templates publics/admin puis d'intégration Actix/Maud ;
|
||||
- prépare le prompt `0.0.4` pendant la fin de `0.0.3`, conformément au cycle normal ;
|
||||
- conserve les autres `DEFER` sans implémentation anticipée.
|
||||
|
||||
L'étude durable est :
|
||||
|
||||
```text
|
||||
docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
```
|
||||
|
||||
## Scope des fichiers
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
Cargo.toml
|
||||
README.md
|
||||
ROADMAP.md
|
||||
CHANGELOG.md
|
||||
docs/000-README.md
|
||||
docs/architecture/001-PROJECT_PROFILE.md
|
||||
docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
|
||||
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
|
||||
docs/validation/001-VALIDATION_MATRIX.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
prompts/004-V0_0_4_START_PROMPT.md
|
||||
deltas/0.0.3/beta.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
`crates/` et `Web/` ne sont pas modifiés. Aucun history `beta.1` n'est inclus dans ce delta.
|
||||
|
||||
## Horizon retenu
|
||||
|
||||
La prochaine mission potentielle est :
|
||||
|
||||
```text
|
||||
0.0.4 fondation PostgreSQL partagée et migrations
|
||||
```
|
||||
|
||||
L'horizon révisable 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
|
||||
```
|
||||
|
||||
Cette numérotation donne une trajectoire produit lisible mais ne transforme pas `0.0.5+` en engagements irrévocables. Les revues d'horizon futures peuvent encore réordonner, scinder ou fusionner ces étapes.
|
||||
|
||||
## Handoff 0.0.4
|
||||
|
||||
`prompts/004-V0_0_4_START_PROMPT.md` est créé maintenant parce que la mission PostgreSQL est suffisamment décidée.
|
||||
|
||||
Le prompt ne fabrique aucune preuve postérieure à `0.0.3` : il ne contient ni commit stable réel de `v0.0.3`, ni SHA-256 d'archive taggée, ni statut post-tag supposé. La future session devra recevoir l'archive et le rapport réels après publication et les vérifier avant développement.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Exécuter depuis la racine du dépôt après application du delta.
|
||||
|
||||
### Version, documentation et Rust
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.3-beta.1'
|
||||
grep -F 'version = "0.0.3-beta.1"' Cargo.toml
|
||||
grep -A2 '^## Statut$' history/0.0.3/alpha.4.md | grep -Fx 'PASS'
|
||||
|
||||
git diff --check
|
||||
|
||||
python3 -B scripts/audit_markdown_headers.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts deltas history
|
||||
python3 -B scripts/audit_markdown_links.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts deltas history
|
||||
python3 -B scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts deltas history
|
||||
|
||||
cargo fmt --all
|
||||
cargo fmt --all -- --check
|
||||
|
||||
python3 -B scripts/audit_rust_test_layout.py crates
|
||||
python3 -B scripts/audit_rust_blank_lines.py crates
|
||||
python3 -B scripts/audit_rust_item_spacing.py crates
|
||||
python3 -B scripts/audit_rust_module_order.py crates
|
||||
python3 -B scripts/audit_rust_trait_import_blocks.py crates
|
||||
python3 -B scripts/audit_rust_reexport_blocks.py crates
|
||||
python3 -B scripts/audit_rust_crate_root_facades.py crates
|
||||
python3 -B scripts/audit_rust_export_completeness.py --root . --summary-only
|
||||
|
||||
cargo metadata --format-version 1 --no-deps > /tmp/sasedev-knowledge-0.0.3-beta.1-metadata.json
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
cargo test -p knowledge-git-lib --test git_read_path
|
||||
cargo test -p knowledge-git-lib --test git_write_candidate
|
||||
cargo test -p knowledge-git-lib --test git_write_push
|
||||
cargo test --workspace --all-targets --all-features
|
||||
```
|
||||
|
||||
### Baseline Web de stabilisation
|
||||
|
||||
```bash
|
||||
(cd Web/knowledge-template-lab && npm ci)
|
||||
(cd Web/knowledge-template-lab && npm run typecheck)
|
||||
(cd Web/knowledge-template-lab && npm run build)
|
||||
```
|
||||
|
||||
Audit du manifest, sous forme d'une commande indépendante :
|
||||
|
||||
```bash
|
||||
python3 -c 'import json; from pathlib import Path; p=Path("../builds/sasedev-knowledge/web/template-lab/.vite/manifest.json"); m=json.loads(p.read_text(encoding="utf-8")); e=m["src/main.ts"]; assert e.get("file"); assert e.get("css"); print("Knowledge 0.0.3-beta.1 Vite manifest audit: clean")'
|
||||
```
|
||||
|
||||
Les smokes HTTP complets des trois launchers seront obligatoires en `rc.1`. `beta.1` ne modifie aucun runtime Web et valide ici la baseline npm/typecheck/build/manifest en plus des tests Rust workspace.
|
||||
|
||||
### Contrôles de réconciliation et d'horizon
|
||||
|
||||
Ces commandes sont volontairement courtes et indépendantes.
|
||||
|
||||
```bash
|
||||
grep -F '## 0.0.3 (candidate)' CHANGELOG.md
|
||||
|
||||
grep -F -- '- `(h) 0.0.4` — fondation PostgreSQL partagée' ROADMAP.md
|
||||
grep -F -- '- `(h) 0.0.6` — templates publics des trois sites' ROADMAP.md
|
||||
grep -F -- '- `(h) 0.0.7` — templates d'administration des trois sites' ROADMAP.md
|
||||
grep -F -- '- `(h) 0.0.8` — lecture publique Actix Web / Maud' ROADMAP.md
|
||||
grep -F -- '- `(h) 0.0.9` — administration Actix Web / Maud et autorisation' ROADMAP.md
|
||||
grep -F -- '- `(h) 0.0.10` — gestion, proposition, revue et publication' ROADMAP.md
|
||||
|
||||
test -f docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
test -f prompts/004-V0_0_4_START_PROMPT.md
|
||||
|
||||
grep -F '### 0.0.4 — PostgreSQL partagé' docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
grep -F '### 0.0.6 — templates publics' docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
grep -F "### 0.0.7 — templates d'administration" docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
grep -F '### 0.0.8 — Actix Web / Maud public' docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
grep -F 'pgr.sasedev.com affichage et gestion de PGR' docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
|
||||
grep -F 'archive sasedev-knowledge-v0.0.3.zip téléchargée depuis le tag Gitea v0.0.3' prompts/004-V0_0_4_START_PROMPT.md
|
||||
grep -F 'Ne pas rechercher, charger ni adopter automatiquement une nouvelle version de PGR.' prompts/004-V0_0_4_START_PROMPT.md
|
||||
! grep -Eq '[0-9a-f]{40}|[0-9a-f]{64}' prompts/004-V0_0_4_START_PROMPT.md
|
||||
|
||||
test -z "$(git diff --name-only -- crates Web)"
|
||||
test ! -e crates/knowledge-store-postgres-lib
|
||||
test ! -e crates/knowledge-forge-gitea-lib
|
||||
test ! -e migrations
|
||||
test ! -e history/0.0.3/beta.1.md
|
||||
```
|
||||
|
||||
### Hygiène texte et lockfiles
|
||||
|
||||
```bash
|
||||
python3 -c 'from pathlib import Path; roots=[Path("README.md"),Path("RULES.md"),Path("ROADMAP.md"),Path("CHANGELOG.md"),Path("docs"),Path("prompts"),Path("deltas"),Path("history")]; paths=[p for r in roots for p in ([r] if r.is_file() else r.rglob("*")) if p.is_file()]; bad=[str(p) for p in paths if (lambda b: b"\r" in b or not b.endswith(b"\n") or b.endswith(b"\n\n") or any(line != line.rstrip(" \t") for line in b.decode("utf-8").splitlines()))(p.read_bytes())]; print(f"Knowledge 0.0.3-beta.1 text hygiene: clean ({len(paths)} file(s))") if not bad else (_ for _ in ()).throw(AssertionError(bad))'
|
||||
|
||||
test -f Cargo.lock
|
||||
git check-ignore -q Cargo.lock
|
||||
if git ls-files --error-unmatch Cargo.lock >/dev/null 2>&1; then echo 'Cargo.lock must remain untracked for Knowledge' >&2; exit 1; fi
|
||||
|
||||
test -f Web/knowledge-template-lab/package-lock.json
|
||||
|
||||
git add -A
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.0.3/beta.1.md`, l'appliquer, commit/push `0.0.3-beta.1`, puis préparer `0.0.3-rc.1` sans nouvelle fonctionnalité. La RC doit geler le scope et rejouer la gate complète, y compris npm/Vite et les trois smokes HTTP.
|
||||
|
||||
### FAIL / PARTIAL / BLOCKED
|
||||
|
||||
Conserver le résultat réel dans son history avant toute correction. Un défaut borné utilise `beta.1.fix.N`. Toute découverte remettant en cause l'intégrité du chemin Git, la mission `0.0.4` ou la trajectoire produit exige un REPLAN explicite avant poursuite.
|
||||
@@ -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.
|
||||
|
||||
149
history/0.0.3/beta.1.md
Normal file
149
history/0.0.3/beta.1.md
Normal file
@@ -0,0 +1,149 @@
|
||||
<!-- file: history/0.0.3/beta.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.3-beta.1 — réconciliation et revue d'horizon
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.0.3-beta.1` exécutée le `2026-09-29` est complète et propre. La tranche réconcilie le chemin Git d'écriture acquis, prépare le changelog candidat et élargit l'horizon produit des trois sites sans modifier `crates/` ni `Web/`.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
`alpha.4` `PASS` a été historisé, committé et poussé avant application de `beta.1` :
|
||||
|
||||
```text
|
||||
history/0.0.3/alpha.4.md PASS
|
||||
commit a87f3ba
|
||||
message 0.0.3-alpha.4
|
||||
branch master
|
||||
push origin/master PASS
|
||||
workspace après push propre
|
||||
```
|
||||
|
||||
Le push observé a avancé `origin/master` de `aca00e6` à `a87f3ba`.
|
||||
|
||||
## Version et documentation
|
||||
|
||||
```text
|
||||
VERSION 0.0.3-beta.1
|
||||
Cargo workspace version 0.0.3-beta.1
|
||||
git diff --check PASS
|
||||
Markdown header audit clean (116 file(s))
|
||||
Markdown link audit clean (82 local link(s), 116 file(s))
|
||||
Markdown table audit clean (4 table(s), 116 file(s))
|
||||
```
|
||||
|
||||
Le changelog contient désormais `## 0.0.3 (candidate)` à partir des capacités réellement acquises. La revue d'horizon retient `0.0.4` comme fondation PostgreSQL partagée et rend explicites les phases ultérieures de modèles/projections, templates publics, templates d'administration, Actix Web / Maud puis gestion/proposition/revue/publication des trois sites.
|
||||
|
||||
Le handoff `prompts/004-V0_0_4_START_PROMPT.md` est présent sans commit stable, SHA-256 ou rapport post-tag `v0.0.3` inventé.
|
||||
|
||||
## Formatage et audits Rust
|
||||
|
||||
```text
|
||||
cargo fmt --all PASS
|
||||
cargo fmt --all -- --check PASS
|
||||
Rust test-layout audit clean (9 crate(s))
|
||||
Rust blank-line audit clean (36 file(s))
|
||||
Rust item-spacing audit clean (36 file(s))
|
||||
Rust module-order audit clean (36 file(s))
|
||||
Rust trait-import-block audit clean (36 file(s))
|
||||
Rust re-export-block audit clean (36 file(s))
|
||||
Rust crate-root facade audit clean (6 crate root(s))
|
||||
Rust export completeness audit 0 candidate(s) across 9 package(s)
|
||||
```
|
||||
|
||||
## Cargo, Clippy et tests Git
|
||||
|
||||
```text
|
||||
cargo metadata --format-version 1 --no-deps PASS
|
||||
cargo check --workspace PASS
|
||||
cargo clippy --workspace --all-targets --all-features
|
||||
-- -D warnings PASS
|
||||
cargo test -p knowledge-git-lib --test git_read_path PASS (2)
|
||||
cargo test -p knowledge-git-lib --test git_write_candidate PASS (2)
|
||||
cargo test -p knowledge-git-lib --test git_write_push PASS (2)
|
||||
cargo test --workspace --all-targets --all-features PASS
|
||||
```
|
||||
|
||||
Tests workspace observés :
|
||||
|
||||
```text
|
||||
knowledge-app-lib 3 PASS
|
||||
knowledge-domain-lib 3 PASS
|
||||
knowledge-git-api 7 PASS
|
||||
knowledge-git-lib 8 unit + 6 integration PASS
|
||||
knowledge-sync-api 1 PASS
|
||||
knowledge-web-lib 4 PASS
|
||||
launchers 0 test chacun
|
||||
```
|
||||
|
||||
Les tests Git réels confirment encore le confinement du candidat, le refus des traversées par symlink, la création/suppression exacte des mutations, le push gardé, la création sous attente d'absence et le conflit concurrent sans écrasement.
|
||||
|
||||
## Baseline Web de stabilisation
|
||||
|
||||
```text
|
||||
npm ci PASS
|
||||
npm audit observé 0 vulnérabilité
|
||||
npm run typecheck PASS
|
||||
npm run build PASS
|
||||
Vite 8.3.1
|
||||
modules transformés 63
|
||||
Vite manifest audit PASS
|
||||
entrée src/main.ts
|
||||
```
|
||||
|
||||
Le build produit le manifest et les assets hashés attendus. Les avertissements Sass/Bootstrap de dépréciation ainsi que l'avertissement npm `@parcel/watcher` sont non bloquants ; le build termine avec succès.
|
||||
|
||||
## Revue d'horizon et contrôles spécifiques
|
||||
|
||||
Les contrôles opérateur confirment :
|
||||
|
||||
```text
|
||||
CHANGELOG 0.0.3 (candidate) présent
|
||||
ROADMAP 0.0.4 PostgreSQL partagé présent
|
||||
ROADMAP 0.0.6 templates publics présent
|
||||
ROADMAP 0.0.7 templates administration présent
|
||||
ROADMAP 0.0.8 Actix Web / Maud public présent
|
||||
ROADMAP 0.0.9 admin Actix / Maud + autorisation présent
|
||||
ROADMAP 0.0.10 gestion/revue/publication présent
|
||||
étude 007 présente
|
||||
prompt 004 présent
|
||||
prompt 004 sans commit/SHA futur inventé PASS
|
||||
aucun diff crates/ PASS
|
||||
aucun diff Web/ PASS
|
||||
crate PostgreSQL absente
|
||||
crate Gitea absente
|
||||
migrations absentes
|
||||
history beta.1 avant gate absent
|
||||
text hygiene clean (116 file(s))
|
||||
Cargo.lock présent localement, ignoré, non suivi
|
||||
package-lock Web présent
|
||||
```
|
||||
|
||||
Après staging, `git diff --cached --check` passe.
|
||||
|
||||
Le staging final observé avant ajout du présent history est exactement :
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M Cargo.toml
|
||||
M README.md
|
||||
M ROADMAP.md
|
||||
M VERSION
|
||||
A deltas/0.0.3/beta.1.md
|
||||
M docs/000-README.md
|
||||
M docs/architecture/001-PROJECT_PROFILE.md
|
||||
M docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
|
||||
M docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
|
||||
A docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
M docs/validation/001-VALIDATION_MATRIX.md
|
||||
A prompts/004-V0_0_4_START_PROMPT.md
|
||||
```
|
||||
|
||||
## Décision
|
||||
|
||||
`0.0.3-beta.1` est `PASS`.
|
||||
|
||||
Le scope produit est réconcilié et l'horizon post-`0.0.3` est suffisamment explicite. `0.0.3-rc.1` peut maintenant geler le scope et rejouer la gate complète, y compris les trois smokes HTTP de production, sans introduire de nouvelle fonctionnalité.
|
||||
140
prompts/004-V0_0_4_START_PROMPT.md
Normal file
140
prompts/004-V0_0_4_START_PROMPT.md
Normal file
@@ -0,0 +1,140 @@
|
||||
<!-- file: prompts/004-V0_0_4_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Knowledge 0.0.4 — prompt de démarrage
|
||||
|
||||
## Condition d'utilisation
|
||||
|
||||
Ce prompt est préparé pendant la stabilisation de `0.0.3`, après la revue d'horizon `0.0.3-beta.1` qui retient la fondation PostgreSQL partagée comme prochaine mission.
|
||||
|
||||
Il ne doit être exécuté qu'après publication réelle de la stable `v0.0.3` et vérification de son rapport post-tag.
|
||||
|
||||
Les valeurs exactes du commit stable, du SHA-256 de l'archive et du résultat `publish.001` ne sont volontairement pas écrites ici avant leur existence réelle.
|
||||
|
||||
## Baseline autoritaire à fournir au démarrage
|
||||
|
||||
La session de `0.0.4` doit recevoir :
|
||||
|
||||
```text
|
||||
archive sasedev-knowledge-v0.0.3.zip téléchargée depuis le tag Gitea v0.0.3
|
||||
rapport sasedev-knowledge-0.0.3-publish.001-report.md
|
||||
```
|
||||
|
||||
Avant tout développement, vérifier que :
|
||||
|
||||
- le rapport post-tag est `PASS` ;
|
||||
- le tag déréférencé, le commit produit et le commentaire/identité de l'archive convergent ;
|
||||
- `VERSION` et `[workspace.package].version` valent `0.0.3` dans l'archive ;
|
||||
- la chaîne deltas/histories de `0.0.3` est complète ;
|
||||
- la roadmap, le changelog stable, l'étude de réconciliation `007` et le présent prompt sont cohérents avec la publication réelle.
|
||||
|
||||
L'archive taggée est la baseline produit. L'absence de `.git` dans cette archive est normale.
|
||||
|
||||
## Autonomie normative
|
||||
|
||||
Knowledge reste autonome.
|
||||
|
||||
Ne pas rechercher, charger ni adopter automatiquement une nouvelle version de PGR. PGR `v0.1.3` reste une provenance historique de l'adoption fermée dans `0.0.2`. Une nouvelle réévaluation PGR n'est autorisée que si elle est explicitement ajoutée au scope de `0.0.4` par une décision future ; elle ne fait pas partie de la mission prévue ici.
|
||||
|
||||
Relire en priorité :
|
||||
|
||||
```text
|
||||
RULES.md
|
||||
docs/rules/200-GOVERNANCE.md
|
||||
docs/rules/210-WORKFLOW.md
|
||||
docs/rules/300-DOCUMENTATION.md
|
||||
docs/rules/400-VALIDATION.md
|
||||
docs/rules/510-RUST_CARGO.md
|
||||
docs/rules/530-WEB_FRONTEND.md
|
||||
docs/architecture/001-PROJECT_PROFILE.md
|
||||
docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
|
||||
docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
|
||||
ROADMAP.md
|
||||
```
|
||||
|
||||
## Mission prévue
|
||||
|
||||
`0.0.4` doit matérialiser la première fondation PostgreSQL partagée de Knowledge sans déplacer la vérité éditoriale hors de Git.
|
||||
|
||||
La release doit au minimum étudier puis matérialiser, dans un scope proportionné :
|
||||
|
||||
- le propriétaire applicatif de la persistance PostgreSQL partagée ;
|
||||
- le choix du driver/ORM ou client Rust réellement nécessaire ;
|
||||
- la configuration de connexion et le lifecycle/pooling ;
|
||||
- un premier schéma et une chaîne de migrations reproductible ;
|
||||
- la configuration logique persistante des sources lorsque cela apporte une valeur réelle ;
|
||||
- la dernière révision synchronisée/indexée ou un état équivalent nécessaire aux futurs cas d'usage ;
|
||||
- les invariants de reconstruction depuis Git ;
|
||||
- une stratégie de tests PostgreSQL locale/éphémère reproductible et proportionnée.
|
||||
|
||||
## Contrats à préserver
|
||||
|
||||
Git reste autoritaire pour le contenu publié.
|
||||
|
||||
PostgreSQL peut devenir autoritaire pour l'état applicatif transversal qui n'est pas un contenu éditorial Git, par exemple configuration logique, sessions futures, états de revue futurs, index et projections reconstructibles.
|
||||
|
||||
Ne pas écrire le corps publié d'un contenu uniquement en PostgreSQL comme raccourci architectural.
|
||||
|
||||
Conserver les frontières existantes :
|
||||
|
||||
```text
|
||||
knowledge-git-api contrats Git passifs provider-neutral
|
||||
knowledge-git-lib lecture + écriture Git contrôlées
|
||||
knowledge-app-lib orchestration applicative partagée
|
||||
knowledge-web-lib composition Actix/Maud/Vite partagée
|
||||
```
|
||||
|
||||
Créer une nouvelle crate uniquement si son ownership est démontré par l'étude de démarrage ; `knowledge-store-postgres-lib` reste un candidat, pas une obligation de nom ou d'architecture avant étude.
|
||||
|
||||
## Étude obligatoire de démarrage
|
||||
|
||||
Avant la première implémentation PostgreSQL, comparer au moins :
|
||||
|
||||
- clients/ORM Rust compatibles avec les règles locales et les besoins réels ;
|
||||
- migrations embarquées ou outillées ;
|
||||
- stratégie de pool/lifecycle ;
|
||||
- représentation des identifiants de source et révisions Git ;
|
||||
- séparation état autoritaire applicatif versus projection reconstructible ;
|
||||
- stratégie de test locale, CI et données éphémères ;
|
||||
- gestion des secrets/configurations de connexion sans valeur sensible versionnée ;
|
||||
- comportement si PostgreSQL est indisponible ;
|
||||
- impact sur les trois applications sans dupliquer trois bases ou trois implémentations.
|
||||
|
||||
Ne pas sélectionner une technologie par simple familiarité ou par copie d'un autre projet.
|
||||
|
||||
## Hors scope initial
|
||||
|
||||
Ne pas absorber automatiquement dans `0.0.4` :
|
||||
|
||||
- formats finaux PGR/HOWTO/snippet et parsing complet ;
|
||||
- templates publics des trois sites ;
|
||||
- templates d'administration ;
|
||||
- routes publiques finales Actix/Maud ;
|
||||
- auth complète et modèle final de rôles/capabilities ;
|
||||
- workflow complet de proposition/revue/publication ;
|
||||
- adapter Gitea ou autre forge ;
|
||||
- moteur de recherche avancé ;
|
||||
- scheduler/jobs ;
|
||||
- rebase/merge automatique ;
|
||||
- partage multi-processus de la racine Git ;
|
||||
- Git LFS/submodules.
|
||||
|
||||
Ces éléments appartiennent à l'horizon réévaluable documenté par `0.0.3-beta.1`.
|
||||
|
||||
## Première tranche attendue
|
||||
|
||||
`0.0.4-alpha.1` doit :
|
||||
|
||||
1. vérifier intégralement la stable `v0.0.3` et son rapport post-tag réels ;
|
||||
2. relire les owners locaux, architecture, étude `007`, roadmap, deltas/histories et décisions `DEFER` ;
|
||||
3. confirmer qu'aucune adoption PGR n'est engagée ;
|
||||
4. étudier les choix PostgreSQL sans créer prématurément une architecture de stockage ;
|
||||
5. décider l'ownership, les contrats, le premier schéma utile, la stratégie de migration et la stratégie de test ;
|
||||
6. produire l'étude et le plan `0.0.4` correspondants ;
|
||||
7. mettre à jour l'horizon seulement si cette étude rend une dépendance future fausse ou insuffisante ;
|
||||
8. ne rédiger le changelog `0.0.4` qu'à l'approche de sa stabilisation ;
|
||||
9. préparer une gate de cadrage proportionnée puis attendre son résultat opérateur avant tout history.
|
||||
|
||||
## Sortie attendue de 0.0.4
|
||||
|
||||
À la fin de `0.0.4`, Knowledge doit posséder une fondation PostgreSQL partagée, testée et migrable, capable de conserver l'état transversal minimal requis par les prochaines projections et façades tout en restant reconstructible/cohérente avec Git lorsque les données sont dérivées du contenu publié.
|
||||
Reference in New Issue
Block a user