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

0.0.3-alpha.1.fix.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-29 10:16:04 +02:00
parent a74a19838f
commit dd63e8578a
11 changed files with 418 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
CHANGELOG.md
View File

@@ -1,18 +1,10 @@
<!-- file: CHANGELOG.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# 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)
- engage l'écriture Git générique contrôlée comme prochaine capacité après la stable de lecture `0.0.2` ;
- retient un worktree d'écriture isolé sous la racine d'état contrôlée et un contrat d'écriture distinct du contrat `GitRepository` de lecture ;
- exige des mutations de fichiers confinées, une identité de commit explicite, des hooks neutralisés et des erreurs publiques redacted ;
- prévoit un push vers `refs/heads/...` avec attente explicite sur l'état distant afin qu'une divergence devienne un conflit au lieu d'un écrasement ;
- conserve rebase/merge automatique, workflow complet de proposition, PostgreSQL, forge et auth/admin hors scope.
## 0.0.2
- matérialise un backend Git générique de lecture derrière `knowledge-git-api`, sans dépendance obligatoire à une forge ;

2
Cargo.toml
View File

@@ -16,7 +16,7 @@ members = [
]
[workspace.package]
version = "0.0.3-alpha.1"
version = "0.0.3-alpha.1.fix.1"
edition = "2024"
publish = false
repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge"

39
ROADMAP.md
View File

@@ -1,11 +1,11 @@
<!-- file: ROADMAP.md -->
<!-- version: 9 -->
<!-- version: 10 -->
# Roadmap SaseDev Knowledge
Le roadmap ne réserve que les releases dont la mission est réellement engagée.
La roadmap montre la release effectivement en cours et un horizon borné des releases suivantes. Une release d'horizon reste prévisionnelle tant qu'une revue d'horizon ne l'a pas engagée comme prochaine mission ; son numéro, son ordre ou son scope peuvent encore être replanifiés.
Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
Statuts : `( )` engagée/planifiée, `(x)` terminée, `(h)` horizon prévisionnel, `(d)` différée, `(c)` annulée.
## Fondation
@@ -15,20 +15,29 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
- `(x) 0.0.2` — implémentation Git générique et synchronisation de lecture : backend provider-neutral derrière `knowledge-git-api`, configuration de sources locales/remotes, matérialisation locale reproductible, refresh/résolution de révision, snapshot/worktree de lecture et convergence des déclencheurs explicite/périodique vers un même cas d'usage, sans API de forge obligatoire, écriture/publication Git, PostgreSQL ni format final HOWTO/snippet.
## Release engagée
## Release en cours
- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture provider-neutral distinct de la lecture, worktree d'écriture isolé, mutations de fichiers confinées, commit avec identité explicite et mise à jour d'une branche `refs/heads/...` uniquement lorsque son état distant correspond à l'attente fournie ; sans forge obligatoire, rebase/merge automatique, PostgreSQL ni workflow complet de proposition.
- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture provider-neutral distinct de la lecture, worktree d'écriture isolé, mutations confinées, commit avec identité explicite et mise à jour d'une branche `refs/heads/...` seulement lorsque son état distant correspond à l'attente fournie ; sans forge obligatoire, rebase/merge automatique, PostgreSQL ni workflow complet de proposition.
## Domaines futurs non numérotés
## Horizon prévisionnel
Les thèmes suivants sont candidats à des releases ultérieures mais ne reçoivent pas encore de numéro :
L'ordre ci-dessous exprime l'horizon de travail actuel. Il sert à préparer les dépendances et éviter qu'une release soit décidée isolément ; il n'engage pas ces releases avant leur revue d'horizon dédiée.
- état PostgreSQL partagé et migrations applicatives ;
- contribution/revue et administration ;
- publication/rendu des trois façades ;
- recherche et indexation avancées ;
- adapter Gitea puis autres forges selon besoin réel ;
- authentification/autorisation complète ;
- déploiement et opérations multi-domaines.
- `(h) 0.0.4` — persistance PostgreSQL partagée : premier schéma réel, migrations, configuration logique persistante des sources et état de synchronisation nécessaire aux futurs cas d'usage transversaux, sans déplacer le contenu publié hors de Git.
- `(h) 0.0.5` — contenu structuré et lecture publique : formats/corpus réels PGR, HOWTO et snippet, normalisation/parsing, relations utiles et rendu public depuis la révision Git/index local, sans workflow complet de contribution.
- `(h) 0.0.6` — identité, autorisation et administration locale : comptes/sessions, rôles ou capabilities réellement nécessaires et surfaces d'administration protégées par façade, sans créer une quatrième application sans ownership démontré.
- `(h) 0.0.7` — propositions, revue et publication : proposition basée sur une révision Git, revue/audit applicatif, détection de conflit et publication produisant une révision Git autoritaire avant exposition comme contenu publié.
La revue d'horizon `0.0.2-beta.1` avait laissé la suite ouverte. L'ouverture explicite de `0.0.3-alpha.1` engage désormais uniquement la mission d'écriture Git contrôlée décrite ci-dessus ; aucun numéro ultérieur n'est réservé.
## Domaines ultérieurs à reclasser
Les thèmes suivants restent volontairement non numérotés tant que l'horizon ci-dessus n'a pas été réévalué ou qu'un besoin plus prioritaire ne les engage pas :
- recherche/indexation avancée au-delà des capacités PostgreSQL/locales réellement nécessaires ;
- adapter Gitea puis autres forges et webhooks forge-only ;
- scheduler/jobs de synchronisation ou publication ;
- quatrième application d'administration transverse ;
- déploiement/opérations multi-domaines ;
- partage concurrent d'une même racine Git entre plusieurs processus ;
- support explicite Git LFS/submodules et politiques de rétention/cleanup avancées.
La revue d'horizon de chaque release doit vérifier la release suivante et réévaluer au moins les deux releases qui la suivent. Elle peut conserver, réordonner, fusionner, scinder ou dénuméroter un élément d'horizon lorsque les preuves produit ou techniques le justifient.

