0.0.1-alpha.1.fix.1
This commit is contained in:
53
.gitignore
vendored
53
.gitignore
vendored
@@ -1,29 +1,54 @@
|
|||||||
# IDE and local editor state
|
# file: .gitignore
|
||||||
|
# version: 2
|
||||||
|
|
||||||
|
# Logs
|
||||||
|
/logs/
|
||||||
|
*.log
|
||||||
|
|
||||||
|
# Editor and IDE files
|
||||||
|
.vscode/
|
||||||
|
.idea/
|
||||||
|
.settings/*
|
||||||
|
!.settings/org.eclipse.core.resources.prefs
|
||||||
.project
|
.project
|
||||||
.classpath
|
.classpath
|
||||||
.settings/
|
.factorypath
|
||||||
.idea/
|
.pydevproject
|
||||||
.vscode/
|
*.suo
|
||||||
|
*.ntvs*
|
||||||
|
*.njsproj
|
||||||
|
*.sln
|
||||||
|
*.swp
|
||||||
|
*.swo
|
||||||
|
*~
|
||||||
|
|
||||||
# Local environment and secrets
|
# Operating system files
|
||||||
|
.DS_Store
|
||||||
|
Thumbs.db
|
||||||
|
|
||||||
|
# Environment and local secrets
|
||||||
.env
|
.env
|
||||||
.env.*
|
.env.*
|
||||||
!.env.example
|
!.env.example
|
||||||
|
|
||||||
|
# Python helper artifacts
|
||||||
|
__pycache__/
|
||||||
|
*.py[cod]
|
||||||
|
.pytest_cache/
|
||||||
|
.mypy_cache/
|
||||||
|
.ruff_cache/
|
||||||
|
|
||||||
# Rust/Cargo outputs
|
# Rust/Cargo outputs
|
||||||
/target/
|
/target/
|
||||||
|
|
||||||
# JavaScript/frontend dependencies and transient outputs
|
# JavaScript/frontend dependencies and transient outputs
|
||||||
/node_modules/
|
node_modules/
|
||||||
/frontend/node_modules/
|
.vite/
|
||||||
/frontend/.vite/
|
dist/
|
||||||
/frontend/dist/
|
|
||||||
|
|
||||||
# Project build outputs kept outside source when configured
|
# Project build outputs kept outside source when configured
|
||||||
/builds/
|
/builds/
|
||||||
|
|
||||||
# OS/transient files
|
# Local/runtime scratch data
|
||||||
.DS_Store
|
/var/
|
||||||
Thumbs.db
|
/tmp/
|
||||||
*.swp
|
|
||||||
*~
|
|
||||||
|
|||||||
2
.settings/org.eclipse.core.resources.prefs
Normal file
2
.settings/org.eclipse.core.resources.prefs
Normal file
@@ -0,0 +1,2 @@
|
|||||||
|
eclipse.preferences.version=1
|
||||||
|
encoding/<project>=UTF-8
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: CHANGELOG.md -->
|
<!-- file: CHANGELOG.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Changelog SaseDev Knowledge
|
# Changelog SaseDev Knowledge
|
||||||
|
|
||||||
@@ -8,6 +8,9 @@ Ce fichier décrit les changements utiles des releases publiées. Les détails d
|
|||||||
## 0.0.1 (candidate)
|
## 0.0.1 (candidate)
|
||||||
|
|
||||||
- établit la gouvernance locale Knowledge à partir de PGR `v0.1.1` vérifiée ;
|
- établit la gouvernance locale Knowledge à partir de PGR `v0.1.1` vérifiée ;
|
||||||
- cadre la séparation Git / forge optionnelle / PostgreSQL ;
|
- cadre trois applications Actix Web distinctes pour PGR, HOWTOs et snippets dans un workspace commun ;
|
||||||
|
- cadre au moins trois sources Git de contenu indépendantes et une forge optionnelle ;
|
||||||
|
- retient PostgreSQL partagé pour l'état transversal sans remplacer Git comme vérité éditoriale ;
|
||||||
- fixe les frontières PGR / HOWTO / snippet / project-local ;
|
- fixe les frontières PGR / HOWTO / snippet / project-local ;
|
||||||
|
- adopte la préférence Eclipse UTF-8 versionnée prévue par PGR ;
|
||||||
- prépare un workspace Rust et une baseline Web composables sans construire prématurément la plateforme complète.
|
- prépare un workspace Rust et une baseline Web composables sans construire prématurément la plateforme complète.
|
||||||
|
|||||||
27
README.md
27
README.md
@@ -1,11 +1,11 @@
|
|||||||
<!-- file: README.md -->
|
<!-- file: README.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# SaseDev Knowledge
|
# SaseDev Knowledge
|
||||||
|
|
||||||
SaseDev Knowledge est la plateforme applicative destinée à publier et administrer plusieurs familles de connaissance SaseDev sans transformer PGR en encyclopédie technique.
|
SaseDev Knowledge est le workspace applicatif destiné à publier et administrer plusieurs familles de connaissance SaseDev sans transformer PGR en encyclopédie technique.
|
||||||
|
|
||||||
Le dépôt applicatif retenu est `sasedev-knowledge`. Le nom court du produit et le préfixe de crates sont `knowledge`.
|
Le dépôt applicatif retenu est `sasedev-knowledge`. Le nom court du projet et le préfixe de crates sont `knowledge`.
|
||||||
|
|
||||||
## Statut
|
## Statut
|
||||||
|
|
||||||
@@ -13,11 +13,28 @@ La version courante est définie par [`VERSION`](VERSION).
|
|||||||
|
|
||||||
`0.0.1` est une release de fondation. Elle établit la gouvernance, les frontières d'architecture, le workspace minimal, les premiers contrats et les validations nécessaires avant toute implémentation fonctionnelle importante.
|
`0.0.1` est une release de fondation. Elle établit la gouvernance, les frontières d'architecture, le workspace minimal, les premiers contrats et les validations nécessaires avant toute implémentation fonctionnelle importante.
|
||||||
|
|
||||||
|
## Topologie produit de fondation
|
||||||
|
|
||||||
|
Le workspace héberge trois applications Web Actix distinctes, correspondant aux trois façades publiques prévues :
|
||||||
|
|
||||||
|
```text
|
||||||
|
knowledge-pgr-server -> pgr.sasedev.com
|
||||||
|
knowledge-howtos-server -> howtos.sasedev.com
|
||||||
|
knowledge-snippets-server -> snippets.sasedev.com
|
||||||
|
```
|
||||||
|
|
||||||
|
Ces trois launchers restent minces et réutilisent les mêmes crates communes lorsqu'une responsabilité est réellement partagée. Leur séparation de processus ne transforme pas le domaine en microservices et n'autorise pas la duplication de logique métier.
|
||||||
|
|
||||||
|
Chaque famille possède au minimum sa propre source Git autoritaire : dépôt `pgr`, dépôt `howtos` et dépôt `snippets`. La configuration doit permettre d'ajouter d'autres sources sans figer le système à exactement trois repositories.
|
||||||
|
|
||||||
|
PostgreSQL est mutualisable et constitue la baseline retenue pour l'état transversal de la plateforme : comptes, sessions, propositions, synchronisation, index et relations entre familles. Il ne remplace jamais les sources Git comme vérité du contenu publié.
|
||||||
|
|
||||||
## Invariants de fondation
|
## Invariants de fondation
|
||||||
|
|
||||||
- Git est la source autoritaire du contenu versionné.
|
- Git est la source autoritaire du contenu versionné.
|
||||||
- Une forge est une intégration optionnelle et ne constitue pas une dépendance du domaine.
|
- Une forge est une intégration optionnelle et ne constitue pas une dépendance du domaine.
|
||||||
- PostgreSQL conserve l'état applicatif ; il ne remplace pas Git comme vérité du contenu publié.
|
- Les trois applications publiques sont déployables séparément mais composent des bibliothèques communes.
|
||||||
|
- PostgreSQL conserve l'état applicatif partagé et les projections ; il ne remplace pas Git comme vérité du contenu publié.
|
||||||
- La lecture publique doit pouvoir fonctionner depuis des copies Git locales et un index/cache applicatif sans appel à une forge pour chaque requête.
|
- La lecture publique doit pouvoir fonctionner depuis des copies Git locales et un index/cache applicatif sans appel à une forge pour chaque requête.
|
||||||
- PGR, HOWTOs, snippets et décisions `project-local` conservent des forces et responsabilités documentaires distinctes.
|
- PGR, HOWTOs, snippets et décisions `project-local` conservent des forces et responsabilités documentaires distinctes.
|
||||||
- Une proposition externe ne publie jamais directement du contenu et conserve la révision Git de base utilisée pour sa création.
|
- Une proposition externe ne publie jamais directement du contenu et conserve la révision Git de base utilisée pour sa création.
|
||||||
@@ -30,7 +47,7 @@ La version courante est définie par [`VERSION`](VERSION).
|
|||||||
- [`docs/000-README.md`](docs/000-README.md) — index documentaire ;
|
- [`docs/000-README.md`](docs/000-README.md) — index documentaire ;
|
||||||
- [`docs/objectives/001-PROJECT_OBJECTIVES.md`](docs/objectives/001-PROJECT_OBJECTIVES.md) — objectifs et non-objectifs ;
|
- [`docs/objectives/001-PROJECT_OBJECTIVES.md`](docs/objectives/001-PROJECT_OBJECTIVES.md) — objectifs et non-objectifs ;
|
||||||
- [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md) — baseline PGR, profils/skeletons et matrice de décisions ;
|
- [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md) — baseline PGR, profils/skeletons et matrice de décisions ;
|
||||||
- [`docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md`](docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md) — architecture de fondation Git/forge/PostgreSQL et frontières de contenu ;
|
- [`docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md`](docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md) — architecture de fondation multi-app Git/forge/PostgreSQL et frontières de contenu ;
|
||||||
- [`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md`](docs/plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan vivant de `0.0.1` ;
|
- [`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md`](docs/plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan vivant de `0.0.1` ;
|
||||||
- [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation ;
|
- [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation ;
|
||||||
- [`prompts/001-V0_0_1_START_PROMPT.md`](prompts/001-V0_0_1_START_PROMPT.md) — prompt de démarrage autoritaire de la release.
|
- [`prompts/001-V0_0_1_START_PROMPT.md`](prompts/001-V0_0_1_START_PROMPT.md) — prompt de démarrage autoritaire de la release.
|
||||||
|
|||||||
10
ROADMAP.md
10
ROADMAP.md
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: ROADMAP.md -->
|
<!-- file: ROADMAP.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Roadmap SaseDev Knowledge
|
# Roadmap SaseDev Knowledge
|
||||||
|
|
||||||
@@ -9,16 +9,16 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
|
|||||||
|
|
||||||
## Fondation
|
## Fondation
|
||||||
|
|
||||||
- `( ) 0.0.1` — fondation Knowledge : gouvernance PGR, architecture Git/forge/PostgreSQL, frontières PGR/HOWTO/snippet, workspace Rust minimal, premiers contrats et baseline Web reproductible sans implémentation fonctionnelle disproportionnée.
|
- `( ) 0.0.1` — fondation Knowledge : gouvernance PGR, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, workspace Rust minimal, premiers contrats et baseline Web reproductible sans implémentation fonctionnelle disproportionnée.
|
||||||
|
|
||||||
## Domaines futurs non numérotés
|
## Domaines futurs non numérotés
|
||||||
|
|
||||||
Les thèmes suivants sont candidats à des releases ultérieures mais ne reçoivent pas encore de numéro :
|
Les thèmes suivants sont candidats à des releases ultérieures mais ne reçoivent pas encore de numéro :
|
||||||
|
|
||||||
- implémentation Git générique et synchronisation réelle ;
|
- implémentation Git générique et synchronisation réelle multi-source ;
|
||||||
- état PostgreSQL et migrations applicatives ;
|
- état PostgreSQL partagé et migrations applicatives ;
|
||||||
- contribution/revue et administration ;
|
- contribution/revue et administration ;
|
||||||
- publication/rendu multi-familles ;
|
- publication/rendu des trois façades ;
|
||||||
- recherche et indexation avancées ;
|
- recherche et indexation avancées ;
|
||||||
- adapter Gitea puis autres forges selon besoin réel ;
|
- adapter Gitea puis autres forges selon besoin réel ;
|
||||||
- authentification/autorisation complète ;
|
- authentification/autorisation complète ;
|
||||||
|
|||||||
44
RULES.md
44
RULES.md
@@ -1,11 +1,11 @@
|
|||||||
<!-- file: RULES.md -->
|
<!-- file: RULES.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Règles SaseDev Knowledge
|
# Règles SaseDev Knowledge
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
Ce document gouverne le dépôt applicatif `sasedev-knowledge` et sert de point d'entrée normatif local.
|
Ce document gouverne le workspace applicatif `sasedev-knowledge` et sert de point d'entrée normatif local.
|
||||||
|
|
||||||
Le contenu éditorial publié par PGR, HOWTOs et snippets vit dans des dépôts Git distincts et conserve sa propre gouvernance. Les règles de ce dépôt ne transforment pas ces contenus en sous-modules normatifs de l'application.
|
Le contenu éditorial publié par PGR, HOWTOs et snippets vit dans des dépôts Git distincts et conserve sa propre gouvernance. Les règles de ce dépôt ne transforment pas ces contenus en sous-modules normatifs de l'application.
|
||||||
|
|
||||||
@@ -50,9 +50,9 @@ Les profils Java/Maven/Gradle, Android et les autres technologies absentes du pr
|
|||||||
|
|
||||||
Les obligations PGR réellement adoptées priment sur une préférence locale de Knowledge dans le même scope.
|
Les obligations PGR réellement adoptées priment sur une préférence locale de Knowledge dans le même scope.
|
||||||
|
|
||||||
Les choix propres au produit restent locaux lorsqu'aucun owner PGR plus spécifique ne les impose. C'est notamment le cas de l'architecture Git/forge/PostgreSQL, du choix Actix Web/Maud, de Bootstrap et de la topologie des dépôts de contenu.
|
Les choix propres au produit restent locaux lorsqu'aucun owner PGR plus spécifique ne les impose. C'est notamment le cas de l'architecture Git/forge/PostgreSQL, du choix Actix Web/Maud, de Bootstrap, de la topologie à trois applications Web et de la topologie des dépôts de contenu.
|
||||||
|
|
||||||
Aucun `OVERRIDE` PGR n'est établi par `0.0.1-alpha.1`.
|
Aucun `OVERRIDE` PGR n'est établi par `0.0.1-alpha.1.fix.1`.
|
||||||
|
|
||||||
Les décisions différées sont explicites dans [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md). Une valeur différée ne doit pas être remplacée par un choix arbitraire provenant d'un autre projet.
|
Les décisions différées sont explicites dans [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md). Une valeur différée ne doit pas être remplacée par un choix arbitraire provenant d'un autre projet.
|
||||||
|
|
||||||
@@ -72,12 +72,42 @@ Les `FAIL`, `PARTIAL` et `BLOCKED` observés sont conservés. Une correction lim
|
|||||||
|
|
||||||
Aucun history n'est créé avant réception de preuves opérateur réelles.
|
Aucun history n'est créé avant réception de preuves opérateur réelles.
|
||||||
|
|
||||||
|
## Politique Eclipse et fichiers locaux
|
||||||
|
|
||||||
|
Les métadonnées Eclipse propres à une machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
|
||||||
|
|
||||||
|
L'exception versionnée est :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.settings/org.eclipse.core.resources.prefs
|
||||||
|
```
|
||||||
|
|
||||||
|
Elle fixe l'encodage UTF-8 du projet et doit rester traquée par Git. Le `.gitignore` doit donc ignorer `.settings/*` puis réautoriser explicitement ce fichier.
|
||||||
|
|
||||||
|
## Topologie applicative
|
||||||
|
|
||||||
|
Le workspace possède trois applications serveur distinctes :
|
||||||
|
|
||||||
|
```text
|
||||||
|
knowledge-pgr-server
|
||||||
|
knowledge-howtos-server
|
||||||
|
knowledge-snippets-server
|
||||||
|
```
|
||||||
|
|
||||||
|
Chaque package exécutable reste une couche de composition mince conformément au profil Rust/Cargo PGR. La logique partagée appartient aux crates `-lib` appropriées et ne doit pas être dupliquée entre les trois `main.rs`.
|
||||||
|
|
||||||
|
Les trois applications peuvent être déployées, redémarrées et dimensionnées séparément. Cette séparation de launchers ne constitue pas une autorisation à fragmenter arbitrairement le domaine en microservices.
|
||||||
|
|
||||||
|
La topologie d'une éventuelle interface d'administration dédiée reste `DEFER` tant qu'une quatrième unité de déploiement n'est pas justifiée.
|
||||||
|
|
||||||
## Git, forge et contenu
|
## Git, forge et contenu
|
||||||
|
|
||||||
Git est la source autoritaire du contenu versionné publié.
|
Git est la source autoritaire du contenu versionné publié.
|
||||||
|
|
||||||
Le domaine MUST pouvoir fonctionner avec un dépôt Git local ou un remote Git générique sans API de forge.
|
Le domaine MUST pouvoir fonctionner avec un dépôt Git local ou un remote Git générique sans API de forge.
|
||||||
|
|
||||||
|
La baseline prévoit au minimum trois sources de contenu indépendantes : `pgr`, `howtos` et `snippets`. Une famille MAY ultérieurement agréger plusieurs repositories ; le nombre trois n'est donc pas codé comme limite du domaine.
|
||||||
|
|
||||||
Les capacités spécifiques d'une forge — webhooks, pull/merge requests, issues, releases, permissions et métadonnées similaires — MUST rester derrière des adapters optionnels.
|
Les capacités spécifiques d'une forge — webhooks, pull/merge requests, issues, releases, permissions et métadonnées similaires — MUST rester derrière des adapters optionnels.
|
||||||
|
|
||||||
Une proposition externe MUST conserver la révision Git de base et MUST NOT écrire directement dans le contenu publié.
|
Une proposition externe MUST conserver la révision Git de base et MUST NOT écrire directement dans le contenu publié.
|
||||||
@@ -88,6 +118,8 @@ La synchronisation générique MUST disposer d'une voie indépendante des webhoo
|
|||||||
|
|
||||||
PostgreSQL est destiné à l'état applicatif : comptes, sessions, propositions, revues, audit applicatif, index, recherche, synchronisation et jobs.
|
PostgreSQL est destiné à l'état applicatif : comptes, sessions, propositions, revues, audit applicatif, index, recherche, synchronisation et jobs.
|
||||||
|
|
||||||
|
La baseline de fondation retient une base PostgreSQL logique partagée par les trois applications afin de conserver un état transversal cohérent et de permettre les relations entre PGR, HOWTOs et snippets. Une séparation physique ultérieure reste possible seulement si une contrainte observée la justifie.
|
||||||
|
|
||||||
Le texte et les métadonnées éditoriales qui constituent le contenu publié restent autoritaires dans Git. Une copie ou projection PostgreSQL de ces données est dérivée et reconstructible.
|
Le texte et les métadonnées éditoriales qui constituent le contenu publié restent autoritaires dans Git. Une copie ou projection PostgreSQL de ces données est dérivée et reconstructible.
|
||||||
|
|
||||||
Le choix du driver, de l'ORM ou de la stratégie de migration reste différé jusqu'à une tranche qui en a réellement besoin.
|
Le choix du driver, de l'ORM ou de la stratégie de migration reste différé jusqu'à une tranche qui en a réellement besoin.
|
||||||
@@ -112,12 +144,12 @@ Un HOWTO ou snippet MAY référencer une règle/owner PGR. Une règle PGR MAY r
|
|||||||
Sous réserve des décisions différées et de la matérialisation par tranche, Knowledge retient comme intentions locales :
|
Sous réserve des décisions différées et de la matérialisation par tranche, Knowledge retient comme intentions locales :
|
||||||
|
|
||||||
- Rust stable, édition 2024 et workspace Cargo ;
|
- Rust stable, édition 2024 et workspace Cargo ;
|
||||||
- Actix Web pour HTTP ;
|
- trois launchers Actix Web distincts pour PGR, HOWTOs et snippets ;
|
||||||
- Maud pour le SSR lorsque pertinent ;
|
- Maud pour le SSR lorsque pertinent ;
|
||||||
- Vite + TypeScript pour les assets et interactions frontend ;
|
- Vite + TypeScript pour les assets et interactions frontend ;
|
||||||
- Sass ;
|
- Sass ;
|
||||||
- Bootstrap ;
|
- Bootstrap ;
|
||||||
- PostgreSQL.
|
- PostgreSQL partagé pour l'état applicatif transversal.
|
||||||
|
|
||||||
Ces choix ne sont pas présentés comme des règles PGR universelles.
|
Ces choix ne sont pas présentés comme des règles PGR universelles.
|
||||||
|
|
||||||
|
|||||||
237
deltas/0.0.1/alpha.1.fix.1.md
Normal file
237
deltas/0.0.1/alpha.1.fix.1.md
Normal file
@@ -0,0 +1,237 @@
|
|||||||
|
<!-- file: deltas/0.0.1/alpha.1.fix.1.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# Delta 0.0.1-alpha.1.fix.1 — conformité Eclipse et topologie multi-app
|
||||||
|
|
||||||
|
## Base requise
|
||||||
|
|
||||||
|
État `0.0.1-alpha.1` committé avec :
|
||||||
|
|
||||||
|
```text
|
||||||
|
deltas/0.0.1/alpha.1.md
|
||||||
|
history/0.0.1/alpha.1.md = FAIL
|
||||||
|
```
|
||||||
|
|
||||||
|
Le delta `alpha.1` historique ne doit pas être modifié.
|
||||||
|
|
||||||
|
La version devient :
|
||||||
|
|
||||||
|
```text
|
||||||
|
0.0.1-alpha.1.fix.1
|
||||||
|
```
|
||||||
|
|
||||||
|
## Objet
|
||||||
|
|
||||||
|
Corriger uniquement les défauts observés pendant la gate `alpha.1` et le cadrage associé :
|
||||||
|
|
||||||
|
- adopter la politique Eclipse PGR réellement applicable ;
|
||||||
|
- versionner `.settings/org.eclipse.core.resources.prefs` ;
|
||||||
|
- ajouter le header `file/version` au `.gitignore` ;
|
||||||
|
- rendre la gate de fichiers consciente des règles Git ignore au lieu d'interdire les fichiers locaux ignorés ;
|
||||||
|
- remplacer la baseline « application Web unique/monolithe » par un workspace modulaire à trois applications Actix Web distinctes ;
|
||||||
|
- expliciter au moins trois sources Git initiales et PostgreSQL partagé pour l'état transversal.
|
||||||
|
|
||||||
|
Aucun code fonctionnel, manifest Cargo, frontend, migration SQL ou adapter forge n'est ajouté.
|
||||||
|
|
||||||
|
## Fichiers ajoutés
|
||||||
|
|
||||||
|
```text
|
||||||
|
.settings/org.eclipse.core.resources.prefs
|
||||||
|
deltas/0.0.1/alpha.1.fix.1.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## Fichiers remplacés
|
||||||
|
|
||||||
|
```text
|
||||||
|
.gitignore
|
||||||
|
VERSION
|
||||||
|
README.md
|
||||||
|
RULES.md
|
||||||
|
ROADMAP.md
|
||||||
|
CHANGELOG.md
|
||||||
|
docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||||
|
docs/architecture/001-PROJECT_PROFILE.md
|
||||||
|
docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
|
||||||
|
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||||
|
docs/validation/001-VALIDATION_MATRIX.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Aucun fichier n'est supprimé.
|
||||||
|
|
||||||
|
## Décisions corrigées
|
||||||
|
|
||||||
|
### Eclipse
|
||||||
|
|
||||||
|
La politique locale devient conforme à la baseline PGR :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.project ignoré
|
||||||
|
.classpath ignoré
|
||||||
|
.settings/* ignoré
|
||||||
|
.settings/org.eclipse.core.resources.prefs versionné
|
||||||
|
```
|
||||||
|
|
||||||
|
La préférence versionnée contient :
|
||||||
|
|
||||||
|
```text
|
||||||
|
eclipse.preferences.version=1
|
||||||
|
encoding/<project>=UTF-8
|
||||||
|
```
|
||||||
|
|
||||||
|
### Topologie applicative
|
||||||
|
|
||||||
|
Le workspace possède trois launchers distincts :
|
||||||
|
|
||||||
|
```text
|
||||||
|
knowledge-pgr-server -> pgr.sasedev.com
|
||||||
|
knowledge-howtos-server -> howtos.sasedev.com
|
||||||
|
knowledge-snippets-server -> snippets.sasedev.com
|
||||||
|
```
|
||||||
|
|
||||||
|
Ils partagent des crates `-lib` lorsque l'ownership est commun ; ils ne deviennent pas trois copies du même domaine.
|
||||||
|
|
||||||
|
### Sources Git
|
||||||
|
|
||||||
|
La baseline contient au minimum trois sources :
|
||||||
|
|
||||||
|
```text
|
||||||
|
pgr
|
||||||
|
howtos
|
||||||
|
snippets
|
||||||
|
```
|
||||||
|
|
||||||
|
Le modèle futur doit permettre plusieurs sources par famille et ne doit pas coder une limite fixe à trois repositories.
|
||||||
|
|
||||||
|
### PostgreSQL
|
||||||
|
|
||||||
|
La baseline retient une base PostgreSQL logique partagée entre les trois applications pour l'état transversal et les projections reconstructibles.
|
||||||
|
|
||||||
|
Le contenu éditorial publié reste autoritaire dans Git.
|
||||||
|
|
||||||
|
## Validation attendue
|
||||||
|
|
||||||
|
Après application du history `alpha.1`, commit/push de `alpha.1`, puis extraction du présent delta depuis la racine du dépôt :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
test "$(cat VERSION)" = "0.0.1-alpha.1.fix.1"
|
||||||
|
|
||||||
|
git diff --check
|
||||||
|
|
||||||
|
grep -Fx '# file: .gitignore' .gitignore
|
||||||
|
grep -Fx '# version: 2' .gitignore
|
||||||
|
grep -Fx '.settings/*' .gitignore
|
||||||
|
grep -Fx '!.settings/org.eclipse.core.resources.prefs' .gitignore
|
||||||
|
|
||||||
|
grep -Fx 'eclipse.preferences.version=1' .settings/org.eclipse.core.resources.prefs
|
||||||
|
grep -Fx 'encoding/<project>=UTF-8' .settings/org.eclipse.core.resources.prefs
|
||||||
|
|
||||||
|
git check-ignore -q .project
|
||||||
|
if git check-ignore -q .settings/org.eclipse.core.resources.prefs; then
|
||||||
|
echo '.settings/org.eclipse.core.resources.prefs must be tracked, not ignored' >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
python3 - <<'PY'
|
||||||
|
from pathlib import Path
|
||||||
|
import re
|
||||||
|
import subprocess
|
||||||
|
|
||||||
|
expected = {
|
||||||
|
".gitignore",
|
||||||
|
".settings/org.eclipse.core.resources.prefs",
|
||||||
|
"VERSION",
|
||||||
|
"README.md",
|
||||||
|
"RULES.md",
|
||||||
|
"ROADMAP.md",
|
||||||
|
"CHANGELOG.md",
|
||||||
|
"docs/000-README.md",
|
||||||
|
"docs/objectives/001-PROJECT_OBJECTIVES.md",
|
||||||
|
"docs/architecture/001-PROJECT_PROFILE.md",
|
||||||
|
"docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md",
|
||||||
|
"docs/plans/001-V0_0_1_FOUNDATION_PLAN.md",
|
||||||
|
"docs/validation/001-VALIDATION_MATRIX.md",
|
||||||
|
"deltas/0.0.1/alpha.1.md",
|
||||||
|
"deltas/0.0.1/alpha.1.fix.1.md",
|
||||||
|
"history/0.0.1/alpha.1.md",
|
||||||
|
"prompts/001-V0_0_1_START_PROMPT.md",
|
||||||
|
}
|
||||||
|
|
||||||
|
actual = set(
|
||||||
|
subprocess.check_output(
|
||||||
|
["git", "ls-files", "--cached", "--others", "--exclude-standard"],
|
||||||
|
text=True,
|
||||||
|
).splitlines()
|
||||||
|
)
|
||||||
|
assert actual == expected, (sorted(actual - expected), sorted(expected - actual))
|
||||||
|
|
||||||
|
for path_string in sorted(expected):
|
||||||
|
path = Path(path_string)
|
||||||
|
if path.suffix != ".md":
|
||||||
|
continue
|
||||||
|
lines = path.read_text(encoding="utf-8").splitlines()
|
||||||
|
assert lines[0] == f"<!-- file: {path.as_posix()} -->", path
|
||||||
|
assert re.fullmatch(r"<!-- version: [1-9][0-9]* -->", lines[1]), path
|
||||||
|
|
||||||
|
rules = Path("RULES.md").read_text(encoding="utf-8")
|
||||||
|
objectives = Path("docs/objectives/001-PROJECT_OBJECTIVES.md").read_text(encoding="utf-8")
|
||||||
|
profile = Path("docs/architecture/001-PROJECT_PROFILE.md").read_text(encoding="utf-8")
|
||||||
|
architecture = Path("docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md").read_text(encoding="utf-8")
|
||||||
|
plan = Path("docs/plans/001-V0_0_1_FOUNDATION_PLAN.md").read_text(encoding="utf-8")
|
||||||
|
|
||||||
|
for phrase in (
|
||||||
|
"knowledge-pgr-server",
|
||||||
|
"knowledge-howtos-server",
|
||||||
|
"knowledge-snippets-server",
|
||||||
|
):
|
||||||
|
assert phrase in rules, phrase
|
||||||
|
assert phrase in objectives, phrase
|
||||||
|
assert phrase in architecture, phrase
|
||||||
|
|
||||||
|
for phrase in (
|
||||||
|
"une base PostgreSQL logique partagée",
|
||||||
|
"au moins trois sources",
|
||||||
|
):
|
||||||
|
assert phrase in architecture, phrase
|
||||||
|
|
||||||
|
assert "Topologie d'administration" in profile
|
||||||
|
assert "### alpha.2 — workspace Rust/Cargo minimal" in plan
|
||||||
|
assert "### rel.1 — fermeture stable" in plan
|
||||||
|
|
||||||
|
for forbidden in (
|
||||||
|
"src/main.rs",
|
||||||
|
"src/lib.rs",
|
||||||
|
"Cargo.toml",
|
||||||
|
"package.json",
|
||||||
|
"vite.config.ts",
|
||||||
|
"migrations/",
|
||||||
|
):
|
||||||
|
assert not Path(forbidden).exists(), forbidden
|
||||||
|
|
||||||
|
print("Knowledge 0.0.1-alpha.1.fix.1 framing audit: clean")
|
||||||
|
PY
|
||||||
|
|
||||||
|
git add -A
|
||||||
|
git diff --cached --check
|
||||||
|
git status --short
|
||||||
|
```
|
||||||
|
|
||||||
|
## Revue opérateur complémentaire
|
||||||
|
|
||||||
|
Vérifier notamment :
|
||||||
|
|
||||||
|
- que `.project` reste local/ignoré et n'apparaît pas dans le staging ;
|
||||||
|
- que `.settings/org.eclipse.core.resources.prefs` apparaît bien comme ajouté/suivi ;
|
||||||
|
- qu'aucun code fonctionnel n'a été introduit ;
|
||||||
|
- que trois applications distinctes sont bien la topologie produit voulue ;
|
||||||
|
- que le partage PostgreSQL concerne l'état de plateforme et non le contenu Git autoritaire ;
|
||||||
|
- que la topologie d'administration reste ouverte et qu'aucun quatrième serveur n'est inventé.
|
||||||
|
|
||||||
|
## Transition
|
||||||
|
|
||||||
|
### PASS
|
||||||
|
|
||||||
|
Produire `history/0.0.1/alpha.1.fix.1.md`, appliquer ce history, committer/pousser la tranche, puis seulement préparer `0.0.1-alpha.2`.
|
||||||
|
|
||||||
|
### FAIL / PARTIAL / BLOCKED
|
||||||
|
|
||||||
|
Conserver le résultat réel dans `history/0.0.1/alpha.1.fix.1.md` et rester dans le scope `alpha.1` avec un éventuel `alpha.1.fix.2`.
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
|
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Profil du projet Knowledge
|
# Profil du projet Knowledge
|
||||||
|
|
||||||
@@ -54,50 +54,62 @@ Les profils Java/Maven/Gradle, Android et autres technologies absentes ne sont p
|
|||||||
|
|
||||||
## Matrice des décisions importantes
|
## Matrice des décisions importantes
|
||||||
|
|
||||||
| Décision | Classification | Contrat retenu / condition de reprise |
|
| Décision | Classification | Contrat retenu / condition de reprise |
|
||||||
|--------------------------------------|-----------------------------------|-------------------------------------------------------------------------------------------------------|
|
|--------------------------------------|-----------------------------------|----------------------------------------------------------------------------------------------------------------|
|
||||||
| Dépôt applicatif | `KEEP-LOCAL` | `sasedev-knowledge` ; explicite le produit et évite un nom générique `knowledge` au niveau forge |
|
| Dépôt applicatif | `KEEP-LOCAL` | `sasedev-knowledge` ; workspace unique de la plateforme |
|
||||||
| Nom court / préfixe crates | `KEEP-LOCAL` | `knowledge` / `knowledge-` |
|
| Nom court / préfixe crates | `KEEP-LOCAL` | `knowledge` / `knowledge-` |
|
||||||
| Dépôt normatif | `KEEP-LOCAL` | dépôt existant `pgr`, jamais fusionné dans le dépôt applicatif |
|
| Dépôt normatif | `KEEP-LOCAL` | dépôt existant `pgr`, jamais fusionné dans le dépôt applicatif |
|
||||||
| Dépôt HOWTO | `KEEP-LOCAL` | dépôt séparé `howtos` |
|
| Dépôt HOWTO | `KEEP-LOCAL` | dépôt séparé `howtos` |
|
||||||
| Dépôt snippets | `KEEP-LOCAL` | dépôt séparé `snippets` |
|
| Dépôt snippets | `KEEP-LOCAL` | dépôt séparé `snippets` |
|
||||||
| Git comme backend du contenu | `KEEP-LOCAL` | invariant d'architecture Knowledge |
|
| Nombre de sources Git | `KEEP-LOCAL` | au moins trois sources initiales, sans limite codée à trois |
|
||||||
| Forge | `KEEP-LOCAL` | capacité optionnelle derrière adapter ; aucune API de forge dans le domaine |
|
| Git comme backend du contenu | `KEEP-LOCAL` | invariant d'architecture Knowledge |
|
||||||
| Gitea | `DEFER` | premier adapter candidat ; reprendre lorsque des capacités forge-only sont implémentées |
|
| Forge | `KEEP-LOCAL` | capacité optionnelle derrière adapter ; aucune API de forge dans le domaine |
|
||||||
| Synchronisation sans webhook | `KEEP-LOCAL` | explicite/polling constituent le socle ; hooks/webhooks sont des accélérateurs |
|
| Gitea | `DEFER` | premier adapter candidat ; reprendre lorsque des capacités forge-only sont implémentées |
|
||||||
| PostgreSQL | `KEEP-LOCAL` | état applicatif et projections ; jamais vérité du contenu Git publié |
|
| Synchronisation sans webhook | `KEEP-LOCAL` | explicite/polling constituent le socle ; hooks/webhooks sont des accélérateurs |
|
||||||
| Rust stable / édition 2024 | `ADOPT` | profil Rust/Cargo PGR |
|
| PostgreSQL | `KEEP-LOCAL` | une base logique partagée pour l'état transversal et les projections ; jamais vérité du contenu Git publié |
|
||||||
| Workspace Cargo | `ADOPT` | skeleton Rust/Cargo ; matérialisation `alpha.2` |
|
| Rust stable / édition 2024 | `ADOPT` | profil Rust/Cargo PGR |
|
||||||
| `Cargo.lock` | `DEFER` | décider lors de la matérialisation selon le rôle application/workspace et `510` |
|
| Workspace Cargo | `ADOPT` | skeleton Rust/Cargo ; matérialisation `alpha.2` |
|
||||||
| Actix Web | `KEEP-LOCAL` | framework HTTP initial ; PGR ne possède pas de profil Actix dédié |
|
| `Cargo.lock` | `DEFER` | décider lors de la matérialisation selon le rôle application/workspace et `510` |
|
||||||
| Maud | `KEEP-LOCAL` | rendu SSR initial lorsque pertinent |
|
| Actix Web | `KEEP-LOCAL` | trois launchers serveur distincts ; PGR ne possède pas de profil Actix dédié |
|
||||||
| TypeScript | `ADOPT` | conforme au owner `530` et à l'intention locale |
|
| Maud | `KEEP-LOCAL` | rendu SSR initial lorsque pertinent |
|
||||||
| Package manager frontend | `DEFER` | choisir dans la tranche Web avant création du manifest/lockfile |
|
| TypeScript | `ADOPT` | conforme au owner `530` et à l'intention locale |
|
||||||
| Vite | `KEEP-LOCAL` + owner `550` adopté | choix local cohérent avec la recommandation PGR ; configuration à décider dans la tranche Web |
|
| Package manager frontend | `DEFER` | choisir dans la tranche Web avant création du manifest/lockfile |
|
||||||
| Sass | `KEEP-LOCAL` + owner `560` adopté | choix local ; compilation intégrée à la chaîne Web si elle apporte la valeur attendue |
|
| Vite | `KEEP-LOCAL` + owner `550` adopté | choix local cohérent avec la recommandation PGR ; configuration à décider dans la tranche Web |
|
||||||
| Bootstrap | `KEEP-LOCAL` | framework CSS local, jamais règle PGR/Tauri/Web universelle |
|
| Sass | `KEEP-LOCAL` + owner `560` adopté | choix local ; compilation intégrée à la chaîne Web si elle apporte la valeur attendue |
|
||||||
| Racine frontend | `DEFER` | décider dans la tranche Web ; `frontend/` reste candidat mais non figé par PGR |
|
| Bootstrap | `KEEP-LOCAL` | framework CSS local, jamais règle PGR/Tauri/Web universelle |
|
||||||
| Driver/ORM PostgreSQL | `DEFER` | reprendre à la première implémentation persistante réelle |
|
| Racine(s) frontend | `DEFER` | décider dans la tranche Web selon le partage réel entre les trois applications |
|
||||||
| Migrations PostgreSQL | `DEFER` | reprendre avec le choix de driver/tooling et le premier schéma réel |
|
| Driver/ORM PostgreSQL | `DEFER` | reprendre à la première implémentation persistante réelle |
|
||||||
| Moteur de recherche | `DEFER` | commencer par capacités PostgreSQL/index applicatif ; réévaluer sur besoin mesuré |
|
| Migrations PostgreSQL | `DEFER` | reprendre avec le choix de driver/tooling et le premier schéma réel |
|
||||||
| Fournisseur d'auth externe | `DEFER` | reprendre lorsque le workflow utilisateur l'exige |
|
| Moteur de recherche | `DEFER` | commencer par capacités PostgreSQL/index applicatif ; réévaluer sur besoin mesuré |
|
||||||
| Topologie de déploiement | `DEFER` | monolithe modulaire par défaut ; séparer seulement sur contrainte observée |
|
| Fournisseur d'auth externe | `DEFER` | reprendre lorsque le workflow utilisateur l'exige |
|
||||||
| Formats finaux HOWTO/snippet | `DEFER` | définir avec corpus réel ; ne pas figer un schéma sans contenu représentatif |
|
| Topologie d'administration | `DEFER` | pas de quatrième application tant qu'un launcher d'administration séparé n'est pas justifié |
|
||||||
| Noms définitifs de toutes les crates | `DEFER` | seules les responsabilités et le préfixe sont cadrés ; créer une crate uniquement avec ownership réel |
|
| Formats finaux HOWTO/snippet | `DEFER` | définir avec corpus réel ; ne pas figer un schéma sans contenu représentatif |
|
||||||
|
| Noms définitifs de toutes les crates | `DEFER` | seules les responsabilités et les trois launchers sont cadrés ; créer une crate uniquement avec ownership réel |
|
||||||
|
|
||||||
Aucun `OVERRIDE` n'est requis à ce stade.
|
Aucun `OVERRIDE` n'est requis à ce stade.
|
||||||
|
|
||||||
## Nomenclature de crates candidate
|
## Nomenclature de crates candidate
|
||||||
|
|
||||||
Le projet n'instancie pas toutes les crates suivantes en `alpha.1`. Elles décrivent des boundaries candidats et ne deviennent des packages que lorsque leur responsabilité est matérialisée :
|
Les trois packages exécutables sont des boundaries produit retenus :
|
||||||
|
|
||||||
|
```text
|
||||||
|
knowledge-pgr-server launcher Actix Web de la façade PGR
|
||||||
|
knowledge-howtos-server launcher Actix Web de la façade HOWTOs
|
||||||
|
knowledge-snippets-server launcher Actix Web de la façade snippets
|
||||||
|
```
|
||||||
|
|
||||||
|
Ils ne sont pas encore matérialisés en `alpha.1.fix.1`. Lorsqu'ils le seront, leurs `main.rs` resteront minces et composeront les bibliothèques réutilisables.
|
||||||
|
|
||||||
|
Les responsabilités de bibliothèques suivantes restent candidates et ne deviennent des packages que lorsqu'elles possèdent un ownership réel :
|
||||||
|
|
||||||
```text
|
```text
|
||||||
knowledge-domain-lib contrats et types métier stables
|
knowledge-domain-lib contrats et types métier stables
|
||||||
knowledge-app-lib orchestration des use cases, si une séparation dédiée devient utile
|
knowledge-app-lib orchestration des use cases transversaux, si la séparation apporte une valeur réelle
|
||||||
knowledge-git-lib implémentation Git générique
|
knowledge-git-lib implémentation Git générique
|
||||||
knowledge-store-postgres-lib état applicatif PostgreSQL
|
knowledge-store-postgres-lib état applicatif PostgreSQL partagé
|
||||||
knowledge-forge-gitea-lib adapter Gitea optionnel
|
knowledge-forge-gitea-lib adapter Gitea optionnel
|
||||||
knowledge-server composition HTTP/SSR et point d'entrée exécutable
|
knowledge-web-lib composition Web réellement partagée, seulement si les trois serveurs dupliqueraient sinon du code
|
||||||
|
knowledge-logging-lib diagnostics partagés, seulement lorsque plusieurs runtimes en ont effectivement besoin
|
||||||
```
|
```
|
||||||
|
|
||||||
Règles de création :
|
Règles de création :
|
||||||
@@ -105,8 +117,10 @@ Règles de création :
|
|||||||
- ne pas créer une crate uniquement pour refléter un diagramme ;
|
- ne pas créer une crate uniquement pour refléter un diagramme ;
|
||||||
- ne pas utiliser `-api` sans frontière de contrat indépendante réellement nécessaire ;
|
- ne pas utiliser `-api` sans frontière de contrat indépendante réellement nécessaire ;
|
||||||
- garder le domaine indépendant d'Actix, Gitea et PostgreSQL ;
|
- garder le domaine indépendant d'Actix, Gitea et PostgreSQL ;
|
||||||
- garder les adapters dépendants des contrats, jamais l'inverse.
|
- garder les adapters dépendants des contrats, jamais l'inverse ;
|
||||||
|
- ne pas dupliquer dans les trois serveurs une logique qui possède clairement un owner commun ;
|
||||||
|
- ne pas créer un service réseau supplémentaire lorsqu'une crate partagée suffit.
|
||||||
|
|
||||||
## Décisions à rouvrir
|
## Décisions à rouvrir
|
||||||
|
|
||||||
Les `DEFER` sont réexaminés dans la tranche qui consomme réellement la décision. Un changement de scope produit, l'ajout d'un host natif ou une contrainte externe peut déclencher un REPLAN ; il ne justifie pas un choix anticipé dans `alpha.1`.
|
Les `DEFER` sont réexaminés dans la tranche qui consomme réellement la décision. Un changement de scope produit, l'ajout d'un host natif ou une contrainte externe peut déclencher un REPLAN ; il ne justifie pas un choix anticipé dans `alpha.1.fix.1`.
|
||||||
|
|||||||
@@ -1,52 +1,80 @@
|
|||||||
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
|
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Architecture de fondation Knowledge
|
# Architecture de fondation Knowledge
|
||||||
|
|
||||||
## Décision structurante
|
## Décision structurante
|
||||||
|
|
||||||
Knowledge part d'un **monolithe modulaire**. Les frontières décrites ici sont des responsabilités et ports logiques, pas une obligation de créer un service ou une crate par boîte.
|
Knowledge est un **workspace modulaire multi-app**. Il possède trois applications Actix Web déployables séparément pour PGR, HOWTOs et snippets, et des bibliothèques communes pour les responsabilités réellement partagées.
|
||||||
|
|
||||||
Le principe directeur est :
|
Cette décision ne crée pas une architecture de microservices distribués : les trois launchers restent des couches de composition minces, peuvent utiliser le même PostgreSQL et partagent les mêmes contrats de domaine, Git, stockage et synchronisation lorsque leur ownership est commun.
|
||||||
|
|
||||||
|
Le principe directeur reste :
|
||||||
|
|
||||||
> Git est le backend du contenu ; une forge est une capacité optionnelle.
|
> Git est le backend du contenu ; une forge est une capacité optionnelle.
|
||||||
|
|
||||||
## Vue de responsabilités
|
## Vue de responsabilités
|
||||||
|
|
||||||
```text
|
```text
|
||||||
HTTP / SSR / admin
|
pgr.sasedev.com howtos.sasedev.com snippets.sasedev.com
|
||||||
|
|
| | |
|
||||||
v
|
knowledge-pgr-server knowledge-howtos-server knowledge-snippets-server
|
||||||
application use cases
|
\________________________|________________________/
|
||||||
|
|
|
|
||||||
+---------------------> content/domain contracts
|
v
|
||||||
| |
|
application use cases
|
||||||
| +---- parsing / validation
|
|
|
||||||
| +---- proposal / review rules
|
+----------------------+-----------------------+
|
||||||
| +---- publication selection
|
| | |
|
||||||
|
|
v v v
|
||||||
+---- GitRepository ----------> Git local / remote générique
|
content/domain contracts GitRepository RepositoryEventSource
|
||||||
|
|
| | |
|
||||||
+---- GitForge ---------------> Gitea ou autre forge, optionnel
|
| v v
|
||||||
|
|
| Git local/remotes explicit/poll/hook/webhook
|
||||||
+---- RepositoryEventSource --> sync explicite / polling / hook / webhook
|
|
|
||||||
|
|
+---------------------> GitForge (optionnel)
|
||||||
+---- application state ------> PostgreSQL
|
| Gitea/autre forge
|
||||||
|
|
|
|
||||||
+---- local index/cache ------> lecture publique / recherche / rendu
|
+---------------------> PostgreSQL partagé
|
||||||
|
| état/index/relations/jobs
|
||||||
|
|
|
||||||
|
+---------------------> projections/cache locales
|
||||||
|
lecture/recherche/rendu
|
||||||
```
|
```
|
||||||
|
|
||||||
La dépendance pointe vers les contrats métier. Les détails Actix, processus Git, API Gitea ou SQL ne remontent pas dans le domaine.
|
La dépendance pointe vers les contrats métier. Les détails Actix, processus Git, API Gitea ou SQL ne remontent pas dans le domaine.
|
||||||
|
|
||||||
## 1. Application et domaine
|
## 1. Applications publiques
|
||||||
|
|
||||||
Le domaine porte les concepts durables : source de contenu, révision, proposition, validation, publication, type documentaire et références entre contenus.
|
Les trois façades publiques sont des unités de déploiement distinctes :
|
||||||
|
|
||||||
La couche application orchestre les cas d'usage tels que synchroniser un dépôt, indexer une révision, ouvrir/revoir une proposition et publier une révision autorisée.
|
```text
|
||||||
|
knowledge-pgr-server -> famille PGR
|
||||||
|
knowledge-howtos-server -> famille HOWTO
|
||||||
|
knowledge-snippets-server -> famille snippet
|
||||||
|
```
|
||||||
|
|
||||||
|
Chaque serveur :
|
||||||
|
|
||||||
|
- compose les mêmes bibliothèques communes lorsque la responsabilité est réellement partagée ;
|
||||||
|
- possède sa configuration de source(s) Git et de publication ;
|
||||||
|
- peut être déployé et dimensionné indépendamment ;
|
||||||
|
- ne porte pas de logique métier dupliquée dans `main.rs` ;
|
||||||
|
- peut utiliser le même PostgreSQL logique que les deux autres applications.
|
||||||
|
|
||||||
|
La topologie d'administration reste `DEFER`. Une future application d'administration séparée n'est créée que si son boundary de déploiement devient réellement utile.
|
||||||
|
|
||||||
|
## 2. Application et domaine
|
||||||
|
|
||||||
|
Le domaine porte les concepts durables : famille de contenu, source de contenu, révision, proposition, validation, publication, type documentaire et références entre contenus.
|
||||||
|
|
||||||
|
La couche application orchestre les cas d'usage tels que synchroniser une source, indexer une révision, ouvrir/revoir une proposition et publier une révision autorisée.
|
||||||
|
|
||||||
Les modèles HTTP, SQL et payloads Gitea ne sont pas des modèles domaine par défaut.
|
Les modèles HTTP, SQL et payloads Gitea ne sont pas des modèles domaine par défaut.
|
||||||
|
|
||||||
## 2. Git générique
|
Le domaine ne suppose pas qu'une famille possède exactement un repository. Il manipule des identités de source configurables afin de permettre plusieurs repositories PGR/HOWTO/snippet à l'avenir sans refonte du modèle.
|
||||||
|
|
||||||
|
## 3. Git générique
|
||||||
|
|
||||||
Le contrat conceptuel `GitRepository` couvre uniquement les opérations Git nécessaires :
|
Le contrat conceptuel `GitRepository` couvre uniquement les opérations Git nécessaires :
|
||||||
|
|
||||||
@@ -65,7 +93,17 @@ L'implémentation doit fonctionner sans connaître Gitea, GitHub ou GitLab.
|
|||||||
|
|
||||||
Le serveur préfère des mirrors/clones et worktrees locaux. Une requête publique ne doit pas déclencher un appel réseau vers la forge.
|
Le serveur préfère des mirrors/clones et worktrees locaux. Une requête publique ne doit pas déclencher un appel réseau vers la forge.
|
||||||
|
|
||||||
## 3. Forge optionnelle
|
La baseline prévoit au moins trois sources Git indépendantes :
|
||||||
|
|
||||||
|
```text
|
||||||
|
pgr source primaire de knowledge-pgr-server
|
||||||
|
howtos source primaire de knowledge-howtos-server
|
||||||
|
snippets source primaire de knowledge-snippets-server
|
||||||
|
```
|
||||||
|
|
||||||
|
Ce mapping est configurable et extensible ; il ne devient pas un `match` codé en dur sur trois repositories.
|
||||||
|
|
||||||
|
## 4. Forge optionnelle
|
||||||
|
|
||||||
Le contrat conceptuel `GitForge` porte uniquement les capacités qui ne sont pas des opérations Git fondamentales :
|
Le contrat conceptuel `GitForge` porte uniquement les capacités qui ne sont pas des opérations Git fondamentales :
|
||||||
|
|
||||||
@@ -81,7 +119,7 @@ L'absence d'un adapter forge ne doit pas empêcher la synchronisation d'un dép
|
|||||||
|
|
||||||
Gitea est le premier candidat d'intégration mais n'est pas figé comme dépendance du domaine.
|
Gitea est le premier candidat d'intégration mais n'est pas figé comme dépendance du domaine.
|
||||||
|
|
||||||
## 4. Événements et synchronisation
|
## 5. Événements et synchronisation
|
||||||
|
|
||||||
Le contrat conceptuel `RepositoryEventSource` produit un **signal de synchronisation**, pas une vérité de contenu.
|
Le contrat conceptuel `RepositoryEventSource` produit un **signal de synchronisation**, pas une vérité de contenu.
|
||||||
|
|
||||||
@@ -98,25 +136,27 @@ watcher filesystem éventuel
|
|||||||
Toutes convergent vers le même cas d'usage interne :
|
Toutes convergent vers le même cas d'usage interne :
|
||||||
|
|
||||||
```text
|
```text
|
||||||
signal
|
signal(source_id)
|
||||||
-> fetch/refresh si nécessaire
|
-> fetch/refresh si nécessaire
|
||||||
-> résolution de la révision cible Git
|
-> résolution de la révision cible Git
|
||||||
-> comparaison avec la dernière révision indexée
|
-> comparaison avec la dernière révision indexée
|
||||||
-> checkout/worktree de la révision
|
-> checkout/worktree de la révision
|
||||||
-> parsing + validation
|
-> parsing + validation selon la famille
|
||||||
-> construction d'une projection/index
|
-> construction d'une projection/index
|
||||||
-> publication atomique de l'état dérivé
|
-> publication atomique de l'état dérivé
|
||||||
```
|
```
|
||||||
|
|
||||||
Un webhook peut être perdu ou dupliqué. Le commit Git résolu reste l'identité autoritaire de la révision.
|
Un webhook peut être perdu ou dupliqué. Le commit Git résolu reste l'identité autoritaire de la révision.
|
||||||
|
|
||||||
## 5. Propositions et revues
|
La synchronisation peut être déclenchée par chacun des trois serveurs au début. Un worker séparé n'est créé que si un besoin d'ownership/lifecycle distinct apparaît.
|
||||||
|
|
||||||
|
## 6. Propositions et revues
|
||||||
|
|
||||||
Le workflow exact reste à formaliser avant implémentation, mais le contrat minimal conserve :
|
Le workflow exact reste à formaliser avant implémentation, mais le contrat minimal conserve :
|
||||||
|
|
||||||
```text
|
```text
|
||||||
auteur
|
auteur
|
||||||
cible
|
famille et source cible
|
||||||
révision Git de base
|
révision Git de base
|
||||||
patch ou contenu proposé
|
patch ou contenu proposé
|
||||||
statut
|
statut
|
||||||
@@ -131,7 +171,7 @@ Si la base n'est plus courante, le workflow doit pouvoir signaler un conflit/reb
|
|||||||
|
|
||||||
Une pull request de forge MAY refléter ou accélérer ce workflow ; elle n'en est pas le modèle autoritaire obligatoire.
|
Une pull request de forge MAY refléter ou accélérer ce workflow ; elle n'en est pas le modèle autoritaire obligatoire.
|
||||||
|
|
||||||
## 6. Parsing et validation des contenus
|
## 7. Parsing et validation des contenus
|
||||||
|
|
||||||
Le contrat conceptuel `ContentRepository` expose du contenu normalisé au métier sans révéler le provider Git ou forge.
|
Le contrat conceptuel `ContentRepository` expose du contenu normalisé au métier sans révéler le provider Git ou forge.
|
||||||
|
|
||||||
@@ -140,6 +180,7 @@ Le format final des HOWTOs/snippets reste `DEFER`. Le parseur devra néanmoins p
|
|||||||
```text
|
```text
|
||||||
identité logique
|
identité logique
|
||||||
famille de contenu
|
famille de contenu
|
||||||
|
source Git
|
||||||
révision source
|
révision source
|
||||||
métadonnées normalisées
|
métadonnées normalisées
|
||||||
corps rendu/parsé
|
corps rendu/parsé
|
||||||
@@ -149,17 +190,21 @@ résultat de validation
|
|||||||
|
|
||||||
Les validations normatives PGR restent propres au corpus PGR. Knowledge ne doit pas inventer une règle PGR pour simplifier son parseur.
|
Les validations normatives PGR restent propres au corpus PGR. Knowledge ne doit pas inventer une règle PGR pour simplifier son parseur.
|
||||||
|
|
||||||
## 7. Index, recherche et cache
|
## 8. PostgreSQL partagé, index, recherche et cache
|
||||||
|
|
||||||
L'index/cache est une projection reconstructible du contenu Git.
|
La baseline retient **une base PostgreSQL logique partagée** par les trois applications.
|
||||||
|
|
||||||
|
Ce choix est justifié par l'état transversal : identités, sessions, propositions, synchronisation, relations entre familles, index et recherche. Il évite trois bases divergentes pour des concepts qui appartiennent à la même plateforme.
|
||||||
|
|
||||||
PostgreSQL MAY contenir des documents/index/métadonnées dérivés et assurer une première capacité de recherche. Aucun moteur de recherche externe n'est sélectionné en `0.0.1`.
|
PostgreSQL MAY contenir des documents/index/métadonnées dérivés et assurer une première capacité de recherche. Aucun moteur de recherche externe n'est sélectionné en `0.0.1`.
|
||||||
|
|
||||||
Une projection doit garder la révision Git source afin de savoir exactement quel contenu elle représente.
|
Les enregistrements dérivés doivent porter au minimum l'identité de famille/source et la révision Git afin de savoir exactement quel contenu ils représentent.
|
||||||
|
|
||||||
## 8. Rendu et publication
|
Une séparation physique de bases ou de schémas par application reste possible ultérieurement si une contrainte de sécurité, disponibilité, charge ou ownership la justifie. Elle n'est pas la baseline de fondation.
|
||||||
|
|
||||||
La publication sélectionne une révision autorisée, la valide/indexe puis la rend disponible localement.
|
## 9. Rendu et publication
|
||||||
|
|
||||||
|
Chaque application publique sélectionne et publie uniquement les familles/sources qui lui sont autorisées.
|
||||||
|
|
||||||
Pour PGR :
|
Pour PGR :
|
||||||
|
|
||||||
@@ -173,19 +218,25 @@ Pour HOWTOs/snippets :
|
|||||||
|
|
||||||
Actix Web et Maud sont des choix de composition/rendu locaux. Vite gère les assets/interactions frontend lorsqu'il est matérialisé.
|
Actix Web et Maud sont des choix de composition/rendu locaux. Vite gère les assets/interactions frontend lorsqu'il est matérialisé.
|
||||||
|
|
||||||
## 9. Administration
|
La stratégie exacte de partage des assets/frontend entre les trois applications reste `DEFER` jusqu'à la tranche Web : un package commun n'est créé que si du code/assets sont réellement communs.
|
||||||
|
|
||||||
|
## 10. Administration
|
||||||
|
|
||||||
L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité.
|
L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité.
|
||||||
|
|
||||||
Elle pourra gérer propositions, revues, synchronisation, validation et publication. Une UI complète est hors scope `0.0.1`.
|
Elle pourra gérer propositions, revues, synchronisation, validation et publication. Une UI complète est hors scope `0.0.1`.
|
||||||
|
|
||||||
## 10. Authentification et autorisation
|
La décision entre routes d'administration réparties dans les trois applications et launcher d'administration dédié reste ouverte jusqu'à ce que les besoins d'auth, lifecycle et déploiement soient connus.
|
||||||
|
|
||||||
|
## 11. Authentification et autorisation
|
||||||
|
|
||||||
Le domaine doit distinguer identité, rôle/capacité et action autorisée, mais le fournisseur d'identité et le mécanisme complet restent différés.
|
Le domaine doit distinguer identité, rôle/capacité et action autorisée, mais le fournisseur d'identité et le mécanisme complet restent différés.
|
||||||
|
|
||||||
Les permissions forge ne sont pas supposées équivalentes aux permissions applicatives.
|
Les permissions forge ne sont pas supposées équivalentes aux permissions applicatives.
|
||||||
|
|
||||||
## 11. Frontières PGR / HOWTO / snippet / project-local
|
Le partage d'une base PostgreSQL facilite une identité et des autorisations transversales aux trois façades sans imposer trois silos de comptes.
|
||||||
|
|
||||||
|
## 12. Frontières PGR / HOWTO / snippet / project-local
|
||||||
|
|
||||||
Les quatre familles gardent une sémantique propre :
|
Les quatre familles gardent une sémantique propre :
|
||||||
|
|
||||||
@@ -200,24 +251,25 @@ Les métadonnées peuvent relier ces familles sans promotion automatique de forc
|
|||||||
|
|
||||||
Une pratique répétée dans HOWTO/snippet peut devenir un candidat d'étude PGR ; elle n'est normative qu'après le workflow PGR correspondant.
|
Une pratique répétée dans HOWTO/snippet peut devenir un candidat d'étude PGR ; elle n'est normative qu'après le workflow PGR correspondant.
|
||||||
|
|
||||||
## 12. Git versus PostgreSQL
|
## 13. Git versus PostgreSQL
|
||||||
|
|
||||||
### Autoritaire dans Git
|
### Autoritaire dans Git
|
||||||
|
|
||||||
- corps du contenu publié ;
|
- corps du contenu publié ;
|
||||||
- métadonnées éditoriales versionnées avec ce contenu ;
|
- métadonnées éditoriales versionnées avec ce contenu ;
|
||||||
- historique de révisions Git ;
|
- historique de révisions Git ;
|
||||||
- refs/tags/branches autorisées par la politique de chaque dépôt.
|
- refs/tags/branches autorisées par la politique de chaque source.
|
||||||
|
|
||||||
### État applicatif PostgreSQL
|
### État applicatif PostgreSQL partagé
|
||||||
|
|
||||||
- utilisateurs/sessions ;
|
- utilisateurs/sessions ;
|
||||||
- propositions et revue ;
|
- propositions et revue ;
|
||||||
- commentaires/audit applicatif ;
|
- commentaires/audit applicatif ;
|
||||||
- configuration logique des sources ;
|
- configuration logique des sources ;
|
||||||
- dernière révision synchronisée/indexée ;
|
- mapping source/famille/application ;
|
||||||
|
- dernière révision synchronisée/indexée par source ;
|
||||||
- index et recherche dérivés ;
|
- index et recherche dérivés ;
|
||||||
- relations calculées ;
|
- relations calculées entre familles ;
|
||||||
- jobs de synchronisation/publication ;
|
- jobs de synchronisation/publication ;
|
||||||
- cache/projections reconstructibles.
|
- cache/projections reconstructibles.
|
||||||
|
|
||||||
@@ -228,10 +280,10 @@ Une modification du contenu publié ne doit pas exister uniquement dans PostgreS
|
|||||||
## Topologie de dépôts retenue
|
## Topologie de dépôts retenue
|
||||||
|
|
||||||
```text
|
```text
|
||||||
sasedev-knowledge application et gouvernance de la plateforme
|
sasedev-knowledge application, workspace et gouvernance de la plateforme
|
||||||
pgr contenu normatif PGR existant
|
pgr source Git normative PGR existante
|
||||||
howtos contenu procédural séparé
|
howtos source Git procédurale séparée
|
||||||
snippets contenu court/contextualisé séparé
|
snippets source Git courte/contextualisée séparée
|
||||||
```
|
```
|
||||||
|
|
||||||
Les dépôts de contenu ne sont pas fusionnés dans PGR et ne sont pas requis comme submodules Git du dépôt applicatif. Leur localisation et leurs credentials sont de la configuration de déploiement.
|
Les dépôts de contenu ne sont pas fusionnés dans PGR et ne sont pas requis comme submodules Git du dépôt applicatif. Leur localisation et leurs credentials sont de la configuration de déploiement.
|
||||||
|
|||||||
@@ -1,11 +1,11 @@
|
|||||||
<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
|
<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Objectifs SaseDev Knowledge
|
# Objectifs SaseDev Knowledge
|
||||||
|
|
||||||
## Mission
|
## Mission
|
||||||
|
|
||||||
SaseDev Knowledge fournit une plateforme contrôlée permettant de publier, relier, rechercher et administrer des contenus de connaissance SaseDev tout en conservant Git comme vérité versionnée et PGR comme référentiel normatif indépendant.
|
SaseDev Knowledge fournit un workspace applicatif contrôlé permettant de publier, relier, rechercher et administrer des contenus de connaissance SaseDev tout en conservant Git comme vérité versionnée et PGR comme référentiel normatif indépendant.
|
||||||
|
|
||||||
## Façades produit visées
|
## Façades produit visées
|
||||||
|
|
||||||
@@ -17,7 +17,33 @@ howtos.sasedev.com
|
|||||||
snippets.sasedev.com
|
snippets.sasedev.com
|
||||||
```
|
```
|
||||||
|
|
||||||
Une même application MAY servir plusieurs hostnames tant que les frontières de contenu restent explicites.
|
Ils correspondent à trois applications Actix Web distinctes dans un même workspace :
|
||||||
|
|
||||||
|
```text
|
||||||
|
knowledge-pgr-server
|
||||||
|
knowledge-howtos-server
|
||||||
|
knowledge-snippets-server
|
||||||
|
```
|
||||||
|
|
||||||
|
Cette séparation permet de faire évoluer, déployer et dimensionner chaque façade indépendamment tout en partageant les bibliothèques de domaine, Git, stockage, rendu et observabilité lorsque leur ownership est réellement commun.
|
||||||
|
|
||||||
|
## Sources Git de contenu
|
||||||
|
|
||||||
|
La fondation retient au minimum trois sources Git indépendantes :
|
||||||
|
|
||||||
|
```text
|
||||||
|
pgr -> contenu normatif PGR
|
||||||
|
howtos -> contenu procédural HOWTO
|
||||||
|
snippets -> contenu court/contextualisé
|
||||||
|
```
|
||||||
|
|
||||||
|
Chaque application possède sa source primaire de publication. L'architecture doit néanmoins permettre plusieurs repositories par famille si le produit l'exige ultérieurement ; les trois dépôts initiaux ne constituent pas une limite codée en dur.
|
||||||
|
|
||||||
|
## État applicatif partagé
|
||||||
|
|
||||||
|
Les trois applications peuvent et, dans la baseline de fondation, doivent utiliser le même stockage PostgreSQL logique pour l'état transversal de plateforme : identités, sessions, propositions, revues, synchronisation, index et relations calculées.
|
||||||
|
|
||||||
|
Ce partage ne fusionne pas les sources de vérité éditoriales : le contenu publié de chaque famille reste autoritaire dans son ou ses repositories Git.
|
||||||
|
|
||||||
## Objectifs durables
|
## Objectifs durables
|
||||||
|
|
||||||
@@ -26,12 +52,14 @@ Knowledge doit permettre à terme :
|
|||||||
- de publier une stable PGR issue d'un tag vérifié, avec un éventuel canal `dev` distinct ;
|
- de publier une stable PGR issue d'un tag vérifié, avec un éventuel canal `dev` distinct ;
|
||||||
- de publier des HOWTOs procéduraux sans leur attribuer une force normative PGR ;
|
- de publier des HOWTOs procéduraux sans leur attribuer une force normative PGR ;
|
||||||
- de publier des snippets courts et contextualisés ;
|
- de publier des snippets courts et contextualisés ;
|
||||||
|
- de déployer séparément les trois façades publiques sans dupliquer la logique partagée ;
|
||||||
- d'administrer des dépôts publics ou privés ;
|
- d'administrer des dépôts publics ou privés ;
|
||||||
- d'accepter des propositions externes sans écriture directe dans le contenu publié ;
|
- d'accepter des propositions externes sans écriture directe dans le contenu publié ;
|
||||||
- de conserver une révision Git de base pour détecter les conflits ;
|
- de conserver une révision Git de base pour détecter les conflits ;
|
||||||
- d'utiliser une forge lorsqu'elle apporte des capacités supplémentaires sans la rendre obligatoire ;
|
- d'utiliser une forge lorsqu'elle apporte des capacités supplémentaires sans la rendre obligatoire ;
|
||||||
- de servir les lectures publiques depuis des données locales/indexées lorsque la forge distante est indisponible ;
|
- de servir les lectures publiques depuis des données locales/indexées lorsque la forge distante est indisponible ;
|
||||||
- de garder les contenus récupérables et intelligibles par un clone Git indépendant du site.
|
- de garder les contenus récupérables et intelligibles par un clone Git indépendant du site ;
|
||||||
|
- de relier PGR, HOWTOs et snippets via un état/index partagé sans leur donner la même force normative.
|
||||||
|
|
||||||
## Non-objectifs de la fondation 0.0.1
|
## Non-objectifs de la fondation 0.0.1
|
||||||
|
|
||||||
@@ -44,8 +72,10 @@ Knowledge doit permettre à terme :
|
|||||||
- un déploiement multi-domaines de production ;
|
- un déploiement multi-domaines de production ;
|
||||||
- un moteur de rendu final pour tous les formats ;
|
- un moteur de rendu final pour tous les formats ;
|
||||||
- un système d'authentification complet ;
|
- un système d'authentification complet ;
|
||||||
- une architecture microservices.
|
- une architecture de microservices distribués.
|
||||||
|
|
||||||
## Principe de simplicité
|
## Principe de simplicité
|
||||||
|
|
||||||
Le monolithe modulaire est la baseline architecturale de départ. Une séparation en services n'est introduite que lorsqu'une contrainte observée justifie un nouveau boundary de déploiement.
|
La baseline n'est plus un processus Web unique. Elle est un **workspace modulaire multi-app** : trois launchers Actix Web séparés et des crates communes réutilisables.
|
||||||
|
|
||||||
|
La séparation des trois façades correspond à une frontière produit explicite ; elle ne doit pas entraîner une multiplication de services internes, de bases ou de crates sans ownership réel. Toute séparation supplémentaire demande une contrainte observée.
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
|
<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Plan 0.0.1 — fondation SaseDev Knowledge
|
# Plan 0.0.1 — fondation SaseDev Knowledge
|
||||||
|
|
||||||
@@ -25,6 +25,7 @@ La release doit établir :
|
|||||||
|
|
||||||
- la gouvernance PGR locale ;
|
- la gouvernance PGR locale ;
|
||||||
- la composition des owners/skeletons réellement applicables ;
|
- la composition des owners/skeletons réellement applicables ;
|
||||||
|
- la topologie du workspace à trois applications Actix Web distinctes ;
|
||||||
- les frontières Git générique / forge optionnelle / PostgreSQL ;
|
- les frontières Git générique / forge optionnelle / PostgreSQL ;
|
||||||
- les frontières PGR / HOWTO / snippet / project-local ;
|
- les frontières PGR / HOWTO / snippet / project-local ;
|
||||||
- un workspace Rust minimal strict et reproductible ;
|
- un workspace Rust minimal strict et reproductible ;
|
||||||
@@ -34,29 +35,33 @@ La release doit établir :
|
|||||||
|
|
||||||
## État acquis et questions ouvertes
|
## État acquis et questions ouvertes
|
||||||
|
|
||||||
Acquis par le cadrage `alpha.1` :
|
Acquis par le cadrage `alpha.1.fix.1` :
|
||||||
|
|
||||||
- dépôt applicatif `sasedev-knowledge`, nom court `knowledge` ;
|
- dépôt applicatif/workspace `sasedev-knowledge`, nom court `knowledge` ;
|
||||||
|
- trois launchers publics retenus : `knowledge-pgr-server`, `knowledge-howtos-server`, `knowledge-snippets-server` ;
|
||||||
|
- au moins trois sources Git indépendantes : `pgr`, `howtos`, `snippets` ;
|
||||||
- Git autoritaire pour le contenu ;
|
- Git autoritaire pour le contenu ;
|
||||||
- forge facultative derrière adapter ;
|
- forge facultative derrière adapter ;
|
||||||
- PostgreSQL pour l'état applicatif/projections ;
|
- une base PostgreSQL logique partagée pour l'état transversal et les projections ;
|
||||||
- monolithe modulaire comme baseline de déploiement ;
|
- crates communes privilégiées à la duplication entre launchers ;
|
||||||
- PGR, HOWTOs et snippets dans des dépôts séparés ;
|
|
||||||
- Rust stable/édition 2024 ;
|
- Rust stable/édition 2024 ;
|
||||||
- Actix Web, Maud, Vite, TypeScript, Sass, Bootstrap et PostgreSQL retenus comme intentions locales conformes aux owners applicables ;
|
- Actix Web, Maud, Vite, TypeScript, Sass, Bootstrap et PostgreSQL retenus comme intentions locales conformes aux owners applicables ;
|
||||||
|
- préférence Eclipse UTF-8 versionnée conformément à la politique PGR ;
|
||||||
- aucun override PGR nécessaire.
|
- aucun override PGR nécessaire.
|
||||||
|
|
||||||
Restent volontairement ouverts jusqu'à la tranche qui les consomme :
|
Restent volontairement ouverts jusqu'à la tranche qui les consomme :
|
||||||
|
|
||||||
- package manager et lockfile frontend ;
|
- package manager et lockfile frontend ;
|
||||||
- `Cargo.lock` ;
|
- `Cargo.lock` ;
|
||||||
- racine/configuration concrète du frontend ;
|
- racine(s) et partage concret du frontend entre les trois applications ;
|
||||||
- driver/ORM et migrations PostgreSQL ;
|
- driver/ORM et migrations PostgreSQL ;
|
||||||
|
- éventuel découpage en schémas PostgreSQL ;
|
||||||
- moteur de recherche ;
|
- moteur de recherche ;
|
||||||
- fournisseur d'identité ;
|
- fournisseur d'identité ;
|
||||||
- adapter forge réel ;
|
- adapter forge réel ;
|
||||||
- formats finaux HOWTO/snippet ;
|
- formats finaux HOWTO/snippet ;
|
||||||
- liste définitive des crates.
|
- topologie d'administration ;
|
||||||
|
- liste définitive des crates de bibliothèque.
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
@@ -65,6 +70,7 @@ Restent volontairement ouverts jusqu'à la tranche qui les consomme :
|
|||||||
- documentation de gouvernance et architecture ;
|
- documentation de gouvernance et architecture ;
|
||||||
- workspace Rust/Cargo minimal ;
|
- workspace Rust/Cargo minimal ;
|
||||||
- configuration de toolchain/lints proportionnée ;
|
- configuration de toolchain/lints proportionnée ;
|
||||||
|
- trois packages serveur distincts uniquement lorsque leur composition devient utile ;
|
||||||
- premiers types/traits de boundary lorsque leur responsabilité est claire ;
|
- premiers types/traits de boundary lorsque leur responsabilité est claire ;
|
||||||
- baseline Web minimale et reproductible ;
|
- baseline Web minimale et reproductible ;
|
||||||
- validation indépendante backend/frontend ;
|
- validation indépendante backend/frontend ;
|
||||||
@@ -83,7 +89,8 @@ Restent volontairement ouverts jusqu'à la tranche qui les consomme :
|
|||||||
- authentification complète ;
|
- authentification complète ;
|
||||||
- production multi-domaines ;
|
- production multi-domaines ;
|
||||||
- moteur de rendu final de tous les formats ;
|
- moteur de rendu final de tous les formats ;
|
||||||
- architecture microservices.
|
- architecture de microservices distribués ;
|
||||||
|
- quatrième application d'administration sans besoin démontré.
|
||||||
|
|
||||||
## Stratégie de validation
|
## Stratégie de validation
|
||||||
|
|
||||||
@@ -91,12 +98,13 @@ Les gates suivent [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-V
|
|||||||
|
|
||||||
Principes :
|
Principes :
|
||||||
|
|
||||||
- gate documentaire pour `alpha.1` ;
|
- gate documentaire pour `alpha.1` et ses fixes ;
|
||||||
|
- politique Eclipse explicitement contrôlée ;
|
||||||
- Cargo officiel dès matérialisation Rust ;
|
- Cargo officiel dès matérialisation Rust ;
|
||||||
- audits Rust structurels PGR seulement s'ils apportent une preuve distincte ;
|
- audits Rust structurels PGR seulement s'ils apportent une preuve distincte ;
|
||||||
- package manager/TypeScript/Vite/Sass officiels dès matérialisation Web ;
|
- package manager/TypeScript/Vite/Sass officiels dès matérialisation Web ;
|
||||||
- backend et frontend validables séparément ;
|
- backend et frontend validables séparément ;
|
||||||
- smoke seulement pour une propriété runtime réellement introduite ;
|
- chaque launcher serveur reçoit un smoke seulement lorsqu'une propriété runtime réelle est introduite ;
|
||||||
- aucune prévalidation assistant ne vaut `PASS` opérateur.
|
- aucune prévalidation assistant ne vaut `PASS` opérateur.
|
||||||
|
|
||||||
## Trajectoire prévisionnelle
|
## Trajectoire prévisionnelle
|
||||||
@@ -105,31 +113,43 @@ Principes :
|
|||||||
|
|
||||||
Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage.
|
Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage.
|
||||||
|
|
||||||
|
Le résultat opérateur initial est `FAIL`. Le fix `alpha.1.fix.1` corrige la politique Eclipse, la gate de fichiers et la topologie produit à trois applications sans ouvrir le scope `alpha.2`.
|
||||||
|
|
||||||
Aucun code fonctionnel n'est ajouté.
|
Aucun code fonctionnel n'est ajouté.
|
||||||
|
|
||||||
### alpha.2 — workspace Rust/Cargo minimal
|
### alpha.2 — workspace Rust/Cargo minimal
|
||||||
|
|
||||||
Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, toolchain/configuration durable réellement nécessaire, premier package possédant une responsabilité claire et gates Cargo officielles.
|
Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, toolchain/configuration durable réellement nécessaire et premier package de bibliothèque possédant une responsabilité claire.
|
||||||
|
|
||||||
Décider explicitement `Cargo.lock`, outputs de build et premier sous-ensemble de crates réellement matérialisé.
|
Décider explicitement `Cargo.lock`, outputs de build et premier sous-ensemble de crates réellement matérialisé.
|
||||||
|
|
||||||
|
Les trois packages serveur sont connus architecturalement mais ne sont pas obligatoirement tous créés dans cette tranche si leur seule existence serait un placeholder.
|
||||||
|
|
||||||
### alpha.3 — contrats domaine/Git/synchronisation
|
### alpha.3 — contrats domaine/Git/synchronisation
|
||||||
|
|
||||||
Introduire uniquement les premiers contrats/types nécessaires aux frontières `GitRepository`, contenu et synchronisation, avec tests ciblés. Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
|
Introduire uniquement les premiers contrats/types nécessaires aux frontières `GitRepository`, source/famille de contenu et synchronisation, avec tests ciblés. Le modèle doit supporter au moins les trois sources initiales sans coder une limite à trois.
|
||||||
|
|
||||||
Les noms conceptuels du cadrage peuvent être adaptés si l'implémentation montre un meilleur owner ; toute modification du plan est tracée dans le delta correspondant.
|
Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
|
||||||
|
|
||||||
### alpha.4 — baseline Web indépendante
|
### alpha.4 — baseline Web indépendante
|
||||||
|
|
||||||
Instancier le skeleton `003-WEB_FRONTEND` : choisir package manager et lockfile, TypeScript strict, Vite, Sass et Bootstrap réellement nécessaires, avec typecheck/build indépendants du backend.
|
Instancier le skeleton `003-WEB_FRONTEND` : choisir package manager et lockfile, TypeScript strict, Vite, Sass et Bootstrap réellement nécessaires, avec typecheck/build indépendants du backend.
|
||||||
|
|
||||||
Ne pas faire de la présence d'Actix/Maud une excuse pour coupler la gate frontend au serveur.
|
Décider à cette tranche si les trois applications partagent un package d'assets/frontend ou possèdent des entrées séparées. Ne pas dupliquer par défaut, ne pas imposer non plus un frontend unique sans preuve de réutilisation.
|
||||||
|
|
||||||
### alpha.5 — composition serveur minimale
|
### alpha.5 — composition des trois serveurs minimale
|
||||||
|
|
||||||
Matérialiser le minimum Actix Web/Maud nécessaire pour prouver la composition avec les contrats et assets de fondation, sans admin complète, auth complète, persistence métier complète ni forge.
|
Matérialiser le minimum Actix Web/Maud nécessaire pour prouver trois launchers minces :
|
||||||
|
|
||||||
Cette tranche peut être réduite ou reportée si `alpha.2` à `alpha.4` montrent qu'une stable de fondation plus petite est suffisante.
|
```text
|
||||||
|
knowledge-pgr-server
|
||||||
|
knowledge-howtos-server
|
||||||
|
knowledge-snippets-server
|
||||||
|
```
|
||||||
|
|
||||||
|
Ils doivent composer les mêmes contrats/bibliothèques lorsque la responsabilité est partagée et rester capables de recevoir des configurations de sources Git distinctes.
|
||||||
|
|
||||||
|
La tranche ne doit pas introduire admin complète, auth complète, persistance métier complète ni forge obligatoire.
|
||||||
|
|
||||||
### beta.1 — réconciliation de fondation
|
### beta.1 — réconciliation de fondation
|
||||||
|
|
||||||
@@ -151,8 +171,10 @@ REPLAN obligatoire si :
|
|||||||
|
|
||||||
- une tranche nécessite plusieurs responsabilités non prévues qui ne peuvent plus être validées proprement ensemble ;
|
- une tranche nécessite plusieurs responsabilités non prévues qui ne peuvent plus être validées proprement ensemble ;
|
||||||
- un choix de crate impose un couplage du domaine à Actix/Gitea/PostgreSQL ;
|
- un choix de crate impose un couplage du domaine à Actix/Gitea/PostgreSQL ;
|
||||||
|
- les trois launchers entraînent une duplication de logique qui devrait être possédée par une crate commune ;
|
||||||
- le frontend ne peut pas être validé indépendamment du host sans raison architecturale réelle ;
|
- le frontend ne peut pas être validé indépendamment du host sans raison architecturale réelle ;
|
||||||
- le choix Git impose une API de forge pour une opération fondamentale ;
|
- le choix Git impose une API de forge pour une opération fondamentale ;
|
||||||
|
- la base PostgreSQL partagée impose un couplage de contenu qui contredit l'autorité Git ;
|
||||||
- le format de contenu doit être figé sans corpus représentatif ;
|
- le format de contenu doit être figé sans corpus représentatif ;
|
||||||
- trois fixes ou plus apparaissent sur une même tranche ;
|
- trois fixes ou plus apparaissent sur une même tranche ;
|
||||||
- un prérequis externe invalide la mission de fondation.
|
- un prérequis externe invalide la mission de fondation.
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||||
<!-- version: 1 -->
|
<!-- version: 2 -->
|
||||||
|
|
||||||
# Matrice de validation Knowledge
|
# Matrice de validation Knowledge
|
||||||
|
|
||||||
@@ -16,13 +16,40 @@ Pour une tranche limitée à gouvernance/documentation :
|
|||||||
```text
|
```text
|
||||||
CHECK VERSION attendue
|
CHECK VERSION attendue
|
||||||
CHECK git diff --check
|
CHECK git diff --check
|
||||||
AUDIT liste des fichiers ajoutés/remplacés/supprimés conforme au delta
|
AUDIT fichiers Git suivis/non ignorés conformes au delta, sans confondre fichiers locaux ignorés et distribution
|
||||||
AUDIT headers file/version des Markdown gouvernés
|
AUDIT headers file/version des Markdown gouvernés
|
||||||
|
AUDIT headers file/version des formats texte qui adoptent explicitement cette convention
|
||||||
AUDIT liens Markdown locaux principaux
|
AUDIT liens Markdown locaux principaux
|
||||||
REVIEW owners PGR / décisions locales / DEFER explicites
|
REVIEW owners PGR / décisions locales / DEFER explicites
|
||||||
REVIEW absence de secret, chemin machine absolu et placeholder non résolu
|
REVIEW absence de secret, chemin machine absolu et placeholder non résolu
|
||||||
```
|
```
|
||||||
|
|
||||||
|
## Politique Eclipse
|
||||||
|
|
||||||
|
Les métadonnées Eclipse spécifiques à la machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
|
||||||
|
|
||||||
|
Le fichier suivant constitue l'exception versionnée :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.settings/org.eclipse.core.resources.prefs
|
||||||
|
```
|
||||||
|
|
||||||
|
Il doit contenir :
|
||||||
|
|
||||||
|
```text
|
||||||
|
eclipse.preferences.version=1
|
||||||
|
encoding/<project>=UTF-8
|
||||||
|
```
|
||||||
|
|
||||||
|
Le `.gitignore` doit contenir :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.settings/*
|
||||||
|
!.settings/org.eclipse.core.resources.prefs
|
||||||
|
```
|
||||||
|
|
||||||
|
Une gate de distribution ne doit donc pas échouer parce qu'un `.project` ignoré existe dans le workspace local. Elle doit en revanche échouer si `org.eclipse.core.resources.prefs` est ignoré ou absent du contenu suivi.
|
||||||
|
|
||||||
## Rust/Cargo
|
## Rust/Cargo
|
||||||
|
|
||||||
Dès qu'un workspace Rust est matérialisé, sélectionner selon le scope :
|
Dès qu'un workspace Rust est matérialisé, sélectionner selon le scope :
|
||||||
@@ -52,9 +79,19 @@ SMOKE navigateur seulement lorsqu'une propriété runtime le justifie
|
|||||||
|
|
||||||
La gate frontend reste exécutable indépendamment du backend autant que la topologie réelle le permet.
|
La gate frontend reste exécutable indépendamment du backend autant que la topologie réelle le permet.
|
||||||
|
|
||||||
## Serveur et intégration
|
Si plusieurs entrées/frontend existent pour PGR, HOWTOs et snippets, la gate doit couvrir chacune des entrées modifiées sans forcer trois builds identiques lorsqu'un package commun possède réellement les assets partagés.
|
||||||
|
|
||||||
Actix Web/Maud reçoivent une gate backend Rust ciblée. Un smoke HTTP est ajouté uniquement lorsqu'une route/runtime réelle est introduite et que compilation/tests ne prouvent pas la propriété visée.
|
## Serveurs et intégration
|
||||||
|
|
||||||
|
Les trois launchers Actix Web/Maud sont validés comme packages exécutables distincts lorsqu'ils sont matérialisés :
|
||||||
|
|
||||||
|
```text
|
||||||
|
knowledge-pgr-server
|
||||||
|
knowledge-howtos-server
|
||||||
|
knowledge-snippets-server
|
||||||
|
```
|
||||||
|
|
||||||
|
Leur compilation peut être prouvée par les gates workspace. Un smoke HTTP ciblé est ajouté uniquement lorsqu'une route/runtime réelle est introduite et que compilation/tests ne prouvent pas la propriété visée.
|
||||||
|
|
||||||
Une gate d'intégration ne remplace pas silencieusement les preuves frontend indépendantes.
|
Une gate d'intégration ne remplace pas silencieusement les preuves frontend indépendantes.
|
||||||
|
|
||||||
@@ -62,6 +99,8 @@ Une gate d'intégration ne remplace pas silencieusement les preuves frontend ind
|
|||||||
|
|
||||||
Les contrats Git génériques sont testés sans dépendance à une forge lorsque cela suffit.
|
Les contrats Git génériques sont testés sans dépendance à une forge lorsque cela suffit.
|
||||||
|
|
||||||
|
Les tests doivent permettre plusieurs `source_id` et ne pas confondre famille de contenu avec provider de forge.
|
||||||
|
|
||||||
Un test live de remote ou de forge doit être explicitement classé comme externe, séparé des tests unitaires et ne doit pas devenir une condition cachée pour les opérations locales.
|
Un test live de remote ou de forge doit être explicitement classé comme externe, séparé des tests unitaires et ne doit pas devenir une condition cachée pour les opérations locales.
|
||||||
|
|
||||||
## PostgreSQL
|
## PostgreSQL
|
||||||
@@ -72,17 +111,23 @@ Lorsqu'elle devient nécessaire, la validation doit distinguer :
|
|||||||
|
|
||||||
- parsing/compilation des migrations ou schémas ;
|
- parsing/compilation des migrations ou schémas ;
|
||||||
- tests avec base éphémère/localement contrôlée ;
|
- tests avec base éphémère/localement contrôlée ;
|
||||||
|
- accès cohérent depuis les trois applications lorsque le stockage partagé est concerné ;
|
||||||
- éventuels smokes externes ;
|
- éventuels smokes externes ;
|
||||||
- reconstruction d'une projection dérivée à partir d'une révision Git connue.
|
- reconstruction d'une projection dérivée à partir d'une révision Git connue ;
|
||||||
|
- isolation correcte par famille/source sans dupliquer trois bases par simple symétrie.
|
||||||
|
|
||||||
## Gate de `0.0.1-alpha.1`
|
## Gate de `0.0.1-alpha.1.fix.1`
|
||||||
|
|
||||||
La première tranche est documentaire. Sa gate doit prouver :
|
Le fix reste documentaire. Sa gate doit prouver :
|
||||||
|
|
||||||
- `VERSION = 0.0.1-alpha.1` ;
|
- `VERSION = 0.0.1-alpha.1.fix.1` ;
|
||||||
- les fichiers exacts du delta ;
|
- le history `alpha.1` `FAIL` déjà committé avant application du fix ;
|
||||||
|
- les fichiers Git suivis/non ignorés exacts de la fondation, sans compter `.project` ;
|
||||||
|
- `.gitignore` avec headers `file/version` et exception Eclipse correcte ;
|
||||||
|
- `.settings/org.eclipse.core.resources.prefs` présent, UTF-8 et non ignoré ;
|
||||||
- l'absence de code fonctionnel ;
|
- l'absence de code fonctionnel ;
|
||||||
- les headers et liens locaux ;
|
- les headers et liens locaux ;
|
||||||
- la présence de la baseline PGR vérifiée et de la matrice de décisions ;
|
- la topologie documentée à trois serveurs Actix distincts ;
|
||||||
|
- au moins trois sources Git initiales et une base PostgreSQL logique partagée ;
|
||||||
- l'absence d'override PGR non documenté ;
|
- l'absence d'override PGR non documenté ;
|
||||||
- la cohérence du plan et de la transition PASS/FAIL.
|
- la cohérence du plan et de la transition PASS/FAIL.
|
||||||
|
|||||||
134
history/0.0.1/alpha.1.fix.1.md
Normal file
134
history/0.0.1/alpha.1.fix.1.md
Normal file
@@ -0,0 +1,134 @@
|
|||||||
|
<!-- file: history/0.0.1/alpha.1.fix.1.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# History 0.0.1-alpha.1.fix.1 — correction du cadrage initial Knowledge
|
||||||
|
|
||||||
|
## Statut
|
||||||
|
|
||||||
|
PASS
|
||||||
|
|
||||||
|
La gate opérateur de `0.0.1-alpha.1.fix.1` exécutée le `2026-09-27` est propre. Le correctif ferme les défauts établis par `alpha.1 FAIL` sans démarrer l'implémentation fonctionnelle.
|
||||||
|
|
||||||
|
## Baseline opérateur
|
||||||
|
|
||||||
|
Le history `alpha.1 FAIL` a été appliqué, puis l'état complet `0.0.1-alpha.1` a été committé et poussé avant application du fix :
|
||||||
|
|
||||||
|
```text
|
||||||
|
commit 116219f
|
||||||
|
message 0.0.1-alpha.1
|
||||||
|
branch master
|
||||||
|
remote https://git.sasedev.com/Sasedev/sasedev-knowledge.git
|
||||||
|
push origin/master PASS
|
||||||
|
```
|
||||||
|
|
||||||
|
Le premier `grep` du history `alpha.1` avait échoué avant application de son archive ; le contrôle a ensuite été rejoué avec succès et a confirmé :
|
||||||
|
|
||||||
|
```text
|
||||||
|
## Statut
|
||||||
|
|
||||||
|
FAIL
|
||||||
|
```
|
||||||
|
|
||||||
|
Cette première absence ne constitue donc pas un défaut du fix : le history requis a été appliqué avant le commit `116219f`.
|
||||||
|
|
||||||
|
## Identité du fix
|
||||||
|
|
||||||
|
La commande suivante a réussi sans sortie :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
test "$(cat VERSION)" = "0.0.1-alpha.1.fix.1"
|
||||||
|
```
|
||||||
|
|
||||||
|
`git diff --check` n'a remonté aucun défaut.
|
||||||
|
|
||||||
|
## Politique Eclipse et `.gitignore`
|
||||||
|
|
||||||
|
Les contrôles opérateur ont confirmé les headers du `.gitignore` :
|
||||||
|
|
||||||
|
```text
|
||||||
|
# file: .gitignore
|
||||||
|
# version: 2
|
||||||
|
```
|
||||||
|
|
||||||
|
ainsi que la politique d'exception :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.settings/*
|
||||||
|
!.settings/org.eclipse.core.resources.prefs
|
||||||
|
```
|
||||||
|
|
||||||
|
Le fichier versionné Eclipse contient bien :
|
||||||
|
|
||||||
|
```text
|
||||||
|
eclipse.preferences.version=1
|
||||||
|
encoding/<project>=UTF-8
|
||||||
|
```
|
||||||
|
|
||||||
|
`git check-ignore -q .project` a confirmé que `.project` reste local/ignoré. Le contrôle inverse sur `.settings/org.eclipse.core.resources.prefs` a confirmé que ce fichier n'est pas ignoré.
|
||||||
|
|
||||||
|
## Gate de framing
|
||||||
|
|
||||||
|
La gate Python spécifique a atteint son message final :
|
||||||
|
|
||||||
|
```text
|
||||||
|
Knowledge 0.0.1-alpha.1.fix.1 framing audit: clean
|
||||||
|
```
|
||||||
|
|
||||||
|
Elle confirme notamment :
|
||||||
|
|
||||||
|
- la distribution Git attendue sans confusion avec les fichiers IDE locaux ignorés ;
|
||||||
|
- les headers Markdown gouvernés ;
|
||||||
|
- les trois applications `knowledge-pgr-server`, `knowledge-howtos-server` et `knowledge-snippets-server` dans les règles, objectifs et architecture ;
|
||||||
|
- au moins trois sources Git initiales ;
|
||||||
|
- une base PostgreSQL logique partagée ;
|
||||||
|
- l'absence de `Cargo.toml`, `src/main.rs`, `src/lib.rs`, `package.json`, `vite.config.ts` et migrations pendant le fix ;
|
||||||
|
- la conservation de `alpha.2` comme prochaine tranche normale.
|
||||||
|
|
||||||
|
## Hygiène Git et scope observé
|
||||||
|
|
||||||
|
`git diff --cached --check` n'a produit aucune erreur.
|
||||||
|
|
||||||
|
Le statut indexé transmis avant ajout du présent history est :
|
||||||
|
|
||||||
|
```text
|
||||||
|
M .gitignore
|
||||||
|
A .settings/org.eclipse.core.resources.prefs
|
||||||
|
M CHANGELOG.md
|
||||||
|
M README.md
|
||||||
|
M ROADMAP.md
|
||||||
|
M RULES.md
|
||||||
|
M VERSION
|
||||||
|
A deltas/0.0.1/alpha.1.fix.1.md
|
||||||
|
M docs/architecture/001-PROJECT_PROFILE.md
|
||||||
|
M docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
|
||||||
|
M docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||||
|
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||||
|
M docs/validation/001-VALIDATION_MATRIX.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Ce scope correspond au correctif annoncé : politique Eclipse, gate de distribution et topologie de fondation multi-app/Git/PostgreSQL.
|
||||||
|
|
||||||
|
## Précision acquise après la gate
|
||||||
|
|
||||||
|
Après le `PASS`, deux archives historiques inachevées ont été fournies comme corpus d'inspiration :
|
||||||
|
|
||||||
|
```text
|
||||||
|
actix-auth-app-master.zip SHA-256 bcdf4c568c827b77c70ee476218c2b07ea0fca408ab87d2f044333309d19ab71
|
||||||
|
amahil-project-master.zip SHA-256 b6a3d83c3c2911a7ff36eeb20e353801fefddaf1e5eb7afec1ff12c67067a359
|
||||||
|
```
|
||||||
|
|
||||||
|
Elles ne changent pas le résultat de la gate `alpha.1.fix.1`. Leur étude appartient à la tranche suivante et doit conserver une distinction stricte entre fonctionnalités réellement câblées, structures préparatoires et intentions non terminées.
|
||||||
|
|
||||||
|
La précision architecturale suivante est acquise pour formalisation à partir de `alpha.2` : chaque application Web PGR/HOWTOs/snippets doit pouvoir posséder sa propre surface d'administration protégée pour son domaine. Une éventuelle quatrième application d'administration peut agréger des fonctions transversales plus tard, mais ne doit pas devenir l'unique frontière d'autorisation. Les URL internes, routes de login/admin et le modèle détaillé de rôles/capacités restent à décider ultérieurement.
|
||||||
|
|
||||||
|
## Décision
|
||||||
|
|
||||||
|
`0.0.1-alpha.1.fix.1` est `PASS`.
|
||||||
|
|
||||||
|
Aucun `fix.2` n'est requis. La trajectoire normale reprend avec :
|
||||||
|
|
||||||
|
```text
|
||||||
|
0.0.1-alpha.2
|
||||||
|
```
|
||||||
|
|
||||||
|
`alpha.2` doit instancier le workspace Rust/Cargo minimal conformément au skeleton PGR `002-RUST_CARGO_WORKSPACE`, décider explicitement la politique `Cargo.lock` et documenter l'étude auth/admin sans implémenter prématurément l'authentification ou l'administration fonctionnelle.
|
||||||
Reference in New Issue
Block a user