L'attribut `download` d'un lien est ignore quand la cible est sur une autre
origine — Firebase Storage ici. Le navigateur se contentait donc d'ouvrir la
ressource dans un onglet, et le nom de fichier calcule par
`downloadFileNameFor` ne servait a rien.
Le fichier est d'abord recupere en blob et le lien pointe sur l'URL d'objet.
Repli sur l'ouverture en onglet si la requete echoue (CORS, reseau) : le
comportement d'avant, faute de mieux — a surveiller, c'est le chemin qui
reintroduit le bug sans rien dire.
Le telechargement groupe attend chaque fichier au lieu de lancer toute la
selection en parallele.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
flutter build web vert. Un seul helper, ImageCompressor, appelé par les
DEUX chemins d'upload de resources_screen — c'est le motif qui a fait
diverger Create et Upload côté serveur deux fois de suite : sur
StoragePath en C1, sur le pré-vol de quota en C3.
La compression se fait AVANT resourceCreate, pas avant l'upload. Le
contrôle de quota livré en C3 porte sur sizeBytes à la création : le
faire après aurait fait décider le serveur sur la taille du fichier
d'origine, et compté au quota une image qui n'existe pas. Un quota qui
compte 12x trop se remplit 12x trop vite.
Deux écarts assumés par rapport à l'énoncé « 2560 px / JPEG q82 » :
- Un PNG à canal alpha reste un PNG. Le passer en JPEG remplirait la
transparence de noir, ce qui abîmerait logos et filigranes. Le
redimensionnement s'applique dans les deux cas ; seul l'encodage
diffère, et le type MIME suit — sinon Firebase servirait un JPEG
étiqueté PNG.
- Si le ré-encodage produit un fichier plus gros que l'original — ce
qui arrive sur une petite image déjà bien encodée — l'original est
conservé. Un échec de décodage renvoie aussi l'original plutôt que
de bloquer l'upload.
Défaut préexistant corrigé au passage : le second chemin d'upload ne
renseignait sizeBytes ni avant ni après. Toutes les ressources créées
par ce chemin comptent donc 0 octet au quota sur l'existant — même
famille que ce que C1 et C3 ont trouvé côté serveur, et un argument de
plus pour le backfill C2.
image 4.2.0 déclarée explicitement : elle était déjà présente en
transitif, dépendre d'un hasard de résolution pour une fonction
utilisateur n'est pas tenable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Socle visuel (constants.dart)
- 11 rôles typographiques, 8 espacements, 5 rayons, paddings de carte et de page,
extraits du CSS des maquettes validées (DOCS/claude design/).
- Les couleurs restent celles de l'app : un écran neuf se fond dans manager-app,
il n'y ouvre pas une seconde palette. Seules les valeurs sans équivalent
existant sont reprises — remplissages discrets, bordures, gris atténué, ambre.
- Mesuré avant : 11 tailles de police différentes dans lib/Components/, de 9 à 25 px.
Écran Guide IA
- Coquille à deux onglets : Configuration / Ce que demandent vos visiteurs.
- Aperçu de conversation branché sur le vrai POST /api/AI/chat, pas une simulation.
- Carte « Ce que connaît votre guide » sur GET /api/Ai/knowledge/{id} : mesuré sur
l'index vectoriel, pas sur les tables de contenu — une section désactivée en est
purgée. Les « points d'intérêt » de la maquette deviennent « morceaux de contenu » :
les points d'une carte sont indexés dans le texte de leur SectionMap.
- Onglet des questions visiteurs alimenté par GET /api/Ai/insights/{id}. Une carte
sans données se masque au lieu d'afficher un cadre creux.
Client API
- AIApi était dans le client généré mais exposé nulle part dans client.dart, où
les 18 autres façades le sont. Câblé.
34 clés i18n FR/EN/NL. flutter analyze propre, flutter build web ✅.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
