0.0.2-alpha.4

docs/rules/000-README.md

@@ -0,0 +1,25 @@
+<!-- file: docs/rules/000-README.md -->
+<!-- version: 1 -->
+
+# Règles locales Knowledge
+
+## Rôle
+
+Ce répertoire contient les owners normatifs durables nécessaires au développement de `sasedev-knowledge` après l'adoption ponctuelle de PGR `v0.1.3`.
+
+Ces documents sont autonomes. Leur lecture ne nécessite pas d'ouvrir le dépôt PGR. Les numéros d'owner conservent une continuité de provenance lorsque cela reste utile, mais le texte local Knowledge est désormais autoritaire pour ce projet.
+
+## Owners actifs
+
+- [`200-GOVERNANCE.md`](200-GOVERNANCE.md) — autorité de baseline, décisions, adoption externe explicite et autonomie normative.
+- [`210-WORKFLOW.md`](210-WORKFLOW.md) — plan, delta, gate opérateur, history, commit/push, fix et handoff.
+- [`300-DOCUMENTATION.md`](300-DOCUMENTATION.md) — rôles documentaires, headers, plans, prompts et historique.
+- [`400-VALIDATION.md`](400-VALIDATION.md) — preuves proportionnées, statuts et autorité opérateur.
+- [`510-RUST_CARGO.md`](510-RUST_CARGO.md) — workspace Rust/Cargo strict, façade crate-root, tests et audits.
+- [`530-WEB_FRONTEND.md`](530-WEB_FRONTEND.md) — TypeScript, npm, Vite, Sass, Bootstrap et contrat template/Maud.
+
+Le mapping d'adoption qui explique pourquoi ces owners existent et quels owners PGR n'ont pas été matérialisés localement est conservé dans [`../architecture/003-PGR_ADOPTION_MAP.md`](../architecture/003-PGR_ADOPTION_MAP.md).
+
+## Priorité
+
+[`../../RULES.md`](../../RULES.md) reste le point d'entrée normatif du dépôt et possède les décisions produit spécifiques. Les owners de ce répertoire détaillent les contrats transverses. Une règle plus spécifique au produit ou à une architecture concrète prime dans son scope lorsqu'elle est explicitement documentée.

docs/rules/200-GOVERNANCE.md

