0.0.1-beta.1

prompts/002-V0_0_2_START_PROMPT.md

@@ -0,0 +1,172 @@
+<!-- file: prompts/002-V0_0_2_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Knowledge 0.0.2 — prompt de démarrage
+
+## Condition d'utilisation
+
+Ce prompt est préparé pendant `0.0.1-beta.1`.
+
+Il ne doit être exécuté qu'après publication complète de `0.0.1` :
+
+```text
+history rel.N réellement PASS
+commit produit 0.0.1
+tag stable v0.0.1 publié
+rapport post-tag sasedev-knowledge-0.0.1-publish.001-report.md = PASS
+```
+
+Si l'une de ces preuves manque, rester sur la fermeture de `0.0.1`.
+
+## Baseline autoritaire
+
+Partir de l'archive téléchargée depuis le tag stable Knowledge `v0.0.1` et du rapport post-tag correspondant.
+
+Ne pas reconstruire la baseline depuis un workspace local non vérifié ou une conversation précédente.
+
+La fondation `0.0.1` a été construite avec PGR stable `v0.1.1`. Au démarrage de `0.0.2`, vérifier la stable PGR courante. Si une stable PGR plus récente existe et doit être adoptée, établir explicitement le mapping d'adoption avant l'implémentation ; ne pas modifier silencieusement les règles locales.
+
+## Mission
+
+`0.0.2` matérialise le premier chemin Git générique réel et la synchronisation de lecture.
+
+La release doit implémenter, derrière les contrats existants, la capacité de partir d'une source Git locale ou d'un remote Git générique, maintenir une copie locale contrôlée, rafraîchir la source, résoudre une référence vers une révision et fournir un snapshot/worktree déterministe utilisable par les futurs parseurs.
+
+La forge reste optionnelle.
+
+## Contrats existants à préserver
+
+Réutiliser les owners de `0.0.1` :
+
+```text
+knowledge-domain-lib
+knowledge-git-api
+knowledge-sync-api
+```
+
+Ne pas remplacer `GitRepository` ou `RepositoryEventSource` par des types Gitea/GitHub/GitLab.
+
+Étendre un contrat seulement lorsqu'un besoin de l'implémentation réelle le démontre.
+
+## Étude obligatoire avant `alpha.1`
+
+Comparer les options réalistes d'implémentation Git, au minimum :
+
+- processus `git` contrôlé ;
+- `gix` ou crate Git native pertinente ;
+- combinaison éventuelle avec justification.
+
+Évaluer :
+
+- fidélité au comportement Git réel ;
+- support local/remote ;
+- clone/mirror/fetch/worktree ;
+- contrôle des chemins et répertoires ;
+- erreurs structurées ;
+- sécurité des arguments/processus ;
+- portabilité ;
+- dépendances natives ;
+- async/blocking et stratégie d'isolation ;
+- testabilité avec repositories temporaires locaux ;
+- coût de maintenance.
+
+Ne pas choisir une bibliothèque sur réputation seule.
+
+## Scope cible
+
+La release doit viser :
+
+- une configuration explicite de source Git locale ou remote ;
+- une implémentation provider-neutral derrière `knowledge-git-api` ;
+- matérialisation locale hors des sources du dépôt applicatif ;
+- refresh/fetch idempotent ;
+- résolution d'une référence vers une révision Git ;
+- préparation d'un snapshot/worktree de lecture ;
+- comparaison de la révision observée avec la précédente ;
+- synchronisation explicite ;
+- déclenchement périodique si la responsabilité runtime est suffisamment claire ;
+- tests locaux reproductibles ne nécessitant aucune forge publique.
+
+## Non-objectifs
+
+Ne pas absorber par anticipation :
+
+- Gitea/GitHub/GitLab API ;
+- webhook forge ;
+- pull/merge requests ;
+- commit/push de publication ;
+- workflow complet de proposition ;
+- PostgreSQL/migrations ;
+- moteur de recherche ;
+- format final HOWTO/snippet ;
+- auth/admin ;
+- worker réseau séparé sans ownership démontré.
+
+Un hook/webhook futur doit pouvoir produire le même signal interne que les mécanismes génériques sans devenir autoritaire.
+
+## Contraintes de lecture
+
+Une requête publique ne doit pas faire un fetch distant pour servir une page.
+
+Le chemin cible est :
+
+```text
+remote/local Git
+  -> matérialisation locale contrôlée
+  -> révision autoritaire résolue
+  -> snapshot/worktree de lecture
+  -> futurs parseurs/projections
+```
+
+Les données dérivées doivent pouvoir être reconstruites à partir de Git.
+
+## Layout Rust
+
+Conserver la convention locale `0.0.1` :
+
+```text
+src/         code
+unit_tests/  tests unitaires rattachés par #[path]
+tests/       tests d'intégration Cargo via API publique
+```
+
+La nouvelle implémentation Git doit avoir des tests unitaires ciblés et des tests d'intégration avec repositories Git temporaires lorsque la preuve exige de traverser la frontière publique.
+
+## Web
+
+La baseline Web/Actix/Maud/Vite de `0.0.1` reste une non-régression.
+
+`0.0.2` ne doit pas modifier l'UI ou le rendu sauf besoin direct démontré par la mission Git/synchronisation.
+
+## Première tranche
+
+Avant de produire `0.0.2-alpha.1` :
+
+1. vérifier intégralement l'archive stable `v0.0.1` et le rapport post-tag ;
+2. vérifier la stable PGR applicable ;
+3. relire `docs/studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md` ;
+4. inventorier exactement les contrats Git/sync existants ;
+5. réaliser l'étude comparative de l'implémentation Git ;
+6. décider l'owner de la configuration de sources ;
+7. décider où résident les copies Git générées, hors dépôt source ;
+8. établir le plan versionné `0.0.2` ;
+9. préparer seulement ensuite `0.0.2-alpha.1`.
+
+## Workflow
+
+Conserver le workflow PGR :
+
+```text
+delta
+-> application opérateur
+-> gates réelles
+-> history PASS/FAIL
+-> commit/push du snapshot observé
+-> tranche suivante ou fix
+```
+
+Ne jamais produire un history `PASS` sans preuves opérateur.
+
+## Sortie attendue
+
+La release `0.0.2` doit fournir un chemin Git/synchronisation de lecture réellement utilisable, indépendant d'une forge, suffisamment stable pour que les releases ultérieures puissent construire parsing, projections, PostgreSQL, publication et administration sans refaire la frontière Git.