0.0.2-alpha.3.fix.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Profil du projet Knowledge
|
||||
|
||||
@@ -17,7 +17,7 @@ Knowledge start prompt prompts/002-V0_0_2_START_PROMPT.md
|
||||
|
||||
La fondation `0.0.1` a été construite sous PGR `v0.1.1`. Cette identité reste historique dans les artefacts `0.0.1`.
|
||||
|
||||
Le démarrage de `0.0.2` vérifie puis adopte la stable PGR courante :
|
||||
Le démarrage explicite de `0.0.2` a réévalué PGR et a retenu la stable suivante comme source d'adoption :
|
||||
|
||||
```text
|
||||
PGR stable tag v0.1.3
|
||||
@@ -26,6 +26,10 @@ PGR archive SHA-256 f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5
|
||||
PGR publish report pgr-0.1.3-publish.001-report.md = PASS
|
||||
```
|
||||
|
||||
Cette référence est une provenance d'adoption figée. Après matérialisation des contrats retenus, la baseline normative de Knowledge est constituée des artefacts locaux du dépôt Knowledge. Une version ou session future ne consulte pas automatiquement le PGR courant ; une nouvelle comparaison PGR exige une réévaluation explicitement engagée.
|
||||
|
||||
`alpha.4` doit terminer cette matérialisation locale pour l'adoption `v0.1.3`, sans recopier mécaniquement la structure PGR et sans réécrire les artefacts historiques déjà publiés.
|
||||
|
||||
L'archive PGR `v0.1.3` vérifiée possède `VERSION = 0.1.3`, `332` entrées ZIP, `290` fichiers, `42` répertoires, une racine unique `pgr/`, aucun symlink et aucun `.git`. Son rapport post-tag indique `48/48` tests Python et les audits Markdown propres.
|
||||
|
||||
Cette prévalidation ne remplace aucune gate opérateur Knowledge.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Plan 0.0.2 — Git générique et synchronisation de lecture
|
||||
|
||||
@@ -17,7 +17,7 @@ Knowledge publish report sasedev-knowledge-0.0.1-publish.001-report.md = PASS
|
||||
Knowledge start prompt prompts/002-V0_0_2_START_PROMPT.md
|
||||
```
|
||||
|
||||
La baseline PGR réévaluée au démarrage de cette release est :
|
||||
La source PGR explicitement réévaluée au démarrage de cette release est :
|
||||
|
||||
```text
|
||||
PGR stable tag v0.1.3
|
||||
@@ -26,9 +26,9 @@ PGR archive SHA-256 f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a0
|
||||
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.
|
||||
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` peut donc matérialiser le premier backend Git réel.
|
||||
`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.
|
||||
|
||||
## Mission
|
||||
|
||||
@@ -43,13 +43,13 @@ source locale/remote
|
||||
-> résultat de synchronisation changed/unchanged
|
||||
```
|
||||
|
||||
La release doit transformer les contrats passifs de `0.0.1` en un backend Git de lecture testable, reproductible et remplaçable, tout en gardant Git autoritaire pour le contenu et la persistance métier hors de ce scope.
|
||||
La release doit transformer les contrats passifs de `0.0.1` en un backend Git de lecture testable, reproductible et remplaçable, tout en gardant Git autoritaire pour le contenu et la persistance métier hors de ce scope. Elle doit également terminer l'adoption PGR engagée au démarrage en rendant Knowledge autonome : règles applicables adaptées/possédées localement, PGR conservé comme provenance et non chargé automatiquement à chaque reprise.
|
||||
|
||||
## État acquis et questions ouvertes
|
||||
|
||||
Décisions déjà matérialisées par le cadrage `alpha.1` et non remises en cause par son `FAIL` documentaire :
|
||||
|
||||
- PGR `v0.1.3` est la baseline applicable au projet existant ;
|
||||
- PGR `v0.1.3` est la source d'adoption explicitement retenue pour `0.0.2`, tandis que la baseline normative courante doit être possédée localement par Knowledge ;
|
||||
- les changements PGR Java/Maven/Gradle/Android ne deviennent pas applicables à Knowledge ;
|
||||
- le `DEFER` Tauri reste inchangé ;
|
||||
- le backend initial utilise un processus `git` contrôlé via `std::process::Command`, sans shell ;
|
||||
@@ -164,24 +164,51 @@ Si la surface « configuration + runner + mirror » ne peut plus être validée
|
||||
|
||||
### alpha.3 — refresh, résolution et snapshot réel
|
||||
|
||||
Statut opérateur : **à valider**.
|
||||
Statut opérateur initial : **FAIL**.
|
||||
|
||||
La tranche complète le chemin de lecture Git sur de vrais repositories temporaires :
|
||||
La tranche a matérialisé et prouvé sur de vrais repositories temporaires :
|
||||
|
||||
- enregistrer explicitement les configurations physiques des sources dans `GitBackend` afin d'implémenter réellement le contrat provider-neutral ;
|
||||
- faire implémenter `knowledge-git-api::GitRepository` par `knowledge-git-lib` ;
|
||||
- étendre le contrat uniquement avec `GitSnapshot` / `prepare_snapshot`, maintenant nécessaires à la matérialisation de lecture ;
|
||||
- enregistrement explicite des configurations physiques dans `GitBackend` ;
|
||||
- implémentation réelle de `knowledge-git-api::GitRepository` par `knowledge-git-lib` ;
|
||||
- extension minimale du contrat avec `GitSnapshot` / `prepare_snapshot` ;
|
||||
- refresh idempotent du mirror via `remote update --prune` ;
|
||||
- résolution typée d'une référence vers un commit avec `rev-parse --verify --end-of-options ...^{commit}` ;
|
||||
- refus des références invalides ou non résolubles ;
|
||||
- préparation d'un worktree/snapshot détaché adressé par révision ;
|
||||
- validation du `HEAD` et de l'état propre d'un snapshot existant avant réutilisation ;
|
||||
- preuve d'un changement de révision après ajout d'un commit source ;
|
||||
- preuve qu'aucune API de forge n'est nécessaire.
|
||||
- résolution typée avec `rev-parse --verify --end-of-options ...^{commit}` ;
|
||||
- worktree/snapshot détaché adressé par révision ;
|
||||
- validation du `HEAD` et de l'état propre avant réutilisation ;
|
||||
- changement de révision après ajout d'un commit source ;
|
||||
- rejet d'une référence invalide et d'un snapshot sale.
|
||||
|
||||
Les tests doivent exercer la frontière `GitRepository` et les effets Git réels. Une imitation complète de `git` par mocks ne constitue pas la preuve principale de cette tranche. Aucun `knowledge-app-lib`, scheduler ou état persistant n'entre dans `alpha.3`.
|
||||
Les tests fonctionnels passent, mais la gate complète échoue sur trois défauts de conformité : ligne vide terminale dans la matrice, formatage rustfmt d'un test `knowledge-git-api` et documentation de crate manquante dans le test d'intégration `git_read_path`.
|
||||
|
||||
### alpha.4 — cas d'usage de synchronisation
|
||||
`alpha.3.fix.1` corrige exclusivement ces défauts techniques et enregistre le présent REPLAN. Il ne modifie pas le comportement Git déjà prouvé.
|
||||
|
||||
La revue de tranche a déclenché un REPLAN explicite : l'autonomie normative après adoption PGR et l'organisation interne des crates doivent être traitées avant l'orchestration de synchronisation.
|
||||
|
||||
### alpha.4 — autonomie normative et structure interne des crates
|
||||
|
||||
Finaliser l'adoption PGR `v0.1.3` comme migration ponctuelle, sans transformer PGR en dépendance documentaire permanente :
|
||||
|
||||
- inventorier les owners/contrats PGR réellement retenus par Knowledge ;
|
||||
- produire un mapping durable `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` fondé sur la baseline locale actuelle ;
|
||||
- pour chaque `ADOPT`, identifier l'owner local qui possède effectivement le contrat ;
|
||||
- adapter et matérialiser localement uniquement les règles, templates/configurations et audits nécessaires au développement de Knowledge ;
|
||||
- ne pas recopier mécaniquement l'arborescence ou les textes PGR lorsque `RULES.md` ou un owner local plus adapté suffit ;
|
||||
- faire de PGR `v0.1.3` une provenance d'adoption figée, et non une « baseline courante » à recharger ;
|
||||
- établir que les futurs prompts de démarrage partent de la baseline Knowledge locale et ne demandent une consultation PGR que si une réévaluation PGR est explicitement dans leur scope ;
|
||||
- vérifier que les règles de gouvernance, workflow, documentation, validation, Rust/Cargo et Web réellement nécessaires sont compréhensibles et applicables depuis le dépôt Knowledge seul.
|
||||
|
||||
La même tranche audite l'organisation interne des crates :
|
||||
|
||||
- `lib.rs` reste la façade publique/documentation de crate ;
|
||||
- les types, traits et implémentations sont déplacés vers des modules nommés selon leur responsabilité lorsqu'ils forment une responsabilité distincte ;
|
||||
- les crates `knowledge-git-api` et `knowledge-sync-api` sont examinées en priorité ;
|
||||
- `api.rs` n'est pas imposé comme nom générique : préférer des modules tels que `reference`, `revision`, `snapshot`, `repository`, `signal` ou autre ownership réel ;
|
||||
- les petites crates/fichiers ne sont pas découpés artificiellement uniquement pour satisfaire une forme ;
|
||||
- les réexports publics restent centralisés à la crate root et les consommateurs externes continuent d'utiliser la façade stable.
|
||||
|
||||
Cette tranche ne change pas la sémantique Git prouvée par `alpha.3` et ne matérialise pas encore le cas d'usage `Changed` / `Unchanged`.
|
||||
|
||||
### alpha.5 — cas d'usage de synchronisation
|
||||
|
||||
Composer les primitives Git en un cas d'usage réellement consommable :
|
||||
|
||||
@@ -250,7 +277,7 @@ REPLAN obligatoire si :
|
||||
- l'orchestration de synchronisation crée une duplication réelle qui impose un nouvel owner commun non prévu ;
|
||||
- des mesures concrètes rendent le backend process inadéquat et justifient de réévaluer `gix` ou `git2` ;
|
||||
- trois fixes ou plus apparaissent sur une même tranche ;
|
||||
- une nouvelle stable PGR modifie un owner réellement applicable au scope courant ;
|
||||
- une réévaluation PGR explicitement engagée révèle un changement substantiel d'un contrat déjà adopté par Knowledge ;
|
||||
- un prérequis externe invalide la mission de `0.0.2`.
|
||||
|
||||
Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être masqué par un simple élargissement opportuniste d'un delta.
|
||||
@@ -260,7 +287,7 @@ Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être
|
||||
- documentation durable : réconciliée à chaque tranche qui change un contrat, puis revue globalement en `beta.1` ;
|
||||
- `CHANGELOG.md` : consolidé en candidate/stable sans catalogue de fixes internes inutile ;
|
||||
- `ROADMAP.md` : revue d'horizon en `beta.1`, sans création automatique d'une prochaine version ;
|
||||
- prompt/handoff suivant : créé uniquement si une prochaine mission est réellement décidée ;
|
||||
- prompt/handoff suivant : créé uniquement si une prochaine mission est réellement décidée et fondé sur la baseline normative locale Knowledge ; aucune consultation PGR automatique n'y est ajoutée ;
|
||||
- fermeture du plan : `rel.1` ou son fix établissant la stable ;
|
||||
- publication : commit produit `0.0.2`, tag stable `v0.0.2`, archive du tag puis rapport post-tag séparé ;
|
||||
- toute tranche suit `delta -> gate opérateur -> history réel -> commit/push -> tranche suivante ou fix`.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||
<!-- version: 23 -->
|
||||
<!-- version: 24 -->
|
||||
|
||||
# Matrice de validation Knowledge
|
||||
|
||||
@@ -635,5 +635,26 @@ La tranche de lecture Git réelle doit prouver :
|
||||
- `Cargo.lock` toujours ignoré/non suivi ;
|
||||
- `git diff --cached --check` propre avant commit.
|
||||
|
||||
Le `PASS` de `alpha.3` autorise uniquement la préparation de `0.0.2-alpha.4`, consacrée au cas d'usage de synchronisation `Changed` / `Unchanged`.
|
||||
La gate opérateur réelle d'`alpha.3` est `FAIL` : les preuves Git fonctionnelles passent, mais `git diff --check`, `cargo fmt --check` et Clippy strict ne sont pas tous propres. La transition autorisée est uniquement `alpha.3.fix.1`.
|
||||
|
||||
## Gate de `0.0.2-alpha.3.fix.1`
|
||||
|
||||
Le fix ferme les défauts techniques d'`alpha.3` et enregistre le REPLAN sans élargir son comportement Git. Il doit prouver :
|
||||
|
||||
- `VERSION = 0.0.2-alpha.3.fix.1` et `[workspace.package].version` identique ;
|
||||
- history `history/0.0.2/alpha.3.md` présent avec statut réel `FAIL` et committé avant application du fix ;
|
||||
- delta historique `deltas/0.0.2/alpha.3.md` inchangé ;
|
||||
- suppression du défaut `git diff --check` sur la matrice de validation ;
|
||||
- formatage rustfmt propre du test `knowledge-git-api` signalé par la gate ;
|
||||
- documentation de crate explicite dans `crates/knowledge-git-lib/tests/git_read_path.rs` afin de satisfaire `missing_docs` ;
|
||||
- comportement Git d'`alpha.3` inchangé : refresh, résolution, snapshot et tests réels restent identiques ;
|
||||
- plan `0.0.2` replanifié avec `alpha.4` dédiée à l'autonomie normative/structure interne des crates et ancien scope de synchronisation déplacé en `alpha.5` ;
|
||||
- PGR `v0.1.3` documenté comme provenance d'adoption figée et non comme dépendance normative vivante ;
|
||||
- règle locale interdisant la consultation automatique de PGR à chaque version/session/tranche, sauf réévaluation PGR explicitement engagée ;
|
||||
- aucune matérialisation prématurée des règles PGR détaillées ni refactor massif de crates dans ce fix : ce travail appartient à `alpha.4` ;
|
||||
- `cargo fmt --all -- --check`, audits Rust, `cargo metadata`, `cargo check`, Clippy strict, tests ciblés `knowledge-git-api`/`knowledge-git-lib`, test d'intégration `git_read_path` et tests workspace propres ;
|
||||
- `Web/` et `knowledge-sync-api` sans diff ;
|
||||
- `Cargo.lock` toujours ignoré/non suivi ;
|
||||
- `git diff --cached --check` propre avant commit.
|
||||
|
||||
Le `PASS` de `alpha.3.fix.1` ferme `alpha.3` et autorise uniquement la préparation de `0.0.2-alpha.4`.
|
||||
|
||||
Reference in New Issue
Block a user