@@ -0,0 +1,122 @@
+<!-- file: docs/rules/200-GOVERNANCE.md -->
+<!-- version: 1 -->
+
+# Gouvernance locale Knowledge
+
+## Principe
+
+La gouvernance de Knowledge sert la qualité, la reprise et la réduction du risque. Elle reste proportionnée au changement : une règle ou une gate doit apporter une preuve, protéger un contrat ou rendre une décision durable ; elle ne doit pas exister uniquement pour ajouter de la cérémonie.
+
+## Baseline autoritaire
+
+Une version ou tranche Knowledge part des artefacts Knowledge réellement autoritaires : archive/tag ou workspace établi, `VERSION`, règles locales, architecture, plan actif, deltas/histories et preuves opérateur disponibles.
+
+Une conversation antérieure, une copie non vérifiée ou une version plus récente d'un référentiel externe ne remplace jamais cette baseline.
+
+## Autonomie normative et provenance PGR
+
+Knowledge est autonome après adoption. PGR `v0.1.3` est la provenance de la réconciliation effectuée pendant `0.0.2`, pas une dépendance normative vivante.
+
+Une nouvelle version, session ou tranche Knowledge MUST NOT rechercher ou charger automatiquement une nouvelle stable PGR. Une comparaison PGR ne peut commencer que si une réévaluation/adoption PGR est explicitement inscrite au scope.
+
+Lors d'une telle réévaluation, les décisions sont classifiées `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis les changements retenus sont adaptés et matérialisés dans Knowledge avant fermeture de l'adoption.
+
+## Autorité locale et priorité
+
+L'ordre d'autorité normal est :
+
+```text
+contrat spécifique de tranche/release établi
+-> RULES.md et owners locaux docs/rules/
+-> architecture, plan et validation locaux
+-> provenance externe uniquement pour expliquer une adoption explicitement engagée
+```
+
+Un owner externe n'est jamais appliqué implicitement parce qu'il porte un numéro identique ou une version plus récente.
+
+## Version canonique
+
+`VERSION` contient exactement l'identité SemVer courante de la release Knowledge, sans préfixe `v`. `[workspace.package].version` est un miroir exact de `VERSION` pour le workspace Rust.
+
+Les autres numéros restent indépendants lorsque leur sémantique l'exige : révision documentaire, lockfile/package, format ou compteur technique. Une égalité de version n'est jamais imposée uniquement parce que deux champs contiennent un numéro.
+
+Le lifecycle Knowledge utilise :
+
+```text
+X.Y.Z-alpha.N
+X.Y.Z-alpha.N.fix.M
+X.Y.Z-beta.N
+X.Y.Z-beta.N.fix.M
+X.Y.Z-rc.N
+X.Y.Z-rc.N.fix.M
+X.Y.Z
+```
+
+`N` et `M` commencent à `1`. Le tag stable est `vX.Y.Z`. `rel.N` nomme une tranche de clôture et n'est pas une version produit SemVer ; sa forme canonique n'utilise pas de zéro de padding (`rel.1`).
+
+## Rôle des phases
+
+### Alpha
+
+L'alpha porte cadrage, implémentation et changements de scope encore attendus. `alpha.1` sert de gate de cadrage de la release : baseline, règles, mission/plan, décisions ouvertes, risques, stratégie de validation et dimensionnement des tranches doivent être vérifiés avant l'implémentation lourde.
+
+Une durée de l'ordre de 15 à 30 minutes peut aider au découpage, mais n'est ni une deadline ni un quota.
+
+### Beta
+
+La beta sert principalement à stabiliser et réconcilier un scope déjà établi. Une expansion fonctionnelle importante exige un REPLAN explicite.
+
+### Release candidate
+
+La RC gèle le scope sauf corrections nécessaires à la validation. Elle porte la gate complète de candidate. Un changement fonctionnel important découvert en RC retourne vers une phase adaptée ou déclenche un REPLAN ; il n'est pas masqué dans un simple fix.
+
+### Stable
+
+La promotion vers `X.Y.Z` doit être proche d'une opération mécanique après une RC propre, tout en exécutant la gate spécifique aux métadonnées/documents/artefacts de promotion.
+
+Pour la clôture stable :
+
+```text
+rel.1 FAIL / PARTIAL / BLOCKED       -> commit X.Y.Z-rel.1
+rel.1.fix.1 FAIL / PARTIAL / BLOCKED -> commit X.Y.Z-rel.1.fix.1
+première clôture réellement PASS     -> commit X.Y.Z
+```
+
+Le commit `X.Y.Z` inclut le history qui établit le `PASS` stable. Le tag `vX.Y.Z` est créé seulement après ce commit. La vérification de l'archive/tag publiée est une preuve post-tag distincte.
+
+## Correctifs de tranche
+
+Un `.fix.M` corrige uniquement la tranche immédiatement concernée. Il conserve son scope fonctionnel et peut corriger code, configuration, documentation, validation ou packaging nécessaires à cet objectif.
+
+Un fix ne doit pas introduire silencieusement une nouvelle fonctionnalité ou un nouveau chantier. Son compteur repart à `1` pour chaque tranche.
+
+À partir de `.fix.3`, une revue du diagnostic et du plan est obligatoire afin de décider explicitement si la poursuite du fix reste appropriée ou si un REPLAN est préférable.
+
+## REPLAN
+
+Un REPLAN est une décision de pilotage, pas un suffixe SemVer. Il s'applique lorsque le plan ne décrit plus correctement la réalité : dépendance inattendue, responsabilité transverse, architecture, risque, volume ou ordre des tranches significativement modifié.
+
+La conclusion d'un REPLAN doit être explicite :
+
+```text
+CONTINUE
+SPLIT
+CONTINUE-NEXT-SESSION
+ABANDON
+```
+
+Une coupure de conversation ou de session ne crée jamais à elle seule une nouvelle version ou une nouvelle tranche. Le même état continue tant que le scope reste valide.
+
+## Abandon et supersession
+
+Une version ou prerelease commencée n'est pas forcée vers stable pour préserver une séquence esthétique. En cas d'abandon ou supersession, l'état et la raison sont documentés, les preuves et décisions utiles sont conservées, et la version déjà consommée reste dans l'historique.
+
+## Décisions différées
+
+Une décision `DEFER` reste indécise jusqu'à son déclencheur réel. Elle n'est pas remplacée par une valeur arbitraire issue d'un exemple, d'un autre projet ou d'un référentiel externe.
+
+Les décisions différées structurantes restent dans le profil/architecture Knowledge et ne sont reprises que par un scope explicite ou un REPLAN.
+
+## Immutabilité historique
+
+Les artefacts historiques restent historiques. Une nouvelle règle s'applique à partir de son adoption et ne réécrit pas deltas, histories, prompts ou décisions anciennes uniquement pour simuler une conformité rétroactive.

