sasedev-knowledge/prompts/002-V0_0_2_START_PROMPT.md

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 :

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 :

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 :

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 :

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 :

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.