PD-295 — Rapport de confrontation (Gate 8 — Closure)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate PMO 8. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

2. Convergences¶

• C-01 — Perimetre B1..B5 : les 4 documents s'accordent sur les 5 briques fonctionnelles (veille-indexer, clarifications-store, scoring, lifecycle, injection unifiee). Aucun document n'introduit de brique supplementaire ni n'en omet une.

• C-02 — Machine a etats scope : la FSM a 4 etats (STORY_ACTIVE, DOMAIN_ACTIVE, GLOBAL_ACTIVE, ARCHIVED) est identique dans la specification (§5.9, INV-295-TR-01..13), les tests (TC-NOM-16, TC-ERR-07, TC-ERR-11), le plan (§2.4 + scope_fsm.py) et l'acceptabilite (lifecycle valide avec 59 archives). Les transitions autorisees et interdites sont coherentes.

• C-03 — Formule reuse_score : les coefficients 0.4/0.4/0.2 (INV-295-05) sont repris a l'identique dans les tests (TC-NOM-05 : L1=1.8, L2=1.0), le plan (§2.3 compute_reuse_score) et l'acceptabilite (303 learnings scores). Interpretation somme brute coherente entre plan (M-01) et tests.

• C-04 — Seuils de promotion : 0.3 (story->domain) et 0.6 (domain->global) contractualises en spec (INV-295-09/10), testes (TC-NOM-09 bords 0.29/0.30/0.59/0.60), implementes au plan (§2.4 step 2) et valides en acceptabilite (lifecycle status).

• C-05 — Eviction conjonctive : regle age > 56 jours ET nb_injections == 0 identique dans spec (INV-295-11), tests (TC-NOM-10 matrice 4 cas), plan (§2.4 step 3) et acceptabilite (59 archives).

• C-06 — Non-blocage step 0 : les 4 documents contractualisent le comportement non bloquant (INV-295-14/15, TC-NOM-13/14, TC-ERR-04/05/06, plan §2.5 step 6 try/except, acceptabilite mode degrade veille confirme).

• C-07 — Stack technique : Python/FAISS/Ollama/nomic-embed-text/Markdown/YAML/JSONL. Aucun document n'introduit Swift, Spring ou autre technologie hors perimetre. Spec §10, tests TC-NOM-15/TC-NR-03, plan §1, acceptabilite 11 scripts Python.

• C-08 — Exclusions : HMAC, Vault, JCS, PII, RGPD purge, rate-limit, reranker neural, BM25, knowledge graph, skill router, resumes hierarchiques — exclus uniformement (spec §2, tests TC-NR-04, plan §10, acceptabilite implicite).

• C-09 — Cardinalites injection : 5/3/3 max pour learnings/veille/clarifications — spec (INV-295-13), tests (TC-NOM-12), plan (§2.5), acceptabilite (5 learnings retournes confirme).

• C-10 — Verbatim brut clarifications : les 4 documents exigent la persistance sans resume ni filtrage (INV-295-03, TC-NOM-03, plan §2.2 step 2, acceptabilite implicite via review Codex).

3. Divergences¶

Les conflits ne sont JAMAIS lisses. Chaque divergence est rendue visible.

• DIV-01 — Index veille FAISS non teste en acceptabilite
• Specification (INV-295-01, INV-295-02) : B1 DOIT scanner les fiches, produire veille.jsonl ET generer embeddings + index FAISS.
• Tests (TC-NOM-01) : attendent veille.jsonl + index FAISS veille produits.
• Plan (§2.1 steps 6-7) : embeddings Ollama + FAISS IndexFlatIP 768 dim.
• Acceptabilite : index-veille (Ollama requis) : Non teste — Ollama sur IA-Server non lance pendant la session. Seul collect-veille (127 fiches JSONL) est valide.

• Impact : le flux complet B1 (JSONL + embeddings + FAISS) n'est valide qu'a 50%. La recherche semantique veille n'a pas ete exercee. Le mode degrade (grep fallback) a ete valide implicitement mais pas le flux nominal.

