0.0.3-rc.1.fix.1

This commit is contained in:
2026-09-29 18:08:50 +02:00
parent 038b91864a
commit 0351aa045e
7 changed files with 321 additions and 9 deletions

View File

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

View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 23 -->
<!-- version: 24 -->
# 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` est 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 est gelé : la RC n'introduit aucune nouvelle fonctionnalité et rejoue les preuves Rust, Git, Web et runtime avant promotion stable.
`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.
`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 +1 @@
0.0.3-rc.1
0.0.3-rc.1.fix.1

154
deltas/0.0.3/rc.1.fix.1.md Normal file
View File

@@ -0,0 +1,154 @@
<!-- file: deltas/0.0.3/rc.1.fix.1.md -->
<!-- version: 1 -->
# Delta 0.0.3-rc.1.fix.1 — correction de la vérification des statuts historiques
## Base requise
État `0.0.3-rc.1` committé et poussé après application du history :
```text
history/0.0.3/rc.1.md = FAIL
```
La version devient :
```text
0.0.3-rc.1.fix.1
```
## Objet
Corriger uniquement l'assertion de validation qui a fait échouer `rc.1` alors que le history `alpha.1` porte bien sémantiquement le statut `PARTIAL`.
Le fichier historique `history/0.0.3/alpha.1.md` n'est pas modifié. Sa représentation `` `PARTIAL` `` reste une preuve historique valide.
Aucune fonctionnalité Git, Web, PostgreSQL, forge, auth ou workflow produit n'est ajoutée.
## Scope
La tranche remplace uniquement :
```text
VERSION
Cargo.toml
README.md
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
docs/validation/001-VALIDATION_MATRIX.md
```
et ajoute :
```text
deltas/0.0.3/rc.1.fix.1.md
```
Aucun fichier n'est supprimé. `crates/`, `Web/`, `CHANGELOG.md`, `ROADMAP.md`, `docs/architecture/`, `docs/studies/`, `docs/rules/`, `prompts/` et tous les histories antérieurs sont gelés.
## Gate opérateur
Exécuter directement dans le shell interactif.
```bash
test "$(cat VERSION)" = '0.0.3-rc.1.fix.1'
grep -F 'version = "0.0.3-rc.1.fix.1"' Cargo.toml
grep -A2 '^## Statut$' history/0.0.3/rc.1.md | grep -Fx 'FAIL'
git diff --check
python3 -B scripts/audit_markdown_headers.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts deltas history
python3 -B scripts/audit_markdown_links.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts deltas history
python3 -B scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts deltas history
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 metadata --format-version 1 --no-deps > /tmp/sasedev-knowledge-0.0.3-rc.1.fix.1-metadata.json
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p knowledge-git-lib --test git_read_path
cargo test -p knowledge-git-lib --test git_write_candidate
cargo test -p knowledge-git-lib --test git_write_push
cargo test --workspace --all-targets --all-features
```
## Contrôles spécifiques courts
Chaque commande est indépendante.
```bash
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.1.md | tr -d '`' | grep -Fx 'PARTIAL'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.1.fix.1.md | tr -d '`' | grep -Fx 'PARTIAL'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.1.fix.2.md | tr -d '`' | grep -Fx 'PASS'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.2.md | tr -d '`' | grep -Fx 'PASS'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.3.md | tr -d '`' | grep -Fx 'FAIL'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.3.fix.1.md | tr -d '`' | grep -Fx 'PASS'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/alpha.4.md | tr -d '`' | grep -Fx 'PASS'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/beta.1.md | tr -d '`' | grep -Fx 'PASS'
sed -n '/^## Statut$/{n;n;p;q;}' history/0.0.3/rc.1.md | tr -d '`' | grep -Fx 'FAIL'
test "$(find history/0.0.3 -maxdepth 1 -type f -name '*.md' | wc -l)" -eq 9
test "$(find deltas/0.0.3 -maxdepth 1 -type f -name '*.md' | wc -l)" -eq 10
test ! -e history/0.0.3/rc.1.fix.1.md
grep -F '## 0.0.3 (candidate)' CHANGELOG.md
grep -F -- '- `( ) 0.0.3` — écriture Git contrôlée et push gardé' ROADMAP.md
grep -F -- '- `(h) 0.0.4` — fondation PostgreSQL partagée' ROADMAP.md
test -f prompts/004-V0_0_4_START_PROMPT.md
test -z "$(git diff --name-only -- crates Web CHANGELOG.md ROADMAP.md docs/architecture docs/studies docs/rules prompts history)"
```
Vérifier l'hygiène texte :
```bash
python3 -c 'from pathlib import Path; roots=[Path("README.md"),Path("RULES.md"),Path("ROADMAP.md"),Path("CHANGELOG.md"),Path("docs"),Path("prompts"),Path("deltas"),Path("history")]; paths=[p for r in roots for p in ([r] if r.is_file() else r.rglob("*")) if p.is_file()]; bad=[str(p) for p in paths if (lambda b: b"\r" in b or not b.endswith(b"\n") or b.endswith(b"\n\n") or any(line != line.rstrip(" \t") for line in b.decode("utf-8").splitlines()))(p.read_bytes())]; print(f"Knowledge 0.0.3-rc.1.fix.1 text hygiene: clean ({len(paths)} file(s))") if not bad else (_ for _ in ()).throw(AssertionError(bad))'
```
Puis :
```bash
test -f Cargo.lock
git check-ignore -q Cargo.lock
if git ls-files --error-unmatch Cargo.lock >/dev/null 2>&1; then
echo 'Cargo.lock must remain untracked for Knowledge' >&2
exit 1
fi
test -f Web/knowledge-template-lab/package-lock.json
git add -A
git diff --cached --check
git status --short
```
Le staging attendu est limité à :
```text
M Cargo.toml
M README.md
M VERSION
A deltas/0.0.3/rc.1.fix.1.md
M docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
M docs/validation/001-VALIDATION_MATRIX.md
```
## Transition
### PASS
Produire `history/0.0.3/rc.1.fix.1.md`, l'appliquer, commit/push `0.0.3-rc.1.fix.1`, puis préparer `0.0.3-rel.1` comme promotion mécanique stable pré-tag.
### FAIL
Produire le history exact puis un nouveau fix RC strictement borné au défaut observé. Ne pas promouvoir `rel.1` tant que la RC corrigée n'est pas `PASS`.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md -->
<!-- version: 9 -->
<!-- version: 10 -->
# Plan 0.0.3 — écriture Git contrôlée et push gardé
@@ -217,6 +217,15 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
- vérifier reproductibilité des tests Git d'écriture locaux, intégrité des deltas/histories, Cargo/Clippy/tests et non-régression Web/runtime prévue par la phase ;
- n'introduire aucune nouvelle fonctionnalité.
### rc.1.fix.1 — correction de la vérification des statuts historiques
- conserver `rc.1 = FAIL` avec la preuve exacte de l'assertion lexicale trop stricte ;
- ne réécrire aucun history antérieur, en particulier `alpha.1` dont le statut historique est écrit `` `PARTIAL` `` ;
- normaliser uniquement la lecture du statut lors des gates afin d'accepter la présentation Markdown existante ;
- ne modifier aucun fichier sous `crates/`, `Web/`, `CHANGELOG.md`, `ROADMAP.md`, `docs/architecture/`, `docs/studies/`, `docs/rules/` ou `prompts/` ;
- rejouer les contrôles documentaires, Cargo/Clippy/tests et la cohérence RC nécessaires à ce fix ;
- autoriser `rel.1` uniquement après `PASS` complet du fix.
### rel.1 — promotion stable pré-tag
- promouvoir mécaniquement `VERSION` et le workspace vers `0.0.3` ;
@@ -255,7 +264,7 @@ 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. La RC doit désormais uniquement confirmer la candidate stable par la gate complète.
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.
## Revue d'horizon

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 38 -->
<!-- version: 39 -->
# Matrice de validation Knowledge
@@ -205,7 +205,7 @@ La release candidate doit prouver :
- `VERSION = 0.0.3-rc.1` et version workspace identique ;
- history `history/0.0.3/beta.1.md` présent avec statut `PASS` et committé avant application ;
- scope produit gelé : aucun diff sous `crates/`, `Web/`, `CHANGELOG.md`, `ROADMAP.md`, `docs/architecture/`, `docs/studies/`, `docs/rules/` ou `prompts/` ;
- tous les histories antérieurs de `0.0.3` présents avec leurs statuts réels et `rc.1.md` seul delta sans history correspondant ;
- tous les histories antérieurs de `0.0.3` présents avec leurs statuts réels et `rc.1.md` seul delta sans history correspondant ; les contrôles de statut doivent comparer la valeur sémantique après retrait d'un éventuel balisage inline Markdown historique, sans réécrire les histories ;
- `CHANGELOG.md` toujours en `## 0.0.3 (candidate)` et `ROADMAP.md` conservant `0.0.3` engagée avec l'horizon validé en beta ;
- handoff `prompts/004-V0_0_4_START_PROMPT.md` présent et toujours sans commit/SHA futur inventé ;
- `cargo fmt --all`, audits Rust, metadata/check, Clippy strict, tests Git ciblés et tests workspace passent ;
@@ -216,6 +216,21 @@ La release candidate doit prouver :
Un `PASS` autorise uniquement `0.0.3-rel.1`. Toute régression fonctionnelle exige un fix RC borné ou un retour de phase approprié ; aucune fonctionnalité ne peut être ajoutée en RC.
## Gate de `0.0.3-rc.1.fix.1`
Le fix de validation RC doit prouver :
- `VERSION = 0.0.3-rc.1.fix.1` et version workspace identique ;
- history `history/0.0.3/rc.1.md` présent avec statut `FAIL` et committé avant application ;
- `alpha.1` toujours historiquement `PARTIAL` sans modification de son fichier ;
- lecture robuste des statuts historiques, qu'ils soient bruts ou entourés de backticks Markdown ;
- aucun diff produit sous `crates/` ou `Web/` et aucun changement du changelog, de la roadmap, de l'architecture, des études, des règles ou des prompts ;
- audits Markdown/Rust locaux, `cargo fmt`, metadata/check, Clippy strict, tests Git ciblés et tests workspace propres ;
- présentation candidate `0.0.3` et handoff `0.0.4` inchangés ;
- `Cargo.lock` local ignoré/non suivi, package-lock Web versionné et staging final propre.
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.
## PostgreSQL
Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.

