0.0.2-beta.1

This commit is contained in:
2026-09-29 06:10:29 +02:00
parent da5445354e
commit 5cee2a65b0
13 changed files with 541 additions and 47 deletions

View File

@@ -1,10 +1,21 @@
<!-- file: CHANGELOG.md --> <!-- file: CHANGELOG.md -->
<!-- version: 12 --> <!-- version: 13 -->
# Changelog SaseDev Knowledge # 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. 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.2 (candidate)
- matérialise un backend Git générique de lecture derrière `knowledge-git-api`, sans dépendance obligatoire à une forge ;
- prend en charge sources locales/remotes, mirror contrôlé, refresh avec pruning, résolution de référence vers commit et snapshots/worktrees détachés adressés par révision ;
- sécurise l'exécution Git sans shell, avec prompts interactifs désactivés, hooks neutralisés et erreurs publiques expurgées des localisations/credentials ;
- matérialise `knowledge-app-lib` comme owner du cas d'usage partagé de synchronisation `Changed` / `Unchanged`, avec révision précédente fournie par l'appelant et sans pseudo-persistance locale ;
- conserve `Periodic` comme origine du même cas d'usage sans imposer de scheduler concret ;
- rend Knowledge autonome après l'adoption ponctuelle PGR `v0.1.3` en possédant localement règles, templates et audits nécessaires au développement courant ;
- normalise les crates bibliothèques autour d'une façade crate-root mince et de modules propriétaires, sans modifier les API publiques validées ;
- conserve PostgreSQL, adapter de forge, écriture/publication Git, auth/admin complète, parsing final HOWTO/snippet, submodules/LFS et partage concurrent de la racine Git hors du scope de cette release.
## 0.0.1 ## 0.0.1
- établit la gouvernance locale Knowledge à partir de PGR `v0.1.1` vérifiée ; - établit la gouvernance locale Knowledge à partir de PGR `v0.1.1` vérifiée ;

View File

@@ -1,5 +1,5 @@
# file: Cargo.toml # file: Cargo.toml
# version: 25 # version: 26
[workspace] [workspace]
resolver = "3" resolver = "3"
@@ -16,7 +16,7 @@ members = [
] ]
[workspace.package] [workspace.package]
version = "0.0.2-alpha.5" version = "0.0.2-beta.1"
edition = "2024" edition = "2024"
publish = false publish = false
repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge" repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge"

View File