2
VERSION
View File

@@ -1 +1 @@
0.0.3-alpha.1
0.0.3-alpha.1.fix.1

184
deltas/0.0.3/alpha.1.fix.1.md Normal file
View File

@@ -0,0 +1,184 @@
<!-- file: deltas/0.0.3/alpha.1.fix.1.md -->
<!-- version: 1 -->
# Delta 0.0.3-alpha.1.fix.1 — cycle documentaire et horizon
## Baseline requise
Partir de `0.0.3-alpha.1` après application et commit/push de son history `PARTIAL`.
La version devient :
```text
0.0.3-alpha.1.fix.1
```
## Objet
Corriger le cadrage documentaire signalé par l'opérateur sans modifier la mission Git ni le code produit :
- retirer l'entrée `0.0.3 (candidate)` écrite trop tôt dans `CHANGELOG.md` ;
- codifier que le changelog de release est préparé vers la stabilisation à partir des changements réellement acquis ;
- conserver `prompts/003-V0_0_3_START_PROMPT.md` comme rattrapage valide, mais codifier que le prompt de `N+1` est normalement produit pendant les dernières phases de `N` après revue d'horizon ;
- transformer `ROADMAP.md` en vue de la release courante plus un horizon prévisionnel borné et explicitement révisable ;
- établir l'horizon actuel `0.0.4` à `0.0.7` sans les considérer comme des missions engagées ;
- mettre à jour le plan `0.0.3` afin que `beta.1` réévalue cet horizon et prépare le prochain prompt avant la stable si la mission suivante est suffisamment définie.
Aucun fichier sous `crates/` ou `Web/` n'est modifié.
## Horizon introduit
L'horizon actuel est :
```text
0.0.4 PostgreSQL partagé et migrations
0.0.5 contenu structuré et lecture publique
0.0.6 identité / autorisation / administration locale
0.0.7 propositions / revue / publication
```
Le statut `(h)` signifie horizon prévisionnel : numéro, ordre et scope peuvent être révisés lors des revues d'horizon ultérieures. Seule `0.0.3` est engagée aujourd'hui.
## Scope des fichiers
REPLACE :
```text
VERSION
Cargo.toml
CHANGELOG.md
ROADMAP.md
docs/rules/210-WORKFLOW.md
docs/rules/300-DOCUMENTATION.md
docs/templates/001-NEW_SESSION_PROMPT.md
docs/templates/002-RELEASE_PLAN.md
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
```
ADD :
```text
deltas/0.0.3/alpha.1.fix.1.md
```
DELETE : aucun.
`prompts/003-V0_0_3_START_PROMPT.md` reste inchangé : il constitue le rattrapage nécessaire à l'ouverture de `0.0.3`.
Aucun history `alpha.1.fix.1` n'est inclus dans ce delta.
## Gate opérateur
Exécuter depuis la racine du dépôt après application du delta :
```bash
test "$(cat VERSION)" = '0.0.3-alpha.1.fix.1'
grep -F 'version = "0.0.3-alpha.1.fix.1"' Cargo.toml
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-alpha.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 --workspace --all-targets --all-features
python3 - <<'PYGATE'
from pathlib import Path
changelog = Path('CHANGELOG.md').read_text(encoding='utf-8')
assert '## 0.0.3' not in changelog
assert '## 0.0.2' in changelog
roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
assert '- `( ) 0.0.3`' in roadmap
for version in ('0.0.4', '0.0.5', '0.0.6', '0.0.7'):
assert f'- `(h) {version}`' in roadmap, version
assert 'horizon prévisionnel' in roadmap
workflow = Path('docs/rules/210-WORKFLOW.md').read_text(encoding='utf-8')
assert 'pendant les dernières phases de `N`' in workflow
assert 'rattrapage et non le cycle normal' in workflow
documentation = Path('docs/rules/300-DOCUMENTATION.md').read_text(encoding='utf-8')
assert "Il n'est normalement pas rédigé au démarrage" in documentation
assert 'au moins les deux releases d\'horizon qui la suivent' in documentation
prompt_template = Path('docs/templates/001-NEW_SESSION_PROMPT.md').read_text(encoding='utf-8')
assert 'pendant les dernières phases de la release `N`' in prompt_template
assert 'MUST NOT inventer ces valeurs' in prompt_template
assert Path('prompts/003-V0_0_3_START_PROMPT.md').is_file()
assert not Path('history/0.0.3/alpha.1.fix.1.md').exists()
assert not Path('crates/knowledge-forge-gitea-lib').exists()
assert not Path('crates/knowledge-store-postgres-lib').exists()
assert not Path('migrations').exists()
print('Knowledge 0.0.3-alpha.1.fix.1 documentation lifecycle audit: clean')
PYGATE
python3 - <<'PYTEXT'
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 = []
for root in roots:
if root.is_file():
paths.append(root)
elif root.is_dir():
paths.extend(path for path in root.rglob('*') if path.is_file())
for path in paths:
data = path.read_bytes()
assert b'\r' not in data, path
assert data.endswith(b'\n'), path
assert not data.endswith(b'\n\n'), path
text = data.decode('utf-8')
for number, line in enumerate(text.splitlines(), start=1):
assert line == line.rstrip(' \t'), (path, number)
print(f'Knowledge 0.0.3-alpha.1.fix.1 text hygiene: clean ({len(paths)} file(s))')
PYTEXT
test -z "$(git diff --name-only -- crates Web)"
test ! -e history/0.0.3/alpha.1.fix.1.md
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
```
La gate ne rejoue pas npm/Vite/HTTP : aucun fichier Web ni contrat runtime n'est modifié.
## Transition
### PASS
Produire `history/0.0.3/alpha.1.fix.1.md`, l'appliquer, commit/push `0.0.3-alpha.1.fix.1`, puis préparer `0.0.3-alpha.2`.
### FAIL / PARTIAL / BLOCKED
Conserver le résultat réel dans son history avant toute correction. Une correction bornée utilise `alpha.1.fix.2`; un problème qui invalide la trajectoire appelle un REPLAN.