docs/rules/210-WORKFLOW.md

@@ -0,0 +1,123 @@
+<!-- file: docs/rules/210-WORKFLOW.md -->
+<!-- version: 1 -->
+
+# Workflow local Knowledge
+
+## Unité de travail
+
+`VERSION` est l'identité canonique de la tranche courante. Une tranche est livrée par un delta, validée dans l'environnement opérateur, puis clôturée par un history qui enregistre l'observation réelle.
+
+Le cycle normal est :
+
+```text
+delta
+-> application opérateur
+-> gate applicable
+-> résultat PASS / FAIL / PARTIAL / BLOCKED
+-> history observé
+-> application du history
+-> git add / diff --cached --check / status
+-> commit
+-> push
+-> tranche suivante ou fix
+```
+
+Le delta suivant ne doit pas être appliqué avant matérialisation Git du history précédent.
+
+## Chemins et archives canoniques
+
+Les contrats de tranche vivent sous :
+
+```text
+deltas/<X.Y.Z>/<tranche>.md
+history/<X.Y.Z>/<tranche>.md
+```
+
+Les archives échangées sont séparées :
+
+```text
+sasedev-knowledge-<X.Y.Z>-<tranche>.delta.zip
+sasedev-knowledge-<X.Y.Z>-<tranche>.history.zip
+```
+
+Un history n'est jamais inclus dans le delta qu'il valide. Le delta suivant peut être livré dans la même réponse que le history précédent lorsque sa préparation est déjà déterminée, mais son application reste postérieure au commit/push du history.
+
+## Contrat d'un delta
+
+Un delta contient des fichiers complets à ajouter ou remplacer. Les suppressions éventuelles sont explicites via un manifeste de suppression lorsque le mécanisme d'application l'exige ; elles ne reposent pas sur une instruction manuelle ambiguë.
+
+Le document de delta indique au minimum :
+
+- baseline requise et version obtenue ;
+- mission et scope ;
+- fichiers/contrats réellement concernés ;
+- hors-scope et décisions différées pertinentes ;
+- gate opérateur reproductible ;
+- transition autorisée après chaque statut attendu.
+
+Un delta doit être applicable sans reconstruire à la main des patchs depuis une conversation.
+
+## Contrat d'un history
+
+Aucun history `PASS` n'est créé avant réception des preuves opérateur réelles. Une prévalidation de génération peut détecter des erreurs, mais ne constitue jamais le résultat autoritaire de la tranche.
+
+Le history enregistre au minimum :
+
+- tranche et baseline observées ;
+- statut `PASS / FAIL / PARTIAL / BLOCKED` ;
+- preuves réellement exécutées et leurs résultats utiles ;
+- anomalies/limites pertinentes ;
+- décision de transition.
+
+Un history appliqué et committé devient immuable. Un futur fix crée son propre history ; il ne remplace pas le résultat précédent.
+
+## Plans et REPLAN
+
+Une release multi-responsabilités possède un plan versionné. Le plan décrit mission, état acquis, scope, hors-scope, validation, trajectoire prévisionnelle, déclencheurs de REPLAN, clôture/transition et revue d'horizon lorsque pertinente.
+
+Les tranches de la trajectoire sont des sous-sections `###` de `## Trajectoire prévisionnelle`.
+
+Un REPLAN modifie uniquement les parties devenues fausses ou insuffisantes. Les deltas/histories gardent la chronologie détaillée ; le plan reste un document de pilotage vivant et non un journal de terminal.
+
+## Fixes
+
+Un `FAIL`, `PARTIAL` ou `BLOCKED` est conservé. Une correction bornée au même scope utilise `.fix.N`. Le history en échec est appliqué, committé et poussé avant le fix.
+
+Un fix ne doit pas absorber silencieusement une nouvelle fonctionnalité. Si le diagnostic révèle une responsabilité transverse ou une mission différente, le plan est replanifié explicitement.
+
+## Handoff opérateur
+
+Après livraison d'un history, les commandes de matérialisation Git sont fournies automatiquement. Pour `origin/master` établi dans ce dépôt, une tranche non stable suit normalement :
+
+```bash
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "<VERSION>"
+git push origin master
+git status --short
+```
+
+Les commandes ne sont pas différées à une réponse ultérieure. Lorsque le delta suivant est prêt, son application est indiquée après ce bloc afin que l'ordre soit sans ambiguïté.
+
+## Prompts et changement de session
+
+Un prompt de démarrage versionné décrit la baseline exacte, les sources requises, la mission et les vérifications nécessaires pour ouvrir une release. Il ne complète pas silencieusement des données manquantes par un état supposé d'une conversation ou d'un workspace non vérifié.
+
+Une coupure de session au milieu d'une tranche ne change pas `VERSION`. Si nécessaire, un handoff local décrit l'état exact, les décisions acquises, les preuves déjà obtenues et ce qui reste à exécuter.
+
+Le pattern normal de nouvelle session est [`../templates/001-NEW_SESSION_PROMPT.md`](../templates/001-NEW_SESSION_PROMPT.md).
+
+## Stable et publication
+
+La première clôture `rel.N[/fix.M]` réellement `PASS` est committée avec le message produit `X.Y.Z`; les clôtures échouées conservent leur identifiant de tranche dans le message de commit conformément à la gouvernance locale.
+
+Le tag stable `vX.Y.Z` est créé seulement après le commit stable. L'archive téléchargée depuis ce tag est la baseline de publication autoritaire ; l'absence de `.git` dans cette archive est normale.
+
+Le rapport post-tag `sasedev-knowledge-X.Y.Z-publish.001-report.md` est une preuve distincte. Il vérifie le tag/archive réellement publiés et ne doit pas être préfabriqué comme preuve du delta `rel.1`.
+
+Le prompt d'une release suivante n'est préparé que si sa mission est réellement décidée. Aucune version future n'est inventée pour remplir un handoff.
+
+## Immutabilité des artefacts historiques
+
+Les deltas, histories et prompts déjà committés ne sont pas réécrits pour adopter une convention plus récente, corriger une esthétique ou masquer un échec passé. Une correction de contrat durable s'applique aux artefacts futurs et est documentée chez son owner local.

