Aller au contenu

PD-295 — Rapport de confrontation (Gate 5 — Plan)

Ce rapport est produit par l'orchestrateur Claude avant Gate 5 PMO. Il confronte spécification, tests, plan et code-contracts afin d'identifier convergences, divergences et zones d'ombre.

1. Sources confrontées

  • Spécification : PD-295-specification.md (étape 1, version canonique contractuelle)
  • Tests : PD-295-tests.md (étape 2, matrice de couverture INV/CA/TC)
  • Plan : PD-295-plan.md (étape 4, résout 4 réserves Gate 3 : M-01/M-02/M-03/M-06)
  • Code contracts : PD-295-code-contracts.yaml (étape 4, 9 modules, invariants cross-module)

2. Convergences

  • CV-01 — Formule reuse_score (INV-295-05) : spec §4, tests TC-NOM-05 (scores 1.0 et 1.8), plan §2.3 et code-contracts scoring.invariants convergent sur la somme pondérée brute 0.4*nb_injections + 0.4*nb_stories_gate8_go + 0.2*nb_domains_distincts. Coefficients hardcodés, pas de normalisation. Les bornes D-295-08 [0.0000..999999.9999] confirment que la valeur n'est pas un ratio.
  • CV-02 — Seuils de promotion (INV-295-09/10) : spec 0.3 / 0.6 appliqués à la somme brute, tests TC-NOM-09 (bornes 0.29/0.30 et 0.59/0.60), plan §2.4 step 2, code-contracts lifecycle.invariants : alignement strict.
  • CV-03 — Éviction conjonctive (INV-295-11) : age > 56j ET nb_injections == 0. Convergence spec §4 / tests TC-NOM-10 matrix 4 cas / plan §2.4 step 3 / code-contracts lifecycle.
  • CV-04 — FSM scope : ALLOWED_TRANSITIONS identiques entre spec §5.9, tests TC-NOM-16 + TC-ERR-07 + TC-ERR-11, plan §2.4 step 4, code-contracts lifecycle. ARCHIVED terminal, aucun downgrade.
  • CV-05 — Bloc injection 3 sections, cardinalités max 5/3/3 (INV-295-13) : convergence entre spec §5.8, tests TC-NOM-12, plan §2.5 step 5 et code-contracts injection.invariants. Note : spec parle de « cardinalités cibles », tests et plan interprètent uniformément comme max (cf. Écart 8 plan).
  • CV-06 — Mode dégradé non bloquant (INV-295-14/15) : _aucun résultat_ si 0 hit ; section vide + stderr si exception ; step 0 jamais bloqué. Convergence spec §5.8, tests TC-NOM-13/14 + TC-ERR-04/05/06/09, plan §2.5 step 6, code-contracts injection.invariants (exit 0 garanti).
  • CV-07 — Scan veille (INV-295-01) : motif ProbatioVault-doc/docs/veille/**/*.md, robustesse par try/except fichier par fichier, fiches invalides ignorées + stderr. Convergence 4/4.
  • CV-08 — Stack contractuelle (CA-295-17) : Python, FAISS (IndexFlatIP), Ollama nomic-embed-text 768 dim, Markdown + YAML. Tests TC-NOM-15 + TC-NR-03. Pas de Swift/Spring. Convergence.
  • CV-09 — Exclusions maintenues (INV-295-16) : HMAC, Vault, JCS, PII filter, purge RGPD, rate-limit, reranker, BM25, knowledge graph restent hors périmètre. Convergence spec §2, tests TC-NR-04, plan §10, code-contracts (aucun module crypto/secret).
  • CV-10 — Atomicité JSONL renforcée (M-06) : plan introduit jsonl_atomic et le contractualise dans code-contracts jsonl-atomic et cross-module M-06-resolution. Pas dans la spec d'origine mais compatible (renforcement défensif, zéro régression fonctionnelle).
  • CV-11 — Canonicalisation tags_hash (M-03) : fonction unique compute_tags_hash() (NFC+lower+#+dedup+sort+sha256). Convergence plan §2.6 / code-contracts data-format / INV-plan-03. Cohérent avec D-295-06 regex ^[a-f0-9]{64}$.
  • CV-12 — Aucune exigence de performance : spec §5.2 colonne percentile n/a, plan §5 confirme hors scope. Convergence.

3. Divergences

⚠️ Conflits rendus visibles. Aucun lissage.

  • DIV-01 — Nommage des fichiers clarifications (ré-entrée step 0) (MAJEUR)
  • Spec : D-295-15 impose clarification_filename regex ^PD-[0-9]{1,4}-clarifications\.md$ (taille 24..31). Tests TC-NEG-04 refuse toute persistance sur filename invalide.
  • Plan §2.2 step 3 : en cas de ré-entrée step 0, création d'un fichier horodaté PD-XXX-clarifications-{YYYY-MM-DD-HHMMSS}.md. Code-contracts clarifications-store.invariants étend la regex à ^PD-[0-9]{1,4}-clarifications(-[0-9]{8}-[0-9]{6})?\.md$.
  • Conflit direct : le filename horodaté viole D-295-15 tel que contractualisé. TC-NEG-04, appliqué strictement, rejettera la persistance produite par le plan. Le plan modifie unilatéralement un contrat spec immuable (Art. I §Immuabilité).

  • Impact : non-régression impossible à faire passer en Gate 8 sans soit amendement spec, soit renoncement à la ré-entrée horodatée (écrasement ou refus). À trancher avant implémentation.

  • DIV-02 — Recherche clarifications : KNN vs filtre exact (MODÉRÉ)

  • Spec §5bis diagramme de séquence : CLR → OLL embed(domain+project) → FAI knn_search(embedding, 3). Le diagramme est normatif (section 5bis obligatoire).
  • Spec §5.5 : « Exposition recherche /clarifications avec filtres --domain et --project ». Ambigu : filtres exacts ou filtres post-KNN.
  • Plan M-02 / §2.5 step 4 / code-contracts clarifications-store.search_clarifications_exact : filtre exact strict sur {domain, project} + tri date DESC. Pas d'appel Ollama pour cette section. Argumenté comme « diagramme stylisé, H-02 ».
  • Conflit : le diagramme §5bis décrit un KNN explicite, le plan opte pour un filtre exact. Le plan reconnaît l'écart mais construit quand même un index FAISS clarifications (dette §9 plan « à brancher ou supprimer »).

  • Impact : tests existants TC-NOM-04 (CA-295-04 « search retrouve la clarification ») et TC-NOM-13 (0 hit) ne départagent pas les deux approches ; aucun test ne vérifie actuellement qu'un filtre non-exact serait refusé ou qu'un KNN retournerait des hits hors {domain,project}. À arbitrer par le PMO : soit amender la spec §5bis, soit supprimer le filtre exact.

  • DIV-03 — Base de calcul de l'âge pour éviction (MODÉRÉ)

  • Spec : seul D-295-12 date (ISO) est défini dans le modèle de données. Aucun champ date_created n'existe au contrat.
  • Plan §2.4 step 3 + H-03 + INV-plan-09 : éviction calculée sur date_created (champ « persisté par gov-compounder »), avec fallback sur D-295-12 date si absent. Code-contracts lifecycle reprend cette règle.
  • Conflit : le plan introduit un nouveau champ non couvert par §5.1 D-295-*. Les tests TC-NOM-10 fournissent directement age=Xj sans préciser la colonne source, donc ils ne tranchent pas — mais un learning historique sans date_created tombera systématiquement sur le fallback, ce qui équivaut à utiliser date pour tous → alors pourquoi introduire date_created ? Dette contractuelle injustifiée ou spec incomplète.

  • Impact : ambiguïté opérationnelle sur le champ réel utilisé. Peut provoquer des évictions divergentes selon la version de gov-compounder qui a écrit la ligne. À résoudre : soit ajouter date_created au modèle §5.1 D-295-*, soit statuer « base = D-295-12 date, point ».

  • DIV-04 — Tri tertiaire sur date_created (MINEUR)

  • Spec : INV-295-07 impose uniquement un tri secondaire par reuse_score. Aucun tri tertiaire spécifié. Q-295-03 liste explicitement le tie-break comme point à clarifier.
  • Plan §2.5 step 2 + INV-plan-08 + code-contracts injection : tri (similarité DESC, reuse_score DESC, date_created DESC) ajouté comme invariant de plan (TC-PLAN-05).
  • Conflit : le plan tranche Q-295-03 unilatéralement via un champ qui lui-même est litigieux (cf. DIV-03). La spec dit « à clarifier », le plan dit « clarifié ».

  • Impact : acceptable si PMO valide le choix, mais la bonne voie est d'amender la spec et d'ajouter date_created à D-295-*. Tests TC-PLAN-05 seul le couvre — non présent dans PD-295-tests.md officiel.

  • DIV-05 — Tests de plan introduits hors PD-295-tests.md (MINEUR)

  • Plan §5 liste 5 tests nouveaux TC-PLAN-01..05 qui couvrent M-03, M-06, Écarts 9/11/13.
  • Tests : le document PD-295-tests.md ne contient aucun TC-PLAN-*. La matrice de couverture §2 ne référence pas ces tests.
  • Conflit : invariants de plan INV-plan-03/06/07/08/09 sans cible de test dans le document tests officiel. Rupture Art. II (séparation auteur/évaluateur) si c'est l'agent d'implémentation qui crée ses propres tests.
  • Impact : exige soit un amendement à PD-295-tests.md (par l'agent tests, pas Claude), soit une note explicite Gate 5 « ces tests seront ajoutés en step 2-bis ».

4. Zones d'ombre

  • ZO-01 — Champ date_created : origine, format, producteur (gov-compounder ?), compatibilité rétrograde avec corpus existant. Pas mentionné en spec §5.1, seulement en plan H-03.
  • ZO-02 — Index FAISS clarifications construit mais non utilisé : si DIV-02 est tranché en faveur du filtre exact, l'index FAISS data/clarifications-index.faiss devient dette morte dès livraison (plan §9 l'admet). Aucune décision sur sa suppression.
  • ZO-03 — Enum exacte de D-295-04 project : spec déclare « Enum 2..32 », sans lister les valeurs. Tests §9 Règles non testables le flaggent « majeur ». Plan §10 admet « traité comme string best-effort, dette ». Aucun des 4 documents ne tranche.
  • ZO-04 — Baseline CS-1 : fenêtre historique de comparaison non définie (Q-295-02). Plan §10 confirme hors scope. Mesure non reproductible tant que cette fenêtre n'est pas fixée.
  • ZO-05 — Validation des champs veille title / summary : spec §5.1 ne les liste pas dans D-295-*, plan H-04 les valide « best-effort » (longueur 256/2000, pas de regex). Si Gate 5 exige regex stricte, plan à revoir.
  • ZO-06 — Tie-break triple égalité : plan admet en §10 « non déterministe au-delà de l'ordre stable Python ». Spec ne statue pas. Acceptable si documenté en Gate 5.
  • ZO-07 — Écriture concurrente multi-process : spec H-295-01 pose « mono-instance ». Plan §2.7 INV-plan-06 fournit une défense jsonl_atomic mais H-07 rappelle « aucune garantie hors mono-instance ». Bonne posture défensive, mais pas de test adversarial multi-writer validé.
  • ZO-08 — Épic parent : Q-295-01 toujours ouvert (champ « Référence épique » vide dans spec §11). Aucun des 3 autres documents ne le renseigne.

5. Recommandation

  • Procéder — convergence confirmée, aucun conflit bloquant
  • Rework nécessaire — divergences à résoudre avant de continuer
  • Escalade — décision humaine requise sur un point structurant

Raison : DIV-01 est un conflit direct entre le plan et un invariant contractuel de la spec (D-295-15) doublé d'un test négatif existant (TC-NEG-04). Il bloque l'implémentation telle que proposée. DIV-02 et DIV-03 modifient des éléments de contrat (séquence §5bis, modèle de données §5.1) sans amendement spec/tests correspondant, en violation de l'Art. I §Immuabilité. DIV-04/DIV-05 sont des dettes de cohérence qui doivent être transférées soit en spec, soit en test officiel.

Actions proposées au PMO Gate 5 (aucune ne relève du rôle confrontation — simple visibilité) :

  1. Trancher DIV-01 : autoriser un amendement spec pour régex filename horodaté, ou retirer la ré-entrée du plan et retomber sur écrasement/refus.
  2. Trancher DIV-02 : confirmer filtre exact et supprimer le diagramme §5bis CLR→OLL→FAI, ou revenir au KNN côté plan.
  3. Trancher DIV-03 / ZO-01 : ajouter officiellement date_created à §5.1 D-295-*, ou figer le calcul d'âge sur D-295-12 date.
  4. Rapatrier les tests TC-PLAN-01..05 dans PD-295-tests.md (step 2 amendement) pour préserver Art. II.
  5. Documenter les zones d'ombre ZO-02..ZO-08 comme dettes explicitement acceptées au Gate 5 ou les déplacer en §10 points à clarifier de la spec.