@@ -1,5 +1,5 @@
<!-- file: README.md --> <!-- file: README.md -->
<!-- version: 15 --> <!-- version: 16 -->
# SaseDev Knowledge # SaseDev Knowledge
@@ -11,7 +11,7 @@ Le dépôt applicatif retenu est `sasedev-knowledge`. Le nom court du projet et
La version courante est définie par [`VERSION`](VERSION). 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-alpha.3.fix.1` ferme en `PASS` le chemin Git générique de lecture. `0.0.2-alpha.4.fix.1` ferme en `PASS` l'autonomie normative après l'adoption ponctuelle PGR `v0.1.3`. `0.0.2-alpha.5` matérialise le cas d'usage partagé de synchronisation de lecture. `0.0.1` est la première stable de fondation de SaseDev Knowledge. Les alphas `0.0.2` ont matérialisé le chemin Git générique de lecture, l'autonomie normative locale et le cas d'usage partagé de synchronisation. `0.0.2-beta.1` réconcilie désormais ces résultats, les `DEFER` et la documentation durable sans ajouter de grande fonctionnalité.
`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. `alpha.4` ne change pas cette sémantique. 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. `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. `alpha.4` ne change pas cette sémantique. 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.

View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md --> <!-- file: ROADMAP.md -->
<!-- version: 6 --> <!-- version: 7 -->
# Roadmap SaseDev Knowledge # Roadmap SaseDev Knowledge
@@ -28,4 +28,4 @@ Les thèmes suivants sont candidats à des releases ultérieures mais ne reçoiv
- authentification/autorisation complète ; - authentification/autorisation complète ;
- déploiement et opérations multi-domaines. - déploiement et opérations multi-domaines.
La revue d'horizon `0.0.1-beta.1` engage uniquement `0.0.2`. Les autres thèmes restent volontairement non numérotés jusqu'à ce qu'un scope et un ordre réellement utiles soient décidés. La revue d'horizon `0.0.2-beta.1` est réalisée : aucune release postérieure à `0.0.2` n'est engagée ni numérotée. Les thèmes futurs restent volontairement non numérotés jusqu'à ce qu'un scope et un ordre réellement utiles soient décidés.

View File

@@ -1 +1 @@
0.0.2-alpha.5 0.0.2-beta.1

168
deltas/0.0.2/beta.1.md Normal file
View File

@@ -0,0 +1,168 @@
<!-- file: deltas/0.0.2/beta.1.md -->
<!-- version: 1 -->
# Delta 0.0.2-beta.1 — réconciliation Git/synchronisation et revue d'horizon
## Base requise
État `0.0.2-alpha.5` committé et poussé après application de son history `PASS`.
La version devient :
```text
0.0.2-beta.1
```
## Nature de la tranche
`beta.1` est une tranche de stabilisation et de réconciliation. Elle n'ajoute aucune grande fonctionnalité, aucune crate, aucune dépendance, aucune route et aucun comportement Git.
Elle réconcilie :
- les neuf packages réellement matérialisés ;
- les contrats Git/synchronisation réellement obtenus ;
- les `DEFER` et hors-scope ;
- les références historiques ambiguës aux alphas `0.0.1` ;
- le changelog candidat ;
- la revue d'horizon.
L'étude durable est :
```text
docs/studies/005-V0_0_2_GIT_SYNC_RECONCILIATION.md
```
## Revue d'horizon
Aucune release postérieure à `0.0.2` n'est engagée ni numérotée. Les domaines futurs restent non numérotés jusqu'à décision d'une mission explicite. Aucun prompt `0.0.3` n'est créé.
## Gate opérateur
```bash
test "$(cat VERSION)" = '0.0.2-beta.1'
grep -F 'version = "0.0.2-beta.1"' Cargo.toml
grep -A2 '^## Statut$' history/0.0.2/alpha.5.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.2-beta.1-metadata.json
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-targets --all-features
(
cd Web/knowledge-template-lab
npm ci
npm run typecheck
npm run build
)
python3 - <<'PYGATE'
import json
from pathlib import Path
metadata = json.loads(Path('/tmp/sasedev-knowledge-0.0.2-beta.1-metadata.json').read_text(encoding='utf-8'))
expected = {
'knowledge-app-lib',
'knowledge-domain-lib',
'knowledge-git-api',
'knowledge-git-lib',
'knowledge-sync-api',
'knowledge-web-lib',
'knowledge-pgr-server',
'knowledge-howtos-server',
'knowledge-snippets-server',
}
assert {package['name'] for package in metadata['packages']} == expected
assert len(metadata['workspace_members']) == 9
study = Path('docs/studies/005-V0_0_2_GIT_SYNC_RECONCILIATION.md').read_text(encoding='utf-8')
for phrase in (
'knowledge-git-lib backend process Git contrôlé',
'knowledge-app-lib cas d\'usage partagé Changed / Unchanged',
'DEFER confirmés',
'Aucun prompt `0.0.3` n\'est créé',
):
assert phrase in study, phrase
roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
assert 'aucune release postérieure à `0.0.2` n\'est engagée ni numérotée' in roadmap
assert '0.0.3' not in roadmap
changelog = Path('CHANGELOG.md').read_text(encoding='utf-8')
assert '## 0.0.2 (candidate)' in changelog
for forbidden in ('alpha.1.fix', 'alpha.2.fix', 'alpha.3.fix', 'alpha.4.fix'):
assert forbidden not in changelog, forbidden
architecture = Path('docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md').read_text(encoding='utf-8')
assert '`0.0.1-alpha.4` possède le frontend indépendant' in architecture
assert '`0.0.1-alpha.5` matérialise `knowledge-web-lib`' in architecture
assert '## Réconciliation `0.0.2-beta.1`' in architecture
manifest_path = Path('../builds/sasedev-knowledge/web/template-lab/.vite/manifest.json')
assert manifest_path.is_file(), manifest_path
manifest = json.loads(manifest_path.read_text(encoding='utf-8'))
assert 'src/main.ts' in manifest, manifest.keys()
assert not Path('prompts/003-V0_0_3_START_PROMPT.md').exists()
assert not Path('history/0.0.2/beta.1.md').exists()
print('Knowledge 0.0.2-beta.1 reconciliation/horizon audit: clean')
PYGATE
python3 - <<'PYTEXT'
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 = []
for root in roots:
if root.is_file():
paths.append(root)
elif root.is_dir():
paths.extend(path for path in root.rglob('*') if path.is_file())
for path in paths:
data = path.read_bytes()
assert b'\r' not in data, path
assert data.endswith(b'\n'), path
text = data.decode('utf-8')
for number, line in enumerate(text.splitlines(), start=1):
assert line == line.rstrip(' \t'), (path, number)
print(f'Knowledge beta.1 text hygiene: clean ({len(paths)} file(s))')
PYTEXT
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 -z "$(git diff --name-only -- crates Web)"
test ! -e crates/knowledge-forge-gitea-lib
test ! -e crates/knowledge-store-postgres-lib
git add -A
git diff --cached --check
git status --short
```
Les warnings de dépendances frontend déjà connus ne constituent pas à eux seuls un `FAIL` si les commandes npm/Vite terminent avec succès.
## Transition
Un `PASS` autorise uniquement `0.0.2-rc.1`. Un échec requis produit un history factuel et un `beta.1.fix.N` ou un REPLAN selon la nature du défaut.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md --> <!-- file: docs/000-README.md -->
<!-- version: 7 --> <!-- version: 8 -->
# Documentation SaseDev Knowledge # Documentation SaseDev Knowledge
@@ -30,6 +30,7 @@
- [`studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md`](studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md) — analyse du pattern Vite manifest / Actix / Maud de `actix-auth-app` et contrat de reprise ciblée pour Knowledge. - [`studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md`](studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md) — analyse du pattern Vite manifest / Actix / Maud de `actix-auth-app` et contrat de reprise ciblée pour Knowledge.
- [`studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md`](studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md) — réconciliation beta de la fondation, DEFER conservés et revue d'horizon engageant uniquement `0.0.2`. - [`studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md`](studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md) — réconciliation beta de la fondation, DEFER conservés et revue d'horizon engageant uniquement `0.0.2`.
- [`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/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.
## Plans ## Plans

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/001-PROJECT_PROFILE.md --> <!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
<!-- version: 15 --> <!-- version: 16 -->
# Profil du projet Knowledge # Profil du projet Knowledge
@@ -166,10 +166,10 @@ Elles justifient de conserver séparées l'identité/authentification partagée,
- une nouvelle stable PGR n'a aucun effet tant qu'une réévaluation n'est pas explicitement planifiée ; - une nouvelle stable PGR n'a aucun effet tant qu'une réévaluation n'est pas explicitement planifiée ;
- les artefacts historiques `0.0.1` et les tranches antérieures de `0.0.2` restent inchangés. - les artefacts historiques `0.0.1` et les tranches antérieures de `0.0.2` restent inchangés.
## Décisions à rouvrir ## Réconciliation beta et décisions différées
La release `0.0.2` rouvre uniquement l'implémentation Git générique et la synchronisation réelle de lecture. `0.0.2-beta.1` confirme que le scope alpha est matérialisé par neuf packages Cargo : contrats domaine/Git/synchronisation, backend Git générique, orchestration application partagée, composition Web et trois launchers. Aucune responsabilité supplémentaire n'est nécessaire pour fermer la mission de lecture/synchronisation de `0.0.2`.
Restent différés : 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, écriture/publication Git et partage concurrent de la même racine Git entre plusieurs processus. Restent différés : 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, écriture/publication Git, 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.
Un changement de scope produit, un besoin mesuré ou une contrainte d'exploitation peut déclencher un REPLAN ; il ne justifie pas un choix anticipé. La revue d'horizon beta ne réserve aucune release suivante. Un changement de scope produit, un besoin mesuré ou une contrainte d'exploitation pourra engager ultérieurement une nouvelle mission ; il ne justifie pas un choix anticipé.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md --> <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
<!-- version: 13 --> <!-- version: 14 -->
# Architecture de fondation Knowledge # Architecture de fondation Knowledge
@@ -15,23 +15,25 @@ Le principe directeur reste :
## Workspace Rust matérialisé ## Workspace Rust matérialisé
`alpha.2` instancie le skeleton PGR `002-RUST_CARGO_WORKSPACE`. `alpha.3` matérialise les trois premières frontières passives : La stable `0.0.1` a matérialisé les premières frontières et le runtime Web :
```text
knowledge-domain-lib famille/source de contenu
knowledge-git-api GitRepository provider-neutral
knowledge-sync-api RepositoryEventSource et signal de réconciliation
```
`alpha.5` complète la fondation avec :
```text ```text
knowledge-domain-lib famille/source de contenu
knowledge-git-api GitRepository provider-neutral
knowledge-sync-api RepositoryEventSource et signal de réconciliation
knowledge-web-lib composition Actix/Maud et assets Vite knowledge-web-lib composition Actix/Maud et assets Vite
knowledge-pgr-server launcher PGR knowledge-pgr-server launcher PGR
knowledge-howtos-server launcher HOWTOs knowledge-howtos-server launcher HOWTOs
knowledge-snippets-server launcher snippets knowledge-snippets-server launcher snippets
``` ```
`0.0.2` ajoute deux owners réels sans changer la topologie multi-app :
```text
knowledge-git-lib backend Git générique : mirror/refresh/resolve/snapshot
knowledge-app-lib cas d'usage partagé de synchronisation Changed/Unchanged
```
Les deux crates `-api` sont justifiées par des implémentations réellement remplaçables ou multiples. Elles restent sans runtime, sans logging propre et sans dépendance à Actix, Gitea ou PostgreSQL. Les deux crates `-api` sont justifiées par des implémentations réellement remplaçables ou multiples. Elles restent sans runtime, sans logging propre et sans dépendance à Actix, Gitea ou PostgreSQL.
Les tests unitaires Rust sont désormais placés hors de `src/` sous `unit_tests/`, conformément à la convention locale Knowledge sélectionnée sur l'option permise par PGR. Les tests unitaires Rust sont désormais placés hors de `src/` sous `unit_tests/`, conformément à la convention locale Knowledge sélectionnée sur l'option permise par PGR.
@@ -330,9 +332,9 @@ En particulier, Knowledge ne doit pas hériter mécaniquement :
- d’une arborescence d’assets spécifique au corpus ; - d’une arborescence d’assets spécifique au corpus ;
- de dépendances TypeScript `@types/*` non justifiées par les packages réellement consommés. - de dépendances TypeScript `@types/*` non justifiées par les packages réellement consommés.
`alpha.4` possède le frontend indépendant et la production du manifest. La clé stable `src/main.ts` constitue l'entrée d'asset commune de départ ; son entrée de manifest doit référencer les sorties JavaScript et CSS générées. `0.0.1-alpha.4` possède le frontend indépendant et la production du manifest. La clé stable `src/main.ts` constitue l'entrée d'asset commune de départ ; son entrée de manifest doit référencer les sorties JavaScript et CSS générées.
`alpha.5` matérialise `knowledge-web-lib` comme owner partagé de l'intégration Actix/Maud. La crate choisit entre un dev server configuré par `KNOWLEDGE_VITE_DEV_ORIGIN` et un manifest configuré par `KNOWLEDGE_VITE_MANIFEST_PATH`. En production elle dérive le répertoire `assets/` depuis le manifest et le sert sous le préfixe `/assets`, tandis que `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe d'URL configurable. Les erreurs de configuration/manifest restent récupérables et remontent avant le démarrage du listener. `0.0.1-alpha.5` matérialise `knowledge-web-lib` comme owner partagé de l'intégration Actix/Maud. La crate choisit entre un dev server configuré par `KNOWLEDGE_VITE_DEV_ORIGIN` et un manifest configuré par `KNOWLEDGE_VITE_MANIFEST_PATH`. En production elle dérive le répertoire `assets/` depuis le manifest et le sert sous le préfixe `/assets`, tandis que `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe d'URL configurable. Les erreurs de configuration/manifest restent récupérables et remontent avant le démarrage du listener.
Les trois packages `knowledge-pgr-server`, `knowledge-howtos-server` et `knowledge-snippets-server` sont des launchers minces : chacun sélectionne `ServerSite` et le nom de sa variable de bind, puis délègue au runtime commun. Ils ne possèdent aucune logique de rendu ou de manifest dupliquée. Les trois packages `knowledge-pgr-server`, `knowledge-howtos-server` et `knowledge-snippets-server` sont des launchers minces : chacun sélectionne `ServerSite` et le nom de sa variable de bind, puis délègue au runtime commun. Ils ne possèdent aucune logique de rendu ou de manifest dupliquée.
@@ -348,6 +350,21 @@ La fondation matérialisée est cohérente avec les objectifs `0.0.1` :
`0.0.2-alpha.1` conserve cette réconciliation comme baseline : la release courante ouvre uniquement le chemin Git générique de lecture et la synchronisation réelle ; les autres axes restent différés. `0.0.2-alpha.1` conserve cette réconciliation comme baseline : la release courante ouvre uniquement le chemin Git générique de lecture et la synchronisation réelle ; les autres axes restent différés.
## Réconciliation `0.0.2-beta.1`
La mission Git/synchronisation est réconciliée avec l'implémentation réellement obtenue :
- neuf packages Cargo, sans crate placeholder ;
- `knowledge-git-api` provider-neutral et `knowledge-git-lib` comme implémentation process Git contrôlée ;
- sources locales/remotes convergeant vers un mirror contrôlé puis vers une révision commit et un snapshot validé ;
- `knowledge-app-lib` comme unique owner du cas d'usage refresh / resolve / compare / snapshot ;
- dernière révision fournie par l'appelant, sans stockage caché ;
- causes de synchronisation non autoritaires, `Periodic` sans scheduler imposé ;
- règles Knowledge autonomes après l'adoption ponctuelle PGR `v0.1.3` ;
- aucun adapter forge, PostgreSQL, auth/admin complète, écriture Git ou format final HOWTO/snippet introduit par anticipation.
Les besoins de rétention de snapshots, submodules/LFS, partage multi-processus de la racine Git et scheduler concret restent différés jusqu'à preuve d'un besoin réel. Aucune prochaine release n'est numérotée par cette réconciliation.
## 10. Administration ## 10. Administration
L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité. L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md --> <!-- file: docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md -->
<!-- version: 10 --> <!-- version: 11 -->
# Plan 0.0.2 — Git générique et synchronisation de lecture # Plan 0.0.2 — Git générique et synchronisation de lecture
@@ -28,7 +28,7 @@ PGR publish report pgr-0.1.3-publish.001-report.md = PASS
Le passage de PGR `v0.1.1` à `v0.1.3` est traité comme adoption d'un projet existant via `230-ADOPTION`. Les artefacts historiques de `0.0.1` ne sont pas réécrits. `v0.1.3` constitue une provenance d'adoption, pas une dépendance normative vivante : les futurs démarrages Knowledge doivent partir des règles locales et ne consultent PGR que lorsqu'une nouvelle adoption est explicitement engagée. Le passage de PGR `v0.1.1` à `v0.1.3` est traité comme adoption d'un projet existant via `230-ADOPTION`. Les artefacts historiques de `0.0.1` ne sont pas réécrits. `v0.1.3` constitue une provenance d'adoption, pas une dépendance normative vivante : les futurs démarrages Knowledge doivent partir des règles locales et ne consultent PGR que lorsqu'une nouvelle adoption est explicitement engagée.
`0.0.2-alpha.1` est `FAIL` pour défaut de structure du présent plan malgré des contrôles techniques propres. `alpha.1.fix.1` a corrigé uniquement ce cadrage documentaire et sa gate opérateur est `PASS`. `alpha.2` a été fermée par `alpha.2.fix.2` `PASS`. `alpha.3` démontre le chemin Git réel mais sa gate est `FAIL` sur hygiène/formatage/documentation de test ; `alpha.3.fix.1` corrige ces défauts et enregistre le REPLAN décrit ci-dessous. `0.0.2-alpha.1` est `FAIL` pour défaut de structure du présent plan malgré des contrôles techniques propres. `alpha.1.fix.1` a corrigé uniquement ce cadrage documentaire et sa gate opérateur est `PASS`. `alpha.2` a été fermée par `alpha.2.fix.2` `PASS`. `alpha.3` a été fermée par `alpha.3.fix.1` `PASS`. `alpha.4` a été fermée par `alpha.4.fix.1` `PASS`, terminant l'adoption PGR comme migration ponctuelle. `alpha.5` est `PASS` et ferme le scope fonctionnel alpha avec `knowledge-app-lib` et le cas d'usage partagé `Changed` / `Unchanged`. `beta.1` est la tranche courante de réconciliation et revue d'horizon.
## Mission ## Mission
@@ -62,12 +62,12 @@ Décisions déjà matérialisées par le cadrage `alpha.1` et non remises en cau
- la racine d'état reste exclusive à une instance/processus pour `0.0.2` ; - la racine d'état reste exclusive à une instance/processus pour `0.0.2` ;
- la révision précédemment observée reste fournie par l'appelant tant que la persistance PostgreSQL est hors scope ; - la révision précédemment observée reste fournie par l'appelant tant que la persistance PostgreSQL est hors scope ;
- `gix` et `git2` restent des alternatives différées, pas des backends ajoutés par symétrie. - `gix` et `git2` restent des alternatives différées, pas des backends ajoutés par symétrie.
- `knowledge-app-lib` est matérialisée en `alpha.5` comme owner du cas d'usage partagé refresh / résolution / comparaison / snapshot.
Questions laissées ouvertes jusqu'à la tranche qui les consomme : Questions laissées ouvertes jusqu'à la tranche qui les consomme :
- politique de nettoyage/rétention des snapshots ; - politique de nettoyage/rétention des snapshots ;
- besoin réel de supporter submodules ou Git LFS dans cette release ; - besoin réel de supporter submodules ou Git LFS dans cette release ;
- besoin réel d'une crate `knowledge-app-lib` pour l'orchestration partagée ;
- mécanisme concret de scheduler périodique, volontairement non requis pour prouver le cas d'usage de synchronisation ; - mécanisme concret de scheduler périodique, volontairement non requis pour prouver le cas d'usage de synchronisation ;
- prochaine mission/version après `0.0.2`, à décider uniquement lors de la revue d'horizon. - prochaine mission/version après `0.0.2`, à décider uniquement lors de la revue d'horizon.
@@ -234,17 +234,20 @@ La gate Rust applique désormais explicitement `cargo fmt --all`, puis `cargo fm
### beta.1 — réconciliation et revue d'horizon ### beta.1 — réconciliation et revue d'horizon
Réconcilier le plan avec l'implémentation réellement obtenue : Tranche courante de stabilisation. Elle n'ajoute aucune grande fonctionnalité.
- inventorier les contrats et crates effectivement matérialisés ; La réconciliation doit :
- vérifier les `DEFER` et hors-scope ;
- retirer ou corriger les hypothèses de forecast devenues fausses ;
- vérifier l'absence de dépendance forge/PostgreSQL/auth/admin ;
- rejouer les gates Rust/Git et la non-régression Web utile ;
- décider si une prochaine mission est suffisamment claire pour engager une version suivante ;
- ne réserver aucun numéro futur par défaut.
Aucune grande fonctionnalité nouvelle n'entre en beta. - inventorier les neuf packages et contrats effectivement matérialisés ;
- confirmer `knowledge-git-lib` comme backend Git et `knowledge-app-lib` comme owner du cas d'usage partagé ;
- vérifier les `DEFER` et hors-scope encore valides ;
- corriger les formulations durables héritées de `0.0.1` qui utilisent encore des numéros d'alpha non qualifiés ;
- confirmer l'absence de dépendance forge/PostgreSQL/auth/admin et d'écriture Git ;
- rejouer la gate Rust/Git et la non-régression Web utile ;
- produire une étude de réconciliation durable ;
- réaliser la revue d'horizon sans réserver de numéro futur par défaut.
Résultat de revue proposé et soumis à la gate beta : aucune prochaine mission n'est suffisamment décidée pour engager une version postérieure à `0.0.2`. Les domaines futurs restent non numérotés.
### rc.1 — candidate stable ### rc.1 — candidate stable
@@ -306,14 +309,10 @@ Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être
## Revue d'horizon ## Revue d'horizon
État courant : **non réalisée**. État courant : **réalisée dans `0.0.2-beta.1` et soumise à validation opérateur**.
Aucune version postérieure à `0.0.2` n'est réservée par le présent plan. Résultat : aucune version postérieure à `0.0.2` n'est réservée. Les domaines futurs restent non numérotés parce qu'aucune mission suivante ne possède encore un scope et un ordre suffisamment décidés.
La revue appartient à `beta.1` et doit s'appuyer sur le backend Git réellement éprouvé, les DEFER encore ouverts et les besoins produit observés. Elle peut : Les besoins différés confirmés incluent notamment : PostgreSQL/migrations, parsing/index, propositions/admin/auth, adapter de forge, écriture/publication Git, scheduler concret, submodules/LFS, politique de rétention des snapshots et partage multi-processus de la racine Git.
- engager une prochaine release avec mission explicite ; Une future mission pourra être engagée depuis la stable `0.0.2` lorsqu'un besoin produit ou d'exploitation choisira explicitement l'un de ces axes. Elle devra repartir de la baseline locale Knowledge et ne consultera PGR que si une réévaluation PGR est elle-même explicitement dans le scope.
- maintenir les domaines futurs non numérotés ;
- reclasser un besoin différé si les preuves obtenues le justifient.
Elle ne doit pas transformer automatiquement PostgreSQL, parsing/index, propositions/admin/auth, forge ou publication en prochaine version uniquement parce que ces domaines sont connus.

View File

@@ -0,0 +1,100 @@
<!-- file: docs/studies/005-V0_0_2_GIT_SYNC_RECONCILIATION.md -->
<!-- version: 1 -->
# Réconciliation 0.0.2 — Git générique et synchronisation
## Objet
Cette étude de `0.0.2-beta.1` réconcilie la mission annoncée avec l'implémentation réellement validée par les alphas. Elle n'ajoute aucune fonctionnalité et sert de baseline durable pour la candidate.
## Inventaire matérialisé
Le workspace contient neuf packages :
```text
knowledge-domain-lib famille/source de contenu
knowledge-git-api contrat GitRepository provider-neutral
knowledge-git-lib backend process Git contrôlé
knowledge-sync-api signaux de réconciliation
knowledge-app-lib cas d'usage partagé Changed / Unchanged
knowledge-web-lib runtime Actix/Maud/Vite partagé
knowledge-pgr-server launcher PGR
knowledge-howtos-server launcher HOWTOs
knowledge-snippets-server launcher snippets
```
Aucune crate n'est un placeholder créé uniquement pour refléter un diagramme.
## Chemin Git obtenu
Le chemin de lecture réellement matérialisé est :
```text
GitSourceConfig
-> mirror contrôlé repositories/<source-key>.git
-> remote update --prune
-> rev-parse <reference>^{commit}
-> GitRevision
-> worktree détaché snapshots/<source-key>/<revision>
-> validation HEAD + worktree propre
-> GitSnapshot
```
L'implémentation reste derrière `knowledge-git-api::GitRepository`. Les sources locales utilisent `--no-local`; les opérations sont lancées sans shell, sans prompt interactif et avec hooks neutralisés sur les opérations concernées. Les erreurs publiques n'exposent pas les localisations ou credentials de source.
## Synchronisation obtenue
`knowledge-app-lib` possède le cas d'usage partagé :
```text
RepositorySyncSignal
-> refresh
-> resolve_revision
-> comparer previous_revision
-> Unchanged
ou
-> prepare_snapshot
-> Changed { revision, snapshot }
```
La révision précédente est fournie par l'appelant ; aucune pseudo-base locale n'est ajoutée. `Periodic` utilise le même chemin de réconciliation qu'une cause explicite, sans scheduler concret.
## Autonomie normative
L'adoption PGR `v0.1.3` est fermée comme migration ponctuelle. Les règles, templates et audits nécessaires au travail courant sont possédés par Knowledge. Une session ou version normale repart de la baseline locale et ne recharge pas PGR.
## DEFER confirmés
Restent hors de `0.0.2` :
- adapter Gitea ou autre forge ;
- écriture Git, branches/propositions/rebase/merge/push et publication ;
- PostgreSQL, migrations et persistance durable de dernière révision ;
- moteur de recherche/index applicatif ;
- auth/admin complète et modèle rôles/capabilities ;
- formats finaux HOWTO/snippet et parsing métier ;
- scheduler périodique concret ;
- support explicite submodules/Git LFS ;
- politique de nettoyage/rétention des snapshots ;
- partage concurrent d'une même racine Git entre plusieurs processus ;
- backend secondaire `gix`/`git2` sans nouvelle preuve de besoin.
Ces points ne sont pas des défauts de `0.0.2`; ils nécessitent une mission distincte ou un besoin d'exploitation démontré.
## Réconciliation documentaire
Les anciennes références `alpha.2` à `alpha.5` de la fondation Web sont qualifiées `0.0.1-*` lorsque leur contexte serait ambigu avec les alphas `0.0.2`. La documentation durable distingue désormais clairement :
- fondation/runtime Web stable `0.0.1` ;
- backend Git et synchronisation `0.0.2` ;
- adoption PGR `v0.1.3` comme provenance historique, non comme dépendance courante.
## Revue d'horizon
La revue ne réserve aucune release après `0.0.2`. Plusieurs domaines futurs sont connus, mais aucun n'a encore un scope et un ordre suffisamment décidés pour devenir la prochaine mission autoritaire.
La prochaine version sera engagée uniquement lorsqu'un besoin produit ou d'exploitation choisira explicitement un axe. Aucun prompt `0.0.3` n'est créé en `beta.1`.
## Conclusion
Le scope fonctionnel de `0.0.2` est complet et cohérent avec sa mission. `beta.1` peut préparer la release candidate sans ajouter de fonctionnalité ; la RC devra se concentrer sur l'intégrité des artefacts, la reproductibilité Git, la gate Rust complète et la non-régression Web/runtime.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md --> <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 27 --> <!-- version: 28 -->
# Matrice de validation Knowledge # Matrice de validation Knowledge
@@ -734,3 +734,28 @@ La tranche de cas d'usage de synchronisation doit prouver :
- `git diff --cached --check` propre avant commit. - `git diff --cached --check` propre avant commit.
Le `PASS` d'`alpha.5` ferme le scope fonctionnel alpha de `0.0.2` et autorise uniquement la préparation de `beta.1` de réconciliation et revue d'horizon. Le `PASS` d'`alpha.5` ferme le scope fonctionnel alpha de `0.0.2` et autorise uniquement la préparation de `beta.1` de réconciliation et revue d'horizon.
## Gate de `0.0.2-beta.1`
La réconciliation beta doit prouver :
- `VERSION = 0.0.2-beta.1` et version workspace identique ;
- history `history/0.0.2/alpha.5.md` présent avec statut `PASS` et committé avant application ;
- aucun nouveau package Cargo, package npm, contrat runtime ou comportement Git introduit ;
- workspace Cargo composé exactement de neuf packages ;
- étude `005-V0_0_2_GIT_SYNC_RECONCILIATION.md` présente et cohérente avec l'implémentation ;
- `knowledge-git-lib` documentée comme backend Git générique réel et `knowledge-app-lib` comme owner du cas d'usage partagé ;
- références historiques aux alphas Web de fondation qualifiées `0.0.1-*` lorsqu'elles seraient ambiguës ;
- `DEFER` PostgreSQL/forge/auth/admin/formats finaux/écriture Git/scheduler/submodules-LFS/rétention snapshots/multi-processus conservés ;
- revue d'horizon réalisée sans engager ni numéroter de release après `0.0.2` ;
- `CHANGELOG.md` contient une section `0.0.2 (candidate)` utile et sans catalogue de fixes internes ;
- `cargo fmt --all` puis `cargo fmt --all -- --check` exécutés avant tout audit Rust ;
- audits Markdown et Rust locaux propres ;
- `cargo metadata`, `cargo check --workspace`, Clippy strict et tests workspace propres ;
- baseline Web `npm ci`, `npm run typecheck` et `npm run build` propre ;
- manifest Vite généré parsable avec l'entrée stable `src/main.ts` ;
- aucun diff sous `crates/` ou `Web/` ;
- `Cargo.lock` présent localement, ignoré et non suivi ;
- hygiène texte et `git diff --cached --check` propres.
Un `PASS` de `beta.1` autorise uniquement `0.0.2-rc.1`. Aucun prompt de release suivante n'est créé tant que la revue d'horizon ne l'a pas engagée.

173
history/0.0.2/beta.1.md Normal file
View File

@@ -0,0 +1,173 @@
<!-- file: history/0.0.2/beta.1.md -->
<!-- version: 1 -->
# History 0.0.2-beta.1 — réconciliation et revue d'horizon
## Statut
PARTIAL
La gate opérateur de `0.0.2-beta.1` exécutée le `2026-09-29` acquiert toutes les preuves documentaires, Rust, Git et Web demandées par le delta, mais elle ne contient pas les trois smokes HTTP pourtant requis par le plan `0.0.2` pendant la stabilisation.
L'absence de cette preuve provient d'une omission de la gate `beta.1` préparée par l'assistant ; aucune commande opérateur transmise n'a échoué. Le statut exact est donc `PARTIAL`, et non `PASS` ni `FAIL`.
## Baseline opérateur
`alpha.5` `PASS` a été historisé, committé et poussé avant application de `beta.1` :
```text
history/0.0.2/alpha.5.md PASS
commit da54453
message 0.0.2-alpha.5
branch master
push origin/master PASS
workspace après push propre
```
Le push observé a avancé `origin/master` de `1fe39df` à `da54453`.
## Version et audits documentaires
Les contrôles passent :
```text
VERSION 0.0.2-beta.1
Cargo workspace version 0.0.2-beta.1
git diff --check PASS
Markdown header audit clean (87 file(s))
Markdown link audit clean (72 local link(s), 87 file(s))
Markdown table audit clean (4 table(s), 87 file(s))
```
## Formatage et audits Rust
L'ordre local est respecté :
```text
cargo fmt --all PASS
cargo fmt --all -- --check PASS
Rust test-layout audit clean (9 crate(s))
Rust blank-line audit clean (32 file(s))
Rust item-spacing audit clean (32 file(s))
Rust module-order audit clean (32 file(s))
Rust trait-import-block audit clean (32 file(s))
Rust re-export-block audit clean (32 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
Les neuf packages compilent en `0.0.2-beta.1`.
```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 --workspace --all-targets --all-features PASS
```
Tests observés :
```text
knowledge-app-lib 3 PASS
knowledge-domain-lib 3 PASS
knowledge-git-api 1 PASS
knowledge-git-lib 8 unit PASS + 2 integration PASS
knowledge-sync-api 1 PASS
knowledge-web-lib 4 PASS
launchers 0 test chacun
```
Les deux tests d'intégration Git réels continuent de prouver le refresh, la résolution, les snapshots, la référence invalide et le snapshot sale.
## Baseline Web et manifest Vite
Les commandes suivantes passent :
```text
npm ci
npm run typecheck
npm run build
```
npm observe `@parcel/watcher@2.6.0` comme package avec script d'installation non couvert par `allowScripts`. Aucune approbation automatique n'est effectuée.
Les warnings de dépréciation Sass issus de Bootstrap restent non bloquants ; Vite termine avec succès et transforme `63` modules.
Le manifest généré est parsable et contient l'entrée stable `src/main.ts`.
## Réconciliation et revue d'horizon
L'audit passe :
```text
Knowledge 0.0.2-beta.1 reconciliation/horizon audit: clean
Knowledge beta.1 text hygiene: clean (87 file(s))
```
Il confirme notamment :
- neuf packages Cargo exactement ;
- `knowledge-git-lib` comme backend Git générique et `knowledge-app-lib` comme owner du cas d'usage partagé ;
- `DEFER` conservés pour PostgreSQL, forge, auth/admin, écriture Git, scheduler, submodules/LFS, rétention des snapshots et partage multi-processus ;
- `CHANGELOG.md` en état candidate sans catalogue des fixes internes ;
- aucune release postérieure à `0.0.2` engagée ni numérotée ;
- aucun prompt `0.0.3` anticipé ;
- aucun diff sous `crates/` ou `Web/` ;
- `Cargo.lock` présent localement, ignoré et non suivi.
Après staging, `git diff --cached --check` passe.
## Preuve manquante
Le plan `docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md` exige pendant la stabilisation la non-régression Web complète, y compris les smokes HTTP des trois launchers.
Le delta et la matrice `beta.1` ont omis ces commandes. Le transcript ne peut donc pas établir :
```text
knowledge-pgr-server smoke HTTP
knowledge-howtos-server smoke HTTP
knowledge-snippets-server smoke HTTP
```
Les preuves de `0.0.1` ne remplacent pas une preuve de stabilisation `0.0.2`.
## Staging observé
Avant ajout du présent history :
```text
M CHANGELOG.md
M Cargo.toml
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.2/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/002-V0_0_2_GIT_SYNC_PLAN.md
A docs/studies/005-V0_0_2_GIT_SYNC_RECONCILIATION.md
M docs/validation/001-VALIDATION_MATRIX.md
```
## Décision
`0.0.2-beta.1` est `PARTIAL`.
La réconciliation et la revue d'horizon sont acquises, mais la phase beta ne peut pas être fermée sans les smokes runtime requis.
La transition autorisée est :
```text
appliquer ce history
-> git add / diff --cached --check / status
-> commit exact "0.0.2-beta.1"
-> push origin master
-> vérifier le workspace propre
-> appliquer seulement ensuite 0.0.2-beta.1.fix.1
```
`beta.1.fix.1` ne doit introduire aucune fonctionnalité ; il corrige le contrat de validation et rejoue la gate de stabilisation complète avec les trois smokes HTTP.