docs: cadrage initial Storytime (specs par jalon, roadmap, CLAUDE.md)

Lecteur d'histoires cadenassé pour le coucher (Android/Flutter).
- CLAUDE.md : principes craftsmanship/TDD/clean code/clean archi + decisions techniques
- ROADMAP.md : suivi haut niveau des 7 jalons, a tenir a jour par etape
- docs/specs/ : specs completes decoupees par jalon, etapes en sous-fichiers
- .gitignore Flutter (pubspec.lock versionne, projet applicatif)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/specs/jalon-1-verrouillage/01-spike-kiosk-mode.md

@@ -0,0 +1,44 @@
+# 1.1 — Spike `kiosk_mode` sur appareil réel ⚠️ BLOQUANT
+
+## Objectif
+Prouver, sur la tablette cible, qu'on peut épingler/désépingler l'app par code et
+que l'épinglage tient face à un usage enfant. C'est un **spike** : on cherche la
+preuve de faisabilité, pas le code définitif.
+
+## Périmètre & hors-périmètre
+- Inclus : intégrer `kiosk_mode`, déclencher l'épinglage au démarrage, bouton de désépinglage (temporaire), observation du flux Android (confirmation, PIN au désépinglage).
+- Exclus : architecture propre (vient en 1.2), UI finale.
+
+## Dépendances
+Jalon 0.
+
+## Conception (jetable)
+- Ajouter `kiosk_mode` au `pubspec.yaml`.
+- Écran de spike : bouton « Épingler » → `startKioskMode()` (ou API équivalente du plugin), affichage de l'état (`getKioskMode()` / stream), bouton « Désépingler ».
+- Tester manuellement les réglages Android : épinglage activé, « exiger le PIN au désépinglage » ON/OFF.
+
+## Protocole de validation (sur appareil réel — pas seulement émulateur)
+1. Lancer, appuyer « Épingler ». Vérifier que l'app est épinglée.
+2. Tenter de sortir : geste accueil, multitâche, retour. → doit être bloqué.
+3. Désépingler via le geste système → doit exiger le PIN Android (si option activée).
+4. Couper/rallumer l'écran : vérifier le comportement.
+5. Redémarrer la tablette : confirmer que l'épinglage ne survit pas (limite connue, à documenter).
+
+## Définition du résultat
+- **Succès** → on passe à 1.2, et 1.3 devient « N/A » (noter dans roadmap).
+- **Échec / instable** → on documente précisément l'échec et on passe à 1.3 (fallback natif). Si 1.3 échoue aussi → escalade matérielle (cf. README jalon).
+
+## Plan de test
+Spike = validation **manuelle documentée** (impossible d'automatiser l'épinglage système de façon fiable hors appareil). Consigner les résultats du protocole dans ce fichier (section « Résultats » ci-dessous).
+
+## Definition of Done
+- Protocole exécuté sur la tablette cible, résultats consignés.
+- Décision plugin vs fallback prise.
+- Étape 1.1 cochée dans `ROADMAP.md` + entrée dans le journal des décisions.
+
+## Résultats (à remplir lors de l'exécution)
+> _Tablette : … / Android : … / version plugin : …_
+> _Observations : …_
+
+## Risques / notes
+- Comportements variables selon constructeur/version Android : c'est exactement ce que ce spike doit révéler tôt.