141 lines
6.4 KiB
Markdown
141 lines
6.4 KiB
Markdown
<!-- 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é.
|