Sasedev/sasedev-knowledge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.2-alpha.4

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-28 22:42:48 +02:00
parent b9508b0228
commit 3f8c795cc0
34 changed files with 2108 additions and 249 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
RULES.md
View File

@@ -1,5 +1,5 @@
<!-- file: RULES.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Règles SaseDev Knowledge
@@ -29,31 +29,18 @@ Une future version de PGR n'a aucun effet automatique sur Knowledge. Elle n'est
`0.0.2-alpha.4` est la tranche de réconciliation qui doit terminer l'autonomie normative de l'adoption `v0.1.3` : inventorier les owners réellement retenus, vérifier où chaque contrat nécessaire est possédé localement, adapter les règles/templates/audits manquants sans recopier mécaniquement l'arborescence PGR et supprimer les références externes nécessaires à la compréhension courante du projet.
## Owners PGR applicables
## Owners normatifs locaux
La fondation retient les owners suivants dans leur scope réel :
Le développement courant est gouverné par les owners Knowledge suivants :
```text
200 gouvernance et lifecycle
210 workflow plan/delta/history/handoff
220 composition des skeletons pendant l'instanciation
230 adoption d'une nouvelle baseline PGR par un projet existant
300 documentation
400 validation proportionnée
500 famille langage/écosystème
510 Rust/Cargo
530 TypeScript
540 écosystème de packages JavaScript
550 Vite lorsque Vite est sélectionné
560 CSS/Sass
700 famille framework pour les frameworks réellement utilisés
```
- [`docs/rules/200-GOVERNANCE.md`](docs/rules/200-GOVERNANCE.md) — baseline, autonomie et décisions ;
- [`docs/rules/210-WORKFLOW.md`](docs/rules/210-WORKFLOW.md) — plan/delta/history/fix/handoff ;
- [`docs/rules/300-DOCUMENTATION.md`](docs/rules/300-DOCUMENTATION.md) — structure documentaire, headers et prompts ;
- [`docs/rules/400-VALIDATION.md`](docs/rules/400-VALIDATION.md) — preuves proportionnées et autorité opérateur ;
- [`docs/rules/510-RUST_CARGO.md`](docs/rules/510-RUST_CARGO.md) — Rust/Cargo strict, façade crate-root et tests ;
- [`docs/rules/530-WEB_FRONTEND.md`](docs/rules/530-WEB_FRONTEND.md) — TypeScript/npm/Vite/Sass/Bootstrap/Maud.
Les skeletons `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE` et `003-WEB_FRONTEND` documentent la provenance de composition de l'état existant. Ils ne sont pas des dépendances documentaires à relire pour développer Knowledge. `alpha.4` doit vérifier que les responsabilités effectivement retenues sont possédées localement avant de considérer l'adoption `v0.1.3` comme complètement matérialisée.
Le profil `710-TAURI` reste `DEFER` / non applicable au produit Web actuel. Aucun skeleton Tauri n'est adopté.
Les owners Java/Maven/Gradle réorganisés en PGR `0.1.2`, le profil Android réévalué en `0.1.3` et les autres technologies absentes du projet restent hors scope.
Le mapping complet de provenance et de décisions `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` est conservé dans [`docs/architecture/003-PGR_ADOPTION_MAP.md`](docs/architecture/003-PGR_ADOPTION_MAP.md). Les owners PGR non matérialisés localement ne sont pas des dépendances documentaires du développement quotidien.
## Priorité et décisions locales
@@ -188,7 +175,7 @@ Le package manager sélectionné est npm. Le fichier `package-lock.json` produit
Le package utilise TypeScript strict, Vite, Sass et Bootstrap. Bootstrap est un choix local Knowledge ; il ne devient pas une règle PGR universelle.
Le skeleton Web PGR `003-WEB_FRONTEND` et sa validation associée sont obligatoires pour `0.0.1`. Le frontend contrôlé doit utiliser la chaîne réellement sélectionnée TypeScript + Vite + Sass + Bootstrap pour valider indépendamment du backend les assets, comportements client et templates statiques de référence.
Le contrat Web courant est possédé par [`docs/rules/530-WEB_FRONTEND.md`](docs/rules/530-WEB_FRONTEND.md). Le frontend contrôlé utilise la chaîne réellement sélectionnée TypeScript + Vite + Sass + Bootstrap pour valider indépendamment du backend les assets, comportements client et templates statiques de référence.
Les templates statiques servent de support de conception, prévisualisation et validation navigateur. Ils MUST NOT devenir silencieusement une seconde implémentation runtime divergente : le HTML servi en production par les applications Actix est rendu avec Maud, et toute adaptation depuis le template de référence doit préserver explicitement les contrats utiles de structure, classes, attributs et assets.
@@ -196,7 +183,7 @@ Le build Vite de production MUST produire un mapping machine-readable des entré
Le pattern de loader observé dans `actix-auth-app` est un corpus d’inspiration. Sa reprise doit être réévaluée selon les règles Rust Knowledge : pas de `panic!`/`unwrap`/`expect`, erreurs récupérables, API minimale, tests ciblés et séparation claire entre debug/dev et production.
`knowledge-web-lib` possède ce contrat partagé à partir d'`alpha.5`. En développement, `KNOWLEDGE_VITE_DEV_ORIGIN` MUST fournir l'origin du dev server et le renderer charge `@vite/client` puis `src/main.ts`. En production, `KNOWLEDGE_VITE_MANIFEST_PATH` MUST désigner le manifest généré et les noms hashés sont résolus depuis l'entrée stable `src/main.ts`. `KNOWLEDGE_ASSET_BASE_PATH` MAY remplacer le préfixe de production `/`.
`knowledge-web-lib` possède ce contrat partagé depuis la fondation `0.0.1`. En développement, `KNOWLEDGE_VITE_DEV_ORIGIN` MUST fournir l'origin du dev server et le renderer charge `@vite/client` puis `src/main.ts`. En production, `KNOWLEDGE_VITE_MANIFEST_PATH` MUST désigner le manifest généré et les noms hashés sont résolus depuis l'entrée stable `src/main.ts`. `KNOWLEDGE_ASSET_BASE_PATH` MAY remplacer le préfixe de production `/`.
Les trois launchers MUST recevoir leur socket de bind par configuration (`KNOWLEDGE_PGR_BIND_ADDRESS`, `KNOWLEDGE_HOWTOS_BIND_ADDRESS`, `KNOWLEDGE_SNIPPETS_BIND_ADDRESS`). Aucun port de déploiement n'est choisi par le code. Les seules routes matérialisées par la fondation sont `/` et `/healthz`; cela ne fixe aucune convention future pour l'authentification ou l'administration.
@@ -204,9 +191,7 @@ Les trois launchers MUST recevoir leur socket de bind par configuration (`KNOWLE
### Politique `Cargo.lock`
PGR `v0.1.1` exige une décision explicite de lockfile selon le type de produit et le besoin de reproductibilité ; il n'impose pas universellement le versionnement de `Cargo.lock`.
Knowledge sélectionne localement la politique suivante :
Knowledge possède localement la politique de lockfile suivante :
```text
Cargo.lock généré localement par Cargo
@@ -220,7 +205,7 @@ Cette décision ne s'applique pas au frontend npm : `Web/knowledge-template-lab/
### Layout des tests
Knowledge sélectionne localement la convention `unit_tests/` séparée que PGR `0.1.1` autorise sans l'imposer globalement.
Knowledge sélectionne localement la convention `unit_tests/` séparée.
Pour toutes les crates Rust de ce workspace :
@@ -239,17 +224,15 @@ Exemple :
mod tests;
```
Cette convention locale est plus stricte que le `MAY` générique de PGR, mais reste conforme à celui-ci. Si PGR doit l'imposer à tous les futurs workspaces, cette évolution appartient à une version ultérieure du référentiel PGR et non à Knowledge.
Le préfixe de crate retenu est `knowledge-`.
Les responsabilités candidates sont documentées dans l'architecture. Une crate n'est matérialisée que lorsqu'elle possède une responsabilité réelle. Le suffixe `-api` n'est utilisé que pour une frontière passive dont des implémentations distinctes/remplaçables sont réellement prévues.
`alpha.3` matérialise ainsi `knowledge-git-api` pour la frontière `GitRepository` et `knowledge-sync-api` pour la frontière `RepositoryEventSource`. Ces crates restent passives, sans runtime ni logging propre, et dépendent seulement des types de domaine nécessaires. Les implémentations Git, hooks, polling, webhooks ou forge restent hors de ces crates de contrat.
Le contrat Rust strict retenu par Knowledge s'applique aux crates matérialisées, notamment Rust 2024, `unsafe` interdit par défaut, lints stricts, exports publics maîtrisés et chemins intra-crate explicites via la façade crate-root. `alpha.4` doit vérifier que l'ensemble des obligations réellement nécessaires de ce contrat est possédé localement sans devoir relire PGR.
Le contrat Rust strict est possédé par [`docs/rules/510-RUST_CARGO.md`](docs/rules/510-RUST_CARGO.md). Pour toutes les crates bibliothèque, `src/lib.rs` reste une façade de documentation, modules et réexports ; les définitions de production résident dans des modules nommés selon leur responsabilité. Les crates `knowledge-git-api` et `knowledge-sync-api` appliquent ce contrat à partir de `0.0.2-alpha.4` sans changer leur API crate-root.
Les audits read-only sélectionnés et possédés localement avec les premiers contrats publics sont `audit_rust_blank_lines.py`, `audit_rust_item_spacing.py`, `audit_rust_module_order.py`, `audit_rust_trait_import_blocks.py`, `audit_rust_reexport_blocks.py` et `audit_rust_export_completeness.py`. L'audit `const` n'est pas sélectionné globalement : il reste opt-in par fichier lorsqu'un ordre mécanique de constantes est réellement approprié.
Les audits Rust read-only possédés localement incluent `audit_rust_blank_lines.py`, `audit_rust_item_spacing.py`, `audit_rust_module_order.py`, `audit_rust_trait_import_blocks.py`, `audit_rust_reexport_blocks.py`, `audit_rust_crate_root_facades.py` et `audit_rust_export_completeness.py`. L'audit `const` n'est pas sélectionné globalement : il reste opt-in uniquement si un ordre mécanique de constantes devient réellement approprié.
## Secrets et configuration locale