From 8cd187b700a10844dd9bff5b1e6c014924d12509 Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Sun, 27 Sep 2026 22:02:32 +0200 Subject: [PATCH] 0.0.1-alpha.2 --- .cargo/config.toml | 6 + CHANGELOG.md | 5 +- Cargo.lock | 7 + Cargo.toml | 39 +++ README.md | 6 +- ROADMAP.md | 4 +- RULES.md | 8 +- VERSION | 2 +- clippy.toml | 22 ++ crates/knowledge-domain-lib/Cargo.toml | 14 + crates/knowledge-domain-lib/src/lib.rs | 8 + deltas/0.0.1/alpha.2.md | 291 ++++++++++++++++++ docs/000-README.md | 6 +- docs/architecture/001-PROJECT_PROFILE.md | 82 +++-- .../002-KNOWLEDGE_ARCHITECTURE.md | 26 +- docs/objectives/001-PROJECT_OBJECTIVES.md | 9 +- docs/plans/001-V0_0_1_FOUNDATION_PLAN.md | 20 +- docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md | 261 ++++++++++++++++ docs/validation/001-VALIDATION_MATRIX.md | 32 +- history/0.0.1/alpha.2.md | 133 ++++++++ rustfmt.toml | 23 ++ 21 files changed, 948 insertions(+), 56 deletions(-) create mode 100644 .cargo/config.toml create mode 100644 Cargo.lock create mode 100644 Cargo.toml create mode 100644 clippy.toml create mode 100644 crates/knowledge-domain-lib/Cargo.toml create mode 100644 crates/knowledge-domain-lib/src/lib.rs create mode 100644 deltas/0.0.1/alpha.2.md create mode 100644 docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md create mode 100644 history/0.0.1/alpha.2.md create mode 100644 rustfmt.toml diff --git a/.cargo/config.toml b/.cargo/config.toml new file mode 100644 index 0000000..d6dcee3 --- /dev/null +++ b/.cargo/config.toml @@ -0,0 +1,6 @@ +# file: .cargo/config.toml +# version: 1 + +[build] +target-dir = "../builds/sasedev-knowledge/target" +build-dir = "../builds/sasedev-knowledge/target" diff --git a/CHANGELOG.md b/CHANGELOG.md index 71a5576..17fb475 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,5 @@ - + # Changelog SaseDev Knowledge @@ -13,4 +13,7 @@ Ce fichier décrit les changements utiles des releases publiées. Les détails d - retient PostgreSQL partagé pour l'état transversal sans remplacer Git comme vérité éditoriale ; - fixe les frontières PGR / HOWTO / snippet / project-local ; - adopte la préférence Eclipse UTF-8 versionnée prévue par PGR ; +- cadre une surface d'administration protégée propre à chaque application Web sans figer encore ses URL ni son modèle détaillé d'autorisation ; +- instancie le workspace Rust/Cargo strict avec une première crate de domaine et une politique explicite de `Cargo.lock` versionné ; +- conserve comme corpus d'inspiration séparé les archives historiques `actix-auth-app` et `amahil-project`, sans importer leurs fonctionnalités inachevées comme exigences ; - prépare un workspace Rust et une baseline Web composables sans construire prématurément la plateforme complète. diff --git a/Cargo.lock b/Cargo.lock new file mode 100644 index 0000000..7f2f6cc --- /dev/null +++ b/Cargo.lock @@ -0,0 +1,7 @@ +# This file is automatically @generated by Cargo. +# It is not intended for manual editing. +version = 4 + +[[package]] +name = "knowledge-domain-lib" +version = "0.0.1-alpha.2" diff --git a/Cargo.toml b/Cargo.toml new file mode 100644 index 0000000..7fb70fd --- /dev/null +++ b/Cargo.toml @@ -0,0 +1,39 @@ +# file: Cargo.toml +# version: 1 + +[workspace] +resolver = "3" +members = ["crates/knowledge-domain-lib"] + +[workspace.package] +version = "0.0.1-alpha.2" +edition = "2024" +publish = false +repository = "https://git.sasedev.com/Sasedev/sasedev-knowledge" + +[workspace.dependencies] + +[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" diff --git a/README.md b/README.md index 023f101..7f342d1 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # SaseDev Knowledge @@ -29,12 +29,15 @@ Chaque famille possède au minimum sa propre source Git autoritaire : dépôt `p PostgreSQL est mutualisable et constitue la baseline retenue pour l'état transversal de la plateforme : comptes, sessions, propositions, synchronisation, index et relations entre familles. Il ne remplace jamais les sources Git comme vérité du contenu publié. +Chaque application Web doit pouvoir exposer sa propre surface d'administration protégée pour son domaine. Les chemins HTTP exacts ne sont pas encore figés. Une éventuelle quatrième application d'administration pourra agréger des fonctions transversales, mais elle ne remplacera pas les contrôles d'autorisation propres aux trois serveurs. + ## Invariants de fondation - Git est la source autoritaire du contenu versionné. - Une forge est une intégration optionnelle et ne constitue pas une dépendance du domaine. - Les trois applications publiques sont déployables séparément mais composent des bibliothèques communes. - PostgreSQL conserve l'état applicatif partagé et les projections ; il ne remplace pas Git comme vérité du contenu publié. +- Chaque serveur Web conserve une frontière d'administration protégée propre à son domaine, indépendamment d'une éventuelle façade d'administration transversale. - La lecture publique doit pouvoir fonctionner depuis des copies Git locales et un index/cache applicatif sans appel à une forge pour chaque requête. - PGR, HOWTOs, snippets et décisions `project-local` conservent des forces et responsabilités documentaires distinctes. - Une proposition externe ne publie jamais directement du contenu et conserve la révision Git de base utilisée pour sa création. @@ -48,6 +51,7 @@ PostgreSQL est mutualisable et constitue la baseline retenue pour l'état transv - [`docs/objectives/001-PROJECT_OBJECTIVES.md`](docs/objectives/001-PROJECT_OBJECTIVES.md) — objectifs et non-objectifs ; - [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md) — baseline PGR, profils/skeletons et matrice de décisions ; - [`docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md`](docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md) — architecture de fondation multi-app Git/forge/PostgreSQL et frontières de contenu ; +- [`docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md`](docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md) — étude des deux corpus historiques auth/admin et décisions de réutilisation conceptuelle ; - [`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md`](docs/plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan vivant de `0.0.1` ; - [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation ; - [`prompts/001-V0_0_1_START_PROMPT.md`](prompts/001-V0_0_1_START_PROMPT.md) — prompt de démarrage autoritaire de la release. diff --git a/ROADMAP.md b/ROADMAP.md index 2a7bc05..890f022 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # Roadmap SaseDev Knowledge @@ -9,7 +9,7 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé. ## Fondation -- `( ) 0.0.1` — fondation Knowledge : gouvernance PGR, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, workspace Rust minimal, premiers contrats et baseline Web reproductible sans implémentation fonctionnelle disproportionnée. +- `( ) 0.0.1` — fondation Knowledge : gouvernance PGR, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, surfaces d'administration locales protégées, workspace Rust minimal, premiers contrats et baseline Web reproductible sans implémentation fonctionnelle disproportionnée. ## Domaines futurs non numérotés diff --git a/RULES.md b/RULES.md index b542574..dea4e0a 100644 --- a/RULES.md +++ b/RULES.md @@ -1,5 +1,5 @@ - + # Règles SaseDev Knowledge @@ -98,7 +98,11 @@ Chaque package exécutable reste une couche de composition mince conformément a Les trois applications peuvent être déployées, redémarrées et dimensionnées séparément. Cette séparation de launchers ne constitue pas une autorisation à fragmenter arbitrairement le domaine en microservices. -La topologie d'une éventuelle interface d'administration dédiée reste `DEFER` tant qu'une quatrième unité de déploiement n'est pas justifiée. +Chaque application serveur MUST pouvoir protéger une surface d'administration propre à son domaine. Cette exigence porte sur la frontière d'autorisation et non sur un chemin HTTP particulier : les routes telles que `/admin`, `/login`, `/adminapi` ou toute alternative restent `DEFER` tant que le routage Web n'est pas matérialisé. + +Une éventuelle quatrième application d'administration MAY agréger plus tard des fonctions transversales. Elle MUST NOT devenir l'unique point de contrôle des opérations privilégiées : les trois applications conservent l'autorisation côté serveur de leurs propres cas d'usage d'administration. + +Le modèle détaillé des rôles, permissions, scopes ou capabilities reste `DEFER`. L'interface cliente ou la visibilité d'un lien d'administration ne constitue jamais à elle seule une preuve d'autorisation. ## Git, forge et contenu diff --git a/VERSION b/VERSION index b6fed41..3fc3728 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.0.1-alpha.1.fix.1 +0.0.1-alpha.2 diff --git a/clippy.toml b/clippy.toml new file mode 100644 index 0000000..80e3ede --- /dev/null +++ b/clippy.toml @@ -0,0 +1,22 @@ +# file: clippy.toml +# version: 1 + +too-many-arguments-threshold = 16 +type-complexity-threshold = 250 +single-char-binding-names-threshold = 3 +trivial-copy-size-limit = 16 +pass-by-value-size-limit = 256 +stack-size-threshold = 512000 +vec-box-size-threshold = 4096 +max-fn-params-bools = 2 +max-include-file-size = 1048576 +cognitive-complexity-threshold = 25 +too-large-for-stack = 2048 +enum-variant-size-threshold = 200 +large-error-threshold = 128 +avoid-breaking-exported-api = true +allow-unwrap-in-tests = true +allow-expect-in-tests = true +allow-useless-vec-in-tests = true +disallowed-names = ["foo", "bar", "baz", "tmp"] +allowed-idents-below-min-chars = ["id"] diff --git a/crates/knowledge-domain-lib/Cargo.toml b/crates/knowledge-domain-lib/Cargo.toml new file mode 100644 index 0000000..aa9511d --- /dev/null +++ b/crates/knowledge-domain-lib/Cargo.toml @@ -0,0 +1,14 @@ +# file: crates/knowledge-domain-lib/Cargo.toml +# version: 1 + +[package] +name = "knowledge-domain-lib" +version.workspace = true +edition.workspace = true +publish.workspace = true +repository.workspace = true + +[dependencies] + +[lints] +workspace = true diff --git a/crates/knowledge-domain-lib/src/lib.rs b/crates/knowledge-domain-lib/src/lib.rs new file mode 100644 index 0000000..b5bdbe2 --- /dev/null +++ b/crates/knowledge-domain-lib/src/lib.rs @@ -0,0 +1,8 @@ +// file: crates/knowledge-domain-lib/src/lib.rs +// version: 1 + +//! Domain boundary for SaseDev Knowledge. +//! +//! The crate is intentionally minimal in `0.0.1-alpha.2`: it establishes ownership of shared +//! domain contracts without introducing the Git/synchronization contracts reserved for the next +//! tranche. diff --git a/deltas/0.0.1/alpha.2.md b/deltas/0.0.1/alpha.2.md new file mode 100644 index 0000000..8b7fe92 --- /dev/null +++ b/deltas/0.0.1/alpha.2.md @@ -0,0 +1,291 @@ + + + +# Delta 0.0.1-alpha.2 — workspace Rust/Cargo et contrat auth/admin + +## Base requise + +État `0.0.1-alpha.1.fix.1` committé et poussé avec : + +```text +history/0.0.1/alpha.1.md = FAIL +history/0.0.1/alpha.1.fix.1.md = PASS +``` + +La version devient : + +```text +0.0.1-alpha.2 +``` + +Le présent delta ne doit être appliqué qu'après matérialisation du history `alpha.1.fix.1` et commit/push de cette tranche. + +## Objet + +Composer le skeleton PGR `002-RUST_CARGO_WORKSPACE` au-dessus de la fondation validée et intégrer la clarification auth/admin issue de l'étude des deux corpus historiques fournis. + +La tranche : + +- instancie un workspace Rust 2024 à train de release unique ; +- crée uniquement la première crate réellement possédée, `knowledge-domain-lib` ; +- adopte les configurations PGR Rustfmt/Clippy adaptées au projet ; +- place les artefacts Cargo hors du dépôt sous `../builds/sasedev-knowledge/target/` ; +- décide explicitement de versionner `Cargo.lock` pour la reproductibilité du workspace applicatif déployable ; +- documente les capacités auth/admin réellement observées dans `actix-auth-app` et `amahil-project`, séparément de leurs structures préparatoires ou intentions incomplètes ; +- établit que chaque future application Web Knowledge conserve sa propre surface d'administration protégée ; +- laisse les URL, le modèle détaillé d'autorisation, OAuth2/OIDC, MFA et une éventuelle quatrième application admin en `DEFER`. + +Aucun serveur Actix Web, aucune route HTTP, aucun schéma PostgreSQL, aucun adapter Git/forge et aucun frontend n'est implémenté dans cette tranche. + +## Corpus auth/admin étudié + +Les archives fournies ont été contrôlées comme corpus d'inspiration uniquement : + +```text +actix-auth-app-master.zip +SHA-256 bcdf4c568c827b77c70ee476218c2b07ea0fca408ab87d2f044333309d19ab71 + +amahil-project-master.zip +SHA-256 b6a3d83c3c2911a7ff36eeb20e353801fefddaf1e5eb7afec1ff12c67067a359 +``` + +L'étude détaillée appartient à [`../../docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md`](../../docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md). + +Elle ne transforme pas les routes ou modèles historiques en contrat Knowledge. + +## Fichiers ajoutés + +```text +.cargo/config.toml +Cargo.toml +clippy.toml +crates/knowledge-domain-lib/Cargo.toml +crates/knowledge-domain-lib/src/lib.rs +docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md +rustfmt.toml +deltas/0.0.1/alpha.2.md +``` + +`Cargo.lock` n'est pas livré préfabriqué dans le delta. Il MUST être généré par la toolchain Cargo de l'opérateur pendant la gate puis versionné avec la tranche. + +## Fichiers remplacés + +```text +VERSION +README.md +RULES.md +ROADMAP.md +CHANGELOG.md +docs/000-README.md +docs/objectives/001-PROJECT_OBJECTIVES.md +docs/architecture/001-PROJECT_PROFILE.md +docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md +docs/plans/001-V0_0_1_FOUNDATION_PLAN.md +docs/validation/001-VALIDATION_MATRIX.md +``` + +Aucun fichier n'est supprimé. + +## Workspace Rust/Cargo + +Le workspace matérialise uniquement : + +```text +crates/knowledge-domain-lib +``` + +Les trois futurs exécutables restent des boundaries produit connues mais ne sont pas créés comme placeholders : + +```text +knowledge-pgr-server +knowledge-howtos-server +knowledge-snippets-server +``` + +Ils seront introduits lorsqu'une composition Web réelle leur donnera un ownership exécutable. + +## Politique `Cargo.lock` + +Knowledge est un workspace applicatif déployable à train de release unique. Le lockfile généré par Cargo est donc versionné afin que les gates opérateur et les livraisons partagent la résolution réellement validée. + +Le lockfile reste un artefact généré par Cargo : il ne doit pas être édité manuellement pour lui ajouter un header PGR. + +## Contrat d'administration retenu + +Chaque futur serveur : + +```text +knowledge-pgr-server +knowledge-howtos-server +knowledge-snippets-server +``` + +MUST vérifier côté serveur l'autorisation de ses opérations privilégiées et MUST pouvoir posséder sa surface d'administration locale. + +Aucune convention de chemin n'est adoptée dans cette tranche. En particulier, les exemples historiques : + +```text +/admin +/adminapi +/login +``` + +ne deviennent pas des URLs Knowledge. + +Une éventuelle quatrième application d'administration reste `DEFER`. Si elle apparaît plus tard, elle pourra agréger des fonctions transversales mais ne remplacera pas les contrôles locaux des trois applications. + +## Validation attendue + +Après application du history `alpha.1.fix.1`, commit/push de `alpha.1.fix.1`, puis extraction du présent delta depuis la racine du dépôt : + +```bash +test "$(cat VERSION)" = "0.0.1-alpha.2" + +git diff --check + +python3 - <<'PY' +from pathlib import Path +import re + +assert Path("Cargo.toml").is_file() +assert Path("rustfmt.toml").is_file() +assert Path("clippy.toml").is_file() +assert Path(".cargo/config.toml").is_file() +assert Path("crates/knowledge-domain-lib/Cargo.toml").is_file() +assert Path("crates/knowledge-domain-lib/src/lib.rs").is_file() +assert Path("docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md").is_file() + +root_manifest = Path("Cargo.toml").read_text(encoding="utf-8") +member_manifest = Path("crates/knowledge-domain-lib/Cargo.toml").read_text(encoding="utf-8") +config = Path(".cargo/config.toml").read_text(encoding="utf-8") +study = Path("docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md").read_text(encoding="utf-8") +rules = Path("RULES.md").read_text(encoding="utf-8") +architecture = Path("docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md").read_text(encoding="utf-8") + +for placeholder in ("project-name", "project-core-lib"): + assert placeholder not in root_manifest + assert placeholder not in member_manifest + assert placeholder not in config + +assert 'resolver = "3"' in root_manifest +assert 'version = "0.0.1-alpha.2"' in root_manifest +assert 'edition = "2024"' in root_manifest +assert 'members = ["crates/knowledge-domain-lib"]' in root_manifest +assert 'target-dir = "../builds/sasedev-knowledge/target"' in config +assert 'build-dir = "../builds/sasedev-knowledge/target"' in config + +for server in ( + "knowledge-pgr-server", + "knowledge-howtos-server", + "knowledge-snippets-server", +): + assert server in rules + assert server in architecture + +for digest in ( + "bcdf4c568c827b77c70ee476218c2b07ea0fca408ab87d2f044333309d19ab71", + "b6a3d83c3c2911a7ff36eeb20e353801fefddaf1e5eb7afec1ff12c67067a359", +): + assert digest in study + +for phrase in ( + "fonctionnalités effectivement câblées", + "structures préparatoires ou incomplètes", + "Les URL restent ouvertes", + "OAuth/OIDC et MFA restent hors scope", +): + assert phrase in study, phrase + +for forbidden_path in ( + "crates/knowledge-pgr-server", + "crates/knowledge-howtos-server", + "crates/knowledge-snippets-server", + "migrations", + "package.json", + "vite.config.ts", +): + assert not Path(forbidden_path).exists(), forbidden_path + +for path in Path(".").rglob("*.md"): + if ".git" in path.parts: + continue + lines = path.read_text(encoding="utf-8").splitlines() + assert lines[0] == f"", path + assert re.fullmatch(r"", lines[1]), path + +print("Knowledge 0.0.1-alpha.2 structural audit: clean") +PY + +cargo metadata --format-version 1 --no-deps > /tmp/sasedev-knowledge-cargo-metadata.json +cargo fmt --all +cargo fmt --all -- --check +cargo check --workspace +cargo clippy --workspace --all-targets --all-features -- -D warnings +cargo test --workspace --all-targets --all-features + +test -f Cargo.lock +if git check-ignore -q Cargo.lock; then + echo 'Cargo.lock must be versioned for Knowledge' >&2 + exit 1 +fi + +python3 - <<'PY' +import json +from pathlib import Path + +metadata = json.loads(Path("/tmp/sasedev-knowledge-cargo-metadata.json").read_text(encoding="utf-8")) +packages = {package["name"] for package in metadata["packages"]} +assert packages == {"knowledge-domain-lib"}, packages +workspace_members = metadata["workspace_members"] +assert len(workspace_members) == 1, workspace_members +print("Knowledge 0.0.1-alpha.2 Cargo metadata audit: clean") +PY + +test -d ../builds/sasedev-knowledge/target + +git add -A +git diff --cached --check +git status --short +``` + +## Résultat attendu du staging + +Le staging doit notamment montrer : + +```text +A .cargo/config.toml +A Cargo.lock +A Cargo.toml +A clippy.toml +A crates/knowledge-domain-lib/Cargo.toml +A crates/knowledge-domain-lib/src/lib.rs +A deltas/0.0.1/alpha.2.md +A docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md +A rustfmt.toml +``` + +avec les documents vivants modifiés par la tranche. + +`.project` doit rester ignoré. Aucun output Cargo ne doit apparaître dans le dépôt. + +## Revue opérateur complémentaire + +Vérifier notamment : + +- que la crate `knowledge-domain-lib` possède une responsabilité réelle et n'est pas un placeholder de serveur ; +- que les trois exécutables ne sont pas encore matérialisés ; +- que `Cargo.lock` provient de Cargo et est bien versionné ; +- que les artefacts Cargo sont créés hors dépôt ; +- que les corpus historiques sont présentés comme inspiration et non comme baseline ; +- que chaque future application conserve une administration locale protégée ; +- qu'aucune URL admin/login, aucun enum de rôles, aucun OAuth/OIDC/MFA et aucune quatrième application admin ne sont figés prématurément. + +## Transition + +### PASS + +Produire `history/0.0.1/alpha.2.md`, appliquer ce history, committer/pousser la tranche, puis seulement préparer `0.0.1-alpha.3`. + +### FAIL / PARTIAL / BLOCKED + +Conserver le résultat réel dans `history/0.0.1/alpha.2.md` et rester dans le scope `alpha.2` avec un éventuel `alpha.2.fix.1`. diff --git a/docs/000-README.md b/docs/000-README.md index 42ce0e1..22dfbea 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation SaseDev Knowledge @@ -12,6 +12,10 @@ - [`architecture/001-PROJECT_PROFILE.md`](architecture/001-PROJECT_PROFILE.md) — baseline PGR, owners/skeletons applicables, décisions `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et nomenclature ; - [`architecture/002-KNOWLEDGE_ARCHITECTURE.md`](architecture/002-KNOWLEDGE_ARCHITECTURE.md) — frontières application/domain, Git, forge, synchronisation, PostgreSQL, contenu et publication. +## Études + +- [`studies/001-AUTH_ADMIN_CORPUS_STUDY.md`](studies/001-AUTH_ADMIN_CORPUS_STUDY.md) — analyse des fonctionnalités auth/admin présentes ou seulement préparées dans deux archives historiques inachevées. + ## Plans - [`plans/001-V0_0_1_FOUNDATION_PLAN.md`](plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan vivant de la release de fondation `0.0.1`. diff --git a/docs/architecture/001-PROJECT_PROFILE.md b/docs/architecture/001-PROJECT_PROFILE.md index 9b98ace..9453874 100644 --- a/docs/architecture/001-PROJECT_PROFILE.md +++ b/docs/architecture/001-PROJECT_PROFILE.md @@ -1,5 +1,5 @@ - + # Profil du projet Knowledge @@ -54,37 +54,39 @@ Les profils Java/Maven/Gradle, Android et autres technologies absentes ne sont p ## Matrice des décisions importantes -| Décision | Classification | Contrat retenu / condition de reprise | -|--------------------------------------|-----------------------------------|----------------------------------------------------------------------------------------------------------------| -| Dépôt applicatif | `KEEP-LOCAL` | `sasedev-knowledge` ; workspace unique de la plateforme | -| Nom court / préfixe crates | `KEEP-LOCAL` | `knowledge` / `knowledge-` | -| Dépôt normatif | `KEEP-LOCAL` | dépôt existant `pgr`, jamais fusionné dans le dépôt applicatif | -| Dépôt HOWTO | `KEEP-LOCAL` | dépôt séparé `howtos` | -| Dépôt snippets | `KEEP-LOCAL` | dépôt séparé `snippets` | -| Nombre de sources Git | `KEEP-LOCAL` | au moins trois sources initiales, sans limite codée à trois | -| Git comme backend du contenu | `KEEP-LOCAL` | invariant d'architecture Knowledge | -| Forge | `KEEP-LOCAL` | capacité optionnelle derrière adapter ; aucune API de forge dans le domaine | -| Gitea | `DEFER` | premier adapter candidat ; reprendre lorsque des capacités forge-only sont implémentées | -| Synchronisation sans webhook | `KEEP-LOCAL` | explicite/polling constituent le socle ; hooks/webhooks sont des accélérateurs | -| PostgreSQL | `KEEP-LOCAL` | une base logique partagée pour l'état transversal et les projections ; jamais vérité du contenu Git publié | -| Rust stable / édition 2024 | `ADOPT` | profil Rust/Cargo PGR | -| Workspace Cargo | `ADOPT` | skeleton Rust/Cargo ; matérialisation `alpha.2` | -| `Cargo.lock` | `DEFER` | décider lors de la matérialisation selon le rôle application/workspace et `510` | -| Actix Web | `KEEP-LOCAL` | trois launchers serveur distincts ; PGR ne possède pas de profil Actix dédié | -| Maud | `KEEP-LOCAL` | rendu SSR initial lorsque pertinent | -| TypeScript | `ADOPT` | conforme au owner `530` et à l'intention locale | -| Package manager frontend | `DEFER` | choisir dans la tranche Web avant création du manifest/lockfile | -| Vite | `KEEP-LOCAL` + owner `550` adopté | choix local cohérent avec la recommandation PGR ; configuration à décider dans la tranche Web | -| Sass | `KEEP-LOCAL` + owner `560` adopté | choix local ; compilation intégrée à la chaîne Web si elle apporte la valeur attendue | -| Bootstrap | `KEEP-LOCAL` | framework CSS local, jamais règle PGR/Tauri/Web universelle | -| Racine(s) frontend | `DEFER` | décider dans la tranche Web selon le partage réel entre les trois applications | -| Driver/ORM PostgreSQL | `DEFER` | reprendre à la première implémentation persistante réelle | -| Migrations PostgreSQL | `DEFER` | reprendre avec le choix de driver/tooling et le premier schéma réel | -| Moteur de recherche | `DEFER` | commencer par capacités PostgreSQL/index applicatif ; réévaluer sur besoin mesuré | -| Fournisseur d'auth externe | `DEFER` | reprendre lorsque le workflow utilisateur l'exige | -| Topologie d'administration | `DEFER` | pas de quatrième application tant qu'un launcher d'administration séparé n'est pas justifié | -| Formats finaux HOWTO/snippet | `DEFER` | définir avec corpus réel ; ne pas figer un schéma sans contenu représentatif | -| Noms définitifs de toutes les crates | `DEFER` | seules les responsabilités et les trois launchers sont cadrés ; créer une crate uniquement avec ownership réel | +| Décision | Classification | Contrat retenu / condition de reprise | +|----------------------------------------|-----------------------------------|----------------------------------------------------------------------------------------------------------------| +| Dépôt applicatif | `KEEP-LOCAL` | `sasedev-knowledge` ; workspace unique de la plateforme | +| Nom court / préfixe crates | `KEEP-LOCAL` | `knowledge` / `knowledge-` | +| Dépôt normatif | `KEEP-LOCAL` | dépôt existant `pgr`, jamais fusionné dans le dépôt applicatif | +| Dépôt HOWTO | `KEEP-LOCAL` | dépôt séparé `howtos` | +| Dépôt snippets | `KEEP-LOCAL` | dépôt séparé `snippets` | +| Nombre de sources Git | `KEEP-LOCAL` | au moins trois sources initiales, sans limite codée à trois | +| Git comme backend du contenu | `KEEP-LOCAL` | invariant d'architecture Knowledge | +| Forge | `KEEP-LOCAL` | capacité optionnelle derrière adapter ; aucune API de forge dans le domaine | +| Gitea | `DEFER` | premier adapter candidat ; reprendre lorsque des capacités forge-only sont implémentées | +| Synchronisation sans webhook | `KEEP-LOCAL` | explicite/polling constituent le socle ; hooks/webhooks sont des accélérateurs | +| PostgreSQL | `KEEP-LOCAL` | une base logique partagée pour l'état transversal et les projections ; jamais vérité du contenu Git publié | +| Rust stable / édition 2024 | `ADOPT` | profil Rust/Cargo PGR | +| Workspace Cargo | `ADOPT` | skeleton Rust/Cargo ; matérialisation `alpha.2` | +| `Cargo.lock` | `KEEP-LOCAL` | versionné : workspace applicatif déployable, résolution reproductible entre opérateur et livraisons | +| Actix Web | `KEEP-LOCAL` | trois launchers serveur distincts ; PGR ne possède pas de profil Actix dédié | +| Maud | `KEEP-LOCAL` | rendu SSR initial lorsque pertinent | +| TypeScript | `ADOPT` | conforme au owner `530` et à l'intention locale | +| Package manager frontend | `DEFER` | choisir dans la tranche Web avant création du manifest/lockfile | +| Vite | `KEEP-LOCAL` + owner `550` adopté | choix local cohérent avec la recommandation PGR ; configuration à décider dans la tranche Web | +| Sass | `KEEP-LOCAL` + owner `560` adopté | choix local ; compilation intégrée à la chaîne Web si elle apporte la valeur attendue | +| Bootstrap | `KEEP-LOCAL` | framework CSS local, jamais règle PGR/Tauri/Web universelle | +| Racine(s) frontend | `DEFER` | décider dans la tranche Web selon le partage réel entre les trois applications | +| Driver/ORM PostgreSQL | `DEFER` | reprendre à la première implémentation persistante réelle | +| Migrations PostgreSQL | `DEFER` | reprendre avec le choix de driver/tooling et le premier schéma réel | +| Moteur de recherche | `DEFER` | commencer par capacités PostgreSQL/index applicatif ; réévaluer sur besoin mesuré | +| Fournisseur d'auth externe | `DEFER` | reprendre lorsque le workflow utilisateur l'exige | +| Surface admin par application | `KEEP-LOCAL` | chaque serveur protège ses opérations privilégiées ; URL exacte encore différée | +| Quatrième application d'administration | `DEFER` | peut agréger du transverse plus tard mais ne remplace jamais les frontières admin locales | +| Modèle rôles/capabilities | `DEFER` | séparer identité partagée et autorisations métier avant de figer enums/scopes | +| Formats finaux HOWTO/snippet | `DEFER` | définir avec corpus réel ; ne pas figer un schéma sans contenu représentatif | +| Noms définitifs de toutes les crates | `DEFER` | seules les responsabilités et les trois launchers sont cadrés ; créer une crate uniquement avec ownership réel | Aucun `OVERRIDE` n'est requis à ce stade. @@ -98,12 +100,12 @@ knowledge-howtos-server launcher Actix Web de la façade HOWTOs knowledge-snippets-server launcher Actix Web de la façade snippets ``` -Ils ne sont pas encore matérialisés en `alpha.1.fix.1`. Lorsqu'ils le seront, leurs `main.rs` resteront minces et composeront les bibliothèques réutilisables. +Ils ne sont pas encore matérialisés en `alpha.2`. Lorsqu'ils le seront, leurs `main.rs` resteront minces et composeront les bibliothèques réutilisables. Chacun doit pouvoir protéger sa propre surface d'administration métier. Les responsabilités de bibliothèques suivantes restent candidates et ne deviennent des packages que lorsqu'elles possèdent un ownership réel : ```text -knowledge-domain-lib contrats et types métier stables +knowledge-domain-lib ownership des contrats et types métier stables ; crate matérialisée en alpha.2 sans contrats Git prématurés knowledge-app-lib orchestration des use cases transversaux, si la séparation apporte une valeur réelle knowledge-git-lib implémentation Git générique knowledge-store-postgres-lib état applicatif PostgreSQL partagé @@ -121,6 +123,18 @@ Règles de création : - ne pas dupliquer dans les trois serveurs une logique qui possède clairement un owner commun ; - ne pas créer un service réseau supplémentaire lorsqu'une crate partagée suffit. +## Corpus auth/admin étudié en alpha.2 + +Les archives historiques `actix-auth-app-master.zip` et `amahil-project-master.zip` sont des sources d'inspiration non autoritaires. Leur analyse est conservée dans [`../studies/001-AUTH_ADMIN_CORPUS_STUDY.md`](../studies/001-AUTH_ADMIN_CORPUS_STUDY.md). + +Elles justifient de conserver séparées : + +- l'identité/authentification partagée de plateforme ; +- l'autorisation privilégiée propre aux cas d'usage de chaque application ; +- une éventuelle façade d'administration transversale ultérieure. + +Elles ne justifient pas encore de créer une crate auth, de figer `/admin` ou `/login`, ni d'adopter OAuth2/OIDC/MFA comme scope `0.0.1`. + ## Décisions à rouvrir Les `DEFER` sont réexaminés dans la tranche qui consomme réellement la décision. Un changement de scope produit, l'ajout d'un host natif ou une contrainte externe peut déclencher un REPLAN ; il ne justifie pas un choix anticipé dans `alpha.1.fix.1`. diff --git a/docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md b/docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md index 764b133..d9fd673 100644 --- a/docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md +++ b/docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md @@ -1,5 +1,5 @@ - + # Architecture de fondation Knowledge @@ -13,6 +13,12 @@ Le principe directeur reste : > Git est le backend du contenu ; une forge est une capacité optionnelle. +## Workspace Rust matérialisé + +`alpha.2` instancie le skeleton PGR `002-RUST_CARGO_WORKSPACE` avec une première crate `knowledge-domain-lib`. Cette crate possède la frontière de domaine commune mais n'introduit pas encore les contrats Git/synchronisation réservés à `alpha.3`. + +Le workspace est une application déployable à train de release unique ; `Cargo.lock` est donc versionné pour conserver la résolution effectivement vérifiée. Les artefacts Cargo sont dirigés hors du dépôt vers `../builds/sasedev-knowledge/target/`. + ## Vue de responsabilités ```text @@ -224,13 +230,25 @@ La stratégie exacte de partage des assets/frontend entre les trois applications L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité. -Elle pourra gérer propositions, revues, synchronisation, validation et publication. Une UI complète est hors scope `0.0.1`. +Chaque application doit pouvoir protéger sa propre surface d'administration métier : -La décision entre routes d'administration réparties dans les trois applications et launcher d'administration dédié reste ouverte jusqu'à ce que les besoins d'auth, lifecycle et déploiement soient connus. +```text +knowledge-pgr-server -> administration PGR +knowledge-howtos-server -> administration HOWTOs +knowledge-snippets-server -> administration snippets +``` + +Les chemins HTTP exacts restent `DEFER`. Les exemples `/admin`, `/adminapi`, `/login` ou autres observés dans les corpus historiques ne sont pas adoptés comme convention Knowledge. + +Une quatrième application d'administration MAY être créée ultérieurement si une vraie responsabilité transversale apparaît. Elle pourra agréger comptes, sources, jobs, propositions ou autres vues communes, mais MUST NOT remplacer les contrôles d'autorisation propres aux trois applications. + +Une UI complète reste hors scope `0.0.1`. ## 11. Authentification et autorisation -Le domaine doit distinguer identité, rôle/capacité et action autorisée, mais le fournisseur d'identité et le mécanisme complet restent différés. +Le domaine doit distinguer identité, authentification, rôle/capacité et action autorisée. L'identité et les sessions peuvent être transversales via PostgreSQL partagé ; l'autorisation métier reste vérifiée côté serveur dans chaque application. + +Le fournisseur d'identité, les URLs de login, le modèle détaillé de rôles/capabilities, OAuth2/OIDC et MFA restent différés. Les permissions forge ne sont pas supposées équivalentes aux permissions applicatives. diff --git a/docs/objectives/001-PROJECT_OBJECTIVES.md b/docs/objectives/001-PROJECT_OBJECTIVES.md index c118d85..573a5ad 100644 --- a/docs/objectives/001-PROJECT_OBJECTIVES.md +++ b/docs/objectives/001-PROJECT_OBJECTIVES.md @@ -1,5 +1,5 @@ - + # Objectifs SaseDev Knowledge @@ -27,6 +27,12 @@ knowledge-snippets-server Cette séparation permet de faire évoluer, déployer et dimensionner chaque façade indépendamment tout en partageant les bibliothèques de domaine, Git, stockage, rendu et observabilité lorsque leur ownership est réellement commun. +## Administration par façade + +Chaque application doit pouvoir proposer sa propre surface d'administration protégée pour les opérations qui appartiennent à son domaine. Les URL internes et le modèle détaillé d'autorisation ne sont pas définis par la fondation. + +Une future quatrième application d'administration peut centraliser des vues et opérations transversales, mais elle ne remplace pas les contrôles locaux des trois serveurs. + ## Sources Git de contenu La fondation retient au minimum trois sources Git indépendantes : @@ -53,6 +59,7 @@ Knowledge doit permettre à terme : - de publier des HOWTOs procéduraux sans leur attribuer une force normative PGR ; - de publier des snippets courts et contextualisés ; - de déployer séparément les trois façades publiques sans dupliquer la logique partagée ; +- de protéger et administrer localement chaque façade, avec une éventuelle vue d'administration transverse en complément ; - d'administrer des dépôts publics ou privés ; - d'accepter des propositions externes sans écriture directe dans le contenu publié ; - de conserver une révision Git de base pour détecter les conflits ; diff --git a/docs/plans/001-V0_0_1_FOUNDATION_PLAN.md b/docs/plans/001-V0_0_1_FOUNDATION_PLAN.md index 5c8e094..348e212 100644 --- a/docs/plans/001-V0_0_1_FOUNDATION_PLAN.md +++ b/docs/plans/001-V0_0_1_FOUNDATION_PLAN.md @@ -1,5 +1,5 @@ - + # Plan 0.0.1 — fondation SaseDev Knowledge @@ -52,7 +52,7 @@ Acquis par le cadrage `alpha.1.fix.1` : Restent volontairement ouverts jusqu'à la tranche qui les consomme : - package manager et lockfile frontend ; -- `Cargo.lock` ; +- 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 ; @@ -60,7 +60,8 @@ Restent volontairement ouverts jusqu'à la tranche qui les consomme : - fournisseur d'identité ; - adapter forge réel ; - formats finaux HOWTO/snippet ; -- topologie d'administration ; +- 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. ## Scope @@ -113,17 +114,19 @@ Principes : Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage. -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 sans ouvrir le scope `alpha.2`. +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`. -Aucun code fonctionnel n'est ajouté. +Aucun code fonctionnel n'est ajouté dans `alpha.1` ou son fix. ### alpha.2 — workspace Rust/Cargo minimal -Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, toolchain/configuration durable réellement nécessaire et premier package de bibliothèque possédant une responsabilité claire. +Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, outillage durable, artefacts Cargo hors dépôt et première crate `knowledge-domain-lib` possédant la frontière de domaine commune. -Décider explicitement `Cargo.lock`, outputs de build et premier sous-ensemble de crates réellement matérialisé. +Décision `Cargo.lock` : le versionner, car Knowledge est un workspace applicatif déployable à train de release unique et doit conserver la résolution effectivement validée. -Les trois packages serveur sont connus architecturalement mais ne sont pas obligatoirement tous créés dans cette tranche si leur seule existence serait un placeholder. +Étudier les deux corpus historiques auth/admin fournis et formaliser uniquement les enseignements durables : identité partageable, autorisation serveur et surface admin propre à chaque application. Ne pas importer les URL, rôles, OAuth/OIDC, MFA ou écrans inachevés comme exigences. + +Les trois packages serveur restent connus architecturalement mais ne sont pas créés dans cette tranche : sans routes/cas d'usage réels, ils seraient encore des placeholders. ### alpha.3 — contrats domaine/Git/synchronisation @@ -172,6 +175,7 @@ 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 ; diff --git a/docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md b/docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md new file mode 100644 index 0000000..c0392da --- /dev/null +++ b/docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md @@ -0,0 +1,261 @@ + + + +# Étude auth/admin — corpus historiques Actix + +## Objet + +Cette étude utilise deux projets historiques **inachevés** comme corpus d'inspiration pour SaseDev Knowledge. Ils ne sont ni des baselines autoritaires ni des dépendances à importer. + +```text +actix-auth-app-master.zip +SHA-256 bcdf4c568c827b77c70ee476218c2b07ea0fca408ab87d2f044333309d19ab71 + +amahil-project-master.zip +SHA-256 b6a3d83c3c2911a7ff36eeb20e353801fefddaf1e5eb7afec1ff12c67067a359 +``` + +L'objectif est de distinguer : + +- les fonctionnalités réellement câblées ; +- les structures préparatoires sans workflow complet ; +- les intentions annoncées mais non implémentées ; +- les concepts réutilisables pour Knowledge ; +- les détails qui doivent rester différés. + +## `actix-auth-app` — fonctionnalités effectivement câblées + +Le projet expose réellement une base d'authentification Actix Web avec pages et API. + +### Routes front observées + +```text +/ +/setlang +/signup +/confirm-signup +/resend-confirmation-signup +/lostpassword +/login +/newpassword +/lostid +/profile +/logout +``` + +Les pages invitées sont protégées par un middleware `guest_only`; le profil et la déconnexion par `auth_only`. + +### API observée + +```text +GET /api/health +GET /api/captcha +POST /api/auth/login +POST /api/auth/logout +POST /api/auth/signup +POST /api/auth/confirm-signup +POST /api/auth/resend-confirmation-signup +POST /api/auth/lostpassword +POST /api/auth/newpassword +POST /api/auth/lostid +POST /api/auth/refresh +GET /api/profile +POST /api/profile/update +POST /api/profile/change-password +POST /api/profile/change-email +POST /api/profile/change-avatar +``` + +Le code observé matérialise notamment : + +- hash/vérification de mot de passe avec Argon2 ; +- access token et refresh token ; +- sessions persistées avec informations de device/user-agent/IP ; +- cookies `HttpOnly`, `SameSite=Lax` et `Secure` conditionnel au mode HTTPS pour les tokens ; +- confirmation d'inscription ; +- récupération d'identifiant et réinitialisation de mot de passe ; +- CAPTCHA pour plusieurs parcours sensibles ; +- rate limiting configurable sur certains parcours de récupération/confirmation ; +- profil utilisateur, changement de mot de passe/email et avatar ; +- statuts utilisateur et compteur d'échecs de connexion ; +- middleware `admin_only`, `auth_only`, `guest_only` ; +- stockage PostgreSQL et queries structurées ; +- traduction Fluent, rendu Maud et frontend TypeScript/Vite/Sass. + +Ces éléments sont des **capacités observées**, pas des exigences Knowledge. + +## `actix-auth-app` — structures préparatoires ou incomplètes + +Le README annonce un kernel OAuth2/OIDC complet, et le schéma/les DTOs/queries couvrent notamment : + +```text +OAuth clients +OAuth authorization codes +OAuth refresh/access tokens +OAuth consents +OAuth provider configs +external user auth providers +user 2FA recovery codes +user events +``` + +Des types existent également pour OAuth/OIDC, MFA/TOTP et plusieurs niveaux d'authentification de session. + +Cependant, aucune route HTTP OAuth/OIDC n'est configurée dans les handlers observés et aucun flow MFA/TOTP complet n'est câblé. La dépendance OTP est même commentée dans le manifest. Ces capacités sont donc classées **préparatoires / annoncées**, pas implémentées de bout en bout. + +Le middleware `admin_only` existe, mais aucune surface d'administration n'est configurée dans les handlers du projet observé. + +Un autre détail interdit la copie mécanique : le modèle courant possède `User`, `Admin`, `Superadmin`, mais `admin_only` compare directement le rôle à `Admin`. Le comportement de `Superadmin` n'est donc pas une base suffisamment sûre pour définir le modèle Knowledge. + +## `amahil-project` — fonctionnalités effectivement câblées + +Amahil contient une base auth très proche sur les parcours classiques : login/logout, inscription, confirmation, récupération, refresh, profil, CAPTCHA, sessions et PostgreSQL. + +Il ajoute surtout un début d'administration applicative : + +```text +scope /adminapi +middleware admin_only +GET /adminapi/user/list +``` + +La liste d'utilisateurs est donc une fonctionnalité admin backend réellement branchée derrière une vérification de rôle. + +Le schéma contient plusieurs niveaux de rôles : + +```text +global +company +project +task +``` + +Cette séparation montre qu'une identité partagée peut coexister avec des autorisations plus locales au domaine. + +## `amahil-project` — interface admin incomplète + +Le gabarit Maud d'administration référence notamment : + +```text +/admin +/admin/users +/admin/users/add +``` + +avec sidebar et gestion des utilisateurs. + +Ces routes frontend ne sont toutefois pas configurées dans le handler `front.rs` observé. Le module admin API contient en outre des opérations add/edit/delete seulement commentées. + +Le corpus montre donc l'intention et une partie de l'UI, mais pas une console d'administration complète. + +## Enseignements retenus pour Knowledge + +### 1. Identité partagée, autorisation distribuée + +Le PostgreSQL partagé peut porter les identités, sessions et métadonnées d'autorisation communes aux trois applications. + +En revanche, chaque application Knowledge garde la responsabilité de vérifier côté serveur les opérations privilégiées de son propre domaine : + +```text +knowledge-pgr-server +knowledge-howtos-server +knowledge-snippets-server +``` + +Une éventuelle application admin transversale est une façade supplémentaire, pas un bypass des autorisations locales. + +### 2. Les URL restent ouvertes + +Les chemins historiques : + +```text +/login +/admin +/adminapi +/profile +``` + +sont des exemples observés, pas un contrat Knowledge. Le routage exact sera décidé avec la première composition Web/auth réelle. + +### 3. Le modèle de rôles reste ouvert + +Les deux archives utilisent des modèles différents : rôle unique enum, tableaux de rôles, niveaux global/company/project/task. + +Knowledge ne copie donc aucun enum historique. Le futur modèle devra distinguer au minimum : + +```text +identity +session/authentication state +platform-level capability when justified +application/domain capability +authorized action +``` + +La granularité concrète reste `DEFER`. + +### 4. Auth commune réutilisable, middleware Web séparé si nécessaire + +Les parcours compte/session sont naturellement candidats à une implémentation partagée entre les trois applications. Une future crate commune n'est créée que lorsqu'un ownership réel et un premier cas d'usage existent. + +Le code Actix spécifique peut rester distinct du domaine d'identité si cette séparation évite de coupler les contrats réutilisables au framework. + +Aucun nom de crate auth n'est figé par cette étude. + +### 5. OAuth/OIDC et MFA restent hors scope + +Les structures de `actix-auth-app` montrent qu'OAuth2/OIDC, fournisseurs externes, consentements, MFA et recovery codes pourront être étudiés plus tard. + +Ils ne deviennent pas des exigences de `0.0.1` parce que le corpus contient des tables ou des dépendances associées. + +### 6. La sécurité n'est pas héritée par copie + +Les archives apportent des idées utiles : Argon2, refresh token, sessions persistées, cookies protégés, rate limits, CAPTCHA et événements/audit. + +Elles ne prouvent pas pour autant un modèle de sécurité complet pour Knowledge. En particulier, cette étude n'a pas établi dans les corpus un contrat CSRF complet, un modèle de capabilities final, ni une administration bout en bout. + +Les propriétés de sécurité Knowledge devront être spécifiées puis testées dans leur propre scope. + +## Capacités candidates pour les futures surfaces admin + +Les éléments suivants combinent ce que les corpus montrent et les besoins déjà cadrés de Knowledge. Ils constituent un backlog conceptuel, pas le scope de `alpha.2`. + +### Commun/transversal + +- gestion des utilisateurs et de leur état ; +- sessions actives et révocation ; +- audit/événements utilisateurs ; +- statut des sources Git et dernière synchronisation ; +- jobs de synchronisation/indexation/publication ; +- propositions, revues et conflits ; +- configuration des sources publiques/privées ; +- santé de PostgreSQL et projections reconstructibles. + +### PGR + +- état stable/dev et révision/tag source ; +- propositions de changement normatif ; +- validation/publication compatible avec la gouvernance PGR. + +### HOWTOs + +- création/révision/publication de procédures ; +- classification, relations et validation du contenu procédural. + +### snippets + +- création/révision/publication de snippets ; +- contexte, langage/technologie, classification et modération. + +Les trois groupes spécifiques ci-dessus sont des **déductions Knowledge**, pas des fonctionnalités directement présentes dans les deux archives historiques. + +## Décision de tranche + +`alpha.2` ne crée : + +- aucune route `/admin` ou `/login` ; +- aucune crate auth/admin ; +- aucun schéma PostgreSQL auth ; +- aucun OAuth/OIDC/MFA ; +- aucun rôle/capability définitif. + +La tranche conserve seulement les invariants architecturaux nécessaires avant matérialisation des serveurs et documente le corpus pour éviter de devoir le réinterpréter depuis la conversation. diff --git a/docs/validation/001-VALIDATION_MATRIX.md b/docs/validation/001-VALIDATION_MATRIX.md index 2374a80..ec39df2 100644 --- a/docs/validation/001-VALIDATION_MATRIX.md +++ b/docs/validation/001-VALIDATION_MATRIX.md @@ -1,5 +1,5 @@ - + # Matrice de validation Knowledge @@ -65,6 +65,18 @@ AUDIT règles structurelles PGR seulement si la preuve n'est pas déjà posséd Le profil strict et les éventuelles exceptions doivent être visibles dans les manifests/règles locales. +## Administration et authentification + +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 : + +- 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. + +Les corpus historiques ne constituent pas des preuves de sécurité pour Knowledge. + ## Frontend Web Dès que le frontend est matérialisé : @@ -131,3 +143,21 @@ Le fix reste documentaire. Sa gate doit prouver : - 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. diff --git a/history/0.0.1/alpha.2.md b/history/0.0.1/alpha.2.md new file mode 100644 index 0000000..1592e95 --- /dev/null +++ b/history/0.0.1/alpha.2.md @@ -0,0 +1,133 @@ + + + +# History 0.0.1-alpha.2 — workspace Rust/Cargo et contrat auth/admin + +## Statut + +PASS + +La gate opérateur de `0.0.1-alpha.2` exécutée le `2026-09-27` est propre. + +## Baseline opérateur + +Le fix précédent a été clôturé avant application de la tranche : + +```text +commit d632afe +message 0.0.1-alpha.1.fix.1 +branch master +push origin/master PASS +status clean après push +``` + +Une première tentative de push a atteint un prompt d'authentification corrompu par une saisie parasite ; aucune publication n'a été constatée sur cette tentative. Le second `git push origin master` a réussi et a avancé `origin/master` de `116219f` à `d632afe`. + +## Identité et structure + +Les contrôles suivants ont réussi : + +```text +VERSION = 0.0.1-alpha.2 +git diff --check = clean +Knowledge 0.0.1-alpha.2 structural audit: clean +``` + +La gate structurelle a confirmé notamment : + +- `Cargo.toml`, `rustfmt.toml`, `clippy.toml` et `.cargo/config.toml` présents ; +- `knowledge-domain-lib` comme unique package matérialisé de la tranche ; +- absence de placeholders `project-name` / `project-core-lib` ; +- resolver Cargo `3`, édition Rust `2024` et version workspace `0.0.1-alpha.2` ; +- artefacts Cargo configurés sous `../builds/sasedev-knowledge/target` ; +- étude auth/admin présente et correctement séparée des intentions incomplètes des corpus historiques ; +- absence volontaire des trois crates serveur, des migrations PostgreSQL et du frontend. + +## Cargo et toolchain + +`cargo metadata --format-version 1 --no-deps` a réussi. La vérification de metadata a atteint : + +```text +Knowledge 0.0.1-alpha.2 Cargo metadata audit: clean +``` + +Le workspace contient exactement : + +```text +knowledge-domain-lib +``` + +Les gates Rust ont toutes réussi : + +```text +cargo fmt --all +cargo fmt --all -- --check +cargo check --workspace +cargo clippy --workspace --all-targets --all-features -- -D warnings +cargo test --workspace --all-targets --all-features +``` + +`cargo check` et Clippy ont terminé sans warning. Les tests ont exécuté la cible unitaire de `knowledge-domain-lib` avec : + +```text +running 0 tests +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out +``` + +L'absence de test comportemental est cohérente avec le scope `alpha.2`, qui ne matérialisait encore aucun contrat fonctionnel. + +## `Cargo.lock` et artefacts + +Le lockfile a été généré par la toolchain opérateur : + +```text +Cargo.lock présent +Cargo.lock non ignoré +``` + +Le répertoire d'artefacts externe attendu existe : + +```text +../builds/sasedev-knowledge/target +``` + +## Hygiène Git et scope observé + +`git diff --cached --check` est propre. Le staging transmis est : + +```text +A .cargo/config.toml +M CHANGELOG.md +A Cargo.lock +A Cargo.toml +M README.md +M ROADMAP.md +M RULES.md +M VERSION +A clippy.toml +A crates/knowledge-domain-lib/Cargo.toml +A crates/knowledge-domain-lib/src/lib.rs +A deltas/0.0.1/alpha.2.md +M docs/000-README.md +M docs/architecture/001-PROJECT_PROFILE.md +M docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md +M docs/objectives/001-PROJECT_OBJECTIVES.md +M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md +A docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md +M docs/validation/001-VALIDATION_MATRIX.md +A rustfmt.toml +``` + +Ce scope correspond au delta annoncé, avec `Cargo.lock` ajouté par Cargo pendant la gate comme prévu. + +## Décision + +`0.0.1-alpha.2` est `PASS`. + +Aucun `alpha.2.fix.N` n'est requis. La transition autorisée est : + +```text +0.0.1-alpha.3 +``` + +`alpha.3` peut introduire les premiers contrats domaine/Git/synchronisation et leurs tests ciblés sans ajouter d'API Gitea, de persistance PostgreSQL, de serveur Actix ou de frontend. diff --git a/rustfmt.toml b/rustfmt.toml new file mode 100644 index 0000000..ecbd44e --- /dev/null +++ b/rustfmt.toml @@ -0,0 +1,23 @@ +# file: rustfmt.toml +# version: 1 + +edition = "2024" +newline_style = "Unix" +use_small_heuristics = "Default" +hard_tabs = false +tab_spaces = 4 +max_width = 160 +chain_width = 140 +fn_call_width = 140 +attr_fn_like_width = 140 +struct_lit_width = 100 +struct_variant_width = 100 +array_width = 140 +single_line_if_else_max_width = 120 +single_line_let_else_max_width = 120 +reorder_imports = true +reorder_modules = true +match_block_trailing_comma = true +use_field_init_shorthand = true +use_try_shorthand = false +force_explicit_abi = true