PD-242 — Confrontation Gate 5¶

Confrontation : Analyse croisée des points Review Phase 1 Date : 2026-02-19

Analyse des écarts BLOQUANTS¶

B1 — Couverture TA non démontrée¶

Review ChatGPT : La matrice ne mappe pas explicitement TA-1..TA-16.

Confrontation : - Argument pour maintenir : La matrice montre INV→TC mais pas TA→TC explicitement. - Argument contre : La spec PD-242-tests.md contient une matrice de couverture TA→TC complète (100%). Le plan référence cette matrice et l'étend avec INV→Task→TC. Les TA sont couverts implicitement via les TC qui les implémentent. - Verdict : FAUX POSITIF — Les TA sont couverts via la matrice tests.md. Ajout d'une référence explicite dans le plan serait un "nice-to-have", pas un bloquant.

B2 — Rate limiting non garanti¶

Review ChatGPT : Le rate limiting nécessite un contrôle backend.

Confrontation : - Argument pour maintenir : Le plan ne mentionne pas explicitement de tâche backend. - Argument contre : La spec définit l'API backend (GET /recovery/envelope) qui retourne 429 si rate limit exceeded. Le backend existe déjà (endpoint à implémenter séparément). Le scope PD-242 est "app" (mobile iOS), pas "backend". Les endpoints API sont spécifiés, pas implémentés ici. - Verdict : ÉCART CONFIRMÉ mais reclassifié MINEUR — Le plan devrait clarifier que le rate limiting est côté backend (hors scope app). Ajouter une note dans les contraintes techniques.

B3 — HKDF SHA3-256 non vérifié¶

Review ChatGPT : Pas de vérification que PD-97 utilise SHA3-256.

Confrontation : - Argument pour maintenir : Le plan assume que PD-97 est conforme sans vérification explicite. - Argument contre : L'exploration du codebase montre que /src/services/hkdf.ts utilise @noble/hashes avec sha3_256(). Le service existant implémente bien HKDF-SHA3-256 (vérifié dans l'exploration TASK agent). La dépendance PD-97 est DONE avec les bons algorithmes. - Verdict : FAUX POSITIF — L'existant utilise SHA3-256 (vérifié). Pas besoin de tâche supplémentaire.

B4 — Protection screenshot non testable¶

Review ChatGPT : TC-SEC-07 n'est pas automatisable en CI.

Confrontation : - Argument pour maintenir : Les tests screenshot sont difficiles à automatiser. - Argument contre : 1. Le plan spécifie secureTextEntry pattern dans CC-04 2. Le test TC-SEC-07 vérifie l'implémentation (props du composant), pas le comportement iOS 3. Le test E2E manuel est accepté dans la DoD (audit iOS) 4. Ce n'est pas un bloquant d'implémentation mais une limite de test - Verdict : ÉCART CONFIRMÉ mais reclassifié MINEUR — Clarifier dans le plan que TC-SEC-07 est un test d'implémentation (vérifier les props) + audit manuel iOS. Pas automatisable à 100%.

Analyse des écarts MAJEURS¶

M1 — Détection device change¶

Review ChatGPT : Mécanisme de détection non décrit.

Confrontation : - Argument pour maintenir : Le flux est décrit mais pas le trigger. - Argument contre : INV-242-10 dit "changement de device DÉCLENCHE automatiquement". Le mécanisme est simple : absence de K_master dans Keychain = nouveau device. TASK-6 précondition dit "Détection absence K_master dans Keychain". C'est explicite. - Verdict : FAUX POSITIF — Le mécanisme est l'absence de K_master dans Keychain (existsMasterKey() retourne false). Pas de "signal backend" nécessaire.

M2 — H_verify stockage et comparaison¶

Review ChatGPT : Stockage et constant-time non documentés.

Confrontation : - Argument pour maintenir : Le plan ne détaille pas la comparaison. - Argument contre : 1. H_verify est stocké backend (API GET /recovery/h_verify/:user_id dans la spec) 2. La comparaison se fait côté app (match/mismatch logique simple, pas de timing attack car H_verify est public) 3. constantTimeEqual() existe dans /src/crypto/utils.ts (PD-97) — peut être utilisé - Verdict : ÉCART CONFIRMÉ MINEUR — Ajouter dans CC-03 l'utilisation de constantTimeEqual() pour la comparaison H_verify.

