# 5.2 — Stockage sécurisé & vérification

## Objectif
Implémenter `ParentalCodeRepository` : stocker le code de façon sûre (haché, jamais
en clair) et vérifier une saisie.

## Périmètre & hors-périmètre
- Inclus : hachage du code, stockage via `flutter_secure_storage`, vérification.
- Exclus : écrans (5.1/5.3).

## Dépendances
5.1 (interface + `ParentalCode`).

## Conception
- **Data** (`features/parental/data/`) :
  - `SecureParentalCodeRepository implements ParentalCodeRepository`.
  - Stocke un **hachage** du code (+ sel) dans `flutter_secure_storage` — jamais la valeur en clair.
    - Pour 4 chiffres, l'espace est petit (10 000 combinaisons) : le hachage protège contre la lecture directe du stockage, sans prétendre à une résistance forte au brute-force hors-ligne. C'est cohérent avec le modèle de menace (garde-fou enfant, cf. CLAUDE.md §1). Documenter ce choix.
  - `isConfigured()` = présence de la clé ; `verify(code)` = comparaison des hachages (comparaison à temps constant si simple à faire).
- **DI** : `parentalCodeRepositoryProvider`.

## Plan TDD
1. **Red** : `secure_parental_code_repository_test.dart` — avec un `flutter_secure_storage` mocké :
   - `setCode` écrit une valeur **différente** du code en clair (hachée).
   - `verify` renvoie `true` pour le bon code, `false` sinon.
   - `isConfigured` reflète la présence de la clé.
2. **Green** : implémenter hachage + repository.
3. **Refactor**.

## Definition of Done
- Tests verts ; aucune écriture du code en clair (vérifié par le test).
- `tool/check.sh` passe ; étape 5.2 cochée dans `ROADMAP.md` ; choix du modèle de menace consigné.

## Risques / notes
- `flutter_secure_storage` s'appuie sur le Keystore Android : tester aussi le cas « valeur absente » au premier lancement.
- Ne pas réinventer de crypto : utiliser une fonction de hachage standard de `crypto`.