UNOV/DOCS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
DOCS/status/parite-manager-visitapp.md
Thomas Fransolet 489ccc6c22 Update docs (v2) and kanban
2026-09-03 14:00:51 +02:00

6.4 KiB
Raw Blame History

2bis. Parité manager-app → apps visiteur

← Section §2bis du tableau de bord : STATUS.md

→ parity-manager-visitapp.md (audit du 2026-08-05, sur le code réel)

  • Couverture par type de section : complète — les 13 SectionType sont dispatchés dans mymuseum-visitapp et visitapp-web, aucun écran vide.
  • 17 écarts au niveau champ : 7 côté mobile (dont le centrage de carte, les horaires des points d'intérêt, et surtout le mode contenu d'un parcours sans géodéclenchement), 10 côté web (dont le provider de carte, les icônes de catégorie, et l'absence totale d'assistant IA).
  • Suivi des corrections : table du test-plan.md §20.

✅ Résolu le 2026-08-06 — assistant IA dans visitapp-web (écart W8)

L'assistant n'existait que sur mobile, alors que le plan Essentiel est web-only et que l'IA est vendue en add-on. components/assistant/AssistantBubble.tsx : bulle flottante montée par le layout de configuration, uniquement si isAssistant est vrai sur l'instance et sur l'app Web (même règle que AiController). Consomme POST /api/AI/chat en AppType.Web — aucun changement backend.

  • Rend les trois formes de réponse du modèle : texte HTML, cards[], et l'action navigation qui route vers la section.
  • Suggestions d'ouverture dérivées du contenu réel (lib/assistantSuggestions.ts, 9 tests) : les sections déjà chargées donnent les questions proposées — un lieu sans agenda n'en propose pas sur l'agenda, et la carte cite un point réel. Zéro configuration client, zéro token.
  • expectsReply sert uniquement à ne pas réarmer la dictée quand le modèle clôt l'échange — pas au focus du champ, où il n'apporterait rien.
  • Quota atteint (429) → message neutre, le visiteur ne lit jamais le motif technique.
  • Maquette de référence : artifact « Assistant de visite — maquette visitapp-web ».

Répercuté sur mymuseum-visitapp le 2026-08-06 — l'assistant mobile n'était pas aligné :

  • Quota IA (429) traité : AssistantChatSheet affichait « Une erreur est survenue, réessayez » pour toute erreur, y compris le quota épuisé — le visiteur était donc invité à boucler sur un mur. Nouvelle AssistantUnavailableException levée par assistantService, message neutre côté sheet.
  • Suggestions d'ouverture ajoutées (Helpers/assistantSuggestions.dart), dérivées de VisitAppContext.currentSections déjà en mémoire. Même liste de phrases que le web — garder les deux fichiers alignés.
  • Forme alignée sur la maquette : pastille ronde pleine + « Votre guide » + nom du lieu en en-tête ; trois points animés au lieu du CircularProgressIndicator + « ... » ; bandeau « Je vous écoute » avec onde pendant la dictée. Le pattern reste une modale bottom sheet (showGeneralDialog + voile) — c'est le bon geste sur mobile, la bulle flottante du web n'aurait pas de sens sur 375 px.

✅ Résolu le 2026-08-06 — refonte de la configuration des parcours (écarts M4, M7, M8, W6, W7, X1)

Le client ne manipule plus 9 booléens répartis sur 3 niveaux, mais répond à 3 questions :

Question Où Ce qu'elle pilote
Où se déroule le parcours ? — En salle / Sur le terrain SectionParcours ShowMap. « En salle » masque automatiquement position et zone sur toutes les étapes
Quelle ambiance ? — Visite / Jeu GuidedPath IsGameMode + messages de début/fin
Comment le visiteur progresse-t-il ? — Libre / Dans l'ordre / Étape par étape (+ masquer les étapes non atteintes) GuidedPath IsLinear, RequireSuccessToAdvance, HideNextStepsUntilComplete — dérivés dans Parcours/progression_mode.dart
  • IsStepLocked, IsHiddenInitially, FactContent supprimés du modèle (migration RemoveDeadGuidedStepFlags). IsStepLocked rendait une étape définitivement infranchissable même après réussite du défi.
  • Navigation libre réellement implémentée (pins et segments de progression cliquables), verrouillage dérivé de la progression, masquage appliqué aussi en mode contenu — mobile et web.
  • Bascule carte/contenu unifiée sur ShowMap seul dans les deux apps.
  • Note ajoutée dans l'éditeur de question : une réponse attendue uniquement numérique déclenche automatiquement le pavé digicode côté visiteur.

Reprise du 2026-08-09 — 4 correctifs sur ce même écran (relecture après coup, à valider via test-plan §19.13 cas 0)

  • La progression enregistrée ne correspondait pas à celle affichée. Un GuidedPathDTO neuf naissait avec isLinear nul : progressionModeOf affichait « Dans l'ordre », mais isLinear ??= false à la sauvegarde enregistrait « Libre ». Tout parcours créé sans toucher à la question partait donc en mode libre. Les valeurs sont désormais posées à la construction. Le test progression_mode_test.dart (12/12) ne pouvait pas l'attraper : il couvre la lecture/écriture des booléens, pas le DTO fabriqué par la popup.
  • « Quelle ambiance ? » était restée une case à cocher alors que les deux autres questions sont des radios — remise en Visite / Jeu, conforme au tableau ci-dessus.
  • Médias d'étape rendus en dur comme des images dans les deux apps visiteur (guided_path_content_progression_page.dart forçait ResourceType.Image, StepCarousel un <img>). Le sélecteur accepte pourtant vidéo et audio depuis toujours : ces deux types donnaient une vignette cassée. Corrigé des deux côtés ; le libellé « Images » devient « Médias ». Le PDF, lui, reste à faire — voir todo-features.md.
  • Menu « Carte de base » : disparaissait en silence quand la configuration n'avait aucune SectionMap ; il reste maintenant visible et désactivé, avec l'explication.

Reste à trancher — la forme, pas le vocabulaire. Configurer une question sur une étape et l'écrire en NL traverse 5 surfaces empilées. Deux options maquettées le 2026-08-09 : artifact « Configurer un parcours sans empiler quatre fenêtres » — A, une fenêtre unique avec rail d'étapes (recommandée) ; B, écran plein cadre à 3 colonnes. Rien ne se code avant l'arbitrage ; détail et ordre d'exécution dans todo-features.md § « SectionParcours — refonte du flux de configuration ».