0.1.2-alpha.2.fix.1
This commit is contained in:
44
Cargo.toml
44
Cargo.toml
@@ -1,44 +0,0 @@
|
||||
# file: Cargo.toml
|
||||
# version: 4
|
||||
|
||||
[workspace]
|
||||
resolver = "3"
|
||||
members = [
|
||||
"crates/knowledge-domain-lib",
|
||||
"crates/knowledge-git-api",
|
||||
"crates/knowledge-sync-api",
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.0.1-alpha.3.fix.2"
|
||||
edition = "2024"
|
||||
publish = false
|
||||
repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge"
|
||||
|
||||
[workspace.dependencies]
|
||||
knowledge-domain-lib = { path = "crates/knowledge-domain-lib" }
|
||||
|
||||
[workspace.lints.rust]
|
||||
missing_docs = "warn"
|
||||
unreachable_pub = "deny"
|
||||
unsafe_code = "forbid"
|
||||
|
||||
[workspace.lints.clippy]
|
||||
unwrap_used = "deny"
|
||||
expect_used = "deny"
|
||||
implicit_return = "deny"
|
||||
needless_return = "allow"
|
||||
useless_vec = "deny"
|
||||
question_mark = "deny"
|
||||
question_mark_used = "deny"
|
||||
needless_match = "allow"
|
||||
manual_ok_err = "allow"
|
||||
manual_unwrap_or = "allow"
|
||||
manual_map = "allow"
|
||||
match_like_matches_macro = "allow"
|
||||
single_match = "allow"
|
||||
manual_unwrap_or_default = "allow"
|
||||
manual_find = "allow"
|
||||
explicit_counter_loop = "allow"
|
||||
get_first = "allow"
|
||||
implicit_saturating_sub = "allow"
|
||||
@@ -1,17 +0,0 @@
|
||||
// file: crates/knowledge-domain-lib/src/content_family.rs
|
||||
// version: 2
|
||||
|
||||
//! Content-family identities owned by the Knowledge domain.
|
||||
|
||||
/// Semantic family of knowledge content.
|
||||
#[derive(Clone, Copy, Debug, Eq, Hash, PartialEq)]
|
||||
pub enum ContentFamily {
|
||||
/// Normative Project Governance Rules content.
|
||||
Pgr,
|
||||
/// Practical HOWTO content derived from concrete workflows.
|
||||
Howto,
|
||||
/// Reusable focused code or configuration snippet content.
|
||||
Snippet,
|
||||
/// Knowledge that remains local to one project and is not promoted to a shared family.
|
||||
ProjectLocal,
|
||||
}
|
||||
@@ -1,184 +0,0 @@
|
||||
<!-- file: deltas/0.0.1/alpha.3.fix.2.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.1-alpha.3.fix.2 — documentation publique `ContentFamily`
|
||||
|
||||
## Base requise
|
||||
|
||||
État `0.0.1-alpha.3.fix.1` committé et poussé après application du history :
|
||||
|
||||
```text
|
||||
history/0.0.1/alpha.3.fix.1.md = FAIL
|
||||
```
|
||||
|
||||
La version devient :
|
||||
|
||||
```text
|
||||
0.0.1-alpha.3.fix.2
|
||||
```
|
||||
|
||||
## Cause du second fix
|
||||
|
||||
Le premier fix a corrigé l'erreur `E0423` :
|
||||
|
||||
- `cargo check --workspace` termine ;
|
||||
- les trois suites ciblées passent ;
|
||||
- `SourceId::new("pgr")` est couvert par régression.
|
||||
|
||||
La gate reste néanmoins `FAIL` parce que Clippy est exécuté avec :
|
||||
|
||||
```text
|
||||
-D warnings
|
||||
```
|
||||
|
||||
et transforme en erreurs quatre warnings `missing_docs` sur les variantes publiques :
|
||||
|
||||
```text
|
||||
ContentFamily::Pgr
|
||||
ContentFamily::Howto
|
||||
ContentFamily::Snippet
|
||||
ContentFamily::ProjectLocal
|
||||
```
|
||||
|
||||
La politique `missing_docs` est intentionnelle. Le correctif ne doit donc ni la réduire ni introduire `#[allow(missing_docs)]`.
|
||||
|
||||
## Correctif
|
||||
|
||||
Le fichier :
|
||||
|
||||
```text
|
||||
crates/knowledge-domain-lib/src/content_family.rs
|
||||
```
|
||||
|
||||
documente explicitement chacune des quatre variantes publiques.
|
||||
|
||||
Aucun variant, contrat, type, trait, dépendance ou comportement n'est modifié.
|
||||
|
||||
## Scope
|
||||
|
||||
Le fix reste strictement correctif.
|
||||
|
||||
Il ne modifie pas :
|
||||
|
||||
- `GitRepository` ;
|
||||
- `RepositoryEventSource` ;
|
||||
- `RepositorySyncSignal` ;
|
||||
- le modèle de sources ;
|
||||
- la trajectoire Web/Maud/Vite ;
|
||||
- les décisions PostgreSQL/forge ;
|
||||
- les frontières des trois applications Web.
|
||||
|
||||
Aucun frontend, serveur Actix, adapter Gitea, schéma PostgreSQL ou nouvelle crate n'est ajouté.
|
||||
|
||||
## Fichiers remplacés
|
||||
|
||||
```text
|
||||
VERSION
|
||||
Cargo.toml
|
||||
crates/knowledge-domain-lib/src/content_family.rs
|
||||
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||
docs/validation/001-VALIDATION_MATRIX.md
|
||||
```
|
||||
|
||||
## Fichier ajouté
|
||||
|
||||
```text
|
||||
deltas/0.0.1/alpha.3.fix.2.md
|
||||
```
|
||||
|
||||
Aucun fichier n'est supprimé.
|
||||
|
||||
## `Cargo.lock`
|
||||
|
||||
Le delta ne livre pas de lockfile préfabriqué. Les packages héritent de la version workspace `0.0.1-alpha.3.fix.2`; Cargo peut donc mettre à jour `Cargo.lock` dans l'environnement opérateur. Toute modification réelle du lockfile reste versionnée.
|
||||
|
||||
## Validation attendue
|
||||
|
||||
Après application du history `alpha.3.fix.1 FAIL`, commit/push de `alpha.3.fix.1`, puis extraction du présent delta :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = "0.0.1-alpha.3.fix.2"
|
||||
|
||||
git diff --check
|
||||
|
||||
python3 - <<'PY'
|
||||
from pathlib import Path
|
||||
import tomllib
|
||||
|
||||
with Path("Cargo.toml").open("rb") as handle:
|
||||
root_manifest = tomllib.load(handle)
|
||||
|
||||
assert root_manifest["workspace"]["package"]["version"] == "0.0.1-alpha.3.fix.2"
|
||||
|
||||
content = Path(
|
||||
"crates/knowledge-domain-lib/src/content_family.rs"
|
||||
).read_text(encoding="utf-8")
|
||||
|
||||
for variant in ("Pgr", "Howto", "Snippet", "ProjectLocal"):
|
||||
marker = f" {variant},"
|
||||
index = content.index(marker)
|
||||
prefix = content[:index].rstrip().splitlines()
|
||||
assert prefix[-1].lstrip().startswith("///"), variant
|
||||
|
||||
assert "allow(missing_docs)" not in content
|
||||
assert "missing_docs = \"warn\"" in Path("Cargo.toml").read_text(encoding="utf-8")
|
||||
|
||||
print("Knowledge 0.0.1-alpha.3.fix.2 structural audit: clean")
|
||||
PY
|
||||
|
||||
cargo metadata --format-version 1 --no-deps > /tmp/sasedev-knowledge-alpha3-fix2-metadata.json
|
||||
|
||||
cargo fmt --all
|
||||
cargo fmt --all -- --check
|
||||
|
||||
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_export_completeness.py --root .
|
||||
|
||||
cargo check --workspace
|
||||
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
|
||||
cargo test -p knowledge-domain-lib --all-targets --all-features
|
||||
cargo test -p knowledge-git-api --all-targets --all-features
|
||||
cargo test -p knowledge-sync-api --all-targets --all-features
|
||||
|
||||
test -f Cargo.lock
|
||||
if git check-ignore -q Cargo.lock; then
|
||||
echo 'Cargo.lock must remain versioned' >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
python3 - <<'PY'
|
||||
import json
|
||||
from pathlib import Path
|
||||
|
||||
metadata = json.loads(
|
||||
Path("/tmp/sasedev-knowledge-alpha3-fix2-metadata.json").read_text(encoding="utf-8")
|
||||
)
|
||||
|
||||
packages = {package["name"] for package in metadata["packages"]}
|
||||
assert packages == {
|
||||
"knowledge-domain-lib",
|
||||
"knowledge-git-api",
|
||||
"knowledge-sync-api",
|
||||
}, packages
|
||||
|
||||
for package in metadata["packages"]:
|
||||
assert package["version"] == "0.0.1-alpha.3.fix.2", (
|
||||
package["name"],
|
||||
package["version"],
|
||||
)
|
||||
|
||||
print("Knowledge 0.0.1-alpha.3.fix.2 Cargo metadata audit: clean")
|
||||
PY
|
||||
|
||||
git add -A
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Ne pas committe `alpha.3.fix.2` avant production de son history à partir des résultats opérateur.
|
||||
213
deltas/0.1.2/alpha.2.fix.1.md
Normal file
213
deltas/0.1.2/alpha.2.fix.1.md
Normal file
@@ -0,0 +1,213 @@
|
||||
<!-- file: deltas/0.1.2/alpha.2.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.2-alpha.2.fix.1 — récupération de contamination inter-projet
|
||||
|
||||
## Baseline et diagnostic
|
||||
|
||||
Baseline Git observée et déjà publiée sur `origin/master` :
|
||||
|
||||
```text
|
||||
17b7ef23a18c913f986c7d57caf958d33479363d
|
||||
```
|
||||
|
||||
Le commit précédent observé est :
|
||||
|
||||
```text
|
||||
6e978bfed8c1ad10d1888cd3da92aeaf70338b7e
|
||||
```
|
||||
|
||||
La gate opérateur de `0.1.2-alpha.2` avait été exécutée avec succès avant cette chaîne de commits : tests Python, audits Markdown, gate Java/Gradle et contrôles de scope étaient `PASS`. `history/0.1.2/alpha.2.md` conserve donc ce résultat réel.
|
||||
|
||||
La publication de la tranche a ensuite été contaminée par des fichiers provenant d'un autre projet. Les preuves Git montrent notamment :
|
||||
|
||||
- `6e978bf` porte les vraies modifications PGR de `alpha.2`, mais ajoute aussi `history/0.0.1/alpha.3.fix.1.md` et utilise un message de commit étranger ;
|
||||
- `17b7ef2` ajoute `Cargo.toml`, `crates/knowledge-domain-lib/src/content_family.rs` et `deltas/0.0.1/alpha.3.fix.2.md` ;
|
||||
- `17b7ef2` remplace `docs/plans/001-V0_0_1_FOUNDATION_PLAN.md` et `docs/validation/001-VALIDATION_MATRIX.md` par du contenu Knowledge ;
|
||||
- `git diff --check 17b7ef2^ 17b7ef2` signale en plus une ligne vide finale parasite dans la matrice de validation ;
|
||||
- les commits étant déjà poussés, le présent fix restaure l'état PGR par un nouveau commit et ne réécrit pas l'historique distant.
|
||||
|
||||
Version avant correction au niveau Git publié : état contaminé après `0.1.2-alpha.2`.
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.1.2-alpha.2.fix.1
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Ramener la branche publiée à l'état PGR attendu après `alpha.2`, tout en préservant les vraies modifications Java/Maven/Gradle et leur history `PASS`.
|
||||
|
||||
Ce fix est exclusivement un correctif de provenance et d'hygiène Git. Il ne change aucune décision normative de `alpha.2` et n'absorbe ni le REPLAN Java/Maven/Gradle préparé pour la tranche suivante ni le scope Android réservé à `0.1.3`.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||
docs/validation/001-VALIDATION_MATRIX.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
deltas/0.1.2/alpha.2.fix.1.md
|
||||
manifests/0.1.2/alpha.2.fix.1.delete.txt
|
||||
```
|
||||
|
||||
DELETE :
|
||||
|
||||
```text
|
||||
Cargo.toml
|
||||
crates/knowledge-domain-lib/src/content_family.rs
|
||||
deltas/0.0.1/alpha.3.fix.2.md
|
||||
history/0.0.1/alpha.3.fix.1.md
|
||||
```
|
||||
|
||||
Le manifest de suppression doit contenir exactement ces quatre chemins.
|
||||
|
||||
Les fichiers suivants de `alpha.2` MUST rester inchangés par le fix :
|
||||
|
||||
```text
|
||||
deltas/0.1.2/alpha.2.md
|
||||
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
|
||||
docs/rules/520-JAVA_MAVEN_GRADLE.md
|
||||
history/0.1.2/alpha.2.md
|
||||
```
|
||||
|
||||
`docs/rules/610-ANDROID.md` reste également inchangé.
|
||||
|
||||
## Restauration autoritaire
|
||||
|
||||
`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md` et `docs/validation/001-VALIDATION_MATRIX.md` n'étaient modifiés ni par `alpha.1` ni par `alpha.2`. Leur contenu attendu est donc exactement celui de la stable `v0.1.1`.
|
||||
|
||||
Le fix restaure ces deux fichiers depuis cette baseline au lieu de tenter de corriger manuellement le contenu Knowledge injecté.
|
||||
|
||||
## Application du manifest
|
||||
|
||||
Après extraction du delta, appliquer explicitement le manifest de suppression :
|
||||
|
||||
```bash
|
||||
while IFS= read -r path; do
|
||||
case "$path" in
|
||||
''|'#'*) continue ;;
|
||||
esac
|
||||
rm -f -- "$path"
|
||||
done < manifests/0.1.2/alpha.2.fix.1.delete.txt
|
||||
```
|
||||
|
||||
Les éventuels répertoires devenus vides ne sont pas des chemins suivis par Git et n'affectent pas le contenu publié.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Le stash `pgr-0.1.2-alpha.3-before-alpha.2-recovery` doit rester intact pendant toute cette gate. Ne pas exécuter `stash pop` avant fermeture du fix.
|
||||
|
||||
```bash
|
||||
test "$(git rev-parse HEAD)" = '17b7ef23a18c913f986c7d57caf958d33479363d'
|
||||
test "$(git rev-parse origin/master)" = '17b7ef23a18c913f986c7d57caf958d33479363d'
|
||||
test "$(cat VERSION)" = '0.1.2-alpha.2.fix.1'
|
||||
|
||||
test -f history/0.1.2/alpha.2.md
|
||||
grep -A2 '^## Statut$' history/0.1.2/alpha.2.md | grep -Fx 'PASS'
|
||||
test -f deltas/0.1.2/alpha.2.fix.1.md
|
||||
test ! -e history/0.1.2/alpha.2.fix.1.md
|
||||
|
||||
test ! -e Cargo.toml
|
||||
test ! -e crates/knowledge-domain-lib/src/content_family.rs
|
||||
test ! -e deltas/0.0.1/alpha.3.fix.2.md
|
||||
test ! -e history/0.0.1/alpha.3.fix.1.md
|
||||
|
||||
git diff --exit-code v0.1.1 -- \
|
||||
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md \
|
||||
docs/validation/001-VALIDATION_MATRIX.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
|
||||
grep -Fx '<!-- version: 3 -->' docs/rules/520-JAVA_MAVEN_GRADLE.md
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/610-ANDROID.md
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_markdown_headers.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
python3 -B scripts/audit_markdown_tables.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
python3 -B scripts/audit_markdown_links.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
|
||||
python3 -B - <<'PYGATE'
|
||||
from pathlib import Path
|
||||
import re
|
||||
|
||||
manifest = Path('manifests/0.1.2/alpha.2.fix.1.delete.txt')
|
||||
paths = [line.strip() for line in manifest.read_text(encoding='utf-8').splitlines() if line.strip() and not line.lstrip().startswith('#')]
|
||||
expected = [
|
||||
'Cargo.toml',
|
||||
'crates/knowledge-domain-lib/src/content_family.rs',
|
||||
'deltas/0.0.1/alpha.3.fix.2.md',
|
||||
'history/0.0.1/alpha.3.fix.1.md',
|
||||
]
|
||||
assert paths == expected, (paths, expected)
|
||||
for path in expected:
|
||||
assert not Path(path).exists(), path
|
||||
|
||||
history = Path('history/0.1.2/alpha.2.md').read_text(encoding='utf-8')
|
||||
assert re.search(r'## Statut\s+PASS\s', history)
|
||||
|
||||
alpha2 = Path('deltas/0.1.2/alpha.2.md').read_text(encoding='utf-8')
|
||||
assert '# Delta 0.1.2-alpha.2 — révision ciblée Java / Gradle' in alpha2
|
||||
|
||||
plan = Path('docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
|
||||
assert plan.startswith('<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->\n<!-- version: 2 -->')
|
||||
|
||||
profile = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8')
|
||||
assert profile.startswith('<!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->\n<!-- version: 3 -->')
|
||||
|
||||
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
|
||||
assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 2 -->')
|
||||
|
||||
for forbidden in (
|
||||
'knowledge-domain-lib',
|
||||
'# Matrice de validation Knowledge',
|
||||
'knowledge-pgr-server',
|
||||
):
|
||||
assert forbidden not in Path('docs/validation/001-VALIDATION_MATRIX.md').read_text(encoding='utf-8'), forbidden
|
||||
|
||||
print('0.1.2 alpha.2.fix.1 recovery audit: clean (foreign Knowledge paths removed, PGR baseline restored, alpha.2 preserved)')
|
||||
PYGATE
|
||||
|
||||
git diff --check
|
||||
git add -A
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu est :
|
||||
|
||||
```text
|
||||
D Cargo.toml
|
||||
M VERSION
|
||||
D crates/knowledge-domain-lib/src/content_family.rs
|
||||
D deltas/0.0.1/alpha.3.fix.2.md
|
||||
A deltas/0.1.2/alpha.2.fix.1.md
|
||||
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||
M docs/validation/001-VALIDATION_MATRIX.md
|
||||
D history/0.0.1/alpha.3.fix.1.md
|
||||
A manifests/0.1.2/alpha.2.fix.1.delete.txt
|
||||
```
|
||||
|
||||
L'ordre exact peut varier ; l'ensemble des chemins doit être identique.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.2/alpha.2.fix.1.md`, commit/push sous l'identité `0.1.2-alpha.2.fix.1`, puis abandonner le stash préparé à partir de l'ancien HEAD contaminé et réémettre la tranche `alpha.3` sur la baseline corrigée.
|
||||
|
||||
La tranche `alpha.3` devra être régénérée ; le stash actuel sert uniquement de sauvegarde de sécurité et ne doit pas devenir la source autoritaire du nouveau delta.
|
||||
|
||||
### FAIL
|
||||
|
||||
Conserver les résultats réels dans `history/0.1.2/alpha.2.fix.1.md` et poursuivre sous `alpha.2.fix.N`. Ne pas restaurer `alpha.3` tant que l'état PGR publié n'est pas propre.
|
||||
@@ -1,214 +1,98 @@
|
||||
<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Plan 0.0.1 — fondation SaseDev Knowledge
|
||||
# Plan 0.0.1 — fondation de PGR
|
||||
|
||||
## Statut et sources
|
||||
## Statut
|
||||
|
||||
Plan actif préparé après vérification de la stable PGR `v0.1.1` et de `pgr-0.1.1-publish.001-report.md` `PASS`.
|
||||
Plan clôturé par la promotion stable `0.0.1` après validation de `0.0.1-rc.1.fix.1`.
|
||||
|
||||
Sources de cadrage :
|
||||
|
||||
```text
|
||||
PGR v0.1.1 archive SHA-256
|
||||
caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
|
||||
|
||||
Knowledge start prompt
|
||||
prompts/001-V0_0_1_START_PROMPT.md
|
||||
```
|
||||
Aucune stable PGR antérieure n'existait. Cette version rend le dépôt capable de se gouverner lui-même avant l'introduction des profils technologiques et templates prévus dans les releases suivantes.
|
||||
|
||||
## Mission
|
||||
|
||||
`0.0.1` doit rendre le nouveau dépôt suffisamment gouverné, reproductible et architecturalement découplé pour commencer ensuite l'implémentation de Knowledge sans coupler le domaine à Gitea, PostgreSQL, Actix ou une représentation éditoriale prématurée.
|
||||
`0.0.1` doit établir la fondation normative, documentaire et opératoire de Project Governance Rules.
|
||||
|
||||
La release doit établir :
|
||||
La release doit notamment fixer :
|
||||
|
||||
- la gouvernance PGR locale ;
|
||||
- la composition des owners/skeletons réellement applicables ;
|
||||
- la topologie du workspace à trois applications Actix Web distinctes ;
|
||||
- les frontières Git générique / forge optionnelle / PostgreSQL ;
|
||||
- les frontières PGR / HOWTO / snippet / project-local ;
|
||||
- un workspace Rust minimal strict et reproductible ;
|
||||
- une baseline frontend indépendante du backend selon les owners Web PGR ;
|
||||
- de premiers contrats ciblés sans implémentation disproportionnée ;
|
||||
- une validation suffisante pour promouvoir une stable `0.0.1`.
|
||||
- la finalité et les non-objectifs de PGR ;
|
||||
- la hiérarchie `MUST` / `SHOULD` / `MAY` et les règles de scope/override/exception ;
|
||||
- le modèle SemVer et le rôle de `VERSION` ;
|
||||
- le lifecycle `alpha` → `beta` → `rc` → stable et les `.fix.N` ;
|
||||
- le cadrage obligatoire de `alpha.1`, le replan et l'abandon/supersession ;
|
||||
- les rôles de `README`, `RULES`, `ROADMAP`, `CHANGELOG` et des collections documentaires ;
|
||||
- les contrats des plans, deltas, historiques, prompts, handoffs et manifests ;
|
||||
- la séparation TEST / AUDIT / DIAGNOSTIC ;
|
||||
- la validation proportionnée et l'autorité du gate opérateur ;
|
||||
- les règles de reprise de session et de baseline ZIP taggée ;
|
||||
- la préparation du prompt de démarrage de `0.0.2`.
|
||||
|
||||
## État acquis et questions ouvertes
|
||||
## Hors périmètre
|
||||
|
||||
Acquis par le cadrage `alpha.1.fix.1` :
|
||||
`0.0.1` ne doit pas encore :
|
||||
|
||||
- dépôt applicatif/workspace `sasedev-knowledge`, nom court `knowledge` ;
|
||||
- trois launchers publics retenus : `knowledge-pgr-server`, `knowledge-howtos-server`, `knowledge-snippets-server` ;
|
||||
- au moins trois sources Git indépendantes : `pgr`, `howtos`, `snippets` ;
|
||||
- Git autoritaire pour le contenu ;
|
||||
- forge facultative derrière adapter ;
|
||||
- une base PostgreSQL logique partagée pour l'état transversal et les projections ;
|
||||
- crates communes privilégiées à la duplication entre launchers ;
|
||||
- Rust stable/édition 2024 ;
|
||||
- Actix Web, Maud, Vite, TypeScript, Sass, Bootstrap et PostgreSQL retenus comme intentions locales conformes aux owners applicables ;
|
||||
- préférence Eclipse UTF-8 versionnée conformément à la politique PGR ;
|
||||
- aucun override PGR nécessaire.
|
||||
- formaliser en détail tous les profils Rust, Java, Android, Tauri, Web, PHP, Python, C/C++ ;
|
||||
- produire le catalogue final des templates techniques ;
|
||||
- fournir des skeleton specifications complets par type de projet ;
|
||||
- créer un générateur PGR ;
|
||||
- anticiper des audits spécialisés sans besoin concret ;
|
||||
- réappliquer PGR à KSP ou games, travail réservé à une release ultérieure.
|
||||
|
||||
Restent volontairement ouverts jusqu'à la tranche qui les consomme :
|
||||
## Principes de dimensionnement
|
||||
|
||||
- package manager et lockfile frontend ;
|
||||
- modèle détaillé des rôles/capabilities ;
|
||||
- racine(s) et partage concret du frontend entre les trois applications ;
|
||||
- driver/ORM et migrations PostgreSQL ;
|
||||
- éventuel découpage en schémas PostgreSQL ;
|
||||
- moteur de recherche ;
|
||||
- fournisseur d'identité ;
|
||||
- adapter forge réel ;
|
||||
- formats finaux HOWTO/snippet ;
|
||||
- URL et routage exacts des surfaces d'administration/login ;
|
||||
- décision d'une éventuelle quatrième application d'administration transverse ;
|
||||
- liste définitive des crates de bibliothèque.
|
||||
Une tranche doit rester cohérente et validable indépendamment. La cible de 15 à 30 minutes de travail effectif reste une heuristique de dimensionnement, pas une deadline.
|
||||
|
||||
## Scope
|
||||
Si le plan devient manifestement faux, un `alpha.N` peut jouer le rôle de REPLAN. Une version n'est jamais forcée vers stable uniquement pour respecter une session de conversation.
|
||||
|
||||
`0.0.1` inclut :
|
||||
## Prévision
|
||||
|
||||
- documentation de gouvernance et architecture ;
|
||||
- workspace Rust/Cargo minimal ;
|
||||
- configuration de toolchain/lints proportionnée ;
|
||||
- trois packages serveur distincts uniquement lorsque leur composition devient utile ;
|
||||
- premiers types/traits de boundary lorsque leur responsabilité est claire ;
|
||||
- baseline Web minimale et reproductible ;
|
||||
- validation indépendante backend/frontend ;
|
||||
- documentation de fermeture et handoff de la stable.
|
||||
### alpha.1 — Bootstrap and framing
|
||||
|
||||
## Hors scope
|
||||
Créer la baseline minimale : identité, `.gitignore`, `VERSION`, documents racine, objectifs, profil du dépôt, architecture de gouvernance, index des règles, matrice de validation, plan actif, delta et prompt initial.
|
||||
|
||||
`0.0.1` n'implémente pas :
|
||||
Aucune implémentation massive des règles détaillées n'est réalisée dans cette tranche.
|
||||
|
||||
- moteur de recherche complet ;
|
||||
- UI d'administration complète ;
|
||||
- workflow complet de contribution ;
|
||||
- adapter multi-forge complet ;
|
||||
- intégration Gitea obligatoire ;
|
||||
- schéma PostgreSQL métier complet ;
|
||||
- authentification complète ;
|
||||
- production multi-domaines ;
|
||||
- moteur de rendu final de tous les formats ;
|
||||
- architecture de microservices distribués ;
|
||||
- quatrième application d'administration sans besoin démontré.
|
||||
### alpha.2 — Core governance rules
|
||||
|
||||
## Stratégie de validation
|
||||
Formaliser les règles communes de versioning et lifecycle : SemVer, `VERSION`, maturité, fixes, cadrage `alpha.1`, replan, abandon/supersession, stable promotion et publication.
|
||||
|
||||
Les gates suivent [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-VALIDATION_MATRIX.md).
|
||||
### alpha.3 — Workflow artifacts
|
||||
|
||||
Principes :
|
||||
Formaliser plans, deltas, history, prompts, handoffs, manifests de suppression, workflow PASS/FAIL et reprise après interruption.
|
||||
|
||||
- gate documentaire pour `alpha.1` et ses fixes ;
|
||||
- politique Eclipse explicitement contrôlée ;
|
||||
- Cargo officiel dès matérialisation Rust ;
|
||||
- audits Rust structurels PGR seulement s'ils apportent une preuve distincte ;
|
||||
- package manager/TypeScript/Vite/Sass officiels dès matérialisation Web ;
|
||||
- backend et frontend validables séparément ;
|
||||
- chaque launcher serveur reçoit un smoke seulement lorsqu'une propriété runtime réelle est introduite ;
|
||||
- aucune prévalidation assistant ne vaut `PASS` opérateur.
|
||||
### alpha.4 — Documentation governance
|
||||
|
||||
## Trajectoire prévisionnelle
|
||||
Formaliser les rôles des documents, taxonomie documentaire, headers, révisions internes, déplacement/split/fusion, conservation historique, objectifs, ideas/studies/architecture/reference et politique de langue.
|
||||
|
||||
### alpha.1 — cadrage et gouvernance
|
||||
### alpha.5 — Validation governance
|
||||
|
||||
Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage.
|
||||
Formaliser la matrice de validation, sélection proportionnelle, TEST/AUDIT/DIAGNOSTIC, opérateur autoritaire, tests utiles/non redondants, mocks lorsque pertinents et transitions de gate.
|
||||
|
||||
Le résultat opérateur initial est `FAIL`. Le fix `alpha.1.fix.1` corrige la politique Eclipse, la gate de fichiers et la topologie produit à trois applications. Sa gate opérateur est `PASS`.
|
||||
### beta.1 — Foundation reconciliation
|
||||
|
||||
Aucun code fonctionnel n'est ajouté dans `alpha.1` ou son fix.
|
||||
Réconcilier les documents de fondation, éliminer duplications et contradictions, vérifier navigation, rôles, scopes et complétude de `0.0.1`.
|
||||
|
||||
### alpha.2 — workspace Rust/Cargo minimal
|
||||
### rc.1 — Foundation release candidate
|
||||
|
||||
Statut opérateur : **PASS**.
|
||||
Geler le scope, préparer l'entrée candidate de changelog et le prompt `0.0.2`, puis exécuter la gate documentaire complète applicable.
|
||||
|
||||
Le skeleton `002-RUST_CARGO_WORKSPACE` est matérialisé avec `knowledge-domain-lib`, `Cargo.lock` versionné, artefacts Cargo hors dépôt et étude auth/admin séparant fonctionnalités réelles et intentions historiques. Les gates `metadata`, `fmt`, `check`, Clippy et tests workspace sont propres.
|
||||
### stable — 0.0.1
|
||||
|
||||
### alpha.3 — contrats domaine/Git/synchronisation
|
||||
Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer `rel.001`, commit/tag `v0.0.1`, puis utiliser l'archive ZIP taggée comme baseline autoritaire de `0.0.2`.
|
||||
|
||||
Statut opérateur initial : **FAIL**.
|
||||
## Clôture
|
||||
|
||||
La gate valide la structure et les audits puis échoue dans `knowledge-domain-lib` : `SourceId::new` tente de construire le tuple struct privé via le re-export crate-root depuis son sous-module. Le même défaut bloque `cargo check`, Clippy et les trois suites ciblées.
|
||||
La release candidate a nécessité `rc.1.fix.1` pour corriger exclusivement une commande de gate incompatible avec l'expansion d'historique d'un Bash interactif. La gate RC complète a ensuite été validée PASS sans modification du scope normatif.
|
||||
|
||||
`alpha.3.fix.1` corrige ce défaut Rust, ajoute une régression directe de construction `SourceId` et précise la trajectoire Web/Maud fournie avant clôture de la tranche ; il ne démarre aucune implémentation frontend ou serveur. Sa gate opérateur reste toutefois **FAIL** : `cargo check` et les tests passent, mais Clippy strict rejette les quatre variantes publiques de `ContentFamily` non documentées sous `missing_docs`.
|
||||
La promotion stable `rel.001` clôt le plan en mettant à jour uniquement les métadonnées vivantes de release et en préparant le tag `v0.0.1`.
|
||||
|
||||
`alpha.3.fix.2` corrige exclusivement cette dette de documentation publique et rejoue la gate Rust complète sans modifier les contrats domaine/Git/synchronisation ni le cadrage Web/Maud.
|
||||
## Critères de fermeture
|
||||
|
||||
Le scope fonctionnel de `alpha.3` reste : introduire uniquement les premiers contrats/types nécessaires aux frontières `GitRepository`, source/famille de contenu et synchronisation, avec tests ciblés. Le modèle doit supporter au moins les trois sources initiales sans coder une limite à trois.
|
||||
`0.0.1` est fermée lorsque :
|
||||
|
||||
Matérialiser `knowledge-git-api` et `knowledge-sync-api` parce que ces frontières ont des implémentations réellement remplaçables/multiples. Garder ces crates passives ; ne pas créer `knowledge-git-lib`, worker, Gitea ou persistence par anticipation.
|
||||
|
||||
Adopter les audits Rust PGR de structure/façade désormais utiles avec les premiers items publics partagés. Ne pas activer globalement l'audit `const`, qui reste sélection explicite par fichier.
|
||||
|
||||
Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
|
||||
|
||||
### alpha.4 — baseline Web indépendante et templates de référence
|
||||
|
||||
Instancier obligatoirement le skeleton `003-WEB_FRONTEND` : choisir package manager et lockfile, TypeScript strict, Vite, Sass et Bootstrap, avec typecheck/build indépendants du backend.
|
||||
|
||||
Le frontend sert d’abord de laboratoire de templates statiques : développer et valider indépendamment le markup de référence, les comportements TypeScript, le responsive Bootstrap et les styles Sass avant adaptation du markup runtime en Maud. Les pages statiques ne deviennent pas une seconde UI de production.
|
||||
|
||||
Activer le manifest de build Vite et définir des clés d’entrée stables pour les assets réellement destinés aux pages Maud. Les outputs restent générés/hors Git conformément à PGR.
|
||||
|
||||
Décider à cette tranche si les trois applications partagent un package d'assets/frontend ou possèdent des entrées séparées. Ne pas dupliquer par défaut, ne pas imposer non plus un frontend unique sans preuve de réutilisation. Définir également une preuve minimale contre la dérive entre templates statiques de référence et future adaptation Maud.
|
||||
|
||||
### alpha.5 — composition Actix/Maud et manifest Vite
|
||||
|
||||
Matérialiser le minimum Actix Web/Maud nécessaire pour prouver trois launchers minces et intégrer les assets produits par `alpha.4` :
|
||||
|
||||
```text
|
||||
knowledge-pgr-server
|
||||
knowledge-howtos-server
|
||||
knowledge-snippets-server
|
||||
```
|
||||
|
||||
Ils doivent composer les mêmes contrats/bibliothèques lorsque la responsabilité est partagée et rester capables de recevoir des configurations de sources Git distinctes.
|
||||
|
||||
Le HTML runtime est rendu avec Maud. En développement, la composition MAY cibler le dev server Vite configuré ; en production, elle MUST résoudre les assets hashés via le manifest Vite ou un mapping équivalent produit par la chaîne Web. Le pattern de `actix-auth-app` est à adapter sous les règles Knowledge, notamment sans `panic!` et sans origin/port codé en dur.
|
||||
|
||||
La tranche ne doit pas introduire admin complète, auth complète, persistance métier complète ni forge obligatoire.
|
||||
|
||||
### beta.1 — réconciliation de fondation
|
||||
|
||||
Rejouer les gates pertinentes, réconcilier docs/architecture avec ce qui existe réellement, traiter les décisions devenues nécessaires et effectuer la revue d'horizon.
|
||||
|
||||
Aucune nouvelle grande fonctionnalité ne doit être introduite en beta par défaut.
|
||||
|
||||
### rc.1 — candidate stable
|
||||
|
||||
Clôturer les défauts de cohérence, préparer la présentation stable, le handoff suivant et vérifier l'absence de scope futur introduit par anticipation.
|
||||
|
||||
### rel.1 — fermeture stable
|
||||
|
||||
Exécuter la gate de release, produire le premier history `rel.N[/fix.M]` réellement `PASS`, matérialiser le commit produit `0.0.1`, publier le tag stable selon la politique Git retenue et effectuer la vérification post-tag requise.
|
||||
|
||||
## Déclencheurs de REPLAN
|
||||
|
||||
REPLAN obligatoire si :
|
||||
|
||||
- une tranche nécessite plusieurs responsabilités non prévues qui ne peuvent plus être validées proprement ensemble ;
|
||||
- un choix de crate impose un couplage du domaine à Actix/Gitea/PostgreSQL ;
|
||||
- les trois launchers entraînent une duplication de logique qui devrait être possédée par une crate commune ;
|
||||
- une future administration transverse tente de contourner ou remplacer les contrôles d'autorisation propres aux trois applications ;
|
||||
- le frontend ne peut pas être validé indépendamment du host sans raison architecturale réelle ;
|
||||
- le choix Git impose une API de forge pour une opération fondamentale ;
|
||||
- la base PostgreSQL partagée impose un couplage de contenu qui contredit l'autorité Git ;
|
||||
- le format de contenu doit être figé sans corpus représentatif ;
|
||||
- trois fixes ou plus apparaissent sur une même tranche ;
|
||||
- un prérequis externe invalide la mission de fondation.
|
||||
|
||||
## Clôture et transition
|
||||
|
||||
- documentation durable : réconciliée à chaque tranche qui change son contrat, puis revue en `beta.1` ;
|
||||
- `CHANGELOG.md` : entrée candidate tenue à jour puis finalisée en `rel.1` ;
|
||||
- `ROADMAP.md` : revue d'horizon en `beta.1`, sans création automatique d'une prochaine version ;
|
||||
- prompt/handoff suivant : préparé avant la clôture une fois la prochaine mission réellement décidée ;
|
||||
- fermeture du plan : `rel.1` ou son fix qui établit la stable ;
|
||||
- publication : commit produit `0.0.1`, tag stable puis rapport post-tag séparé.
|
||||
|
||||
## Revue d'horizon
|
||||
|
||||
- état : requise en `beta.1` ;
|
||||
- raison : aucune version après `0.0.1` n'est suffisamment cadrée pour être réservée aujourd'hui ;
|
||||
- sorties autorisées : engager une prochaine version avec mission réelle, laisser l'horizon ouvert ou différer la suite ;
|
||||
- interdiction : fabriquer un numéro uniquement pour satisfaire une cadence documentaire.
|
||||
- PGR peut expliquer et appliquer son propre cycle de version ;
|
||||
- les responsabilités des principaux artefacts de gouvernance sont non ambiguës ;
|
||||
- la validation d'une tranche peut être sélectionnée proportionnellement ;
|
||||
- une interruption ou reprise de session est gouvernée ;
|
||||
- le passage RC → stable → tag → archive suivante est défini ;
|
||||
- aucune règle technologique détaillée hors fondation n'est nécessaire pour comprendre le workflow PGR.
|
||||
|
||||
@@ -1,216 +1,104 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 14 -->
|
||||
|
||||
# Matrice de validation Knowledge
|
||||
# Matrice de validation PGR
|
||||
|
||||
## Principe
|
||||
## Rôle
|
||||
|
||||
La gate opérateur sélectionne les preuves nécessaires au scope réellement modifié. Une commande n'est pas exécutée uniquement pour augmenter le nombre de checks.
|
||||
Cette matrice décrit les validations canoniques du dépôt PGR. Elle évolue avec le projet et ne doit pas inventer des scripts uniquement pour remplir une case.
|
||||
|
||||
La prévalidation de génération ne vaut pas preuve opérateur.
|
||||
La matrice définit les contrôles disponibles ; chaque delta sélectionne uniquement ceux qui sont nécessaires pour son scope et les preuves qu'il peut avoir invalidées.
|
||||
|
||||
## Fondation documentaire
|
||||
Les catégories et règles de sélection sont définies dans [`../rules/400-VALIDATION.md`](../rules/400-VALIDATION.md).
|
||||
|
||||
Pour une tranche limitée à gouvernance/documentation :
|
||||
## Contrôles actifs
|
||||
|
||||
```text
|
||||
CHECK VERSION attendue
|
||||
CHECK git diff --check
|
||||
AUDIT fichiers Git suivis/non ignorés conformes au delta, sans confondre fichiers locaux ignorés et distribution
|
||||
AUDIT headers file/version des Markdown gouvernés
|
||||
AUDIT headers file/version des formats texte qui adoptent explicitement cette convention
|
||||
AUDIT liens Markdown locaux principaux
|
||||
REVIEW owners PGR / décisions locales / DEFER explicites
|
||||
REVIEW absence de secret, chemin machine absolu et placeholder non résolu
|
||||
```
|
||||
| ID | Catégorie | Commande / contrôle | Prérequis | Trigger | Phase | Coût | Acteur |
|
||||
|---------------------|-----------|--------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
|
||||
| `PGR-GIT-001` | `CHECK` | `git diff --check` ou `git diff --cached --check` selon l'état de l'index | Git | toute modification suivie | alpha/beta/RC/stable | faible | opérateur |
|
||||
| `PGR-VERSION-001` | `CHECK` | comparer `VERSION` à la version attendue par le delta courant | fichier `VERSION` | changement de tranche/version | alpha/beta/RC/stable | faible | opérateur |
|
||||
| `PGR-LAYOUT-001` | `AUDIT` | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta | scope du delta | changement de structure | alpha/beta/RC/stable | faible | opérateur/revue |
|
||||
| `PGR-DOC-001` | `AUDIT` | vérifier chemins, rôles et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
|
||||
| `PGR-MD-HEADER-001` | `AUDIT` | `python3 -B scripts/audit_markdown_headers.py <paths...>` | Python 3 | Markdown gouverné modifié | alpha/beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-MD-TABLE-001` | `AUDIT` | `python3 -B scripts/audit_markdown_tables.py <paths...>` | Python 3 | table Markdown ajoutée/modifiée | alpha/beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-NAV-001` | `AUDIT` | `python3 -B scripts/audit_markdown_links.py <paths...>` | Python 3 | navigation ou réconciliation | alpha/beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-SCOPE-001` | `AUDIT` | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants | réconciliation de phase | beta/RC/stable | faible | revue |
|
||||
| `PGR-STATUS-001` | `CHECK` | `git status --short` | Git | avant fermeture d'une tranche | alpha/beta/RC/stable | faible | opérateur |
|
||||
|
||||
## Politique Eclipse
|
||||
Un contrôle manuel peut rester dans la matrice lorsqu'aucun audit automatisé fiable n'existe encore. PGR SHOULD automatiser uniquement les propriétés stables et objectivement contrôlables.
|
||||
|
||||
Les métadonnées Eclipse spécifiques à la machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
|
||||
`PGR-MD-TABLE-001` reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown. Il couvre les tableaux Markdown ordinaires ainsi que les exemples placés dans des fences explicitement `markdown` ou `md`. Les autres blocs fenced restent ignorés afin de ne pas interpréter comme Markdown des sorties terminal, extraits de code ou tableaux ASCII d'un autre langage.
|
||||
|
||||
Le fichier suivant constitue l'exception versionnée :
|
||||
`PGR-MD-HEADER-001` contrôle seulement les deux premières lignes des fichiers Markdown sélectionnés : chemin relatif depuis la racine et révision interne positive. La revue `PGR-DOC-001` reste responsable du rôle documentaire et de la pertinence réelle d'un incrément de révision.
|
||||
|
||||
`PGR-NAV-001` est automatisé séparément par `audit_markdown_links.py`. Il vérifie uniquement l'existence des cibles de liens Markdown locaux inline, sans contrôler les anchors, les headers, les responsabilités documentaires ou la forme des tableaux.
|
||||
|
||||
PGR préfère plusieurs audits simples avec une responsabilité identifiable à un script unique qui agrège des règles indépendantes.
|
||||
|
||||
## Contrôles Rust réutilisables, hors gate du dépôt PGR
|
||||
|
||||
[`002-RUST_STYLE_AUDITS.md`](002-RUST_STYLE_AUDITS.md) décrit les audits monotâches de structure Rust : lignes vides, blocs `const`, séparation des items, ordre des modules, disposition des imports de traits et blocs de réexports. Ils acceptent des chemins Rust sélectionnés et partagent un petit support lexical ; leur validation ciblée dans PGR est `python3 -B -m unittest discover -s tests -p test_rust_audits.py -v`.
|
||||
|
||||
Pour une nouvelle baseline contrôlée, les propriétés sans ordre métier peuvent faire partie du profil strict. L'audit `const_blocks` reste explicitement sélectionné, car une table de protocole, un schéma ou une séquence normative ne doit jamais être réordonné pour satisfaire un tri mécanique. Leur disponibilité ne transforme pas PGR en workspace Rust ; le projet propriétaire exécute ces audits après `cargo fmt`, et Rustfmt/Clippy/rustc conservent les contrôles qu'ils possèdent.
|
||||
|
||||
[`003-RUST_EXPORT_COMPLETENESS.md`](003-RUST_EXPORT_COMPLETENESS.md) décrit séparément `audit_rust_export_completeness.py`, audit facultatif de façade crate-root. Sa validation ciblée dans PGR est `python3 -B -m unittest discover -s tests -p test_rust_export_completeness.py -v`. L'audit est destiné aux projets Rust qui choisissent explicitement ce contrat ; PGR n'exécute pas ce script sur son propre dépôt comme gate, car il ne constitue pas lui-même un workspace Rust.
|
||||
|
||||
[`004-RUST_CARGO_BASELINE_DRY_RUN.md`](004-RUST_CARGO_BASELINE_DRY_RUN.md) décrit une preuve temporaire de réutilisabilité des skeletons/templates Rust/Cargo. Le mode « nouveau projet » utilise la toolchain officielle dans un répertoire temporaire ; le mode « projet existant » vérifie qu’un mapping d’adoption n’écrase pas les décisions locales classées `KEEP-LOCAL` ou `DEFER`. Cette preuve est sélectionnée lorsque les artefacts Rust/Cargo eux-mêmes changent ou lorsqu’une phase de release doit reconfirmer leur composabilité ; elle n’est pas une cérémonie de chaque delta documentaire.
|
||||
|
||||
## Validation frontend Web réutilisable, hors gate du dépôt PGR
|
||||
|
||||
[`005-WEB_FRONTEND_VALIDATION.md`](005-WEB_FRONTEND_VALIDATION.md) décrit la validation indépendante du host pour un frontend réel : restauration reproductible selon le package manager choisi, type-check TypeScript, styles, build de production et smoke navigateur seulement lorsqu'il apporte une preuve supplémentaire.
|
||||
|
||||
Cette validation appartient aux projets qui possèdent réellement un frontend ou aux dry-runs de skeletons correspondants. Le dépôt PGR n'installe pas TypeScript, Vite ou Sass uniquement pour simuler une gate qu'il ne possède pas. Les outils officiels restent propriétaires de leurs preuves ; un audit Python PGR ne les réimplémente pas.
|
||||
|
||||
## Politique Eclipse actuelle
|
||||
|
||||
Les métadonnées Eclipse spécifiques à une machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
|
||||
|
||||
Le fichier suivant constitue une exception versionnée, car il porte l'encodage UTF-8 du projet et n'est pas nécessairement régénéré lors d'un import Git :
|
||||
|
||||
```text
|
||||
.settings/org.eclipse.core.resources.prefs
|
||||
```
|
||||
|
||||
Il doit contenir :
|
||||
|
||||
```text
|
||||
eclipse.preferences.version=1
|
||||
encoding/<project>=UTF-8
|
||||
```
|
||||
|
||||
Le `.gitignore` doit contenir :
|
||||
Le `.gitignore` doit donc contenir :
|
||||
|
||||
```text
|
||||
.settings/*
|
||||
!.settings/org.eclipse.core.resources.prefs
|
||||
```
|
||||
|
||||
Une gate de distribution ne doit donc pas échouer parce qu'un `.project` ignoré existe dans le workspace local. Elle doit en revanche échouer si `org.eclipse.core.resources.prefs` est ignoré ou absent du contenu suivi.
|
||||
## Gate documentaire courante
|
||||
|
||||
## Rust/Cargo
|
||||
Pour une tranche documentaire, le delta sélectionne les contrôles nécessaires à son scope. Une gate typique peut inclure :
|
||||
|
||||
Dès qu'un workspace Rust est matérialisé, sélectionner selon le scope :
|
||||
```bash
|
||||
test "$(cat VERSION)" = "<version attendue>"
|
||||
|
||||
```text
|
||||
CHECK cargo metadata --no-deps
|
||||
FORMAT cargo fmt --all -- --check
|
||||
CHECK cargo check --workspace
|
||||
LINT cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
TEST cargo test ciblé ou workspace selon le changement
|
||||
AUDIT règles structurelles PGR seulement si la preuve n'est pas déjà possédée par Cargo/Rustfmt/Clippy
|
||||
git diff --check
|
||||
|
||||
git add <fichiers du delta>
|
||||
|
||||
git diff --cached --check
|
||||
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le profil strict et les éventuelles exceptions doivent être visibles dans les manifests/règles locales.
|
||||
Le placeholder `<version attendue>` appartient à la documentation de la matrice ; chaque delta fournit la commande concrète avec sa propre version.
|
||||
|
||||
## Administration et authentification
|
||||
Selon le scope, la gate peut également vérifier que :
|
||||
|
||||
Aucune route admin/login n'est validée tant qu'elle n'existe pas réellement. Lorsqu'elles seront matérialisées, les gates devront prouver séparément :
|
||||
- les fichiers ajoutés/remplacés/supprimés correspondent au delta ;
|
||||
- les headers `file/version` correspondent aux chemins réels ;
|
||||
- les liens Markdown principaux sont cohérents ;
|
||||
- aucun secret, chemin machine absolu ou artefact local non autorisé n'est introduit ;
|
||||
- les exceptions Git intentionnellement versionnées restent effectivement traçables ;
|
||||
- aucun répertoire ou contrôle n'est ajouté uniquement pour satisfaire une structure théorique.
|
||||
|
||||
- refus d'accès non authentifié aux opérations privilégiées ;
|
||||
- refus d'accès authentifié sans autorisation suffisante ;
|
||||
- autorisation vérifiée côté serveur et pas seulement par la navigation frontend ;
|
||||
- isolation correcte des opérations PGR, HOWTOs et snippets ;
|
||||
- comportement d'une éventuelle façade admin transverse sans bypass des contrôles locaux.
|
||||
## Autorité de validation
|
||||
|
||||
Les corpus historiques ne constituent pas des preuves de sécurité pour Knowledge.
|
||||
Une validation n'est `PASS` qu'après exécution réelle de la gate opérateur applicable. La génération du delta ou une prévalidation par l'IA ne constitue pas le résultat opérateur.
|
||||
|
||||
## Frontend Web
|
||||
|
||||
Dès que le frontend est matérialisé :
|
||||
|
||||
```text
|
||||
RESTORE mode reproductible du package manager sélectionné
|
||||
TYPECHECK script typecheck TypeScript
|
||||
BUILD production Vite lorsque ses entrées/configuration/outputs changent
|
||||
STYLES preuve séparée uniquement si le build ne prouve pas déjà la compilation requise
|
||||
SMOKE navigateur seulement lorsqu'une propriété runtime le justifie
|
||||
```
|
||||
|
||||
La gate frontend reste exécutable indépendamment du backend autant que la topologie réelle le permet. Les templates statiques de référence appartiennent à cette gate : leur rôle est de prouver le design/markup/assets côté Web avant adaptation Maud, pas de prouver le rendu Actix.
|
||||
|
||||
Lorsque Vite est sélectionné pour les assets réellement servis par Maud, la gate de production doit également prouver l’émission d’un manifest parsable et la présence des clés d’entrée attendues. Une gate d’intégration Actix/Maud distincte prouve ensuite que ces clés sont résolues sans coder les noms hashés.
|
||||
|
||||
Si plusieurs entrées/frontend existent pour PGR, HOWTOs et snippets, la gate doit couvrir chacune des entrées modifiées sans forcer trois builds identiques lorsqu'un package commun possède réellement les assets partagés.
|
||||
|
||||
## Serveurs et intégration
|
||||
|
||||
Les trois launchers Actix Web/Maud sont validés comme packages exécutables distincts lorsqu'ils sont matérialisés :
|
||||
|
||||
```text
|
||||
knowledge-pgr-server
|
||||
knowledge-howtos-server
|
||||
knowledge-snippets-server
|
||||
```
|
||||
|
||||
Leur compilation peut être prouvée par les gates workspace. Un smoke HTTP ciblé est ajouté uniquement lorsqu'une route/runtime réelle est introduite et que compilation/tests ne prouvent pas la propriété visée.
|
||||
|
||||
Une gate d'intégration ne remplace pas silencieusement les preuves frontend indépendantes.
|
||||
|
||||
## Git et forge
|
||||
|
||||
Les contrats Git génériques sont testés sans dépendance à une forge lorsque cela suffit.
|
||||
|
||||
Les tests doivent permettre plusieurs `source_id` et ne pas confondre famille de contenu avec provider de forge.
|
||||
|
||||
Un test live de remote ou de forge doit être explicitement classé comme externe, séparé des tests unitaires et ne doit pas devenir une condition cachée pour les opérations locales.
|
||||
|
||||
## PostgreSQL
|
||||
|
||||
Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.
|
||||
|
||||
Lorsqu'elle devient nécessaire, la validation doit distinguer :
|
||||
|
||||
- parsing/compilation des migrations ou schémas ;
|
||||
- tests avec base éphémère/localement contrôlée ;
|
||||
- accès cohérent depuis les trois applications lorsque le stockage partagé est concerné ;
|
||||
- éventuels smokes externes ;
|
||||
- reconstruction d'une projection dérivée à partir d'une révision Git connue ;
|
||||
- isolation correcte par famille/source sans dupliquer trois bases par simple symétrie.
|
||||
|
||||
## Gate de `0.0.1-alpha.1.fix.1`
|
||||
|
||||
Le fix reste documentaire. Sa gate doit prouver :
|
||||
|
||||
- `VERSION = 0.0.1-alpha.1.fix.1` ;
|
||||
- le history `alpha.1` `FAIL` déjà committé avant application du fix ;
|
||||
- les fichiers Git suivis/non ignorés exacts de la fondation, sans compter `.project` ;
|
||||
- `.gitignore` avec headers `file/version` et exception Eclipse correcte ;
|
||||
- `.settings/org.eclipse.core.resources.prefs` présent, UTF-8 et non ignoré ;
|
||||
- l'absence de code fonctionnel ;
|
||||
- les headers et liens locaux ;
|
||||
- la topologie documentée à trois serveurs Actix distincts ;
|
||||
- au moins trois sources Git initiales et une base PostgreSQL logique partagée ;
|
||||
- l'absence d'override PGR non documenté ;
|
||||
- la cohérence du plan et de la transition PASS/FAIL.
|
||||
|
||||
## Gate de `0.0.1-alpha.2`
|
||||
|
||||
La tranche doit prouver :
|
||||
|
||||
- `VERSION = 0.0.1-alpha.2` et `[workspace.package].version` identique ;
|
||||
- `Cargo.lock` versionné et non ignoré ;
|
||||
- `Cargo.toml`, `rustfmt.toml`, `clippy.toml` et `.cargo/config.toml` sans placeholder PGR ;
|
||||
- `cargo metadata --format-version 1 --no-deps` ;
|
||||
- `cargo fmt --all -- --check` ;
|
||||
- `cargo check --workspace` ;
|
||||
- `cargo clippy --workspace --all-targets --all-features -- -D warnings` ;
|
||||
- `cargo test --workspace --all-targets --all-features` ;
|
||||
- artefacts Cargo hors dépôt sous `../builds/sasedev-knowledge/target/` ;
|
||||
- seule `knowledge-domain-lib` matérialisée comme première crate, sans création placeholder des trois serveurs ;
|
||||
- étude auth/admin présente avec distinction entre fonctionnalités câblées, préparatoires et seulement annoncées ;
|
||||
- surfaces admin locales documentées sans figer `/admin`, `/login` ou un modèle de rôles ;
|
||||
- hygiène Git et headers documentaires applicables.
|
||||
|
||||
## Gate de `0.0.1-alpha.3`
|
||||
|
||||
La tranche doit prouver :
|
||||
|
||||
- `VERSION = 0.0.1-alpha.3` et `[workspace.package].version` identique ;
|
||||
- trois packages seulement : `knowledge-domain-lib`, `knowledge-git-api`, `knowledge-sync-api` ;
|
||||
- `knowledge-git-api` et `knowledge-sync-api` comme crates passives sans dépendance Actix, Gitea, PostgreSQL ou runtime ;
|
||||
- source/famille de contenu capables de représenter plus de trois sources configurées ;
|
||||
- `GitRepository` indépendant d'une forge et sans format de hash Git figé ;
|
||||
- `RepositoryEventSource` produisant un signal non autoritaire lié à un `source_id` ;
|
||||
- `Cargo.lock` régénéré par Cargo et versionné après ajout des deux packages ;
|
||||
- `cargo fmt --all -- --check`, `cargo check --workspace` et Clippy strict ;
|
||||
- tests ciblés des trois crates ;
|
||||
- audits Rust PGR sélectionnés propres, y compris la façade crate-root ;
|
||||
- absence de `knowledge-git-lib`, adapter Gitea, schéma PostgreSQL, Actix Web et frontend ;
|
||||
- hygiène Git et headers documentaires/code applicables.
|
||||
|
||||
L'audit `audit_rust_const_blocks.py` n'appartient pas à la gate globale de cette tranche.
|
||||
|
||||
## Gate de `0.0.1-alpha.3.fix.1`
|
||||
|
||||
Le fix doit prouver :
|
||||
|
||||
- `VERSION = 0.0.1-alpha.3.fix.1` et version workspace identique ;
|
||||
- history `alpha.3` `FAIL` committé avant application du fix ;
|
||||
- construction valide de `SourceId` depuis son module sans contourner la visibilité du tuple struct ;
|
||||
- test de régression direct `SourceId::new("pgr")` + tests précédents ;
|
||||
- audits Rust PGR sélectionnés propres ;
|
||||
- `cargo check`, Clippy strict et les trois suites ciblées `PASS` ;
|
||||
- aucune dépendance ou crate fonctionnelle Web/Actix/PostgreSQL/Gitea ajoutée ;
|
||||
- trajectoire Web documentée : skeleton Web PGR obligatoire en `alpha.4`, templates statiques de référence, rendu runtime Maud, manifest Vite produit côté frontend et intégration Actix/Maud seulement en `alpha.5` ;
|
||||
- hygiène Git et documentation propres.
|
||||
|
||||
## Gate de `0.0.1-alpha.3.fix.2`
|
||||
|
||||
Le second fix doit prouver :
|
||||
|
||||
- `VERSION = 0.0.1-alpha.3.fix.2` et version workspace identique ;
|
||||
- history `alpha.3.fix.1` `FAIL` committé avant application du fix ;
|
||||
- documentation Rust présente sur chacune des quatre variantes publiques `Pgr`, `Howto`, `Snippet` et `ProjectLocal` ;
|
||||
- aucune réduction de la politique `missing_docs` et aucun `allow(missing_docs)` introduit pour contourner la gate ;
|
||||
- audits Rust PGR sélectionnés propres ;
|
||||
- `cargo check --workspace` sans warning `missing_docs` ;
|
||||
- Clippy workspace strict `-D warnings` `PASS` ;
|
||||
- les trois suites ciblées `knowledge-domain-lib`, `knowledge-git-api` et `knowledge-sync-api` `PASS` ;
|
||||
- `Cargo.lock` régénéré/versionné si la version workspace le modifie ;
|
||||
- aucun changement fonctionnel des contrats domaine/Git/synchronisation ;
|
||||
- aucun frontend, serveur Actix, schéma PostgreSQL ou adapter de forge ajouté ;
|
||||
- hygiène Git et documentation propres.
|
||||
Les résultats `FAIL`, `PARTIAL` et `BLOCKED` doivent être enregistrés comme tels et ne doivent pas être transformés implicitement en PASS.
|
||||
|
||||
Après un `PASS`, l'history de la tranche validée est fourni séparément du delta suivant. Un `FAIL` reste normalement dans le scope de la tranche courante via `.fix.N`, sauf REPLAN, abandon ou supersession explicitement justifié.
|
||||
|
||||
@@ -1,143 +0,0 @@
|
||||
<!-- file: history/0.0.1/alpha.3.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.1-alpha.3.fix.1 — correction `SourceId` et précision Web/Maud
|
||||
|
||||
## Statut
|
||||
|
||||
FAIL
|
||||
|
||||
La gate opérateur de `0.0.1-alpha.3.fix.1` exécutée le `2026-09-27` confirme la correction de `SourceId` et le passage des tests ciblés, mais Clippy strict échoue sur la documentation manquante des variantes publiques de `ContentFamily`.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `alpha.3` `FAIL` a été historisée, committée et poussée avant application du fix :
|
||||
|
||||
```text
|
||||
history/0.0.1/alpha.3.md = FAIL
|
||||
commit 6b6bdcf
|
||||
message 0.0.1-alpha.3
|
||||
branch master
|
||||
push origin/master PASS
|
||||
status clean après push
|
||||
```
|
||||
|
||||
Le push observé a avancé `origin/master` de `8cd187b` à `6b6bdcf`.
|
||||
|
||||
## Correction `SourceId`
|
||||
|
||||
La vérification ciblée confirme que le fix attendu est présent :
|
||||
|
||||
```text
|
||||
return Ok(Self(value.to_owned()));
|
||||
```
|
||||
|
||||
L'erreur de compilation `E0423` observée sur `alpha.3` n'est plus reproduite.
|
||||
|
||||
## Structure et audits
|
||||
|
||||
Les contrôles suivants sont propres :
|
||||
|
||||
```text
|
||||
VERSION = 0.0.1-alpha.3.fix.1
|
||||
git diff --check = clean
|
||||
cargo fmt --all -- --check = PASS
|
||||
Rust blank-line audit: clean (8 file(s))
|
||||
Rust item-spacing audit: clean (8 file(s))
|
||||
Rust module-order audit: clean (8 file(s))
|
||||
Rust trait-import-block audit: clean (8 file(s))
|
||||
Rust re-export-block audit: clean (8 file(s))
|
||||
Rust export completeness audit: 0 candidate(s) across 3 package(s)
|
||||
```
|
||||
|
||||
## `cargo check`
|
||||
|
||||
`cargo check --workspace` termine avec succès pour les trois crates.
|
||||
|
||||
Il émet cependant quatre warnings `missing_docs` dans :
|
||||
|
||||
```text
|
||||
crates/knowledge-domain-lib/src/content_family.rs
|
||||
```
|
||||
|
||||
sur les variantes publiques :
|
||||
|
||||
```text
|
||||
Pgr
|
||||
Howto
|
||||
Snippet
|
||||
ProjectLocal
|
||||
```
|
||||
|
||||
La politique workspace déclare `missing_docs = "warn"`, donc ces diagnostics restent des warnings sous `cargo check`.
|
||||
|
||||
## Échec Clippy strict
|
||||
|
||||
La commande :
|
||||
|
||||
```text
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
```
|
||||
|
||||
transforme les warnings `missing_docs` en erreurs, comme attendu par la gate stricte.
|
||||
|
||||
Les quatre variantes publiques non documentées empêchent donc le `PASS` de tranche.
|
||||
|
||||
Le défaut ne doit pas être contourné par un `allow(missing_docs)` ni par une réduction de la politique de lint ; les items publics doivent être documentés.
|
||||
|
||||
## Tests ciblés
|
||||
|
||||
Les tests passent malgré les warnings documentaires :
|
||||
|
||||
```text
|
||||
knowledge-domain-lib : 3 passed; 0 failed
|
||||
knowledge-git-api : 1 passed; 0 failed
|
||||
knowledge-sync-api : 1 passed; 0 failed
|
||||
```
|
||||
|
||||
Les preuves confirment notamment :
|
||||
|
||||
- construction valide de `SourceId` ;
|
||||
- rejet d'un identifiant vide ;
|
||||
- absence de limite codée à trois repositories ;
|
||||
- indépendance du contrat Git vis-à-vis d'une forge ;
|
||||
- caractère non autoritaire de `ExternalSignal`.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
`git diff --cached --check` est propre.
|
||||
|
||||
Le staging transmis avant ajout du présent history contient :
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M Cargo.lock
|
||||
M Cargo.toml
|
||||
M README.md
|
||||
M ROADMAP.md
|
||||
M RULES.md
|
||||
M VERSION
|
||||
M crates/knowledge-domain-lib/src/source.rs
|
||||
M crates/knowledge-domain-lib/src/unit_tests.rs
|
||||
A deltas/0.0.1/alpha.3.fix.1.md
|
||||
M docs/000-README.md
|
||||
M docs/architecture/001-PROJECT_PROFILE.md
|
||||
M docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
|
||||
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||
A docs/studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md
|
||||
M docs/validation/001-VALIDATION_MATRIX.md
|
||||
```
|
||||
|
||||
Ce scope est cohérent avec le fix annoncé et le `Cargo.lock` régénéré par Cargo.
|
||||
|
||||
## Décision
|
||||
|
||||
`0.0.1-alpha.3.fix.1` est `FAIL`.
|
||||
|
||||
La transition autorisée est :
|
||||
|
||||
```text
|
||||
0.0.1-alpha.3.fix.2
|
||||
```
|
||||
|
||||
Le second fix doit rester minimal : documenter les quatre variantes publiques de `ContentFamily`, conserver la politique `missing_docs`, puis rejouer `cargo check`, Clippy strict et les trois suites ciblées. Aucun élargissement fonctionnel n'est autorisé.
|
||||
125
history/0.1.2/alpha.2.fix.1.md
Normal file
125
history/0.1.2/alpha.2.fix.1.md
Normal file
@@ -0,0 +1,125 @@
|
||||
<!-- file: history/0.1.2/alpha.2.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.2-alpha.2.fix.1 — récupération de contamination inter-projet
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.2-alpha.2.fix.1` exécutée le `2026-09-27` est propre. Le correctif retire les fichiers Knowledge introduits accidentellement dans la branche PGR, restaure les deux documents PGR écrasés depuis la stable autoritaire `v0.1.1` et conserve intégralement le contenu normatif validé de `alpha.2`.
|
||||
|
||||
## Baseline Git observée
|
||||
|
||||
Avant application du fix, la branche locale et distante pointaient toutes deux sur le commit contaminé :
|
||||
|
||||
```text
|
||||
17b7ef23a18c913f986c7d57caf958d33479363d
|
||||
```
|
||||
|
||||
Le stash de sécurité contenant l'ancienne application locale de `alpha.3` a été créé avant récupération et n'a pas été restauré pendant la gate.
|
||||
|
||||
La version appliquée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.2-alpha.2.fix.1
|
||||
```
|
||||
|
||||
## Récupération vérifiée
|
||||
|
||||
Les quatre chemins étrangers annoncés par le manifest sont absents après application :
|
||||
|
||||
```text
|
||||
Cargo.toml
|
||||
crates/knowledge-domain-lib/src/content_family.rs
|
||||
deltas/0.0.1/alpha.3.fix.2.md
|
||||
history/0.0.1/alpha.3.fix.1.md
|
||||
```
|
||||
|
||||
Le manifest `manifests/0.1.2/alpha.2.fix.1.delete.txt` contient exactement ces quatre chemins.
|
||||
|
||||
Les deux fichiers PGR écrasés ont été restaurés exactement à leur contenu de `v0.1.1` :
|
||||
|
||||
```text
|
||||
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||
docs/validation/001-VALIDATION_MATRIX.md
|
||||
```
|
||||
|
||||
La commande `git diff --exit-code v0.1.1 -- <ces deux fichiers>` n'a produit aucune différence.
|
||||
|
||||
## Préservation de `alpha.2`
|
||||
|
||||
La tranche normative précédente reste intacte et son history reste `PASS` :
|
||||
|
||||
```text
|
||||
history/0.1.2/alpha.2.md PASS
|
||||
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md version 2
|
||||
docs/rules/520-JAVA_MAVEN_GRADLE.md version 3
|
||||
docs/rules/610-ANDROID.md version 2
|
||||
```
|
||||
|
||||
Le fix ne modifie donc aucune décision Java/Maven/Gradle ni aucune responsabilité Android.
|
||||
|
||||
## Tests Python
|
||||
|
||||
La suite complète a affiché :
|
||||
|
||||
```text
|
||||
Ran 48 tests in 0.721s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `48/48` tests `PASS`.
|
||||
|
||||
## Audits Markdown
|
||||
|
||||
Les audits ont affiché :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (237 file(s))
|
||||
Markdown table audit: clean (10 table(s), 237 file(s))
|
||||
Markdown link audit: clean (273 local link(s), 237 file(s))
|
||||
```
|
||||
|
||||
## Gate de récupération
|
||||
|
||||
Le contrôle spécifique a terminé proprement :
|
||||
|
||||
```text
|
||||
0.1.2 alpha.2.fix.1 recovery audit: clean (foreign Knowledge paths removed, PGR baseline restored, alpha.2 preserved)
|
||||
```
|
||||
|
||||
Il confirme que :
|
||||
|
||||
- le manifest de suppression est exact ;
|
||||
- aucun chemin Knowledge contaminant ne subsiste ;
|
||||
- `history/0.1.2/alpha.2.md` conserve son statut `PASS` ;
|
||||
- le delta `alpha.2`, le plan `008`, le profil `520` et le profil Android sont préservés ;
|
||||
- la matrice de validation restaurée ne contient plus de contenu Knowledge.
|
||||
|
||||
## Hygiène Git et scope
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucune erreur.
|
||||
|
||||
Le statut indexé transmis avant ajout du présent history est exactement :
|
||||
|
||||
```text
|
||||
D Cargo.toml
|
||||
M VERSION
|
||||
D crates/knowledge-domain-lib/src/content_family.rs
|
||||
D deltas/0.0.1/alpha.3.fix.2.md
|
||||
A deltas/0.1.2/alpha.2.fix.1.md
|
||||
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
|
||||
M docs/validation/001-VALIDATION_MATRIX.md
|
||||
D history/0.0.1/alpha.3.fix.1.md
|
||||
A manifests/0.1.2/alpha.2.fix.1.delete.txt
|
||||
```
|
||||
|
||||
Le scope correspond exactement au correctif annoncé.
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.2-alpha.2.fix.1` est `PASS`.
|
||||
|
||||
La contamination inter-projet est corrigée sans réécriture de l'historique Git distant. L'ancienne application locale de `alpha.3` ne doit pas être restaurée comme source autoritaire : le stash de sécurité peut être supprimé après commit/push du présent fix, puis `alpha.3` doit être réappliquée depuis le delta régénéré sur cette baseline propre.
|
||||
4
manifests/0.1.2/alpha.2.fix.1.delete.txt
Normal file
4
manifests/0.1.2/alpha.2.fix.1.delete.txt
Normal file
@@ -0,0 +1,4 @@
|
||||
Cargo.toml
|
||||
crates/knowledge-domain-lib/src/content_family.rs
|
||||
deltas/0.0.1/alpha.3.fix.2.md
|
||||
history/0.0.1/alpha.3.fix.1.md
|
||||
Reference in New Issue
Block a user