38
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Plan 0.0.3 — écriture Git contrôlée et push gardé
@@ -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` est la tranche courante de cadrage. Aucun history n'existe avant la gate opérateur.
`0.0.3-alpha.1` a produit une gate technique propre jusqu'aux tests workspace mais reste `PARTIAL` : la fin de gate n'a pas été fournie et la revue opérateur a détecté un mauvais cycle de rédaction du changelog, du prompt suivant et de la roadmap. `0.0.3-alpha.1.fix.1` corrige uniquement ce workflow documentaire avant l'implémentation fonctionnelle.
## Mission
@@ -131,9 +131,20 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
- confirmer l'autonomie normative Knowledge sans nouvelle consultation PGR ;
- réconcilier les `DEFER` avec la prochaine mission ;
- produire l'étude `006` ;
- engager `0.0.3` dans la roadmap ;
- engager `0.0.3` et établir un premier horizon au-delà d'elle ;
- mettre à jour les owners/architecture vivants nécessaires ;
- établir le présent plan ;
- créer exceptionnellement `prompts/003-V0_0_3_START_PROMPT.md` comme rattrapage, puisque `0.0.2` avait été fermée sans prochaine mission décidée ;
- ne modifier aucun code sous `crates/` ni `Web/`.
### alpha.1.fix.1 — correction du cycle documentaire
- conserver `alpha.1` comme `PARTIAL` sans réécrire ses preuves ;
- retirer du changelog l'entrée candidate écrite prématurément ;
- faire de la roadmap une vue de la release en cours plus un horizon prévisionnel borné ;
- codifier que le changelog est rédigé vers la stabilisation à partir des changements réellement acquis ;
- codifier que le prompt de `N+1` est normalement préparé pendant les dernières phases de `N`, après revue d'horizon ;
- garder `prompts/003-V0_0_3_START_PROMPT.md` comme rattrapage historique valide ;
- ne modifier aucun code sous `crates/` ni `Web/`.
### alpha.2 — contrat d'écriture provider-neutral
@@ -167,8 +178,9 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
- réconcilier contrats, implémentation et documentation durable ;
- vérifier les `DEFER` encore valides ;
- rejouer la non-régression utile, y compris runtime global si nécessaire à la stabilisation ;
- décider explicitement si une mission suivante est suffisamment définie pour être engagée ;
- ne pas numéroter automatiquement une version ultérieure.
- réévaluer `0.0.4` comme prochaine mission potentielle et l'horizon `0.0.5` / `0.0.6` / `0.0.7` ;
- réordonner, scinder ou dénuméroter ces horizons si les preuves de `0.0.3` le justifient ;
- si `0.0.4` est suffisamment décidée, préparer son prompt de démarrage avant la clôture stable de `0.0.3`.
### rc.1 — candidate stable
@@ -180,7 +192,8 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
### rel.1 — promotion stable pré-tag
- promouvoir mécaniquement `VERSION` et le workspace vers `0.0.3` ;
- fermer changelog/roadmap/plan sans nouveau scope ;
- finaliser le changelog à partir du scope réellement acquis ;
- fermer roadmap/plan sans nouveau scope et vérifier que le handoff de la prochaine release décidée est déjà présent ;
- rejouer la gate stable prévue ;
- produire le history observé avant commit produit/tag ;
- ne fabriquer aucun rapport post-tag avant publication réelle.
@@ -214,10 +227,17 @@ 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.
Un `PASS` de `alpha.1` autorise uniquement `0.0.3-alpha.2`. Tout autre statut produit d'abord son history puis un fix ou REPLAN selon le diagnostic.
Le `PARTIAL` de `alpha.1` autorise uniquement `0.0.3-alpha.1.fix.1`. Un `PASS` de ce fix autorise `0.0.3-alpha.2`. Tout autre statut produit d'abord son history puis un nouveau fix ou REPLAN selon le diagnostic.
## Revue d'horizon
La revue d'horizon n'est pas réalisée en `alpha.1`.
`alpha.1.fix.1` établit un horizon prévisionnel afin que `0.0.3` ne soit pas développée isolément :
Les thèmes PostgreSQL, proposition/revue, rendu/publication produit, recherche, forge, auth/admin et opérations restent non numérotés. `beta.1` décidera, à partir du retour réel de l'écriture Git, si l'un d'eux devient la prochaine mission.
```text
0.0.4 PostgreSQL partagé et migrations
0.0.5 contenu structuré et lecture publique
0.0.6 identité / autorisation / administration locale
0.0.7 propositions / revue / publication
```
Ces numéros sont des horizons, pas encore des missions engagées. `beta.1` doit les réévaluer à la lumière de l'implémentation réelle de `0.0.3`, confirmer ou modifier la prochaine mission et préparer le prompt de cette mission pendant la fin de `0.0.3` si elle est suffisamment définie. Recherche avancée, adapters de forge, scheduler, administration transverse, opérations multi-domaines et autres `DEFER` restent reclassables ultérieurement.

10
docs/rules/210-WORKFLOW.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/210-WORKFLOW.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Workflow local Knowledge
@@ -102,7 +102,11 @@ Les commandes ne sont pas différées à une réponse ultérieure. Lorsque le de
## 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é.
Un prompt de démarrage versionné décrit la baseline attendue, 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é.
Le cycle normal prépare le prompt de la release `N+1` pendant les dernières phases de `N`, après la revue d'horizon qui a suffisamment défini la prochaine mission et avant la clôture stable de `N`. Comme le commit/tag/rapport post-tag définitifs de `N` n'existent pas encore à ce moment, le prompt versionné ne doit pas inventer leur SHA ou leur résultat : il exige que l'introduction de la session suivante fournisse l'archive taggée et le rapport post-tag réels et qu'ils soient vérifiés avant développement.
Si une stable historique a été fermée sans prompt de la release suivante parce que la mission n'était pas encore décidée, le prompt peut exceptionnellement être créé au démarrage réel de cette release ; cette situation est un rattrapage et non le cycle normal.
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.
@@ -116,7 +120,7 @@ Le tag stable `vX.Y.Z` est créé seulement après le commit stable. L'archive t
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.
Le prompt d'une release suivante n'est préparé que si sa mission est suffisamment décidée par la revue d'horizon. Lorsqu'elle l'est, ce prompt fait partie des artefacts de fin de la release courante afin que la stable publiée contienne déjà son handoff vers la suite. Les éléments post-tag encore inconnus restent à vérifier au démarrage suivant plutôt qu'à être inventés.
## Immutabilité des artefacts historiques

12
docs/rules/300-DOCUMENTATION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/300-DOCUMENTATION.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Documentation locale Knowledge
@@ -22,9 +22,9 @@ La révision documentaire augmente lorsqu'un contenu réel du fichier change ; e
`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.
`ROADMAP.md` décrit la release en cours et un horizon borné des prochaines releases. Il distingue explicitement une mission engagée d'une version d'horizon encore révisable ; l'horizon sert à ordonner les dépendances et à préparer la suite sans transformer chaque intention en engagement irrévocable. Il ne sert ni de journal quotidien ni de catalogue exhaustif des prereleases.
`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.
`CHANGELOG.md` synthétise les changements réellement acquis d'une release. Il n'est normalement pas rédigé au démarrage ou pendant le cadrage alpha à partir d'intentions : une entrée candidate est préparée vers les phases de stabilisation, lorsque l'implémentation et les histories permettent de décrire ce qui existe effectivement, puis finalisée avant la promotion stable. 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.
@@ -64,14 +64,16 @@ Le plan est mis à jour lorsqu'une hypothèse de pilotage devient fausse, pas po
## 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`.
Lorsqu'une release approche de sa stabilisation, une revue d'horizon explicite réévalue la release suivante et, autant que les dépendances sont suffisamment connues, au moins les deux releases d'horizon qui la suivent. Elle peut engager la prochaine mission, réordonner ou scinder un horizon, maintenir un domaine non numéroté ou reclasser un `DEFER`.
La revue n'invente pas un numéro de version uniquement pour assurer la continuité documentaire.
Une version marquée comme horizon n'est pas encore une promesse de scope : son numéro et sa mission peuvent changer à la revue suivante. La roadmap doit néanmoins donner assez de visibilité pour que la release en cours soit développée dans une trajectoire produit cohérente plutôt qu'en isolation.
## 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.
Le prompt de la release suivante est normalement rédigé pendant les dernières phases de la release courante, après sa revue d'horizon. Il fait partie du handoff livré par la stable courante. Les identifiants post-tag qui n'existent pas encore lors de sa rédaction ne sont pas inventés : la session suivante les reçoit dans son texte d'introduction et les vérifie contre l'archive et le rapport réellement publiés.
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).

