Vincent Bourdon
16fd4c8c36
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>
45 lines
2.4 KiB
Markdown
45 lines
2.4 KiB
Markdown
# 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.
|