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>
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
# 1.3 — Fallback natif Kotlin (platform channel)
|
||||
|
||||
## Objectif
|
||||
Si le plugin `kiosk_mode` s'est révélé insuffisant en 1.1, fournir une
|
||||
implémentation native Kotlin du verrouillage via un platform channel, derrière la
|
||||
même interface `LockingRepository`.
|
||||
|
||||
## Condition d'exécution
|
||||
**Étape conditionnelle.** À réaliser uniquement si 1.1 a conclu que le plugin ne
|
||||
tient pas. Sinon : marquer « N/A » dans la roadmap et passer au jalon 2.
|
||||
|
||||
## Périmètre & hors-périmètre
|
||||
- Inclus : `MethodChannel` Dart↔Kotlin, code Kotlin appelant `Activity.startLockTask()`/`stopLockTask()`, impl. `NativeChannelLockingRepository`.
|
||||
- Exclus : Device Owner / mode kiosque complet (relève d'un changement de stratégie matérielle, pas de cette étape).
|
||||
|
||||
## Dépendances
|
||||
1.1 (échec plugin), 1.2 (interface existante).
|
||||
|
||||
## Conception
|
||||
- **Côté Android** (`android/app/src/main/kotlin/...`) :
|
||||
- `MethodChannel("storytime/locking")` avec méthodes `startLock`, `stopLock`, `currentState`.
|
||||
- Appeler `startLockTask()` / `stopLockTask()` sur l'`Activity`. Sans Device Owner, cela déclenche le **Screen Pinning** standard (confirmation système).
|
||||
- Gérer les exceptions et renvoyer un code d'erreur exploitable côté Dart.
|
||||
- **Côté Dart** (`features/locking/data/`) :
|
||||
- `NativeChannelLockingRepository implements LockingRepository`, mappant les réponses du channel vers `Result`/`LockingFailure`.
|
||||
- Brancher `lockingRepositoryProvider` sur cette impl. à la place de la version plugin.
|
||||
|
||||
## Plan TDD
|
||||
1. **Red** : `native_channel_locking_repository_test.dart` — en mockant `MethodChannel` (via `TestDefaultBinaryMessengerBinding`), `startLock` qui répond OK → `Ok` ; qui lève `PlatformException` → `LockingFailure`.
|
||||
2. **Green** : implémenter le repository Dart + mapping.
|
||||
3. **Validation manuelle** : reprendre le protocole de 1.1 avec l'impl. native (épingler/sortir/désépingler/PIN).
|
||||
4. **Refactor**.
|
||||
|
||||
> Le code Kotlin lui-même est validé par le test d'intégration manuel (protocole 1.1) ; le test unitaire Dart couvre le mapping et la frontière du channel.
|
||||
|
||||
## Definition of Done
|
||||
- Test du repository natif vert ; protocole de 1.1 repassé avec succès sur la tablette.
|
||||
- `lockingRepositoryProvider` pointe sur l'impl. retenue.
|
||||
- `tool/check.sh` passe.
|
||||
- Étape 1.3 cochée dans `ROADMAP.md` (ou « N/A » si non nécessaire) + décision au journal.
|
||||
|
||||
## Risques / notes
|
||||
- Si même `startLockTask()` natif ne satisfait pas le besoin sans Device Owner → **escalade** : revenir à l'utilisateur sur le choix « tablette dédiée / mode kiosque », comme acté au cadrage.
|
||||
Reference in New Issue
Block a user