0.0.3-rel.1

This commit is contained in:
2026-09-29 18:54:33 +02:00
parent 0351aa045e
commit 9a1f73d57b
10 changed files with 295 additions and 23 deletions

View File

@@ -1,11 +1,11 @@
<!-- file: CHANGELOG.md -->
<!-- version: 17 -->
<!-- version: 18 -->
# Changelog SaseDev Knowledge
Ce fichier décrit les changements utiles des releases publiées. Les détails de tranches et preuves opérateur appartiennent aux plans, deltas et histories.
## 0.0.3 (candidate)
## 0.0.3
- ajoute un contrat Git d'écriture provider-neutral distinct de `GitRepository`, afin que les consommateurs lecture seule n'acquièrent aucune obligation d'écriture ;
- valide les chemins de mutation, l'identité de commit, les branches `refs/heads/...` et l'état distant attendu avant toute opération backend ;

View File

@@ -1,5 +1,5 @@
# file: Cargo.toml
# version: 38
# version: 39
[workspace]
resolver = "3"
@@ -16,7 +16,7 @@ members = [
]
[workspace.package]
version = "0.0.3-rc.1.fix.1"
version = "0.0.3"
edition = "2024"
publish = false
repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge"

View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 24 -->
<!-- version: 25 -->
# SaseDev Knowledge
@@ -13,7 +13,7 @@ La version courante est définie par [`VERSION`](VERSION).
`0.0.1` est la première stable de fondation de SaseDev Knowledge. `0.0.2` est la stable du chemin Git générique de lecture, de l'autonomie normative locale et du cas d'usage partagé de synchronisation `Changed` / `Unchanged`.
`0.0.3-rc.1.fix.1` est le correctif de validation de la release candidate du chemin Git générique complet : lecture/snapshot, création d'un commit candidat isolé, puis push compare-and-exchange protégé par `--force-with-lease` contre l'état distant explicitement attendu. Une branche peut être créée uniquement lorsque son absence est attendue ; toute divergence devient un conflit récupérable sans écrasement silencieux. Le scope reste gelé : `rc.1` a passé les preuves Rust, Git, Web et runtime mais sa gate a échoué sur une assertion lexicale trop stricte du statut historique `alpha.1`. Le fix ne modifie aucun produit et corrige uniquement cette vérification avant promotion stable.
`0.0.3` est la stable du chemin Git générique complet en lecture et écriture contrôlée : lecture/snapshot, création d'un commit candidat isolé, mutations confinées, identité explicite puis push compare-and-exchange protégé par `--force-with-lease` contre l'état distant attendu. Une branche peut être créée uniquement lorsque son absence est attendue ; toute divergence devient un conflit récupérable sans écrasement silencieux. Cette stable reste provider-neutral et n'introduit ni forge obligatoire, ni PostgreSQL, ni rebase/merge automatique, ni workflow produit complet de proposition/publication.
`knowledge-git-lib` implémente `knowledge-git-api::GitRepository` pour des sources physiques enregistrées : mirror contrôlé, refresh avec pruning, résolution d'une référence vers un commit et snapshot/worktree détaché adressé par révision. La création locale du candidat d'`alpha.3` reste séparée de cette sémantique de lecture. Les règles nécessaires au développement courant sont désormais possédées localement sous `docs/rules/`, et les futurs prompts Knowledge ne chargent pas PGR sauf réévaluation explicitement engagée. `knowledge-app-lib` compose maintenant refresh, résolution, comparaison avec la révision précédente et préparation de snapshot en un résultat explicite `Changed` / `Unchanged`, sans persister la dernière révision ni matérialiser de scheduler.

