Files
storytime/docs/specs/jalon-1-verrouillage/01-spike-kiosk-mode.md
T
Vincent Bourdon 16fd4c8c36 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>
2026-06-19 17:03:33 +02:00

2.4 KiB

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.