6221978526
Cartes 600, 610 et 620 closes (back-office XR, ressource 360, appairage tablette), 250 et 320 retirées du planifié, 015 et 330 à jour ; STATUS, roadmap, test-plan, todo-features et plans VR / frontière immersif alignés ; kanban.html regénéré. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011VxSQeGQYUvPmSEoGdnidA
1.8 KiB
title
| title |
|---|
| Back-office XR — le canal VR est administrable |
Clos le 12/09. Le chantier tenait en trois lots, et les trois sont retombés : XR-1 le 11/09 (Device.AppType, migration 20260911135527_AddAppTypeToDevice, DeviceController.Create qui résout l'ApplicationInstance sur appType, ApiKeyAppType.VrApp en fin d'enum, 224 tests au vert), XR-3 qui était déjà fait sans que le plan le sache (export ouvert aux apps depuis 9cc45c5), et XR-2 le 12/09.
L'écran XR est une coquille à deux sous-onglets : « Configuration », qui réutilise AppConfigurationLinkScreen tel quel — il est déjà générique sur l'appType, zéro code neuf —, et « Casques », la grille avec pincode d'appairage, état connecté, batterie, version et dernier vu. i18n FR/EN/NL.
⚠️ Deux affirmations du plan étaient fausses, relevées dans le code. La grille kiosk ne liste pas des Device mais des AppConfigurationLink : le filtre par canal était déjà implicite, et le paramètre appType de /api/device ajouté par XR-1 ne sert pas à cet écran. Et batterie / version / dernier vu ne sont pas dans DeviceDTO, seulement dans DeviceDetailDTO — donc un appel de détail par casque, assumé sur une flotte qui se compte en unités.
Reste au plan deux puces purement documentaires de XR-3 : figer le JSON d'export comme contrat public versionné, et décider si l'export doit rendre toutes les langues d'un coup pour un casque en borne. Le prochain vrai coût est XR-4, l'app Unity — carte séparée.