sasedev-knowledge/prompts/002-V0_0_2_START_PROMPT.md

<!-- 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.