• DIV-02 — Fallback grep veille sans filtres impact/verdict (M-3 accepte)

• Specification (§5.8 step 2) : recuperation veille avec impact_pv in {fort, modere}.
• Plan (§2.5 step 3) : filtre post-KNN impact_pv in {fort, modere}. Test TC-PLAN-04 prevu pour couvrir ce filtre.
• Acceptabilite : M-3 accepte comme ecart residuel — le fallback grep n'applique pas --impact/--verdict. Justification : mode degrade exceptionnel, outil interne.

• Impact : en mode degrade (Ollama down), les fiches impact_pv=faible ou impact_pv=aucun peuvent etre injectees dans le step 0, contrevenant a l'intention du filtre spec. L'impact reste faible (outil interne, mode degrade rare).

• DIV-03 — Validation dimension embedding non implementee (M-5 accepte)

• Specification (§5.2) : embedding_dimension = 768 fixe, hors bornes = Indexation rejetee.
• Tests (TC-NEG-05) : dimension != 768 doit etre rejetee avec erreur explicite et index non publie.
• Plan (§2.1 step 6) : raise ValueError si dimension != 768.
• Acceptabilite : M-5 accepte — pas de validation dimension avant faiss.search. Justification : coherence avec codebase existante (index-learnings.py meme pattern).

• Impact : si Ollama retourne un modele avec dimension != 768 (changement de modele, mise a jour), l'index sera corrompu silencieusement. Risque faible en pratique (modele fixe nomic-embed-text), mais le test TC-NEG-05 serait en echec.

• DIV-04 — Index publie avec vecteurs zero si Ollama down (M-7 accepte)

• Specification (INV-295-15) : si source echoue, section vide + stderr, sans blocage.
• Plan (§2.1 steps 6-7) : embeddings Ollama, dimension 768, FAISS.
• Acceptabilite : M-7 accepte — index publie avec vecteurs zero quand Ollama down. Justification : meme pattern que index-learnings.py, index regenere par reindex-all.py.

