0.0.3-beta.1

prompts/004-V0_0_4_START_PROMPT.md

@@ -0,0 +1,140 @@
+<!-- file: prompts/004-V0_0_4_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Knowledge 0.0.4 — prompt de démarrage
+
+## Condition d'utilisation
+
+Ce prompt est préparé pendant la stabilisation de `0.0.3`, après la revue d'horizon `0.0.3-beta.1` qui retient la fondation PostgreSQL partagée comme prochaine mission.
+
+Il ne doit être exécuté qu'après publication réelle de la stable `v0.0.3` et vérification de son rapport post-tag.
+
+Les valeurs exactes du commit stable, du SHA-256 de l'archive et du résultat `publish.001` ne sont volontairement pas écrites ici avant leur existence réelle.
+
+## Baseline autoritaire à fournir au démarrage
+
+La session de `0.0.4` doit recevoir :
+
+```text
+archive sasedev-knowledge-v0.0.3.zip téléchargée depuis le tag Gitea v0.0.3
+rapport sasedev-knowledge-0.0.3-publish.001-report.md
+```
+
+Avant tout développement, vérifier que :
+
+- le rapport post-tag est `PASS` ;
+- le tag déréférencé, le commit produit et le commentaire/identité de l'archive convergent ;
+- `VERSION` et `[workspace.package].version` valent `0.0.3` dans l'archive ;
+- la chaîne deltas/histories de `0.0.3` est complète ;
+- la roadmap, le changelog stable, l'étude de réconciliation `007` et le présent prompt sont cohérents avec la publication réelle.
+
+L'archive taggée est la baseline produit. L'absence de `.git` dans cette archive est normale.
+
+## Autonomie normative
+
+Knowledge reste autonome.
+
+Ne pas rechercher, charger ni adopter automatiquement une nouvelle version de PGR. PGR `v0.1.3` reste une provenance historique de l'adoption fermée dans `0.0.2`. Une nouvelle réévaluation PGR n'est autorisée que si elle est explicitement ajoutée au scope de `0.0.4` par une décision future ; elle ne fait pas partie de la mission prévue ici.
+
+Relire en priorité :
+
+```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
+docs/architecture/001-PROJECT_PROFILE.md
+docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
+docs/studies/007-V0_0_3_GIT_WRITE_RECONCILIATION.md
+ROADMAP.md
+```
+
+## Mission prévue
+
+`0.0.4` doit matérialiser la première fondation PostgreSQL partagée de Knowledge sans déplacer la vérité éditoriale hors de Git.
+
+La release doit au minimum étudier puis matérialiser, dans un scope proportionné :
+
+- le propriétaire applicatif de la persistance PostgreSQL partagée ;
+- le choix du driver/ORM ou client Rust réellement nécessaire ;
+- la configuration de connexion et le lifecycle/pooling ;
+- un premier schéma et une chaîne de migrations reproductible ;
+- la configuration logique persistante des sources lorsque cela apporte une valeur réelle ;
+- la dernière révision synchronisée/indexée ou un état équivalent nécessaire aux futurs cas d'usage ;
+- les invariants de reconstruction depuis Git ;
+- une stratégie de tests PostgreSQL locale/éphémère reproductible et proportionnée.
+
+## Contrats à préserver
+
+Git reste autoritaire pour le contenu publié.
+
+PostgreSQL peut devenir autoritaire pour l'état applicatif transversal qui n'est pas un contenu éditorial Git, par exemple configuration logique, sessions futures, états de revue futurs, index et projections reconstructibles.
+
+Ne pas écrire le corps publié d'un contenu uniquement en PostgreSQL comme raccourci architectural.
+
+Conserver les frontières existantes :
+
+```text
+knowledge-git-api       contrats Git passifs provider-neutral
+knowledge-git-lib       lecture + écriture Git contrôlées
+knowledge-app-lib       orchestration applicative partagée
+knowledge-web-lib       composition Actix/Maud/Vite partagée
+```
+
+Créer une nouvelle crate uniquement si son ownership est démontré par l'étude de démarrage ; `knowledge-store-postgres-lib` reste un candidat, pas une obligation de nom ou d'architecture avant étude.
+
+## Étude obligatoire de démarrage
+
+Avant la première implémentation PostgreSQL, comparer au moins :
+
+- clients/ORM Rust compatibles avec les règles locales et les besoins réels ;
+- migrations embarquées ou outillées ;
+- stratégie de pool/lifecycle ;
+- représentation des identifiants de source et révisions Git ;
+- séparation état autoritaire applicatif versus projection reconstructible ;
+- stratégie de test locale, CI et données éphémères ;
+- gestion des secrets/configurations de connexion sans valeur sensible versionnée ;
+- comportement si PostgreSQL est indisponible ;
+- impact sur les trois applications sans dupliquer trois bases ou trois implémentations.
+
+Ne pas sélectionner une technologie par simple familiarité ou par copie d'un autre projet.
+
+## Hors scope initial
+
+Ne pas absorber automatiquement dans `0.0.4` :
+
+- formats finaux PGR/HOWTO/snippet et parsing complet ;
+- templates publics des trois sites ;
+- templates d'administration ;
+- routes publiques finales Actix/Maud ;
+- auth complète et modèle final de rôles/capabilities ;
+- workflow complet de proposition/revue/publication ;
+- adapter Gitea ou autre forge ;
+- moteur de recherche avancé ;
+- scheduler/jobs ;
+- rebase/merge automatique ;
+- partage multi-processus de la racine Git ;
+- Git LFS/submodules.
+
+Ces éléments appartiennent à l'horizon réévaluable documenté par `0.0.3-beta.1`.
+
+## Première tranche attendue
+
+`0.0.4-alpha.1` doit :
+
+1. vérifier intégralement la stable `v0.0.3` et son rapport post-tag réels ;
+2. relire les owners locaux, architecture, étude `007`, roadmap, deltas/histories et décisions `DEFER` ;
+3. confirmer qu'aucune adoption PGR n'est engagée ;
+4. étudier les choix PostgreSQL sans créer prématurément une architecture de stockage ;
+5. décider l'ownership, les contrats, le premier schéma utile, la stratégie de migration et la stratégie de test ;
+6. produire l'étude et le plan `0.0.4` correspondants ;
+7. mettre à jour l'horizon seulement si cette étude rend une dépendance future fausse ou insuffisante ;
+8. ne rédiger le changelog `0.0.4` qu'à l'approche de sa stabilisation ;
+9. préparer une gate de cadrage proportionnée puis attendre son résultat opérateur avant tout history.
+
+## Sortie attendue de 0.0.4
+
+À la fin de `0.0.4`, Knowledge doit posséder une fondation PostgreSQL partagée, testée et migrable, capable de conserver l'état transversal minimal requis par les prochaines projections et façades tout en restant reconstructible/cohérente avec Git lorsque les données sont dérivées du contenu publié.