PD-295 — Dossier de conformité (Étape 3, itération v2)¶
Type de gate : CONFORMITY_CHECK¶
1. Documents de référence¶
- PD-295-besoin — présent
- PD-295-specification (v2, corrigée v1→v2) — présent
- PD-295-tests (v2, corrigée v1→v2) — présent
- PD-295-review-step3-v2 (Claude, P1) — présent
- PD-295-confrontation-step3-v2 (Codex, P2) — présent
- PD-295-verdict-step3-v1 (précédent NON_CONFORME 5.812/10) — présent
2. Rapport de confrontation¶
Voir : PD-295-confrontation-step3-v2.md. Recommandation : "Rework nécessaire" (2 divergences mineures, aucun conflit bloquant).
3. Évolution v1 → v2¶
3.1 Écarts v1 résolus (14/17)¶
Tous les 3 bloquants et 8 majeurs v1 sont levés, traçabilité explicite dans le changelog v2 de chaque document (spec §Changelog v1→v2, tests §Changelog v1→v2) :
- G3-B1 (normalisation
reuse_score) → tanh, testé TC-NOM-07 - G3-B2 (clé idempotence) → séparation clé/query_hash, testé TC-ERR-10
- G3-B3 (CA-295-20 testable) → baseline figée 10 stories pre/post B5, CA-295-20 conserve un Q ouvert mais est désormais testable
- G3-M1 →
nb_domainsdéfini commemax(1, len(set(domains))) - G3-M2 → INV-295-04 persistance clarifications dans TOUS les modes
- G3-M3 → lock partagé rwlock (fcntl)
- G3-M4 → jointure learnings/scores sur
{story, gate, tag_hash} - G3-M5 →
/morningtop 3 learnings rendu OBLIGATOIRE (INV-295-22) - G3-M6 → TC ajoutés pour INV-295-17 complet
- G3-M7 → séparation CA "Gate 8" vs CA "post-merge" (§7 / §7 bis)
- G3-M8 → signature HMAC + horodatage ISO8601 ajoutés §5.1.6
3.2 Écarts v2 restants (review Claude + confrontation Codex)¶
BLOQUANT (1)¶
| ID | Type | Description |
|---|---|---|
| G3v2-B1 | SEC | La correction G3-M8 a introduit un mécanisme HMAC dont la secret_key = str(file_mtime_ns) du script émetteur. Ce n'est pas un secret (lisible via stat), il est invalidé par tout git checkout/touch/cp, et deux scripts différents produisent des clés différentes pour le même learning → INV-295-20 (« auditabilité probatoire ») littéralement implémentable mais ne garantit pas la propriété attendue. Risque RGPD/audit. |
MAJEURS (9 + 2 divergences confrontation = 11)¶
| ID | Type | Description |
|---|---|---|
| G3v2-M1 | AMB | Condition nb_domains>=1 vacuous (par construction nb_domains>=1 toujours vrai → réduit la règle de promotion à un simple seuil sur reuse_score). Le test TC-NOM-11 ne distingue pas nb_domains==0 (impossible) de ==1. |
| G3v2-M2 | AMB | Cardinalité de la section clarifications dans B5 jamais fixée (Q-295-02 reste ouverte mais INV-295-12 exige 3 sections + CA-295-13 vérifie 5 learnings / 3 veilles sans mentionner les clarifications). |
| G3v2-M3 | ECT | CS-2, CS-3, CS-4 (§7 bis) sont référencés sans définition formelle des formules de calcul. La correction G3-M7 a déplacé les KPI en §7 bis mais n'a pas ajouté les formules de mesure. |
| G3v2-M4 | SEC | Le flux B3 (scoring) n'est pas dans la politique de lock rwlock → race possible avec B4 (promotion) et B5 (lecture). La correction G3-M3 couvre B4↔B5 mais laisse B3 hors scope. |
| G3v2-M5 | ECT | B5 (gov-learnings-inject) ne propage pas explicitement --domain --project à search-clarifications alors que ces flags sont obligatoires côté CLI (INV-295-14). Gap d'interface. |
| G3v2-M6 | ECT | Purge des clarifications dépend de step 10 (gov-compounder), mais les stories rejetées en Gate ⅗/8 ne passent jamais step 10 → bypass de la rétention 18 mois. |
| G3v2-M7 | AMB | Collision possible entre bucket idempotence (5 min) et rate-limit (3 requêtes / 5 min) — deux mécanismes temporels indépendants avec fenêtres identiques sans règle d'arbitrage. |
| G3v2-M8 | AMB | Schéma JSONL des clarifications (data/clarifications.jsonl) absent de la spec, alors que learnings/veille ont leurs schémas documentés en §5.3. |
| G3v2-M9 | SEC | restore-learning.py émet un événement audit signé mais la politique de clé pour cet event n'est pas documentée (hérite-t-il de G3v2-B1 ?). |
| G3v2-M10 (DIV-01) | ECT | Limite query > 500 chars dans tests TC-NEG-04 mais absente de la spec → implémentation conforme spec peut échouer QA. |
| G3v2-M11 (DIV-02) | AMB | Cohérence count>0 ⇒ result_ids non vide exigée par tests TC-NEG-03 mais pas formalisée dans spec §5.1.6. |
MINEURS (9)¶
Écarts mineurs listés dans la review v2, non détaillés ici. Impact estimé : -0.25 par écart.
3.3 Scoring v2 par critère¶
completeness — impacté par G3v2-B1 (cascade sur INV-295-20), G3v2-M2, G3v2-M3, G3v2-M8, G3v2-M10, G3v2-M11 et 3 mineurs : - 10 − 2 − 1 − 1 − 1 − 1 − 1 − 3×0.25 = 2.25
Correction : G3v2-B1 pèse sur completeness mais pas sur l'ensemble. Je distribue plus finement :
completeness : spec couvre les 5 briques, les invariants, les CA, les modèles de données ; écarts majeurs de complétude = M2 (cardinalité), M3 (formules KPI), M8 (schéma JSONL clarifications), M11 (règle count/result_ids), 3 mineurs. - 10 − 1 − 1 − 1 − 1 − 3×0.25 = 5.25
testability — impacté par G3v2-M1 (règle vacuous non distinguable), G3v2-M5 (flag interface), G3v2-M10 (DIV-01 impl vs tests), 2 mineurs : - 10 − 1 − 1 − 1 − 2×0.25 = 6.5
clarity — impacté par G3v2-M4 (lock scope flou), G3v2-M6 (bypass rétention non explicite), G3v2-M7 (collision buckets), G3v2-M9 (cascade audit), 2 mineurs : - 10 − 1 − 1 − 1 − 1 − 2×0.25 = 5.5
traceability — quasi inchangé, index/jointures désormais explicites. G3v2-B1 impacte la propriété probatoire mais pas la traçabilité formelle des invariants → 2 mineurs uniquement : - 10 − 2 − 2×0.25 = 7.5
Attention : G3v2-B1 est un BLOQUANT qui impacte directement traceability (auditabilité probatoire cassée) : - 10 − 2 − 2×0.25 = 7.5 (le bloquant est déjà compté dans -2)
4. Verdict attendu¶
Scores v2 : - completeness = 5.25 - testability = 6.5 - clarity = 5.5 - traceability = 7.5 - moyenne = 6.19
Règles de dérivation : - Au moins un score < 6 (completeness 5.25, clarity 5.5) → NON_CONFORME - Moyenne < 7 → NON_CONFORME
Convergence v1 → v2 : - v1 mean = 5.812 - v2 mean = 6.19 - delta = +0.375 (amélioration mais < 0.5) - mean v2 < 7 → plateau insuffisant → ESCALADE possible selon règle
Décision : la convergence est strictement inférieure à 0.5 ET la moyenne reste < 7. Selon la matrice de convergence du skill /gov-gate :
delta < 0.5 ET mean < 7→ ESCALADE — plateau insuffisant
Cependant, le contenu des écarts v2 est qualitativement différent (1 bloquant unique sur HMAC — un problème de design de sécurité bien identifié, résolvable par un choix simple comme passer à une clé statique gérée via Vault). La v3 a une probabilité élevée de converger en GO si l'on corrige (a) G3v2-B1 (clé HMAC via Vault), (b) G3v2-M1-M11 qui sont des précisions de spec.
- GO — conformité vérifiée
- RESERVE — conformité partielle, conditions à satisfaire
- NON_CONFORME — 1 bloquant + 11 majeurs. Boucle de correction v3 déclenchée (dernière itération avant plafond Art. I)
- ESCALADE — décision humaine requise (convergence plateau, mais v3 possible dans le plafond)