<!-- file: prompts/003-V0_0_3_START_PROMPT.md -->
<!-- version: 1 -->

# Knowledge 0.0.3 — prompt de démarrage

## Condition d'utilisation

Ce prompt est matérialisé lors de l'ouverture explicite de `0.0.3`, après fermeture et publication complète de `0.0.2`.

La reprise n'est valide que si les preuves suivantes sont disponibles :

```text
history rel.1 de 0.0.2              PASS
commit produit 0.0.2                183d354a67bec6d2d512c4898f5189759a6120b0
tag stable v0.0.2                   publié
archive sasedev-knowledge-v0.0.2.zip vérifiée
rapport post-tag publish.001        PASS
```

## Baseline autoritaire

Partir de :

```text
tag Knowledge          v0.0.2
commit Knowledge       183d354a67bec6d2d512c4898f5189759a6120b0
archive SHA-256        0e518c7eaad115811cccc8fb2b38a1e68150ec985c2ca72ec08a9ca5bbb202ce
publish report         sasedev-knowledge-0.0.2-publish.001-report.md = PASS
```

L'archive taggée est la baseline produit. L'absence de `.git` dans cette archive est normale.

Ne pas reconstruire l'état depuis une conversation, un workspace local ou une version ultérieure non vérifiée.

## Autonomie normative

Knowledge est autonome après l'adoption fermée en `0.0.2`.

Ne pas rechercher, charger ni adopter automatiquement une nouvelle version de PGR. PGR `v0.1.3` reste uniquement une provenance historique locale. Une réévaluation PGR n'est autorisée que si elle est explicitement ajoutée au scope par un REPLAN ou une release future.

Relire les owners Knowledge :

```text
RULES.md
docs/rules/200-GOVERNANCE.md
docs/rules/210-WORKFLOW.md
docs/rules/300-DOCUMENTATION.md
docs/rules/400-VALIDATION.md
docs/rules/510-RUST_CARGO.md
docs/rules/530-WEB_FRONTEND.md
```

## Mission

`0.0.3` matérialise l'écriture Git générique contrôlée et un push gardé indépendant d'une forge.

La release doit pouvoir :

- partir d'une `GitRevision` de base explicite ;
- créer un worktree d'écriture isolé sous la racine d'état contrôlée ;
- appliquer des mutations de fichiers confinées ;
- créer un commit avec identité explicite et hooks neutralisés ;
- produire une révision candidate ;
- mettre à jour une branche `refs/heads/...` uniquement si son état distant correspond à l'attente fournie ;
- signaler un conflit sans écraser une divergence concurrente.

## Contrats à préserver

Réutiliser la séparation actuelle :

```text
knowledge-git-api  contrats passifs provider-neutral
knowledge-git-lib  implémentation process Git contrôlée
knowledge-app-lib  orchestration application existante, sans backend Git/DB/forge
```

Ne pas transformer le contrat de lecture existant en interface d'écriture obligatoire. Introduire un contrat distinct seulement lorsque les types d'écriture sont matérialisés.

## Étude obligatoire de cadrage

Avant toute implémentation fonctionnelle, vérifier :

- pourquoi l'écriture Git est le prochain axe utile parmi les `DEFER` ;
- worktree d'écriture isolé versus plumbing Git ;
- confinement des chemins et risques `.git`/`..`/symlinks ;
- identité auteur/committer explicite ;
- neutralisation des hooks et prompts ;
- sémantique d'attente distante/compare-and-exchange ;
- création d'une branche absente ;
- conflit sur branche divergente ;
- cleanup après succès/échec ;
- redaction des erreurs ;
- tests reproductibles avec remote bare local.

Le résultat est documenté dans :

```text
docs/studies/006-V0_0_3_GIT_WRITE_STUDY.md
```

## Non-objectifs

Ne pas absorber par anticipation :

- rebase/merge automatique ;
- workflow complet de proposition/revue ;
- PostgreSQL/migrations ;
- Gitea ou autre API de forge ;
- auth/admin ;
- routes HTTP d'écriture ;
- UI de contribution ;
- signature de commits ;
- scheduler/jobs ;
- formats finaux HOWTO/snippet ;
- Git LFS/submodules ;
- partage multi-processus de la racine Git.

## Première tranche

`0.0.3-alpha.1` doit :

1. vérifier intégralement la stable `v0.0.2` et son rapport post-tag ;
2. relire les règles/owners locaux, architecture, roadmap, deltas/histories et `DEFER` ;
3. confirmer qu'aucune adoption PGR n'est engagée ;
4. déterminer et documenter l'écriture Git contrôlée comme mission `0.0.3` ;
5. produire l'étude `006` et le plan `003` ;
6. mettre à jour les documents vivants nécessaires ;
7. ne modifier aucun fichier produit sous `crates/` ou `Web/` ;
8. préparer la gate de cadrage puis attendre le résultat opérateur avant tout history.

## Sortie attendue

À la fin de `0.0.3`, Knowledge doit posséder une primitive d'écriture Git générique, sûre et testable permettant de produire puis pousser une révision candidate sans dépendre d'une forge et sans écraser silencieusement une branche ayant divergé.