PD-262 — Dossier de conformite Gate 5 (v2)¶
1. Bilan correction v1 → v2¶
Les 5 ecarts v1 (E-01 a E-05) sont resolus : - E-01 (BLOQ) : getDeviceIdPseudo() ajoute au module natif T1, bridge T2, et utilise par T5 audit - E-02 (MAJ) : Distinction reconstruction boot vs transition state machine formalisee dans FT5/FT6 - E-03 (MAJ) : STUB endpoint audit backend identifie comme PD-283 - E-04 (MAJ) : TC-INV-02 et TC-NEG-03 clarifies comme tests d'integration sur device reel - E-05 (MAJ) : Bootstrapping first_launch_clean documente dans C1
2. Ecarts residuels v2¶
MAJEUR (3)¶
| ID | Type | Description | Impact |
|---|---|---|---|
| E-06 | DIV | Le bootstrapping first_launch_clean introduit un marqueur UserDefaults volatil de session pour detecter une reinstallation, alors que la spec §3.6 interdit UserDefaults pour tout mecanisme anti-tampering | Non-conformite spec §3.6 — necessite mecanisme alternatif (ex: marqueur container app) |
| E-07 | AMB | Aucun mecanisme pour distinguer TestFlight de Release de Production dans le module natif. Le champ environment du payload audit peut etre incorrect | Payload audit potentiellement incorrect sur environment — detection TestFlight via appStoreReceiptURL non documentee |
| E-08 | DIV | Les contracts CC-262-T10 exigent TC-INV-02/TC-NEG-03 "presents" dans les fichiers test, mais le plan les classe "device reel uniquement". Contradiction sur le niveau de test CI vs device reel | Seuil couverture 80% potentiellement impacte si tests adversariaux sont des no-op en CI |
MINEUR (4)¶
| ID | Type | Description | Impact |
|---|---|---|---|
| E-09 | DIV | Le plan (C4) ajoute deleteMasterKey() et deleteBiometricSecret() comme cibles de purge, mais INV-262-05 ne les liste pas explicitement (K_master et K_bio sont en Keychain, pas en "memoire") | Extension de purge coherente avec intention spec mais non formellement couverte par INV-262-05 |
| E-10 | ECT | Aucun test ne couvre le cas identifierForVendor = nil (HT-02) → device_id_pseudo vide → payload rejete par regex → lockout conserve | Scenario d'erreur silencieux non teste |
| E-11 | AMB | CC-262-T8 output dit "tamperingLockout: boolean (persisted)" suggerant persistance AsyncStorage, alors que Keychain natif est source de verite. Mecanisme de synchronisation boot non detaille | Risque de desynchronisation si "persisted" signifie AsyncStorage |
| E-12 | ECT | Plan numeration C9=Tests, C10=Expo Config mais contracts T9=Expo Config, T10=Tests — inversion | Risque de confusion agents multi-step, pas de conflit fonctionnel |
3. Scoring v2¶
| Critere | Score | Ecarts |
|---|---|---|
| feasibility | 9.5 | E-12 (-0.25 MIN), E-10 (-0.25 MIN) |
| coverage | 8.75 | E-08 (-1 MAJ), E-09 (-0.25 MIN) |
| risk_mitigation | 8.75 | E-07 (-1 MAJ), E-11 (-0.25 MIN) |
| coherence | 9.0 | E-06 (-1 MAJ) |
Moyenne v2 : (9.5 + 8.75 + 8.75 + 9.0) / 4 = 9.0 Moyenne v1 : 8.0 Delta : +1.0 (amelioration significative)
4. Convergence¶
Tous les scores >= 8. Moyenne >= 8. → GO
5. Note sur ecarts P1 ChatGPT non retenus¶
3 ecarts BLOQUANT identifies par ChatGPT P1 v2 ne sont pas retenus dans le dossier : - BLOQ-1 (native authority JS) : Contredit par la confrontation Claude P2 (CONV-03) — le plan specifie explicitement ecriture Keychain AVANT resolve() Promise JS. Faux positif. - BLOQ-2 (crash/kill FT6) : Contredit par la confrontation Claude P2 (CONV-12) — FT6 couvre explicitement ce cas via fail-closed. Faux positif. - BLOQ-3 (mock Keychain metadata) : Methodologie de test, pas non-conformite du plan. Reclasse MINEUR (couvert par E-08 test alignment).