docs/rules/300-DOCUMENTATION.md

@@ -0,0 +1,93 @@
+<!-- file: docs/rules/300-DOCUMENTATION.md -->
+<!-- version: 1 -->
+
+# Documentation locale Knowledge
+
+## Langue et identités
+
+Les noms techniques, chemins, fichiers, crates, identifiants et code sont en anglais. La documentation normative et explicative principale est en français.
+
+Chaque fichier Markdown gouverné par Knowledge commence par :
+
+```text
+<!-- file: <chemin relatif exact> -->
+<!-- version: <entier positif> -->
+```
+
+La révision documentaire augmente lorsqu'un contenu réel du fichier change ; elle n'est pas un compteur global de release et ne doit pas être synchronisée mécaniquement avec `VERSION`.
+
+## Rôle des documents racine
+
+`README.md` est une entrée de projet : identité, état utile, démarrage et liens vers les owners. Il ne devient pas une copie complète des règles ou de l'architecture.
+
+`RULES.md` est l'entrée normative locale et renvoie vers les owners détaillés sous `docs/rules/`.
+
+`ROADMAP.md` décrit les objectifs et horizons produits réellement engagés. Il ne sert ni de journal quotidien ni de catalogue exhaustif des prereleases. Une version future n'y est pas réservée sans mission réelle.
+
+`CHANGELOG.md` synthétise les changements utiles aux jalons de release. Les fixes et essais alpha internes ne sont pas transformés en catalogue exhaustif lorsque leur détail appartient déjà aux deltas/histories.
+
+`docs/000-README.md` indexe la documentation durable et fournit le chemin de lecture principal.
+
+## Familles documentaires
+
+Knowledge distingue :
+
+```text
+RULES / docs/rules   contrat normatif local
+docs/architecture   architecture et décisions structurantes
+docs/studies        analyse avant décision ou réconciliation
+docs/plans          pilotage vivant d'une release multi-tranches
+docs/validation     matrices, critères et contrats de preuve
+docs/templates      patterns locaux réutilisables
+prompts              handoff versionné d'ouverture d'une release
+deltas               contrat d'une tranche à appliquer
+history              résultat réellement observé d'une tranche
+```
+
+Un delta/history ne remplace pas la documentation durable. Une décision structurante acquise finit chez son owner durable lorsqu'elle doit gouverner la suite.
+
+## Documents vivants et historiques
+
+`RULES.md`, `docs/rules/`, l'architecture, la roadmap et un plan actif sont des documents vivants : ils évoluent lorsque leur contrat actuel change.
+
+`deltas/`, `history/` et les prompts de releases passées sont historiques après commit. Ils ne sont pas réécrits uniquement pour se conformer à une nouvelle convention apparue plus tard.
+
+Une étude terminée peut rester historique tout en étant référencée depuis la décision durable qu'elle a permis d'établir.
+
+## Plans
+
+Un plan actif contient au minimum, lorsque pertinent : statut/sources, mission, état acquis/questions ouvertes, scope, hors-scope, stratégie de validation, trajectoire prévisionnelle, déclencheurs de REPLAN, clôture/transition et revue d'horizon.
+
+Les phases prévisionnelles se trouvent sous `## Trajectoire prévisionnelle` et utilisent des headings `###`.
+
+Le plan est mis à jour lorsqu'une hypothèse de pilotage devient fausse, pas pour recopier chaque sortie de commande. Les preuves détaillées appartiennent aux histories.
+
+## Revue d'horizon
+
+Lorsqu'une release approche de sa stabilisation et que la suite n'est pas déjà décidée, une revue d'horizon explicite détermine s'il faut engager une prochaine mission, maintenir les domaines futurs non numérotés ou reclasser un `DEFER`.
+
+La revue n'invente pas un numéro de version uniquement pour assurer la continuité documentaire.
+
+## Prompts de nouvelle session
+
+Un prompt normal Knowledge repart de la stable Knowledge, de son rapport post-tag lorsqu'il existe, puis du prompt versionné local. Il vérifie les artefacts Knowledge locaux avant de préparer la tranche suivante.
+
+Il MUST NOT demander de rechercher ou charger PGR ou un autre référentiel externe, sauf lorsque cette release contient explicitement une réévaluation/adoption de ce référentiel.
+
+Le pattern local est [`../templates/001-NEW_SESSION_PROMPT.md`](../templates/001-NEW_SESSION_PROMPT.md).
+
+## Templates
+
+Les templates locaux sont des patterns adaptables, pas des documents normatifs à recopier aveuglément. L'owner normatif reste la règle locale correspondante ; un template sert à réduire les omissions lors de la création d'un nouvel artefact.
+
+## Liens, tables et audits
+
+Les liens Markdown locaux doivent pointer vers des cibles existantes. Les tables source doivent rester syntaxiquement cohérentes. Les arbres générés (`.git`, `node_modules`, `target`, `builds`) n'appartiennent pas au corpus documentaire gouverné.
+
+Les audits Markdown locaux sont read-only :
+
+```text
+scripts/audit_markdown_headers.py
+scripts/audit_markdown_links.py
+scripts/audit_markdown_tables.py
+```

