0.0.2-alpha.2
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# 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.
|
||||
|
||||
`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` corrige uniquement ce cadrage documentaire avant toute implémentation Git.
|
||||
`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.
|
||||
|
||||
## Mission
|
||||
|
||||
@@ -65,10 +65,6 @@ Décisions déjà matérialisées par le cadrage `alpha.1` et non remises en cau
|
||||
|
||||
Questions laissées ouvertes jusqu'à la tranche qui les consomme :
|
||||
|
||||
- forme exacte des types de configuration publics de `knowledge-git-lib` ;
|
||||
- frontière exacte entre runner de processus interne et API publique ;
|
||||
- modèle d'erreur précis du backend Git, notamment redaction des arguments sensibles ;
|
||||
- politique de collision/normalisation de `source-key` et validation des chemins ;
|
||||
- politique de nettoyage/rétention des snapshots ;
|
||||
- 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 ;
|
||||
@@ -139,11 +135,15 @@ Le résultat opérateur initial est **FAIL** : les contrôles techniques transmi
|
||||
|
||||
`alpha.1.fix.1` corrige uniquement cette structure documentaire, ajoute la gate de non-régression correspondante et ne modifie aucune décision technique de l'étude Git. Aucun fichier sous `crates/` ou `Web/` n'est modifié dans `alpha.1` ou son fix.
|
||||
|
||||
La trajectoire normale ne reprend vers `alpha.2` qu'après `PASS` opérateur du fix.
|
||||
La gate opérateur de `alpha.1.fix.1` est **PASS**.
|
||||
|
||||
### alpha.2 — contrats minimaux et backend process
|
||||
|
||||
Matérialiser le premier backend réel sans encore prétendre couvrir tout le cycle de synchronisation :
|
||||
Statut opérateur : **à valider**.
|
||||
|
||||
Le delta matérialise le premier backend réel sans encore prétendre couvrir tout le cycle de synchronisation. Les choix concrets de la tranche sont : configuration publique `GitBackendConfig`/`GitSourceConfig`, runner process strictement interne, erreurs publiques redacted par construction et `source-key` hexadécimale déterministe dérivée du `SourceId`.
|
||||
|
||||
Le scope reste :
|
||||
|
||||
- créer `knowledge-git-lib` avec responsabilité réelle ;
|
||||
- introduire uniquement les types/configurations nécessaires aux sources et à la racine d'état ;
|
||||
|
||||
Reference in New Issue
Block a user