31
docs/templates/001-NEW_SESSION_PROMPT.md vendored
View File

@@ -1,25 +1,42 @@
<!-- file: docs/templates/001-NEW_SESSION_PROMPT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Pattern local — prompt de nouvelle session
## Usage
Ce pattern prépare le court message opérateur remis après une stable Knowledge publiée. Le prompt détaillé reste un fichier versionné sous `prompts/`.
Ce pattern prépare le prompt versionné qui permettra d'ouvrir une future release Knowledge.
Le cycle normal crée le prompt de `N+1` pendant les dernières phases de la release `N`, après une revue d'horizon ayant suffisamment défini la mission suivante et avant la clôture stable de `N`. Il doit donc être présent dans la stable `N` publiée.
Une session normale Knowledge ne consulte pas PGR. Une mention PGR n'apparaît que lorsque la release cible contient explicitement une réévaluation/adoption PGR.
## Forme normale
## Informations connues à la rédaction
Lorsque le rapport post-tag de la baseline est `PASS` :
Pendant la fin de `N`, les éléments suivants peuvent être établis :
```text
Partir de l'archive sasedev-knowledge-vX.Y.Z.zip téléchargée depuis le tag Gitea vX.Y.Z et du rapport post-tag sasedev-knowledge-X.Y.Z-publish.001-report.md. Lire et exécuter prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md. Vérifier intégralement l'archive Knowledge, les règles locales, la gouvernance, l'architecture, la structure documentaire, les deltas/histories, les décisions différées et la cohérence globale avant de préparer <NEXT_RELEASE>-alpha.1.
release stable attendue N
release suivante N+1
mission de N+1 décidée par la revue d'horizon
chemin du prompt prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md
```
`X.Y.Z` désigne la stable autoritaire de départ et `<NEXT_RELEASE>` la release suivante réellement décidée ; ces deux valeurs ne sont pas supposées identiques.
Le commit stable exact, le SHA-256 de l'archive taggée et le résultat du rapport post-tag de `N` n'existent pas encore nécessairement. Le prompt MUST NOT inventer ces valeurs.
Les noms et versions sont remplacés uniquement par des valeurs établies. Si le rapport post-tag n'existe pas ou n'est pas `PASS`, il n'est pas présenté comme preuve.
## Forme normale du texte d'introduction de la session suivante
Après publication réelle de `N`, l'opérateur fournit :
```text
Partir de l'archive sasedev-knowledge-vX.Y.Z.zip téléchargée depuis le tag Gitea vX.Y.Z et du rapport post-tag sasedev-knowledge-X.Y.Z-publish.001-report.md. Considérer cette stable comme la baseline autoritaire de SaseDev Knowledge. Lire et exécuter prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md. Vérifier intégralement l'archive, les règles et owners normatifs locaux, la gouvernance, l'architecture, la structure documentaire, les deltas/histories, les décisions DEFER, la revue d'horizon et la cohérence globale avant de préparer <NEXT_RELEASE>-alpha.1.
```
Le prompt versionné exige alors de vérifier que l'archive et le rapport fournis correspondent réellement à la stable publiée avant tout développement.
## Rattrapage exceptionnel
Si une stable a été fermée sans prompt suivant parce qu'aucune mission n'était encore décidée, le prompt MAY être créé lors de l'ouverture réelle de la release suivante. Ce cas est documenté comme rattrapage ; il ne devient pas le cycle normal.
## Réévaluation externe explicite

