Le filtre incrémental testait la présence du fichier, jamais sa version.
La prémisse d'origine était fausse, et ça change ce que le correctif répare :
« une image remplacée dans le CMS ne remonte jamais » n'existe pas, parce que
Upload appelle GenerateHexId() à chaque téléversement — remplacer une image
produit un nouvel id, donc une nouvelle URL, que l'ancien filtre téléchargeait
déjà.
Le vrai cas de péremption vient d'être créé par D3 : les MP3 déjà présents sur
les devices y sont en <id>.unknown, et « le fichier est présent » les déclarait
à jour. Sans D2, D3 ne réparait que les installations neuves. isResourceOutdated
traite donc .unknown comme absent.
Deux pièges tranchés en écrivant. La montée v4 laisse les dates existantes à
NULL et les considère à jour : backfiller à zéro aurait fait re-télécharger
l'intégralité des visites de tous les visiteurs sur leur réseau mobile, au
premier lancement. Et la boucle en masse héritée de D1 écrasait la date que la
boucle de téléchargement venait d'écrire, DatabaseHelper.insert faisant un
UPDATE de la ligne entière quand l'id existe ; pour un téléchargement échoué,
c'est l'ancienne date locale qui est conservée, jamais celle du serveur.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La prémisse du lot était périmée. Trois documents annonçaient un
`flutter build apk` en échec côté Gradle/NDK, revérifié le 11/08 : les
trois flavors (dev, mdlf, fortsaintheribert) construisent, exit 0.
La config Android de ce repo était déjà à niveau — Gradle 8.11.1, AGP
8.9.0, -Xmx4096M, enableJetifier=false, aucun forçage androidx.lifecycle.
Les dix crans du 12/08 ont amené tablet-app jusqu'à mymuseum ; il n'y
avait pas la même migration à refaire ici. Le repo qui a servi de modèle
au portage K2 n'avait pas de raison d'être en retard d'outillage sur
celui qui le copiait.
Restaient les deux avertissements du build :
- NDK 27.0.12077973 -> 28.2.13676358, réclamé nommément par speech_to_text
- Kotlin 2.1.0 -> 2.3.10, sous le seuil 2.2.20 annoncé comme rupture par
Flutter. C'est la version de tablet-app : un alignement, pas une
version neuve introduite dans le projet.
Six builds — les trois flavors avant, les trois après. APK de 382 à 349 Mo.
Non pris volontairement : Kotlin réglé, Flutter réclame Gradle 8.14.0 et
AGP 8.11.1. C'est du terrain neuf pour les deux repos (tablet-app est à
8.11.1/8.9.1, mêmes avertissements latents) — le faire ici seul désaligne
les deux apps au lieu de les aligner. À faire d'un bloc sur les deux, ou
pas du tout.
Débloque D0 / test-plan §21 sur device, donc la mesure des bugs offline
D2-D5 et la confirmation du volet visiteur de D1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le bloc commenté parsait section.data type par type pour retrouver les
ressources à télécharger. Il n'y a plus rien à redécouvrir : le serveur
collecte désormais via GetReferencedResourceIds() et met toutes les
ressources référencées dans la charge d'export.
Répare aussi la purge des fichiers obsolètes : elle est pilotée par
usedImageOrAudioIds, qui ne contenait jusqu'ici que les images de sections —
tout le reste était donc considéré comme inutilisé.
Un nouveau type de section est couvert sans toucher à ce fichier.
flutter analyze sans erreur. ⚠️ Non vérifiable par un build : l'APK ne compile
pas (Gradle/NDK). À confirmer sur device au §21 du plan de test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le cas PDF n'était traité nulle part : un PDF tombait dans le `default` et
affichait "Not supported type".
⚠️ Le correctif ne va pas dans showElementForResource comme l'annonçait le
plan : cette fonction fait un `return CachedCustomResource(...)` avant son
switch, donc tout son switch est du code mort. Le vrai dispatcher est
CachedCustomResource, et il en a deux — ressource distante et fichier local
déjà téléchargé pour l'offline. Les deux sont traités. Le cas distant doit
télécharger avant d'afficher, PDFView n'acceptant qu'un chemin de fichier.
QuestionType : _kindOf comparait des entiers bruts, remplacé par les alias
nommés du client.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lib/api/openApiTest.dart portait une annotation @Openapi générant, depuis
le swagger local de ce repo, un package manager_api_new dans le repo —
alors que le pubspec consomme celui de manager-app par `path:`. Un
build_runner lancé ici aurait donc créé un second client divergent.
Importé nulle part, et porteur d'une des 5 erreurs Dart du repo
(extends_non_class). Après suppression : 720 → 718 issues, 5 → 4 erreurs,
les 4 restantes étant les constantes ElevenLabs de la branche Ray-Ban,
préexistantes et hors du graphe de main.dart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant
AssistantChatSheet.dart (+252), Helpers/assistantSuggestions.dart,
Services/assistantService.dart — même comportement et mêmes suggestions que
visitapp-web, dérivées du contenu réel.
Parcours guidés
guided_path_content_progression_page (+72), guided_path_map_progression_page (+39),
parcours_page : alignés sur les 3 questions de progression qui remplacent les
9 booléens côté manager-app.
Carte
Helpers/mapCenter.dart + les trois vues (flutter_map, google_map, map_box) et
marker_view : centrage et icônes honorés.
Fix du build
guided_step_challenge.dart:83 — typage explicite. Avec le // @dart=2.18 de
manager_api_new côté manager-app, c'est ce qui débloque flutter build apk.
flutter build apk ✅.
Reste ouvert : M3 — meterZoneGPS toujours ignoré, une constante en dur à 100 m
remplace le rayon configuré par section.
