laundry.request, laundry.service.assignment)
et le système de design app-design-system.md. La structure des flux est calquée
sur l'app Laundryheap (vérité terrain d'interaction) ; positions au pixel et icônes restent indicatives.
Chaque écran porte son ID de la spec (app-screen-prompts-v2.md) et ce qu'il emprunte à Laundryheap.Personnel uniquement — pas d'inscription, pas de fork client (notre client reste sur le web).
↳ LH : écran d'accueil / SignInDriver« Prochaine tâche » + compteurs + cartes de rôle. Multi-rôle coursier/atelier en une seule priorité.
↳ LH : Task list home / TasksListAffectations laundry.service.assignment en frise chronologique. Express = priorité étiquetée, pas qu'une couleur.
Frise trajet→arrivé→scan→terminé ; cas hôtel (hotel_code, concierge_room) ; « Je suis arrivé » comme étape explicite.
Scan « n / N » validé serveur ; chaque sac reçoit sa load_line (lot A/B/C, température). Repli = compteur bag_count.
Notre spécificité : weight_first_kg = moment estimation. Poids en direct, chiffres tabulaires, jamais 0,00.
Capture cadrée réutilisable (entrée, sac, véhicule, dommage). Miniature horodatée = « stockée sur l'appareil », pas encore envoyée.
↳ LH : proof photo overlayFrontière de paiement nette : la remise physique déclenche le débit. Jamais « Payé » avant confirmation serveur.
↳ LH : CompleteDropoff (+ notre capture)Codes d'exception vérifiés (pickup_customer_absent…), 4 gravités, et le code choisi impose la preuve. Critique = magenta, pas rouge.
Fil d'événements opérationnels (tâche, exception, approbation, virement). Jamais « le client a été notifié » depuis un tap.
↳ LH : DriverInbox