M3 — Stratégie test timeout¶

Review ChatGPT : Stratégie fake timers non spécifiée.

Confrontation : - Argument pour maintenir : Le plan ne mentionne pas la stratégie de test. - Argument contre : Jest supporte jest.useFakeTimers() et jest.advanceTimersByTime(). C'est une pratique standard non spécifique à PD-242. Les patterns de test sont documentés dans le projet existant. - Verdict : FAUX POSITIF — Stratégie standard Jest. Pas besoin de documenter dans le plan.

M4 — Garanties anti-fuite logs¶

Review ChatGPT : Le plan ne décrit pas les garanties anti-fuite.

Confrontation : - Argument pour maintenir : Pas de section explicite sur les interdictions logs. - Argument contre : 1. INV-242-02 "phrase jamais stockée" + TC-SEC-03/04 couvrent ce point 2. TC-LOG-01 dans tests.md vérifie explicitement l'absence de logs 3. Le plan réfère à CC-03 avec postconditions incluant ce point - Verdict : FAUX POSITIF — Couvert par INV-242-02 et TC-LOG-01. Les interdictions sont dans les invariants, pas besoin de répéter.

M5 — Approche zeroize best-effort¶

Review ChatGPT : L'approche best-effort non documentée.

Confrontation : - Argument pour maintenir : Le plan ne détaille pas les limites JS/GC. - Argument contre : 1. La spec dit "Partiel — best-effort" pour INV-242-03 2. Le code existant a zeroize() dans /src/crypto/zeroize.ts 3. CC-03 mentionne zeroizeRecoveryKey() dans l'interface - Verdict : FAUX POSITIF — Best-effort documenté dans la spec. Le plan implémente ce qui est spécifié.

M6 — Jest + ESM compatibilité¶

Review ChatGPT : @noble/bip39 ESM-only peut casser Jest.

Confrontation : - Argument pour maintenir : ESM + Jest peut nécessiter configuration. - Argument contre : 1. Le projet utilise déjà @noble/hashes et @noble/ciphers (mêmes auteurs, même ESM) 2. Jest config existante gère déjà ces dépendances 3. TASK-1 inclut "Vérifier compatibilité Metro bundler" et test import basique - Verdict : ÉCART CONFIRMÉ MINEUR — Ajouter dans TASK-1 une vérification Jest en plus de Metro. Risque faible car patterns existants.

M7 — Vérification backend ZK¶

Review ChatGPT : Propriété backend non garantie.

Confrontation : - Argument pour maintenir : Le plan ne contient pas de tâche backend. - Argument contre : 1. PD-242 scope = "app" (client iOS), pas "backend" 2. La spec API définit les contrats backend (POST/GET/DELETE) 3. L'architecture ZK est garantie par design : backend reçoit uniquement envelope + H_verify, jamais K_recovery 4. INV-242-04 est vérifié par analyse code (TC-SEC-06), pas par test d'intégration - Verdict : FAUX POSITIF — La propriété ZK est architecturale. Le backend ne peut pas déchiffrer car il n'a jamais K_recovery. Vérifié par design.

Synthèse confrontation¶

Écarts finaux : 0 bloquants, 0 majeurs, 4 mineurs

Écarts mineurs à corriger¶

1. B2 : Clarifier dans contraintes techniques que rate limiting = backend (hors scope app)
2. B4 : Préciser que TC-SEC-07 = test d'implémentation + audit manuel iOS
3. M2 : Ajouter dans CC-03 l'utilisation de constantTimeEqual() pour H_verify
4. M6 : Ajouter dans TASK-1 vérification Jest en plus de Metro

Conclusion¶

La confrontation révèle que 7 des 11 points identifiés sont des faux positifs. Le reviewer ChatGPT a sur-estimé les risques en ne tenant pas compte du contexte existant (PD-97/98 DONE, architecture ZK par design, scope app vs backend).

Les 4 écarts mineurs restants sont des clarifications documentaires sans impact sur l'implémentabilité.

Impact sur le scoring : Aucun écart bloquant ou majeur. Le plan est conforme.