• Impact : un index avec vecteurs zero degrade les resultats KNN (faux positifs de similarite). Non bloquant pour step 0 (l'injection continue), mais la qualite des resultats veille est compromise jusqu'au prochain reindex-all.py. Distinct de DIV-01 : ici l'index est publie mais avec des donnees degradees.

• DIV-05 — Scores tous a 0.0 — B3 non exerce avec donnees reelles

• Tests (TC-NOM-05) : dataset deterministe L1=1.8, L2=1.0.
• Plan (§2.3) : formule brute testable.
• Acceptabilite : 303 scores calcules — tous a 0.0 (normal, #28 pas encore utilise).

• Impact : la formule est implementee mais n'a ete validee qu'avec le cas trivial (zero injections = score 0.0). Les cas non triviaux (injections reelles, gate8 GO, multi-domaines) n'ont pas ete exerces en conditions reelles. Les promotions (seuils 0.3/0.6) n'ont donc pas ete declenchees en environnement reel.

• DIV-06 — Sonar Phase 1.5 non applicable

• Procedures CLAUDE.md : Scan Sonar local OBLIGATOIRE [...] Phase 1.5 est BLOQUANTE.
• Acceptabilite : Non applicable : projet Python scripts internes, pas de projet SonarQube configure.

• Impact : derogation structurelle documentee. La qualite est assuree par review Codex (Phase 2). Coherent avec le contexte du projet (scripts Python CLI, pas de CI, pas de SonarQube).

• DIV-07 — Clarifications : filtre exact vs KNN (plan H-02 vs spec §5bis)

• Specification (diagramme §5bis) : montre un appel KNN FAISS pour les clarifications (CLR -> OLL -> FAI).
• Plan (§2.5 step 4, H-02) : filtre exact {domain, project} + tri recence, pas de KNN. Index FAISS construit pour usage futur mais non utilise au step 0.
• Tests (TC-NOM-04) : teste l'indexation FAISS clarifications + recherche, sans preciser si KNN ou filtre exact.
• Acceptabilite : ne mentionne pas explicitement le choix filtre exact vs KNN.
• Impact : ecart deja traite en Gate 5 (reserve M-02 resolue par le plan). Le diagramme spec §5bis est documente comme "stylise". Le filtre exact est plus robuste (pas de dependance Ollama pour les clarifications). Divergence resolue par decision de plan, mais le diagramme spec reste incoherent avec l'implementation.

4. Zones d'ombre¶

• ZO-01 — Regles non testables persistantes : les tests §9 identifient 4 regles non testables (tie-break final, enum project, baseline CS-1, procedure ARCHIVED manuelle). Aucun document ulterieur ne les resout. La specification (Q-295-03) et le plan (§10) les documentent comme dette acceptee. Le tie-break est partiellement resolu par le plan (INV-plan-08 : tri tertiaire date_created desc), mais le cas similarite + score + date tous egaux reste non deterministe.

• ZO-02 — Tests plan (TC-PLAN-01..05) non mentionnes en acceptabilite : le plan introduit 5 tests supplementaires (canonicalisation tags_hash, atomicite JSONL, score absent=0.0, filtre impact_pv, tiebreak date). L'acceptabilite ne mentionne pas leur execution. Le plan les prevoit comme tests unitaires (pytest + fixtures) mais la wave 5 (tests) n'est pas documentee en acceptabilite.

• ZO-03 — Invariants plan (INV-plan-03..09) non traces en acceptabilite : le plan ajoute 5 invariants (canonicalisation tags_hash, atomicite JSONL, score absent=0.0, tiebreak date, base d'age). L'acceptabilite ne les mentionne pas explicitement. La review Codex (Phase 2) a couvert le code mais sans reference aux invariants plan.

• ZO-04 — Reentrancy clarifications non testee : le plan (§2.2 step 3, H-06) prevoit la creation de fichiers horodates PD-XXX-clarifications-{ts}.md en cas de reexecution step 0. Aucun test (TC-*) ne couvre ce cas. L'acceptabilite ne le mentionne pas.

• ZO-05 — Normalisation L2 embeddings FAISS : le plan (§9 point de vigilance) mentionne que IndexFlatIP necessite faiss.normalize_L2 avant insertion. Aucun test ne verifie que la normalisation est effectivement appliquee. L'acceptabilite ne mentionne pas ce point (index FAISS veille non teste, cf. DIV-01).

• ZO-06 — Backfill date_created : le plan (H-03) prevoit un script one-shot de backfill date_created = date pour les learnings anterieurs. Ce script n'est pas mentionne dans la decomposition ni dans l'acceptabilite. Si non execute, le fallback sur D-295-12 date sera systematique pour le corpus historique.

5. Recommandation¶

• Proceder — convergence confirmee, aucun conflit bloquant
• Rework necessaire — divergences a resoudre avant de continuer
• Escalade — decision humaine requise sur un point structurant

Justification : les 10 convergences couvrent l'essentiel du contrat fonctionnel (FSM, formule scoring, seuils, non-blocage, stack, exclusions, cardinalites). Les 7 divergences identifiees se repartissent en : - 3 ecarts residuels acceptes par coherence codebase (DIV-02 M-3, DIV-03 M-5, DIV-04 M-7), tous documentes et justifies en acceptabilite - 1 flux non teste par contrainte d'environnement (DIV-01 index FAISS veille, Ollama non disponible) - 1 scoring non exerce en conditions reelles (DIV-05, structural — #28 pas encore utilise) - 1 derogation structurelle documentee (DIV-06 Sonar) - 1 divergence deja resolue en Gate 5 (DIV-07 filtre exact clarifications)

Les zones d'ombre (ZO-01..06) sont principalement des dettes documentaires mineures ou des cas limites non testables, sans impact bloquant sur la livraison. La decision finale revient au PMO.