134
history/0.0.3/rc.1.fix.1.md Normal file
View File

@@ -0,0 +1,134 @@
<!-- file: history/0.0.3/rc.1.fix.1.md -->
<!-- version: 1 -->
# History 0.0.3-rc.1.fix.1 — correction de la vérification des statuts historiques
## Statut
PASS
La gate opérateur de `0.0.3-rc.1.fix.1` exécutée le `2026-09-29` est complète et propre.
## Baseline opérateur
`rc.1` `FAIL` a été historisé, committé et poussé avant application du fix :
```text
history/0.0.3/rc.1.md FAIL
commit 038b918
message 0.0.3-rc.1
branch master
push origin/master PASS
```
Le push observé a avancé `origin/master` de `282d59c` à `038b918`.
## Version, Markdown et format
```text
VERSION 0.0.3-rc.1.fix.1
Cargo workspace version 0.0.3-rc.1.fix.1
history rc.1 FAIL
git diff --check PASS
Markdown header audit clean (120 file(s))
Markdown link audit clean (82 local link(s), 120 file(s))
Markdown table audit clean (4 table(s), 120 file(s))
cargo fmt --all PASS
cargo fmt --all -- --check PASS
```
## Audits Rust
```text
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
```text
cargo metadata --format-version 1 --no-deps PASS
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 reconfirment le chemin de lecture, la création de candidat avec confinement et nettoyage, le push gardé et le conflit concurrent sans écrasement.
## Correction de la preuve RC
La vérification robuste des statuts historiques passe après retrait de l'éventuel balisage inline Markdown :
```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
```
Le fichier historique `history/0.0.3/alpha.1.md` n'a pas été réécrit.
Les contrôles confirment aussi :
```text
histories 0.0.3 avant fix history 9
deltas 0.0.3 10
CHANGELOG 0.0.3 candidate présent
ROADMAP 0.0.3 engagée présente
ROADMAP 0.0.4 PostgreSQL horizon présente
prompt 004 présent
scope crates/Web/docs gelés PASS
text hygiene clean (120 file(s))
Cargo.lock présent localement, ignoré, non suivi
package-lock Web présent
```
Aucun build Web ni smoke HTTP n'était requis par ce fix parce qu'aucun fichier produit ou Web n'a changé ; ces preuves avaient déjà passé sur `rc.1` et seront rejouées pendant `rel.1`.
## Staging final
Le staging observé avant ajout du présent history est :
```text
M Cargo.toml
M README.md
M VERSION
A deltas/0.0.3/rc.1.fix.1.md
M docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
M docs/validation/001-VALIDATION_MATRIX.md
```
`git diff --cached --check` passe.
## Décision
`0.0.3-rc.1.fix.1` est `PASS`.
La release peut passer à `0.0.3-rel.1` pour promotion stable pré-tag. Cette promotion doit rester mécanique, rejouer la gate stable complète — y compris Web et les trois smokes HTTP — puis produire son history réel avant commit stable et tag `v0.0.3`.