8
docs/templates/002-RELEASE_PLAN.md vendored
View File

@@ -1,5 +1,5 @@
<!-- file: docs/templates/002-RELEASE_PLAN.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Pattern local — plan de release
@@ -30,4 +30,8 @@ Le nombre de tranches n'est pas fixé. Les phases annoncées restent sous `## Tr
Le plan pilote le travail restant ; il n'est pas un journal de commandes. Les preuves détaillées vivent dans `history/` et les règles durables vivent chez leur owner local.
Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses. Aucune version postérieure n'est réservée uniquement pour remplir la roadmap.
Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses.
La revue d'horizon de fin de release doit réévaluer la prochaine mission et un horizon borné au-delà d'elle. Lorsque `N+1` est suffisamment décidée, la fin de `N` prépare aussi son prompt versionné de démarrage afin que la stable `N` contienne déjà le handoff vers la suite.
Le changelog n'est pas une intention du plan : son entrée de release est préparée vers la stabilisation à partir du résultat réellement matérialisé, puis finalisée avant la promotion stable.

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

@@ -0,0 +1,134 @@
<!-- file: history/0.0.3/alpha.1.fix.1.md -->
<!-- version: 1 -->
# History 0.0.3-alpha.1.fix.1 — cycle documentaire et horizon
## Statut
PARTIAL
La gate opérateur de `0.0.3-alpha.1.fix.1` exécutée le `2026-09-29` acquiert toutes les preuves transmises jusqu'aux tests workspace, mais le transcript reçu s'arrête avant le bloc final explicitement requis par le delta.
Aucune commande observée n'a échoué. Le statut exact est donc `PARTIAL`, et non `PASS` ni `FAIL`.
## Baseline opérateur
`alpha.1` `PARTIAL` a été historisé, committé et poussé avant application de `alpha.1.fix.1` :
```text
history/0.0.3/alpha.1.md PARTIAL
commit a74a198
message 0.0.3-alpha.1
branch master
push origin/master PASS
workspace après push propre
```
Le push observé a avancé `origin/master` de `183d354` à `a74a198`.
## Version et audits documentaires
Les contrôles observés passent :
```text
VERSION 0.0.3-alpha.1.fix.1
Cargo workspace version 0.0.3-alpha.1.fix.1
git diff --check PASS
Markdown header audit clean (102 file(s))
Markdown link audit clean (78 local link(s), 102 file(s))
Markdown table audit clean (4 table(s), 102 file(s))
```
## Formatage et audits Rust
L'ordre local est respecté :
```text
cargo fmt --all PASS
cargo fmt --all -- --check PASS
Rust test-layout audit clean (9 crate(s))
Rust blank-line audit clean (32 file(s))
Rust item-spacing audit clean (32 file(s))
Rust module-order audit clean (32 file(s))
Rust trait-import-block audit clean (32 file(s))
Rust re-export-block audit clean (32 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
Les neuf packages compilent en `0.0.3-alpha.1.fix.1`.
```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 --workspace --all-targets --all-features PASS
```
Tests workspace observés :
```text
knowledge-app-lib 3 PASS
knowledge-domain-lib 3 PASS
knowledge-git-api 1 PASS
knowledge-git-lib 8 unit PASS + 2 integration PASS
knowledge-sync-api 1 PASS
knowledge-web-lib 4 PASS
launchers 0 test chacun
```
Les deux tests d'intégration Git réels continuent de prouver les chemins de lecture déjà acquis : refresh/résolution/snapshot, rejet d'une référence invalide et rejet d'un snapshot existant sale.
## Correction documentaire acquise dans le contenu
Le delta appliqué porte bien la correction décidée après `alpha.1` :
- l'entrée candidate `0.0.3` a été retirée du changelog ;
- le changelog est désormais défini comme artefact de stabilisation plutôt que de démarrage ;
- le prompt de `N+1` est normalement préparé pendant les dernières phases de `N` après revue d'horizon ;
- `prompts/003-V0_0_3_START_PROMPT.md` reste le rattrapage historique nécessaire pour `0.0.3` ;
- la roadmap distingue la release engagée d'un horizon prévisionnel révisable ;
- le plan `0.0.3` prévoit une revue d'horizon en `beta.1`.
La revue opérateur postérieure précise que l'horizon actuel reste volontairement incomplet : les futures revues devront aussi intégrer explicitement les phases de templates/frontends publics et admin des trois sites PGR, Snippets et Howtos, leur intégration Actix Web/Maud, ainsi que Git et PostgreSQL. Cette précision est un besoin d'horizon futur, pas un échec de la correction courante.
## Preuves manquantes
Le delta `alpha.1.fix.1` exigeait encore après les tests workspace :
```text
audit Python du cycle documentaire/horizon
hygiène texte des fichiers gouvernés
absence de diff sous crates/ et Web/
absence du history alpha.1.fix.1 pendant la gate
politique Cargo.lock
présence du package-lock Web
git add -A
git diff --cached --check
git status --short
```
Ces résultats ne figurent pas dans le transcript opérateur reçu. Ils ne sont donc ni inventés ni assimilés à un PASS.
## Décision
`0.0.3-alpha.1.fix.1` est `PARTIAL`.
La correction documentaire et la non-régression Rust observée sont acquises, mais la tranche ne peut pas être clôturée en `PASS` sans les preuves finales explicitement requises.
La transition autorisée est :
```text
appliquer ce history
-> git add / diff --cached --check / status
-> commit exact "0.0.3-alpha.1.fix.1"
-> push origin master
-> vérifier le workspace propre
-> appliquer seulement ensuite 0.0.3-alpha.1.fix.2
```
`alpha.1.fix.2` reste une correction de validation bornée : aucune fonctionnalité Git, Web ou PostgreSQL ne doit y être ajoutée. Un `PASS` de ce fix autorisera `alpha.2`.