PD-276 — Dossier de conformité Gate 5 (v1)¶
Gate : AMBIGUITY | Story : PD-276 | Itération : v1
1. Documents de référence¶
| Document | Source | Étape |
|---|---|---|
| PD-276-plan.md | Claude (claude -p) | 4 |
| PD-276-code-contracts.yaml | Claude (claude -p) | 4 |
| PD-276-specification.md | ChatGPT v2 | 1 |
| PD-276-tests.md | ChatGPT v2 | 2 |
| PD-276-review-step5.md | ChatGPT gpt-5.3-codex | 5.1 |
| PD-276-confrontation-step5.md | Claude (claude -p) | 5.2 |
2. Synthèse des écarts¶
BLOQUANT (1)¶
| ID | Type | Référence | Description | Source |
|---|---|---|---|---|
| ECT-01 | Contradiction | INV-276-09 (spec) vs checks Prolog 10/22 | La spec v2 contractualise service_method(argon2, validateParams) mais les checks Prolog consomment deriveKey. Le plan résout via un alias deriveKey()→validateParams() mais la spec ne documente pas cette dualité. INV-276-09 doit lister les deux faits. | Review #1 + DIV-01 + DIV-05 |
MAJEUR (4)¶
| ID | Type | Référence | Description | Source |
|---|---|---|---|---|
| AMB-02 | Ambiguïté | C3 concaténation canonique | Le séparateur null byte dans la concaténation HMAC apparaît dans le plan et les code-contracts mais pas dans la spec. Risque de collision sans séparateur. | Review #4 + DIV-02 |
| AMB-03 | Ambiguïté | Plan C1 vs F1 (diagramme) | Le diagramme F1 montre POST /auth/register via Argon2Controller mais la note précise que ce controller n'est pas utilisé pour la validation métier. Architecture d'appel ambiguë. | Review #6 |
| ECT-04 | Incohérence | C5 flag readOnly vs signature inchangée | Le plan annonce un flag readOnly en sortie LEGACY mais les code-contracts interdisent de changer la signature des méthodes existantes. | Review #5 |
| SEC-05 | Risque | C6 migration phase 2 | Critère d'achèvement du backfill (zéro LEGACY) non contractualisé dans un garde-fou exécutable. | Review #7 |
MINEUR (3)¶
| ID | Type | Référence | Description | Source |
|---|---|---|---|---|
| AMB-06 | Ambiguïté | Diagramme ASCII PV::MB::v1 | Le diagramme ASCII de F3 utilise PV::MB::v1 au lieu de ProbatioVault::MetadataBinding::v1. Raccourci de lisibilité, pas d'impact code. | Review #2 (déclassé) |
| AMB-07 | Ambiguïté | E-05 HTTP 500 vs non-conformité | METADATA_TAG_MISSING mappé HTTP 500 mais la spec le pose comme non-conformité de données. | Review #9 |
| ECT-08 | Traçabilité | Q-276-05 vs extract-facts.py | Le plan fixe le nom du script CI mais Q-276-05 reste ouvert dans la spec. | Review #10 + DIV confrontation |
3. Convergences confirmées¶
- Architecture 4 agents (argon2, binding, migration, tests) cohérente avec les 8 modules
- Stack NestJS/TypeORM/PostgreSQL correctement ciblée
- HKDF avec contexte strict pour K_binding
- Migration 2 phases avec rollback
- Machine à états dérivée du metadata_tag (pas de champ état séparé)
- Couverture 38 tests couvrant 11/11 invariants
- Politique LEGACY phase 1 lecture seule avec warning
- Zeroization de K_binding dans finally (pattern existant)
4. Scoring¶
| Critère | Score | Justification |
|---|---|---|
| feasibility | 8.0 | Architecture bien dimensionnée, composants NestJS standard, dépendances existantes réutilisées |
| coverage | 7.0 | 1 BLOQUANT deriveKey/validateParams, séparateur HMAC non contractualisé dans spec |
| risk_mitigation | 7.0 | Migration sans garde-fou backfill, flag readOnly vs signature, SLA < 100ms non budgété |
| coherence | 7.0 | Incohérence spec↔plan sur INV-276-09, diagramme PV::MB::v1, E-05 HTTP code |
Score moyen : 7.25
5. Verdict préliminaire¶
Avec un score moyen de 7.25 (>= 7) mais 3 scores à 7.0 (< 8), le verdict attendu est RESERVE.
Le BLOQUANT #1 (deriveKey/validateParams) est un problème de documentation spec → il doit être corrigé dans la spec mais n'empêche pas le plan de fonctionner (l'alias est la bonne solution). Déclassé en MAJEUR pour le scoring car le plan le résout correctement, mais la spec reste incohérente.
Dossier assemblé par l'orchestrateur Claude le 2026-02-28.