docs/rules/400-VALIDATION.md

@@ -0,0 +1,103 @@
+<!-- file: docs/rules/400-VALIDATION.md -->
+<!-- version: 1 -->
+
+# Validation locale Knowledge
+
+## Principe
+
+Une tranche sélectionne ses preuves à partir du scope modifié, des contrats potentiellement invalidés et du risque réel. La validation est proportionnée : elle ne rejoue pas mécaniquement toutes les commandes disponibles lorsque celles-ci n'apportent aucune preuve nouvelle.
+
+La matrice canonique est [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-VALIDATION_MATRIX.md).
+
+## Statuts
+
+Les statuts reconnus sont :
+
+```text
+PASS     toutes les preuves requises ont réussi
+FAIL     au moins une preuve requise a échoué
+PARTIAL  seules certaines preuves requises ont été acquises
+BLOCKED  un prérequis externe empêche d'exécuter une preuve requise
+```
+
+Un statut incomplet ne devient jamais implicitement `PASS`.
+
+## Autorité de la gate
+
+La gate opérateur exécutée dans l'environnement autoritaire possède le statut de tranche. Une prévalidation par assistant, génération locale ou CI supplémentaire peut réduire le risque de livraison mais ne remplace pas cette gate.
+
+Une commande qui échoue dans la gate reste un `FAIL` même si des tests exécutés ensuite passent. Les preuves positives sont conservées dans le diagnostic mais ne neutralisent pas l'échec requis.
+
+## Catégories de preuve
+
+Les gates peuvent combiner, selon le scope :
+
+```text
+FORMAT       état produit par le formatter officiel
+AUDIT        contrat structurel read-only non possédé par l'outil officiel
+CHECK        compilation/typecheck/manifest sans production nécessaire d'artefact
+LINT         politique statique stricte
+TEST         comportement ciblé ou workspace
+BUILD        production d'un artefact réellement nécessaire
+SMOKE        preuve d'intégration/processus/frontière runtime
+PACKAGE      layout ou archive de livraison
+PUBLISH      tag/archive/remote effectivement publiés
+```
+
+Une catégorie n'est pas ajoutée pour remplir un quota ; elle doit protéger une propriété affectée par la tranche.
+
+## Niveau de preuve
+
+Une propriété est vérifiée au niveau le plus fiable et le moins redondant disponible :
+
+```text
+compilateur / langage
+-> outil officiel ou linter
+-> manifest / build system
+-> audit structurel read-only
+-> test comportemental
+-> smoke d'intégration lorsque l'environnement le nécessite
+```
+
+Une règle qualitative qui exige du jugement humain reste une revue plutôt qu'une regex fragile créée uniquement pour automatiser.
+
+## Tests
+
+Les tests ciblés sont privilégiés pour le scope directement modifié. Les tests workspace sont utilisés lorsqu'un contrat transverse, un changement de structure ou une phase de consolidation peut invalider plusieurs composants.
+
+Les tests unitaires doivent rester indépendants d'Internet et de services externes non contrôlés. Un test d'intégration réel peut utiliser des ressources locales isolées et temporaires lorsqu'il prouve une frontière que des fakes ne démontrent pas correctement.
+
+Un test ne modifie pas l'API produit uniquement pour faciliter son accès à des détails internes.
+
+## Audits
+
+Les audits locaux sont read-only et monotâches autant que raisonnable. Ils contrôlent une propriété du dépôt que le compilateur, rustfmt, Clippy, Cargo, TypeScript, npm ou Vite ne possède pas déjà de manière fiable.
+
+Un audit ne doit pas analyser les caches et dépendances générés comme s'ils faisaient partie du source gouverné. Les scripts Markdown locaux ignorent notamment `.git`, `node_modules`, `target` et `builds`.
+
+Lorsqu'un audit lexical rencontre un cas que son modèle ne sait pas interpréter sans heuristique fragile, la propriété revient à l'outil officiel ou à une revue humaine plutôt qu'à un faux positif permanent.
+
+## Ordre normal
+
+Pour une tranche Rust transverse, la séquence habituelle est :
+
+```text
+format
+-> audits structurels applicables
+-> cargo check / metadata utile
+-> clippy strict
+-> tests ciblés
+-> tests workspace si justifiés
+-> smokes/builds/packages seulement si le scope les invalide
+-> git diff --cached --check / status
+```
+
+Pour une tranche Web, les preuves npm/typecheck/build sont ajoutées lorsque `Web/` ou son contrat d'intégration est touché. Une tranche documentaire ou Rust sans diff Web ne rejoue pas automatiquement le frontend.
+
+## Régression et dette externe
+
+Un warning provenant d'une dépendance tierce n'est pas automatiquement un `FAIL` si la gate locale ne le traite pas comme tel et si l'outil termine avec succès. Il doit toutefois être reclassé si une mise à jour de toolchain le transforme en rupture réelle ou si la release cible exige zéro warning sur cette frontière.
+
+## Traçabilité
+
+Chaque delta liste sa gate exécutable et la matrice conserve le contrat durable. Le history enregistre les résultats réellement observés ; il ne résume pas une prévalidation comme si elle avait été exécutée par l'opérateur.

