0.0.1-alpha.1.fix.1
This commit is contained in:
44
RULES.md
44
RULES.md
@@ -1,11 +1,11 @@
|
||||
<!-- file: RULES.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Règles SaseDev Knowledge
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -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 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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
## 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 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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 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 :
|
||||
|
||||
- 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 ;
|
||||
- Vite + TypeScript pour les assets et interactions frontend ;
|
||||
- Sass ;
|
||||
- Bootstrap ;
|
||||
- PostgreSQL.
|
||||
- PostgreSQL partagé pour l'état applicatif transversal.
|
||||
|
||||
Ces choix ne sont pas présentés comme des règles PGR universelles.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user