PD-295 — Bibliothèque documentaire → mémoire vivante (besoin v3 minimaliste)¶
Version 3 — 2026-04-12. Refonte minimaliste après 9 itérations de cycles 1-2-3 archivés. Les versions précédentes avaient empilé HMAC, clé Vault, canonicalisation JCS RFC 8785, fail-closed strict, subprocess isolation avec buffer mémoire, machine à états 12 transitions, 6 familles PII, conformité RGPD art. 17 — tout ça pour un outil interne de gouvernance utilisé uniquement par moi sur mon laptop et mon IA-Server. Cette v3 retire tout le théâtre sécurité et ne garde que ce qui a du sens pour un outil de dev personnel.
1. Contexte et besoin¶
Le workflow /gov produit des connaissances à chaque story (learnings, clarifications PO, verdicts) et j'ai accumulé 128 fiches de veille dans ProbatioVault-doc/docs/veille/. Aujourd'hui ces sources sont plates : les skills /learnings, /specs, /plans, /contracts existent mais aucune n'injecte automatiquement au démarrage d'une nouvelle story. Deux sources se perdent totalement : les réponses PO au step 0 (jetées après rédaction du besoin) et les fiches de veille (accessibles seulement par lecture manuelle).
Je veux que la bibliothèque vienne au-devant d'une nouvelle story : injection automatique de learnings pertinents + fiches de veille + clarifications passées au step 0, avec promotion des learnings qui se révèlent utiles et éviction de ceux qui ne resservent jamais.
2. Stack et contraintes¶
Contrainte unique : rester sur FAISS + Ollama + Markdown + YAML. Tout ce qui est déjà dans le repo ProbatioVault-ia-governance continue de fonctionner tel quel. Pas de migration, pas de nouveau moteur de stockage, pas de refonte.
Contexte d'usage : outil interne mono-utilisateur, tourne sur mon laptop macOS et/ou IA-Server Linux. Pas de clients externes, pas d'opérateur tiers, pas de conformité RGPD externe, pas de vecteur d'attaque réaliste. Les clarifications PO sont mes propres réponses que j'écris dans mon propre repo git privé.
3. Périmètre — 5 briques¶
3.1 [B1] Index FAISS des fiches de veille¶
Parcourir ProbatioVault-doc/docs/veille/**/*.md, parser le frontmatter YAML + titre H1 + résumé, écrire data/veille.jsonl, générer l'index FAISS via Ollama nomic-embed-text. Skill /veille-search pour la recherche, avec flags --impact et --verdict. Cloner collect-specs.py, index-learnings.py, search-learnings.py.
3.2 [B2] Clarifications step 0 persistées¶
Modifier gov-step-0.md pour qu'après les 4 questions PO, le verbatim soit écrit dans PD-XX-clarifications.md dans le dossier epic. Pas de résumé, pas de filtre, pas de PII theater. C'est moi qui écris, c'est pour moi, c'est dans mon git privé. Si je veux retirer une clarification un jour, rm PD-XX-clarifications.md && ./scripts/reindex-all.py. Indexer dans data/clarifications.jsonl + FAISS. Skill /clarifications avec filtres --domain et --project.
3.3 [B3] Scoring de réutilisation¶
Lire learnings-injections.jsonl (déjà créé par #28 commit 076dc3e), calculer pour chaque learning un reuse_score = nb_injections * 0.4 + nb_stories_gate8_go_apres_injection * 0.4 + nb_domains_distincts * 0.2. Écrire dans data/learnings-scores.jsonl (fichier parallèle, jointure par {story, gate, tags_hash}). Modifier search-learnings.py pour trier secondairement par reuse_score.
3.4 [B4] Promotion et éviction¶
Ajouter un champ scope: story|domain|global à learnings.jsonl. Migration initiale : tous les learnings existants passent à scope: story. Règles de promotion : reuse_score >= 0.3 → scope: domain, reuse_score >= 0.6 → scope: global. Règle d'éviction : nb_injections == 0 ET date > 8 semaines → déplacement vers learnings-archive.jsonl (n'est plus indexé). Filtrage à l'injection step 0 selon le domaine de la story. Commit git atomique avant migration pour rollback facile.
3.5 [B5] Injection unifiée au step 0¶
Modifier gov-learnings-inject.md pour qu'il injecte au step 0 un bloc markdown avec 3 sections : 5 learnings pertinents pondérés par reuse_score, 3 fiches de veille impact fort/modéré, 3 clarifications passées du même domaine. Format lisible. Si une source retourne 0 résultats, sa section affiche "aucun résultat" sans bloquer. Si une source échoue (erreur fichier, Ollama down), la section est vide et l'erreur est loggée dans stderr — pas de fail-closed, pas de blocage du step 0.
4. Ordre d'implémentation¶
B1 → B2 (indépendants) → B3 → B4 (promotion dépend de B3) → B5 (unifie B1+B2+B4). Total ~4 jours de dev, 5 commits.
5. Critères de succès (mesure continue post-merge)¶
Ces 4 KPI ne sont pas vérifiés à Gate 8. Ils sont mesurés post-merge via scripts/analyze-compounding.py (déjà créé par #28) :
- CS-1 : taux de Gate 8 GO v1 augmente vs baseline pré-B5
- CS-2 : ≥ 30 % des learnings sont réinjectés au moins une fois dans les 3 mois post-merge
- CS-3 : ≥ 1 clarification passée est remontée par mois sur une story du même domaine
- CS-4 : ≥ 5 des 5 premières stories post-B5 voient une fiche de veille impact fort/modéré injectée au step 0
6. Ce qu'on ne fait pas¶
Pas de signature HMAC. Pas de clé Vault pour signer des événements. Pas de canonicalisation JCS RFC 8785. Pas de fail-closed strict. Pas de machine à états formelle à 12 transitions. Pas de subprocess isolation avec buffer mémoire inviolable. Pas de filtrage PII par pii_ruleset_v1. Pas de purge multi-artefacts avec droit à l'oubli. Pas de rwlock distribué avec reprise crash. Pas de rate-limiting sur les opérations de lecture. Pas de détection de dérive d'horloge. Pas de reranker neural. Pas de BM25 hybrid. Pas de knowledge graph. Pas de skill router. Pas de résumés hiérarchiques pré-générés.
Justification : PD-295 est un outil interne mono-utilisateur. Les contraintes de sécurité et de conformité qui justifient ces mécanismes dans un SaaS multi-tenant n'existent pas ici. Si un jour PD-295 est exposé à des utilisateurs externes ou entre en périmètre RGPD, une story séparée ajoutera les contraintes adaptées à ce moment-là, en repartant d'une base qui marche.
7. Contraintes de volume du besoin¶
Ce besoin tient en ~80 lignes délibérément. Les 9 itérations précédentes ont montré que plus un document est long, plus la review adversariale trouve de points à corriger, et plus la dette conceptuelle s'accumule. La discipline de volume est une mitigation active contre le biais "plus c'est détaillé, plus c'est bon".
8. Arbitrages déjà tranchés¶
- Scope PD-295 = 5 briques, un seul plan, un seul Gate 8 (2026-04-11)
- Pas de pipeline externe à casser, learnings.jsonl est parsé en défensif par les 5 scripts internes (2026-04-11)
- Rollback git atomique avant migration B4 (2026-04-11)
- Pas de théâtre sécurité pour un outil interne (2026-04-12, après 9 itérations de cycle 1-2-3)