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

0.0.3-rel.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-29 18:54:33 +02:00
parent 0351aa045e
commit 9a1f73d57b
10 changed files with 295 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/000-README.md
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.

12
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
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.

22
docs/validation/001-VALIDATION_MATRIX.md
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.