Je lance l'audit Gate 5 v2 du plan PD-284. Tous les documents sont fournis dans le prompt — je procède à l'analyse.
PD-284 — Plan d'implémentation : Revue (Gate 5 v2)¶
1. Références¶
- Spécification : PD-284-specification.md (v3)
- Tests contractuels : PD-284-tests.md (v3)
- Plan d'implémentation : PD-284-plan.md (v2 corrigé)
- Code contracts : PD-284-code-contracts.yaml
- Date de revue : 2026-03-13
- Reviewer : Claude Opus 4.6 (mode factuel, auditeur PMO)
2. Vérification des écarts v1¶
| ID v1 | Gravité | Correction annoncée | Vérification | Statut |
|---|---|---|---|---|
| E-01 | MAJEUR | Clause CE-SSE-01 ajoutée (HT-03 vs CC SSE) | HT-03 contient la clause CE-SSE-01 complète. CC seal-sse-client forbidden référence la clause. L'alternative react-native-sse est autorisée sous wrapper conforme. | RÉSOLU |
| E-02 | MAJEUR | Table §2.1b mapping 7 états→5 étapes | §2.1b présent avec les 7 états mappés (RECEIVED/QUEUED_PRIORITY→Capture, TSA_PENDING/TSA_SEALED→TSA, ANCHOR_PENDING→Merkle/Blockchain, SEALED→Scellé, FAILED_TIMEOUT→overlay). Règle overlay documentée. | RÉSOLU |
| E-03 | MAJEUR | failure_reason typé C1, affiché C9/C10 | C1 liste FailureReason dans interfaces. C9 invariant : "failure_reason affiché comme overlay erreur quand état = FAILED_TIMEOUT". INV-284-08 mapping mentionne l'affichage. §2.1b : overlay erreur + failure_reason + message support. | RÉSOLU |
| E-04 | MAJEUR | purgeStaleSealArtifacts() dans C12/C7 | C12 expose purgeStaleSealArtifacts en interface. C7 invariant : "appelée au démarrage de triggerUrgentSeal() (avant POST)". §7 sécurité le confirme. Learning PD-283/PD-262 cité. | RÉSOLU |
| E-05 | MAJEUR | Section §11 contraintes techniques | §11 présent : PD-80 STUB + mocks msw/jest.fn(), Jest+RNTL, Metro CJS/Hermes, aucune variable CI spécifique. Complet. | RÉSOLU |
| E-06 | MAJEUR | TC-NOM-13 test proxy CI (re-render ≤ 2) | §5 mapping TC-NOM-13 : "Test proxy CI : vérifier nombre de re-renders ≤ 2 par événement SSE via jest.fn()". §12 périmètre de test : proxy en CI, device hors CI. Ticket de suivi mentionné. | RÉSOLU |
| E-07 | MAJEUR | HT-09 formalisée + test vérification | HT-09 documentée : "PD-80 est idempotent sur POST /seals/urgent". Test de vérification décrit : 2× POST même document_id → même seal_id. Fallback fail-closed si non-idempotent. Chaîne R-03→HT-09 cohérente. | RÉSOLU |
| E-08 | MINEUR | Ring buffer uniformisé | CA-284-07 : "Cache FIFO ring buffer (tableau circulaire)". CC C4 : "ring buffer, pas LRU". §9 point de vigilance 3 : "tableau circulaire (ring buffer)". Aucune mention résiduelle de Set. | RÉSOLU |
| E-09 | MINEUR | position_in_queue affiché C9 | C9 description : "affichage position_in_queue en état QUEUED_PRIORITY". §2.1b : "Étape 1 active + affichage position_in_queue". CC C9 invariant : "position_in_queue affiché en sous-titre". | RÉSOLU |
| E-10 | MINEUR | getSensitiveArtifact() dans C12 | C12 interface : getSensitiveArtifact. CC C10 : "tsa_token_ref lu via C12.getSensitiveArtifact(sealId, 'tsa_token_ref') — lecture transitoire, jamais dans state Zustand". Flux clair. | RÉSOLU |
| E-11 | MINEUR | tsa_timestamp ajouté dans C1 | C1 interfaces liste TsaTimestamp. Type présent dans le contrat seal-types. | RÉSOLU |
| E-12 | MINEUR | degradation_flag inconnu : silencieux + justification | §6 gestion des erreurs : "Traiter comme none + telemetry silencieuse (pas de toast). Justification : un flag inconnu n'est PAS une erreur contrôlée §3 mais un cas conservateur." Tranché. | RÉSOLU |
| E-13 | MINEUR | mode_expert : tâche formalisée | §9 dette technique : "Tâche explicite : ajouter mode_expert: boolean (défaut false) dans useSettingsStore. Fichier : src/store/useSettingsStore.ts. Persistance AsyncStorage. Rattachée à C10." | RÉSOLU |
Bilan v1 → v2 : 13/13 écarts RÉSOLUS.
3. Constatations (nouveaux écarts v2)¶
| ID | Type | Référence | Description | Impact | Gravité |
|---|---|---|---|---|---|
| E-14 | Non-conformité Spec | Plan §12 (×2) | Double numérotation §12 : "§12. Mécanismes cross-module" et "§12. Périmètre de test" portent le même numéro de section. Le premier devrait être §12 et le second §13 (ou l'inverse). Ambiguïté de référencement dans les renvois internes. | Confusion documentaire lors du référencement de sections. Aucun impact fonctionnel. | MINEUR |
| E-15 | Couverture manquante | CC C10 / Spec §5.4 | proof_package_url absent du mapping expert C10. La spec §5.4 dit : "blockchain_tx_hash, proof_package_url : à SEALED". Le CC C10 EXPERT_FIELDS_BY_STATE résume : "blockchain à SEALED" sans lister explicitement proof_package_url. L'implémenteur pourrait omettre l'affichage de l'URL de téléchargement du package de preuve. | Champ expert contractuel potentiellement non affiché à l'état SEALED. | MINEUR |
| E-16 | Hypothèse implicite | C1 types / Plan §3, §4 | tsa_timestamp typé (C1) mais sans consommateur identifié. Le type TsaTimestamp est déclaré dans C1 (correction E-11). La spec §5.12 l'inclut dans le payload TSA_SEALED. Mais aucun composant (C9, C10) ne le consomme ou ne l'affiche. La spec §5.4 ne le liste pas dans le mode expert. Le plan ne documente pas si ce champ est reçu-mais-non-affiché ou s'il devrait être affiché. | Champ typé sans usage — dette morte ou oubli d'affichage. Pas de risque fonctionnel si intentionnel. | MINEUR |
| E-17 | Couverture manquante | Spec §5.8 sse_reconnect_max_cumulative_delay / TC-NOM-08 | Absence de TC pour le plafond cumulé de backoff (30s). Le paramètre sse_reconnect_max_cumulative_delay=30s est contractualisé (spec §5.8, CC C3). Le plan documente le comportement : failover immédiat si cumulé dépassé. Mais aucun TC ne couvre le scénario où base × Σfactor^i > max_cumulative_delay déclenche un failover AVANT max_attempts. TC-NOM-08 ne teste que le cas nominal (1+2+4=7s < 30s). | Scénario de configuration non standard non testé. Avec les defaults, jamais atteint (7s << 30s). | MINEUR |
| E-18 | Code Contract — Cohérence | CC seal-store invariant / CC seal-event-processor | Chevauchement de responsabilité sur la validation degradation_flag. CC C5 (seal-store) dit "Flag inconnu traité comme none + telemetry". CC C4 (seal-event-processor) dit "Validation Zod du payload avant application". Si Zod rejette un degradation_flag inconnu comme invalide (erreur contrôlée + toast), cela contredit le traitement silencieux documenté dans C5 et §6. Le plan ne précise pas si la validation Zod du champ degradation_flag est stricte (enum closed) ou permissive (string avec post-traitement). | Comportement contradictoire possible : toast Zod vs silence conservateur. | MINEUR |
4. Synthèse¶
| Gravité | Nombre | IDs |
|---|---|---|
| BLOQUANT | 0 | — |
| MAJEUR | 0 | — |
| MINEUR | 5 | E-14, E-15, E-16, E-17, E-18 |
Écarts v1 : 13/13 RÉSOLUS (7 MAJEURS + 6 MINEURS corrigés).
Nouveaux écarts v2 : 5 MINEURS identifiés — aucun ne remet en cause la faisabilité, la conformité structurelle ou la sécurité du plan.
5. Scoring¶
| Axe | Score | Justification |
|---|---|---|
| Feasibility | 9/10 | Tous les mécanismes sont concrets, le tech stack (Zustand, Zod, NetInfo, SecureStore, Jest+RNTL) est maîtrisé. Clause CE-SSE-01 couvre le risque SSE RN. Dépendance PD-80 STUB correctement gérée par mocks. |
| Completeness | 9/10 | 13 invariants mappés, 17 CA tracés, tous les TC ont un mécanisme + observable. Gaps résiduels : proof_package_url implicite dans C10, tsa_timestamp sans consommateur, TC plafond cumulé absent. |
| Coherence | 8/10 | Double §12, chevauchement mineur C4/C5 sur degradation_flag. Le reste est parfaitement aligné : spec → plan → CC → TC. Chaîne R-03→HT-09 solide. |
| Traceability | 9/10 | Matrices §3 (invariants→mécanismes), §4 (CA→mécanismes), §5 (TC→mécanismes+observables) exhaustives. Réserves Gate 3 (R-01/R-02/R-03) intégrées et référencées. |
Score global : 8.75/10
6. Verdict de la revue¶
- Statut : ✅ CONFORME
- Motif : Les 13 écarts v1 (dont 7 MAJEURS) sont tous effectivement corrigés. Les 5 nouveaux écarts sont MINEURS et ne constituent ni un risque de non-conformité, ni un blocage d'implémentation. Le plan est complet, traçable et cohérent avec la spécification v3.