View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md -->
<!-- version: 11 -->
<!-- version: 12 -->
# Roadmap SaseDev Knowledge
@@ -14,16 +14,16 @@ Statuts : `( )` engagée/planifiée, `(x)` terminée, `(h)` horizon prévisionne
## Releases livrées
- `(x) 0.0.2` — Git générique et synchronisation de lecture : backend provider-neutral, sources locales/remotes, mirror contrôlé, refresh/résolution de révision, snapshot/worktree de lecture et cas d'usage partagé `Changed` / `Unchanged`, sans forge obligatoire ni persistance PostgreSQL.
- `(x) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture séparé de la lecture, worktree candidat isolé, mutations confinées, commit à identité explicite et mise à jour d'une branche `refs/heads/...` uniquement lorsque son état distant correspond à l'attente fournie ; divergence = conflit récupérable, sans rebase/merge automatique ni forge obligatoire.
## Release en cours
## Release engagée
- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture séparé de la lecture, worktree candidat isolé, mutations confinées, commit à identité explicite et mise à jour d'une branche `refs/heads/...` uniquement lorsque son état distant correspond à l'attente fournie ; divergence = conflit récupérable, sans rebase/merge automatique ni forge obligatoire.
- `( ) 0.0.4` — fondation PostgreSQL partagée : premier schéma réel et migrations, configuration logique persistante des sources, dernière révision synchronisée/indexée et état transversal minimal reconstructible ; Git reste autoritaire pour le contenu publié.
## Horizon produit après 0.0.3
## Horizon produit après 0.0.4
La revue `0.0.3-beta.1` retient `0.0.4` comme prochaine mission si `0.0.3` ferme sa RC/stable sans découverte bloquante. Les versions suivantes restent des horizons : elles explicitent la trajectoire des trois produits Web sans figer prématurément leurs détails.
La revue `0.0.3-beta.1`, confirmée pendant la promotion stable, engage `0.0.4` comme prochaine mission. Les versions suivantes restent des horizons : elles explicitent la trajectoire des trois produits Web sans figer prématurément leurs détails.
- `(h) 0.0.4` — fondation PostgreSQL partagée : premier schéma réel et migrations, configuration logique persistante des sources, dernière révision synchronisée/indexée et état transversal minimal reconstructible ; Git reste autoritaire pour le contenu publié.
- `(h) 0.0.5` — modèles de contenu et projections : corpus réels PGR/HOWTO/snippet, parsing/validation, métadonnées et relations utiles, projection locale lisible depuis Git + PostgreSQL et contrats de lecture nécessaires aux trois façades.
- `(h) 0.0.6` — templates publics des trois sites : développer et valider dans `Web/knowledge-template-lab` les pages de garde, navigation, listes, détails, recherche/filtrage visible et composants partagés pour PGR, HOWTOs et snippets, sans encore faire de ces templates le rendu runtime définitif.
- `(h) 0.0.7` — templates d'administration des trois sites : dashboards et surfaces de gestion propres à PGR, HOWTOs et snippets, formulaires/états de proposition et revue nécessaires au produit, toujours comme références Web validables avant adaptation serveur.

View File

@@ -1 +1 @@
0.0.3-rc.1.fix.1
0.0.3

77
deltas/0.0.3/rel.1.md Normal file
View File

@@ -0,0 +1,77 @@
<!-- file: deltas/0.0.3/rel.1.md -->
<!-- version: 1 -->
# Delta 0.0.3 rel.1 — promotion stable pré-tag
## Baseline et version
Baseline : `0.0.3-rc.1.fix.1`, avec `history/0.0.3/rc.1.fix.1.md` appliqué et committé.
Ce delta MUST NOT être appliqué avant ce commit.
Version avant application :
```text
0.0.3-rc.1.fix.1
```
Version après application :
```text
0.0.3
```
`rel.1` identifie la tranche de clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
## Objet
Promouvoir mécaniquement la candidate corrigée vers la stable `0.0.3` sans rouvrir le scope.
La tranche finalise la version stable, la présentation README/roadmap/changelog, l'index documentaire, le plan historique `0.0.3` et la matrice de validation. Elle engage `0.0.4` comme prochaine mission conformément à la revue d'horizon déjà acquise et conserve le prompt `004` préparé avant clôture.
Aucun fichier Rust, frontend, architecture, étude, règle normative ou prompt n'est modifié.
## Scope
REPLACE :
```text
VERSION
Cargo.toml
README.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
docs/validation/001-VALIDATION_MATRIX.md
```
ADD :
```text
deltas/0.0.3/rel.1.md
```
DELETE : aucun.
Le history `rc.1.fix.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
## Présentation stable attendue
```text
VERSION 0.0.3
Cargo workspace version 0.0.3
ROADMAP (x) 0.0.3 ; ( ) 0.0.4
CHANGELOG ## 0.0.3
README 0.0.3 présentée comme stable
plan 003 plan historique de la stable 0.0.3
prompt 004 présent pour 0.0.4
```
Les versions `0.0.5` à `0.0.10` restent des horizons révisables.
## Gate pré-tag
Exécuter depuis la racine du dépôt les commandes fournies avec le delta. La gate doit couvrir : version/history précédent, audits Markdown, `cargo fmt --all` puis `--check`, audits Rust, metadata/check/Clippy, tests Git ciblés et workspace, npm/typecheck/build, manifest, cohérence stable/histories/deltas, hygiène texte, trois smokes HTTP, lockfiles et staging final.
Aucun tag `v0.0.3`, archive taggée ou rapport post-tag ne doit être déclaré comme existant pendant cette gate.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 11 -->
<!-- version: 12 -->
# Documentation SaseDev Knowledge
@@ -38,7 +38,7 @@
- [`plans/001-V0_0_1_FOUNDATION_PLAN.md`](plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan historique de la stable de fondation `0.0.1`.
- [`plans/002-V0_0_2_GIT_SYNC_PLAN.md`](plans/002-V0_0_2_GIT_SYNC_PLAN.md) — plan historique de la stable Git générique et synchronisation de lecture `0.0.2`.
- [`plans/003-V0_0_3_GIT_WRITE_PLAN.md`](plans/003-V0_0_3_GIT_WRITE_PLAN.md) — plan actif de `0.0.3`, écriture Git contrôlée et push gardé.
- [`plans/003-V0_0_3_GIT_WRITE_PLAN.md`](plans/003-V0_0_3_GIT_WRITE_PLAN.md) — plan historique de la stable `0.0.3`, écriture Git contrôlée et push gardé.
## Validation
@@ -50,4 +50,4 @@ Les deltas et histories sont des artefacts de workflow, pas des substituts à ce
- [`../prompts/002-V0_0_2_START_PROMPT.md`](../prompts/002-V0_0_2_START_PROMPT.md) — handoff historique exécuté pour ouvrir `0.0.2` depuis `v0.0.1` publiée et vérifiée.
- [`../prompts/003-V0_0_3_START_PROMPT.md`](../prompts/003-V0_0_3_START_PROMPT.md) — prompt local de reprise de `0.0.3` depuis `v0.0.2` publiée et vérifiée.
- [`../prompts/004-V0_0_4_START_PROMPT.md`](../prompts/004-V0_0_4_START_PROMPT.md) — handoff préparé pendant `0.0.3-beta.1` pour ouvrir `0.0.4` depuis la future stable `v0.0.3` réellement publiée.
- [`../prompts/004-V0_0_4_START_PROMPT.md`](../prompts/004-V0_0_4_START_PROMPT.md) — handoff préparé pendant `0.0.3` pour ouvrir `0.0.4` depuis la stable `v0.0.3` une fois son tag/archive et son rapport post-tag réellement publiés et vérifiés.

View File

@@ -1,11 +1,11 @@
<!-- file: docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md -->
<!-- version: 10 -->
<!-- version: 11 -->
# Plan 0.0.3 — écriture Git contrôlée et push gardé
## Statut et sources
Plan actif de `0.0.3`, ouvert depuis la stable Knowledge `v0.0.2` publiée et vérifiée.
Plan historique de la stable `0.0.3`, ouverte depuis la stable Knowledge `v0.0.2` publiée et vérifiée.
Sources autoritaires de reprise :
@@ -19,7 +19,7 @@ Knowledge start prompt prompts/003-V0_0_3_START_PROMPT.md
PGR `v0.1.3` reste une provenance historique de l'adoption fermée pendant `0.0.2`. Aucune version PGR plus récente n'est une source de cette release et aucune réévaluation PGR n'est engagée.
`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion en `PASS`. `alpha.4` a fermé le scope fonctionnel alpha en `PASS` avec push gardé, création de branche sous attente d'absence et conflit concurrent sans écrasement. `beta.1` a réconcilié l'état acquis, préparé le changelog candidat, rejoué la non-régression Rust/Web et effectué la revue d'horizon produit en `PASS`. `rc.1` gèle maintenant ce scope et rejoue la gate complète avant promotion stable.
`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion en `PASS`. `alpha.4` a fermé le scope fonctionnel alpha en `PASS` avec push gardé, création de branche sous attente d'absence et conflit concurrent sans écrasement. `beta.1` a réconcilié l'état acquis, préparé le changelog candidat, rejoué la non-régression Rust/Web et effectué la revue d'horizon produit en `PASS`. `rc.1` a rejoué toutes les preuves produit/runtime mais reste historisée `FAIL` pour une assertion lexicale de statut ; `rc.1.fix.1` a corrigé uniquement cette preuve en `PASS`. `rel.1` est la tranche courante de promotion mécanique pré-tag vers la stable `0.0.3`.
## Mission
@@ -264,11 +264,11 @@ La release est fermable lorsque :
- les règles/architecture décrivent l'état effectivement obtenu ;
- beta et RC ont fermé les non-régressions prévues.
Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` a corrigé uniquement le test en `PASS`. `alpha.4` a ensuite fermé le scope fonctionnel alpha en `PASS`. `beta.1` a stabilisé et réconcilié cet état en `PASS`, sans nouveau code produit. `rc.1` a confirmé toutes les preuves produit/runtime mais reste `FAIL` à cause d'une assertion lexicale trop stricte sur le statut historique `alpha.1`. `rc.1.fix.1` doit corriger uniquement cette preuve avant promotion stable.
Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` a corrigé uniquement le test en `PASS`. `alpha.4` a ensuite fermé le scope fonctionnel alpha en `PASS`. `beta.1` a stabilisé et réconcilié cet état en `PASS`, sans nouveau code produit. `rc.1` a confirmé toutes les preuves produit/runtime mais reste `FAIL` à cause d'une assertion lexicale trop stricte sur le statut historique `alpha.1`. `rc.1.fix.1` a corrigé uniquement cette preuve en `PASS`. `rel.1` assure maintenant la promotion stable pré-tag sans rouvrir le scope.
## Revue d'horizon
La revue `0.0.3-beta.1` remplace l'horizon initial trop centré sur les seules briques backend. La prochaine mission suffisamment définie est :
La revue `0.0.3-beta.1` remplace l'horizon initial trop centré sur les seules briques backend. La prochaine mission engagée par la promotion stable est :
```text
0.0.4 fondation PostgreSQL partagée et migrations
@@ -289,4 +289,4 @@ Ces versions après `0.0.4` restent des horizons révisables. Elles rendent cepe
Recherche avancée, adapters de forge, webhooks forge-only, scheduler, administration transverse, opérations multi-domaines, Git LFS/submodules et partage multi-processus restent non numérotés tant qu'un besoin réel ne les engage pas.
`prompts/004-V0_0_4_START_PROMPT.md` est préparé pendant `beta.1` conformément au cycle normal de handoff. Il exige au prochain démarrage l'archive taggée réelle `v0.0.3` et son rapport post-tag, sans inventer à l'avance le commit stable ou le SHA-256 qui n'existent pas encore.
`prompts/004-V0_0_4_START_PROMPT.md` a été préparé pendant `beta.1` conformément au cycle normal de handoff. La stable `0.0.3` le conserve : au prochain démarrage il exigera l'archive taggée réelle `v0.0.3` et son rapport post-tag, sans avoir inventé à l'avance le commit stable ou le SHA-256.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 39 -->
<!-- version: 40 -->
# Matrice de validation Knowledge
@@ -231,6 +231,26 @@ Le fix de validation RC doit prouver :
Un `PASS` autorise `0.0.3-rel.1`. Le fix ne rejoue pas les smokes HTTP ni le build Web déjà `PASS` sur `rc.1`, puisqu'aucun fichier produit ou Web n'est modifié ; la gate stable `rel.1` les rejouera avant publication.
## Gate de `0.0.3-rel.1`
La fermeture stable pré-tag doit prouver :
- `VERSION = 0.0.3` et version workspace identique ;
- history `history/0.0.3/rc.1.fix.1.md` présent avec statut `PASS` et committé avant application ;
- `rel.1` comme seul delta `0.0.3` sans history correspondant pendant sa gate ;
- changelog stable `## 0.0.3` sans marqueur `candidate` ;
- roadmap avec `0.0.3` terminée, `0.0.4` engagée et `0.0.5` à `0.0.10` conservées comme horizons révisables ;
- README, index documentaire et plan `0.0.3` présentés comme stables/historiques ;
- prompt `004` présent, sans commit/SHA post-tag inventé et sans consultation PGR automatique ;
- `cargo fmt --all`, audits Rust, metadata/check, Clippy strict, tests Git ciblés et tests workspace passent ;
- baseline Web `npm ci`, typecheck, build Vite et manifest passent ;
- les trois smokes HTTP production passent sur `/healthz`, `/` et les assets du manifest ;
- PostgreSQL, migrations, forge, auth/admin et workflows encore différés restent absents du code produit de `0.0.3` ;
- `Cargo.lock` local reste ignoré/non suivi, package-lock Web versionné et staging final propre ;
- aucun tag stable ni rapport post-tag n'est déclaré comme existant avant le history `rel.1` `PASS` et le commit stable.
Un `PASS` de `rel.1` autorise le commit produit exact `0.0.3`, le push, puis seulement la création/push du tag annoté `v0.0.3`, le téléchargement de l'archive réellement servie et la production séparée du rapport `sasedev-knowledge-0.0.3-publish.001-report.md`.
## PostgreSQL
Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.

175
history/0.0.3/rel.1.md Normal file
View File

@@ -0,0 +1,175 @@
<!-- file: history/0.0.3/rel.1.md -->
<!-- version: 1 -->
# History 0.0.3-rel.1 — promotion stable pré-tag
## Statut
PARTIAL
La gate opérateur de `0.0.3-rel.1` exécutée le `2026-09-29` acquiert toutes les preuves produit/runtime et atteint le staging final attendu, mais deux contrôles explicitement demandés n'apparaissent pas dans le transcript : l'audit de composition du workspace à partir du JSON `cargo metadata` et l'audit d'hygiène texte. La tranche est donc conservée `PARTIAL` plutôt que promue implicitement en `PASS`.
## Baseline opérateur
`rc.1.fix.1` `PASS` a été historisé, committé et poussé avant application de `rel.1` :
```text
history/0.0.3/rc.1.fix.1.md PASS
commit 0351aa0
message 0.0.3-rc.1.fix.1
branch master
push origin/master PASS
workspace après push propre
```
Un premier `git push origin master` a été interrompu à l'invite utilisateur, puis le second push a réussi et a avancé `origin/master` de `038b918` à `0351aa0`.
## Promotion stable et documentation
```text
VERSION 0.0.3
Cargo workspace version 0.0.3
history rc.1.fix.1 PASS
git diff --check PASS
Markdown header audit clean (122 file(s))
Markdown link audit clean (82 local link(s), 122 file(s))
Markdown table audit clean (4 table(s), 122 file(s))
```
Les contrôles confirment également :
```text
CHANGELOG ## 0.0.3, sans marqueur candidate
ROADMAP 0.0.3 terminée
ROADMAP 0.0.4 engagée
ROADMAP 0.0.5 -> 0.0.10 horizons révisables
README 0.0.3 présentée comme stable
plan 003 historique de la stable 0.0.3
prompt 004 présent
prompt 004 sans commit/SHA post-tag inventé
PostgreSQL / migrations absents
forge Gitea absente
```
Les dix histories antérieurs sont présents avec leurs statuts réels :
```text
alpha.1 PARTIAL
alpha.1.fix.1 PARTIAL
alpha.1.fix.2 PASS
alpha.2 PASS
alpha.3 FAIL
alpha.3.fix.1 PASS
alpha.4 PASS
beta.1 PASS
rc.1 FAIL
rc.1.fix.1 PASS
```
## Formatage et audits Rust
```text
cargo fmt --all PASS
cargo fmt --all -- --check PASS
Rust test-layout audit clean (9 crate(s))
Rust blank-line audit clean (36 file(s))
Rust item-spacing audit clean (36 file(s))
Rust module-order audit clean (36 file(s))
Rust trait-import-block audit clean (36 file(s))
Rust re-export-block audit clean (36 file(s))
Rust crate-root facade audit clean (6 crate root(s))
Rust export completeness audit 0 candidate(s) across 9 package(s)
```
## Cargo, Clippy et tests Git
```text
cargo metadata --format-version 1 --no-deps PASS (fichier JSON produit)
cargo check --workspace PASS
cargo clippy --workspace --all-targets --all-features
-- -D warnings PASS
cargo test -p knowledge-git-lib --test git_read_path PASS (2)
cargo test -p knowledge-git-lib --test git_write_candidate PASS (2)
cargo test -p knowledge-git-lib --test git_write_push PASS (2)
cargo test --workspace --all-targets --all-features PASS
```
Tests workspace observés :
```text
knowledge-app-lib 3 PASS
knowledge-domain-lib 3 PASS
knowledge-git-api 7 PASS
knowledge-git-lib 8 unit + 6 integration PASS
knowledge-sync-api 1 PASS
knowledge-web-lib 4 PASS
launchers 0 test chacun
```
Les tests Git réels confirment encore le chemin de lecture, le candidat isolé et confiné, le push gardé et le conflit concurrent sans écrasement.
## Baseline Web et runtime
```text
npm ci PASS
npm audit observé 0 vulnérabilité
npm run typecheck PASS
npm run build PASS
Vite 8.3.1
modules transformés 63
Vite manifest audit PASS
```
Les avertissements Sass/Bootstrap de dépréciation et l'avertissement npm sur le script d'installation `@parcel/watcher` restent non bloquants ; le build termine avec succès.
Les trois serveurs ont ensuite été reconstruits et les smokes de production passent avec `/healthz`, `/` et les assets hashés du manifest :
```text
knowledge-pgr-server PASS
knowledge-howtos-server PASS
knowledge-snippets-server PASS
```
## Preuves manquantes
Deux commandes annoncées dans la gate `rel.1` ne sont pas présentes dans le retour opérateur :
```text
workspace audit depuis /tmp/sasedev-knowledge-0.0.3-rel.1-metadata.json NON FOURNI
text hygiene sur README/RULES/ROADMAP/CHANGELOG/docs/prompts/deltas/history NON FOURNI
```
Le fichier metadata a bien été produit et utilisé indirectement par les commandes Cargo, mais la vérification explicite de l'ensemble exact des neuf packages n'a pas été exécutée dans le transcript. De même, les audits Markdown passent mais ne remplacent pas l'audit d'hygiène texte demandé.
## Scope, lockfiles et staging
Les contrôles finaux fournis confirment :
```text
aucun diff crates/Web/architecture/studies/rules/prompts PASS
Cargo.lock présent, ignoré, non suivi
package-lock Web présent
tag local v0.0.3 absent
rapport publish.001 absent
git diff --cached --check PASS
```
Le staging final observé avant ajout du présent history est exactement :
```text
M CHANGELOG.md
M Cargo.toml
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.3/rel.1.md
M docs/000-README.md
M docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
M docs/validation/001-VALIDATION_MATRIX.md
```
## Décision
`0.0.3-rel.1` est `PARTIAL`.
Aucune régression produit n'est observée et aucune correction fonctionnelle n'est nécessaire. Conformément au workflow local, ce résultat doit être historisé, committé et poussé avec le message `0.0.3-rel.1`, sans créer le tag `v0.0.3`. La transition autorisée est uniquement `rel.1.fix.1`, bornée à la complétion des deux preuves manquantes avant le premier commit stable réellement `PASS`.