0.0.1-alpha.1
This commit is contained in:
265
prompts/001-V0_0_1_START_PROMPT.md
Normal file
265
prompts/001-V0_0_1_START_PROMPT.md
Normal file
@@ -0,0 +1,265 @@
|
||||
<!-- file: prompts/001-V0_0_1_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Knowledge 0.0.1 — prompt de démarrage
|
||||
|
||||
## Mission
|
||||
|
||||
Initialiser le nouveau projet SaseDev Knowledge en conformité avec la stable PGR fournie.
|
||||
|
||||
Cette première version ne doit pas chercher à implémenter toute la plateforme. Elle doit établir une fondation de gouvernance, une architecture suffisamment précise pour éviter les mauvais couplages, un workspace minimal reproductible et un plan versionné pour les prochaines tranches.
|
||||
|
||||
La première tranche à préparer après audit est `0.0.1-alpha.1`.
|
||||
|
||||
## Baselines autoritaires
|
||||
|
||||
Utiliser comme autorité PGR :
|
||||
|
||||
- l'archive téléchargée depuis le tag Gitea stable `v0.1.1`, attendue sous un nom du type `pgr-v0.1.1.zip` ;
|
||||
- le rapport post-tag `pgr-0.1.1-publish.001-report.md`, qui doit être `PASS`.
|
||||
|
||||
Vérifier les hashes fournis avec les artefacts de session. Ne pas inventer un hash si l'archive ou le rapport réellement fournis diffèrent d'un nom ou d'une copie antérieure.
|
||||
|
||||
L'absence de `.git` dans une archive de tag est normale.
|
||||
|
||||
Ne pas utiliser une conversation précédente comme autorité lorsque l'information peut être vérifiée dans l'archive PGR ou les artefacts fournis.
|
||||
|
||||
## Produit à construire
|
||||
|
||||
Le projet doit préparer une plateforme SaseDev Knowledge permettant à terme de publier et administrer :
|
||||
|
||||
- PGR ;
|
||||
- des HOWTOs ;
|
||||
- des snippets.
|
||||
|
||||
Les façades publiques envisagées sont notamment :
|
||||
|
||||
- `pgr.sasedev.com` ;
|
||||
- `howtos.sasedev.com` ;
|
||||
- `snippets.sasedev.com`.
|
||||
|
||||
Ces hostnames sont des intentions produit. Leur déploiement effectif ne fait pas partie de `0.0.1` sauf nécessité architecturale démontrée.
|
||||
|
||||
L'application doit être développée en interne et ne doit pas dépendre d'un CMS existant.
|
||||
|
||||
## Principe fondamental de stockage
|
||||
|
||||
Concevoir la plateforme avec la règle suivante :
|
||||
|
||||
> Git est le backend de contenu ; une forge est une capacité optionnelle.
|
||||
|
||||
Le cœur doit fonctionner avec :
|
||||
|
||||
- un dépôt Git local ;
|
||||
- un remote Git générique ;
|
||||
- éventuellement une forge telle que Gitea.
|
||||
|
||||
Gitea ne doit pas être introduit comme dépendance du domaine.
|
||||
|
||||
Les capacités forge-only — webhooks, pull requests, issues, releases, permissions — doivent être séparées des opérations Git fondamentales.
|
||||
|
||||
La lecture publique doit pouvoir continuer à partir d'une copie Git locale/index/cache lorsque la forge distante est temporairement indisponible.
|
||||
|
||||
## Source de vérité et PostgreSQL
|
||||
|
||||
Git est la source autoritaire du contenu versionné.
|
||||
|
||||
PostgreSQL est destiné à l'état applicatif, par exemple :
|
||||
|
||||
- utilisateurs et sessions ;
|
||||
- propositions ;
|
||||
- révisions et commentaires ;
|
||||
- revue/modération ;
|
||||
- audit applicatif ;
|
||||
- index de contenu ;
|
||||
- tags/relations calculés ;
|
||||
- recherche ;
|
||||
- état de synchronisation ;
|
||||
- jobs de publication.
|
||||
|
||||
Ne pas faire de PostgreSQL la source autoritaire du contenu publié lorsque ce contenu existe dans Git.
|
||||
|
||||
## Synchronisation générique
|
||||
|
||||
Le système doit pouvoir détecter les changements sans dépendre des webhooks.
|
||||
|
||||
Étudier et cadrer :
|
||||
|
||||
- synchronisation explicite ;
|
||||
- polling ;
|
||||
- hook Git local/serveur ;
|
||||
- webhook de forge.
|
||||
|
||||
Tous doivent converger vers un même cas d'usage interne de synchronisation.
|
||||
|
||||
Un watcher filesystem peut être un accélérateur, mais ne doit pas remplacer Git comme source de vérité sur la révision courante.
|
||||
|
||||
## Contributions externes
|
||||
|
||||
Le système doit permettre à un utilisateur externe de proposer :
|
||||
|
||||
- une correction ;
|
||||
- un nouveau HOWTO ;
|
||||
- un nouveau snippet ;
|
||||
- éventuellement une amélioration de documentation PGR, sans contourner le workflow propre à PGR.
|
||||
|
||||
Une proposition ne doit jamais écrire directement dans le contenu publié.
|
||||
|
||||
Elle doit conserver la révision Git de base afin de détecter les conflits et besoins de rebase.
|
||||
|
||||
Le workflow d'administration doit pouvoir fonctionner même sans pull request fournie par une forge.
|
||||
|
||||
Lorsqu'une forge compatible est disponible, une branche/PR peut être utilisée comme intégration optionnelle.
|
||||
|
||||
## Frontières documentaires
|
||||
|
||||
Étudier et formaliser la distinction :
|
||||
|
||||
- `normative` : PGR ;
|
||||
- `guidance/howto` : procédure, explication, diagnostic, anti-pattern ;
|
||||
- `snippet` : exemple court/configuration/commande contextualisée ;
|
||||
- `project-local` : décision concrète d'un projet.
|
||||
|
||||
Le système de métadonnées doit pouvoir relier ces contenus sans leur donner la même force normative.
|
||||
|
||||
Prévoir qu'un HOWTO/snippet puisse référencer des owners/règles PGR et que PGR puisse référencer facultativement une guidance externe sans en dépendre pour être intelligible.
|
||||
|
||||
## Stack technique initialement souhaitée
|
||||
|
||||
Évaluer cette stack par rapport à PGR et la retenir sauf raison documentée de déroger :
|
||||
|
||||
- Rust stable ;
|
||||
- workspace Cargo ;
|
||||
- Actix Web pour HTTP ;
|
||||
- Maud pour le rendu HTML SSR ;
|
||||
- Vite + TypeScript pour les assets et interactions frontend ;
|
||||
- Sass ;
|
||||
- Bootstrap ;
|
||||
- PostgreSQL.
|
||||
|
||||
Ne pas figer prématurément :
|
||||
|
||||
- l'ORM/driver PostgreSQL ;
|
||||
- le moteur de recherche ;
|
||||
- la topologie de déploiement ;
|
||||
- les noms définitifs des crates ;
|
||||
- un découpage microservices ;
|
||||
- le fournisseur Git/forge ;
|
||||
- l'authentification externe ;
|
||||
- les formats finaux HOWTO/snippet.
|
||||
|
||||
Ces points doivent être étudiés au moment où ils deviennent nécessaires.
|
||||
|
||||
## Travail PGR obligatoire avant implémentation
|
||||
|
||||
Lire dans la stable PGR au minimum :
|
||||
|
||||
- règles générales et workflow ;
|
||||
- modèle de profils ;
|
||||
- profil Rust/Cargo ;
|
||||
- profil TypeScript ;
|
||||
- profil JavaScript package ecosystem ;
|
||||
- profil Vite ;
|
||||
- profil CSS/Sass ;
|
||||
- profils/éléments Tauri uniquement pour comprendre les frontières, sans les adopter automatiquement ;
|
||||
- skeleton de fondation projet ;
|
||||
- skeleton workspace Rust ;
|
||||
- skeleton Web frontend ;
|
||||
- validations associées ;
|
||||
- templates Web TypeScript/package ;
|
||||
- études pertinentes ;
|
||||
- règles de documentation, versions, deltas/histories et handoff opérateur.
|
||||
|
||||
Ne pas recopier mécaniquement toute la structure PGR. Appliquer uniquement les owners/skeletons nécessaires et documenter les décisions locales.
|
||||
|
||||
## Architecture à étudier en 0.0.1
|
||||
|
||||
La première version doit aboutir à une décision claire sur au moins les frontières suivantes :
|
||||
|
||||
1. application/domain ;
|
||||
2. Git générique ;
|
||||
3. adapter forge ;
|
||||
4. synchronisation événementielle/polling ;
|
||||
5. workflow de propositions ;
|
||||
6. parsing et validation des contenus ;
|
||||
7. index/recherche/cache ;
|
||||
8. rendu/publication ;
|
||||
9. administration ;
|
||||
10. authentification/autorisation au niveau conceptuel ;
|
||||
11. séparation PGR/HOWTO/snippet ;
|
||||
12. séparation contenu Git / état PostgreSQL.
|
||||
|
||||
Éviter de multiplier les crates sans ownership réel.
|
||||
|
||||
## Dépôts
|
||||
|
||||
Étudier explicitement au moins les options suivantes :
|
||||
|
||||
- un dépôt applicatif Knowledge ;
|
||||
- le dépôt PGR existant comme source de contenu normative ;
|
||||
- un dépôt HOWTOs séparé ;
|
||||
- un dépôt snippets séparé.
|
||||
|
||||
Ne pas fusionner ces contenus dans PGR uniquement pour simplifier l'implémentation.
|
||||
|
||||
Le nom final du dépôt applicatif doit être proposé et justifié. `sasedev-knowledge` est un candidat, pas une obligation.
|
||||
|
||||
## Première version 0.0.1
|
||||
|
||||
`0.0.1` doit rester une version de fondation.
|
||||
|
||||
Objectifs candidats :
|
||||
|
||||
- gouvernance du nouveau dépôt ;
|
||||
- sélection des profils/skeletons PGR applicables ;
|
||||
- workspace Rust minimal ;
|
||||
- architecture/ADR ou étude fondatrice ;
|
||||
- configuration minimale reproductible ;
|
||||
- premiers contrats/interfaces sans implémentation disproportionnée ;
|
||||
- plan vivant des tranches suivantes ;
|
||||
- validations/audits adaptés.
|
||||
|
||||
Ne pas construire en `0.0.1` :
|
||||
|
||||
- moteur de recherche complet ;
|
||||
- UI d'administration complète ;
|
||||
- workflow de contribution complet ;
|
||||
- support complet Gitea/GitHub/GitLab ;
|
||||
- publication multi-domaines en production ;
|
||||
- moteur de rendu final de tous les formats ;
|
||||
- système d'authentification complet.
|
||||
|
||||
## Étude avant `alpha.1`
|
||||
|
||||
Avant de produire le premier delta :
|
||||
|
||||
1. vérifier intégralement l'archive PGR et son rapport post-tag ;
|
||||
2. relever les règles réellement applicables ;
|
||||
3. établir une matrice `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` pour les décisions importantes ;
|
||||
4. proposer l'architecture minimale ;
|
||||
5. proposer la nomenclature du dépôt et des premières crates ;
|
||||
6. identifier les décisions qui doivent rester différées ;
|
||||
7. vérifier que le scope `0.0.1` est suffisamment petit ;
|
||||
8. préparer un plan versionné ;
|
||||
9. seulement ensuite produire `0.0.1-alpha.1`.
|
||||
|
||||
## Livrables attendus de l'assistant
|
||||
|
||||
Pour chaque tranche :
|
||||
|
||||
- analyse fondée sur les artefacts réels ;
|
||||
- delta ZIP applicable à la racine du dépôt ;
|
||||
- delta Markdown ;
|
||||
- commandes opérateur exactes ;
|
||||
- après retour opérateur : history observé ;
|
||||
- tranche suivante ou `.fix.N` selon le résultat réel.
|
||||
|
||||
Ne jamais produire un history `PASS` avant réception des preuves opérateur correspondantes.
|
||||
|
||||
Lorsqu'un FAIL provient uniquement d'une gate ou d'un défaut de validation, conserver le contenu livré, historiser le FAIL et produire un fix limité au défaut réel.
|
||||
|
||||
## Condition de fin de session
|
||||
|
||||
Une session de version se termine uniquement selon le workflow PGR applicable : tranche de release, history observé, commit stable, tag stable et rapport post-tag lorsque la release l'exige.
|
||||
|
||||
Préparer avant la clôture le prompt de démarrage de la version suivante et le texte introductif correspondant.
|
||||
Reference in New Issue
Block a user