D5 — les échecs de téléchargement ne disparaissent plus dans un print : ils sont
collectés et la visite n'est déclarée téléchargée que si elle l'est vraiment.
Nouvelle clé downloadIncomplete dans les 10 langues, sans quoi getFromLocale
aurait rendu une chaîne vide.
Trouvé en câblant l'écran, et c'est pire que le bug d'origine : sans état
d'échec, une visite incomplète restait sur « téléchargement en cours »
indéfiniment. Le compteur d'avancement n'est incrémenté qu'en cas de succès, donc
il n'atteignait jamais le total et l'écran ne concluait jamais. Relancer ne
re-télécharge que ce qui manque.
J4 — mention d'information accessible depuis l'assistant lui-même, là où la
collecte a lieu (§8.3 des CGU). Texte repris mot pour mot de
DOCS/mention-information-visiteurs.md.
FR/NL/EN seulement, repli sur l'anglais : traduire une mention de protection des
données sans relecture humaine serait pire que la servir en anglais. Les 7 autres
langues attendent une traduction relue, à demander avec la relecture juridique.
flutter analyze lib sans erreur, flutter build apk --debug --flavor dev vert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Complète d5f3686, qui rendait la reprise illimitée : un type MIME réellement
absent de la table se serait re-téléchargé à chaque visite pour se réécrire en
.unknown, en boucle, sur le réseau mobile du visiteur.
La date nulle sert de borne — elle ne vaut que pour les fichiers écrits avant
D2, donc la reprise ne joue qu'une fois. Déduire l'extension de l'URL en repli
n'est pas possible : une URL Firebase n'en porte pas.
flutter analyze : aucune erreur sur le fichier.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