docs/rules/510-RUST_CARGO.md

@@ -0,0 +1,79 @@
+<!-- file: docs/rules/510-RUST_CARGO.md -->
+<!-- version: 1 -->
+
+# Rust / Cargo local Knowledge
+
+## Toolchain et workspace
+
+Knowledge utilise Rust stable, édition 2024 et un workspace Cargo à train de release unique. `[workspace.package].version` suit `VERSION` et les crates membres héritent de la version commune.
+
+Aucun `rust-toolchain.toml` n'est ajouté sans besoin réel de reproductibilité ou de compatibilité. Les artefacts Cargo sont dirigés hors de l'arborescence source par la configuration locale lorsque possible.
+
+`Cargo.lock` est généré localement, ignoré et non versionné pour ce workspace. Cette politique ne s'applique pas au lockfile npm.
+
+## Nomenclature et responsabilités
+
+Les crates utilisent le préfixe `knowledge-`. Les suffixes portent un contrat :
+
+```text
+-api     frontière passive de contrats réutilisables/remplaçables
+-lib     implémentation ou fonctionnalité réutilisable
+-server  launcher/processus mince
+```
+
+Une crate n'est pas créée par symétrie. Une `-api` ne contient ni runtime, ni logging imposé, ni implémentation de provider. Un launcher ne duplique pas une logique qui possède un owner bibliothèque commun.
+
+## Façade crate-root
+
+Pour toute crate bibliothèque Knowledge, `src/lib.rs` est une façade de crate. Il contient la documentation de crate, les déclarations de modules, les réexports publics/internes nécessaires et, lorsque pertinent, le rattachement conditionnel des tests.
+
+Les `struct`, `enum`, `trait`, fonctions, implémentations et autres définitions de comportement appartiennent à des modules nommés selon leur responsabilité. Une petite crate n'est pas artificiellement éclatée en nombreux fichiers : un seul module de responsabilité peut suffire, mais les définitions ne s'accumulent pas dans `lib.rs`.
+
+Les crates `-api` nomment leurs modules par le contrat réel (`reference`, `revision`, `snapshot`, `repository`, `signal`, etc.) plutôt que par un générique `api.rs` sans ownership.
+
+Les consommateurs externes utilisent la façade `owner_crate::Item`. Les références intra-crate vers des items partagés passent par `crate::Item` afin de garder une identité stable indépendante du module propriétaire.
+
+`scripts/audit_rust_crate_root_facades.py` contrôle que les crate-roots de bibliothèque restent des façades sans définitions top-level de production.
+
+## Safety, erreurs et contrôle de flux
+
+`unsafe` est interdit par défaut. Les lints workspace stricts restent autoritaires.
+
+Le code de production ne doit pas utiliser `unwrap`, `expect`, `panic!` ou l'opérateur `?` lorsque les lints locaux les interdisent. Les erreurs récupérables sont propagées explicitement avec le type d'erreur possédé par la couche concernée.
+
+Les retours explicites exigés par la politique Clippy locale sont conservés, y compris dans les closures lorsque le lint `implicit_return` s'applique.
+
+## Imports, modules et réexports
+
+Les `use` non exportés sont réservés aux imports réellement nécessaires, notamment les traits. Les modules de production précèdent les modules de tests conditionnels et suivent un ordre déterministe lorsqu'aucune sémantique ne l'interdit.
+
+Les réexports crate-root restent groupés par visibilité. La façade publique doit être complète pour les items partagés et les modules propriétaires restent privés sauf besoin architectural explicite.
+
+## Tests
+
+Les tests unitaires résident sous `unit_tests/` à la racine de chaque crate et sont rattachés depuis le module source correspondant. Les tests d'intégration Cargo résident sous `tests/` et consomment l'API publique.
+
+Les tests ne rendent pas l'API produit plus visible uniquement pour accéder à des détails internes.
+
+## Formatage et audits
+
+La séquence normale d'un changement Rust pertinent inclut :
+
+```bash
+cargo fmt --all
+cargo fmt --all -- --check
+python3 -B scripts/audit_rust_test_layout.py crates
+python3 -B scripts/audit_rust_blank_lines.py crates
+python3 -B scripts/audit_rust_item_spacing.py crates
+python3 -B scripts/audit_rust_module_order.py crates
+python3 -B scripts/audit_rust_trait_import_blocks.py crates
+python3 -B scripts/audit_rust_reexport_blocks.py crates
+python3 -B scripts/audit_rust_crate_root_facades.py crates
+python3 -B scripts/audit_rust_export_completeness.py --root . --summary-only
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Les tests ciblés sont sélectionnés selon le scope. `cargo test --workspace --all-targets --all-features` est utilisé pour les changements transverses et les phases de consolidation.
+
+L'audit mécanique des blocs `const` n'est pas sélectionné globalement par Knowledge : l'ordre de constantes peut être sémantique. Il ne sera ajouté localement que si un besoin réel et un corpus approprié le justifient.

docs/rules/530-WEB_FRONTEND.md

@@ -0,0 +1,57 @@
+<!-- file: docs/rules/530-WEB_FRONTEND.md -->
+<!-- version: 1 -->
+
+# Frontend Web local Knowledge
+
+## Scope
+
+Cet owner regroupe les contrats Web réellement utilisés par Knowledge : TypeScript, npm, Vite, Sass, Bootstrap et l'articulation entre le template statique de référence et le rendu runtime Maud.
+
+Il remplace, pour le développement courant de Knowledge, la nécessité de relire plusieurs profils Web externes séparés.
+
+## Package et dépendances
+
+Le package de référence est `Web/knowledge-template-lab/` et utilise npm. `package.json` possède les scripts explicites `typecheck`, `dev`, `build` et `preview` nécessaires au workflow courant.
+
+`package-lock.json` est versionné. `node_modules/`, caches Vite et sorties de build restent générés et hors Git.
+
+Les versions de dépendances sont décidées dans le package Knowledge ; aucune version externe n'est adoptée automatiquement parce qu'un template ou référentiel plus récent existe.
+
+## TypeScript
+
+Le frontend utilise TypeScript strict. Le typecheck doit couvrir le code applicatif et la configuration Vite selon les `tsconfig` locaux.
+
+Une dépendance de types n'est ajoutée que lorsqu'elle est réellement nécessaire à l'IDE, au compilateur ou au package consommé.
+
+## Vite
+
+`vite.config.ts` est le propriétaire de `root`, `base`, cache, dev server, preview, outputs et manifest. Les caches et builds sont dirigés vers les outputs Knowledge hors source.
+
+Le build de production doit générer un manifest machine-readable et conserver l'entrée stable `src/main.ts`. Les noms d'assets hashés ne sont pas codés en dur dans le backend Rust.
+
+## Sass et Bootstrap
+
+Sass est la chaîne de styles sélectionnée et Bootstrap est un choix local Knowledge. Les warnings de dépréciation provenant d'une dépendance tierce sont suivis comme dette/compatibilité mais ne deviennent bloquants que si la gate locale l'exige ou s'ils annoncent une rupture effective de la toolchain retenue.
+
+## Template statique et Maud
+
+Le template sous `Web/knowledge-template-lab/` sert de harness de conception et de validation. Il ne constitue pas une seconde implémentation runtime.
+
+Le markup de production est rendu par `knowledge-web-lib` avec Maud. L'adaptation depuis le template doit préserver les contrats utiles de structure, classes, attributs et assets.
+
+En développement, `KNOWLEDGE_VITE_DEV_ORIGIN` fournit l'origin Vite. En production, `KNOWLEDGE_VITE_MANIFEST_PATH` désigne le manifest et `KNOWLEDGE_ASSET_BASE_PATH` peut remplacer le préfixe public.
+
+## Validation
+
+Lorsqu'un changement touche le package Web ou son contrat d'intégration, la preuve normale est :
+
+```bash
+(
+  cd Web/knowledge-template-lab
+  npm ci
+  npm run typecheck
+  npm run build
+)
+```
+
+Les smokes Actix/Maud pertinents sont ajoutés lorsqu'un changement touche réellement le runtime ou la résolution d'assets. Une tranche exclusivement documentaire ou Rust sans diff Web ne rejoue pas automatiquement le build frontend si aucune preuve n'est invalidée.