Ce commit porte deux sessions à la fois — voir la note de collision en
fin de message.
C4 — compression des images à l'upload, flutter build web vert. Un seul
helper appelé par les deux chemins d'upload de resources_screen, le
motif exact qui a fait diverger Create et Upload côté serveur en C1 puis
en C3. La compression se fait avant resourceCreate parce que le pré-vol
de quota de C3 porte sur sizeBytes à la création. Écart assumé à
l'énoncé « JPEG q82 » : un PNG à canal alpha reste un PNG, sinon la
transparence se remplit de noir. Défaut préexistant trouvé au passage :
le second chemin d'upload ne renseignait sizeBytes ni avant ni après,
donc tout ce qui est passé par là compte 0 octet au quota.
K8 — retour à l'accueil après 5 min, flutter build apk vert. Écrit une
seule fois dans section_page_detail, qui enveloppe les treize types.
Le retour passe par le même dispose, donc il émet un sectionLeave avec
sa durée réelle : K8 répare une statistique en plus d'un écran.
Checklist D0 ajoutée — DOCS/claude design/checklist-d0-offline.html.
Les 15 cas du §21, chaque groupe relié au bug qu'il décide : 21.2 tranche
D2 et D4, 21.1.4 tranche D3, 21.4.1 tranche D5. Les cas 21.1.2/3/5/6 sont
la première vérification RÉELLE de D1, corrigé le 11/08 mais validé par
l'analyse seule. Si tout passe, le lot D se ferme et le plan perd un à
deux jours — c'est le lien L11.
COLLISION SUR DOCS, à retenir. La session manager-service avait des
modifications stagées et non commitées sur STATUS.md, kanban.html et
v1-plan.md, alors que son prompt lui demandait de ne pas toucher à
DOCS/. Rien n'est perdu : ses changements et les miens coexistent, et
ils sont tous dans ce commit — deux cartes ferées de son côté (tests du
RAG, dettes serveur audit & plafond users) plus ses done-items.
Ce que ça a produit : mes compteurs de kanban étaient calculés par
arithmétique à partir d'un état déjà périmé, donc faux de trois cartes.
Ils sont désormais recalés sur la MESURE — on compte les <article> et on
écrit le résultat, on ne raisonne plus par delta. Planifié 19, six
colonnes cohérentes, 44 done-items, bandeau et libellé alignés.
Leçon pour la suite : un compteur dérivé d'un delta est faux dès qu'une
autre main touche le fichier. Mesurer, toujours.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flutter build apk --debug vert, APK produit. SectionArticle et
SectionEvent sont branchés dans main_view.getContent ; seul
SectionParcours reste dehors, et définitivement.
Quatre choses que l'implémentation a corrigées ou apprises, toutes
reportées dans le plan, STATUS et la maquette :
- La barre de pied de la maquette n'appartient pas aux écrans.
section_page_detail la dessine déjà pour les treize types, avec les
clés back/menu selon isFromMenu. La dessiner aurait affiché deux
boutons retour. La maquette est corrigée sur ce point.
- Un seul constructeur de marqueurs au lieu des quatre de mymuseum.
MapAnnotationDTO et MapAnnotation ont des champs rigoureusement
identiques mais sont deux types Dart distincts. Normalisé par une
classe interne — L5 appliqué au front, et il porte d'autant plus que
la convention [lng, lat] est l'endroit exact où une divergence ne
lève aucune erreur.
- L'audio d'article se résout dans contents avant l'API, donc sans
appel réseau quand il est embarqué, donc hors ligne aussi. Mymuseum
appelle l'API systématiquement en ligne.
- Clé i18n event.live ajoutée aux 10 langues. Sans les 10,
getFromLocale renvoie "" et la pastille rendrait une boîte vide.
PL, CN, UK et AR sont de ma main et demandent une relecture humaine.
Ce qui n'est pas prouvé, et qui est écrit comme tel : le rendu. Aucun
des deux écrans n'a été vu à l'œil — un build vert ne dit rien d'une
mise en page, c'est la leçon du §1bis appliquée au design. Et aucun
SectionEvent n'existe en base, le type étant né avec Postgres v3 : le
§19.13 cas E en créera un.
Kanban : la carte « Types de section manquants sur le kiosk » quitte
Urgent (2 -> 1) pour Fait récemment (40 -> 41), bandeau du haut et
libellé « Quarante et un » compris. Compteurs des six colonnes
revérifiés un à un.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Correction d'une affirmation fausse écrite plus tôt dans la journée et
reprise dans la maquette, le plan et une décision validée : « tablet-app
n'a aucun i18n ». Il en a un — lib/Helpers/translations.dart, table de 10
langues (FR EN NL DE IT ES PL CN AR UK), ~150 entrées, lue par
TranslationHelper.getFromLocale à 19 endroits, avec déjà une clé back.
Ce n'est pas de l'ARB : chercher l10n/ ou AppLocalizations ne le trouve
pas, alors que le CLAUDE.md du repo le décrit.
Ce que ça change : le motif donné pour « hors dates, aucune prose » — un
bandeau serait français pour un néerlandophone — était faux. Un libellé
traduit coûte une clé × 10 langues. La règle reste défendable (rien à
traduire vaut mieux que quelque chose à traduire) mais devient un choix,
pas une contrainte. À reconfirmer.
Corollaire d'implémentation : le bouton Retour des deux écrans passe par
la clé back existante, il ne s'écrit pas en dur.
Ajouté en V2 — portrait et paysage sur toute la borne. tablet-app n'a
aucune stratégie d'orientation : chaque écran est écrit pour la forme
qu'on lui a vue, et la maquette du 12/08 ne tranche que le paysage, pour
deux types. Une borne se monte pourtant aussi bien en totem qu'en
comptoir, et le choix appartient au lieu. Le chantier n'est pas
« ajouter le portrait » mais rendre les treize types indifférents à
l'orientation — repasse UI transversale, même famille que la repasse
globale de manager-app. La maquette est compatible (le rail qui tombe
sous le texte est le comportement portrait) mais ne le spécifie pas.
Kanban : carte V2 ajoutée, Planifié 21 -> 22 (colonne et bandeau). Le
motif « et tablet-app ne compile même plus » de la carte Kiosk web est
corrigé — il est tombé avec K1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Une seule passe de design pour les deux écrans. Les trancher séparément
donnerait deux grammaires différentes sur la même dalle, alors qu'ils
posent la même question : ces écrans sont dessinés pour un téléphone tenu
debout, une borne fait 1280 px de large et se lit à un mètre.
Six règles communes, chacune corrigeant un idiome de téléphone qui devient
faux sur une dalle large et fixe : deux colonnes (un ancrage fixe, un flux
qui défile), texte plafonné à ~65 caractères, héros à 26 % au lieu de 52 %,
plus de showModalBottomSheet (il y a la place à côté), carte affichée à sa
taille utile sans « Agrandir », et accents dérivés de
configuration.primaryColor — précédent K4, tablet-app n'a pas de flavor.
Quatre décisions prises le 12/08 :
- Fond clair, aux valeurs réelles de l'app (kBackgroundColor #FFFFFF,
kBackgroundLight #F3F3F3), pour que la section ne dénote pas.
- Pas de sélecteur de langue : elle est choisie en amont.
- Hors dates, aucune prose : le programme reste, sans pastille EN COURS,
et les dates du héros disent qu'on est avant ou après.
- Retour automatique après 5 min : adopté mais sorti du périmètre, K8.
Trois états incomplets, tous possibles en configuration. La règle qui les
couvre : le rail média n'existe que s'il a quelque chose à ancrer.
- Sans audio : le dock tombe, l'image reprend la hauteur.
- Sans photo : le rail tombe — une colonne de 38 % avec un seul lecteur
serait un trou. L'audio passe en tête de la colonne de lecture.
- Texte seul : une colonne centrée, toujours plafonnée. Le vide latéral
est voulu, c'est lui qui garde le texte lisible.
Quatre vérifications faites dans le code plutôt que supposées :
- Les statistiques sont déjà acquises. section_page_detail émet
sectionView et sectionLeave avec durée et enveloppe les treize types :
l'article sera compté dès que son case entre dans le switch.
- tablet-app n'a aucun i18n — pas de l10n/, pas d'AppLocalizations,
libellés français en dur. C'est ce qui interdit un bandeau « Édition
passée » et impose d'exprimer l'état hors dates par des dates.
- audioIds est une List<TranslationDTO> : « sans audio » est un état de
la langue courante, pas de l'article. Un article peut avoir sa version
française et pas sa néerlandaise.
- isContentTop existe déjà et dit si le texte passe avant le média. En
paysage il ne veut plus dire « au-dessus » mais « à gauche » : à
câbler, sinon un réglage déjà offert dans manager-app reste sans effet.
Retiré de la maquette : un repère « 3 / 8 » en pied d'article, inventé
pour occuper la place libérée par le sélecteur de langue. SectionPageDetail
ne reçoit qu'une section et un booléen isFromMenu, jamais la liste de ses
voisines — le repère n'était adossé à aucune donnée.
K8 ajouté au plan et au kanban : le retour à l'accueil s'écrit une seule
fois dans section_page_detail. Bénéfice de bord, il passe par le même
dispose et émet donc un sectionLeave avec sa durée réelle au lieu de
laisser une consultation ouverte jusqu'au visiteur suivant.
Source de vérité dans le repo, artifact pour la diffusion (convention DB0).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
K5 — les 3 flavors de mymuseum-visitapp construisent. La prémisse du lot
était fausse : sa config Android était déjà à niveau, ce sont les dix
crans du 12/08 qui ont amené tablet-app jusqu'à lui. Restaient deux
alignements (NDK 28.2.13676358 réclamé par speech_to_text, Kotlin 2.3.10).
Un cran de plus existe — Gradle 8.14.0 / AGP 8.11.1 — délibérément non
pris : terrain neuf pour les deux repos, le faire ici seul les désaligne.
Correction 1 — tablet-app couvre 10 des 13 types, pas 11. Le switch de
main_view.getContent traite Map, Slider, Video, Web, Menu, Quiz, Pdf,
Game, Agenda, Weather. SectionArticle (type 6) a son case commenté
« TODO » et un article_view.dart d'1 Ko : un article rend « Ce type n'est
pas supporté ». Contrairement à SectionEvent et SectionParcours, ce type
existait dans Mongo — c'est un vrai retard, et il sortira de la migration
avec du contenu réel. Ajouté au plan en K7.
Le travail de K7 n'est pas la copie mais le passage en paysage : les
écrans de mymuseum sont pensés pour un téléphone debout, une borne est
large. K3 (SectionEvent) pose la même question — une seule passe de
design pour les deux, sinon deux mises en page sur la même borne.
Correction 2 — le travail V1 des deux apps visiteur est committé sur des
branches qui ne sont pas master : Meta-Rayban-Test pour mymuseum-visitapp,
AI-Assistant-test pour tablet-app. Le §5bis décrit pourtant la première
comme « un POC jamais mergé ». À trancher avant K6 (publier les APK).
Corollaire relevé au §5bis : l'APK se construit sans le POC dedans, les
4 erreurs Ray-Ban étant hors du graphe de main.dart.
kanban.html : carte build mymuseum retirée d'Urgent (3 -> 2), done-item
K5 ajouté (39 -> 40), bandeau du haut réaligné, carte périmètre kiosk
corrigée. Compteurs de colonnes revérifiés un à un.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux sessions ont débordé de leur périmètre le 12/08 en committant le repo
d'une autre. Rien de perdu, mais la règle manquait au §4bis.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
v1-plan.md — le tableau des crans d'outillage passe de six à dix : le compte de
six datait du moment où la chaîne Gradle passait, avant que la compilation Kotlin
ne révèle la suite. K2 et K4 marqués livrés, avec les deux bugs latents trouvés
pendant le portage et la décision de rendu de l'écran Game (couleurs dérivées de
la configuration, faute de flavor sur tablet-app).
STATUS.md — §1bis passe tablet-app en ✅ ; le diagnostic « un seul défaut, purement
Gradle » y disait le faux depuis le 6 août. §1sexies porte le détail du lot K.
Trois pièges de vérification consignés, tous rencontrés aujourd'hui :
- `flutter build apk … | tail` renvoie le code de sortie du tail, pas celui du
build : un échec y ressort en « exit code 0 ».
- `flutter analyze` écrit « error - », pas « error • » : un grep sur la mauvaise
forme a fait conclure à 0 erreur alors qu'il en restait 10.
- un build jamais lancé ne vaut pas un build vert supposé. « À reconfirmer par un
vrai build » dans une doc veut dire que ce n'est pas confirmé, et un point non
confirmé ne doit pas être chiffré comme une demi-heure.
Réflexe noté pour K5 : trois des quatre derniers crans étaient de simples
alignements sur mymuseum-visitapp. Commencer par un diff des gradle.properties et
build.gradle des deux repos plutôt que de remonter les erreurs une par une.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lot C — C2 et C3 passent en livré dans v1-plan.md et STATUS.md §1sexies,
avec ce que la doc annonçait de faux et qu'il ne faut pas re-croire :
- La méthode de C2, « SizeBytes par listing du bucket Firebase », était
inapplicable — le serveur n'avait aucun client de stockage. Le sondage
passe par HEAD, via un sondeur partagé avec la migration.
- Le pré-vol de C3 existait déjà à moitié sans être documenté : le chemin
multipart contrôlait, le chemin JSON non, et les deux lectures du quota
divergeaient entre le plan et l'instance.
- L'angle mort laissé par C1 était une fausse crainte : le type n'entre pas
dans le chemin de stockage.
- Le « 37 lignes sur 45 » disparaît au profit de l'inventaire que le backfill
produit lui-même.
Deux suites que ces chantiers créent, consignées pour ne pas se perdre :
- C6, nouvelle ligne du lot C : manager-app supprime toujours le blob de son
côté, après la ligne et en avalant l'échec. Depuis C3 c'est du code mort.
À retirer, mais pas avant que Firebase:StorageBucket soit posé en prod,
sinon plus personne ne supprime.
- I9, nouvelle étape du lot I : renseigner Firebase:StorageBucket, puis
lancer le backfill en dryRun avant de l'appliquer. Sans lui le quota porte
sur des SizeBytes à zéro pour tout l'existant et laisse tout passer (L10).
S'y ajoute un piège de build : dotnet restore échoue en 401 si la source
NuGet git.dev-espaces-naturels.lu est déclarée dans l'image, et
Google.Cloud.Storage.V1 est le premier paquet ajouté depuis longtemps.
Lot K — K2 livré : tablet-app est rebranché sur le contrat d'API de
Postgres v3, les 132 erreurs de contrat sont tombées, et la table des
conventions de coordonnées est consignée. Reste K4, le renommage
Puzzle → Game. Point de vigilance noté : le filtre des configurations
tablette a changé de source, à valider sur device.
Compteurs du kanban recomptés colonne par colonne : Urgent 4, Migration v3 2,
Bugs ouverts 5, À tester 6, Planifié 20, Bascule prod 8, Fait récemment 38.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux chantiers menés en parallèle, consignés dans la même passe parce que
l'index de ce repo est partagé et que leurs modifications s'entrelacent
dans STATUS.md, v1-plan.md et kanban.html.
Lot K — les apps visiteur parlent l'ancien contrat. Découvert en lançant le
premier vrai flutter build apk sur tablet-app depuis des mois, la commande
que trois documents disaient « à reconfirmer ». Le diagnostic « un seul
défaut, purement Gradle, peut-être réglé par 5a6701d » était doublement
faux : six crans d'outillage Android (Gradle 7.5 → 8.11.1, AGP 7.2.0 →
8.9.1, Kotlin 2.0.10, option AGP supprimée, jcenter mort), corrigés le
12/08, puis 132 erreurs Dart que le Gradle masquait. Elles tiennent en trois
causes — les cinq champs de ConfigurationDTO migrés vers
AppConfigurationLinkDTO, GeoPointDTO.latitude/longitude devenus
GeometryDTO geometry avec PostGIS, et les min() sur dynamic qui en
découlent. mymuseum-visitapp a déjà fait ce portage : c'est une copie, pas
une conception. Bloquant de la bascule (lien L19) : les tablettes en service
chez MDLF et au Fort ne s'arrêteraient pas proprement le jour J, elles
dégraderaient sans erreur visible. +3 à 5 jours de travail déjà dû.
Périmètre kiosk tranché : SectionParcours exclu définitivement d'une borne
fixe, SectionEvent à supporter. Leçon générale ajoutée au §1bis — un build
jamais lancé ne vaut pas mieux qu'un build vert supposé, et « à reconfirmer
par un vrai build » veut dire que ce n'est pas confirmé.
Lot F — le volet manager-app est livré. Écran d'audit log sur GET /api/Audit
réservé au SuperAdmin, et compteur « X / 5 utilisateurs » avec bouton d'ajout
désactivé au plafond. Deux dettes serveur ouvertes par ce chantier et
laissées ouvertes à dessein, le périmètre étant manager-app seul : le
plafond de 5 n'est appliqué nulle part côté serveur — ce qui est livré est
un garde-fou d'interface, un POST direct sur l'API passe toujours — et
aucune section n'est journalisée, AuditedTypes.Contains exigeant l'égalité
exacte de type alors que Section est abstraite, si bien que le journal
couvre tout sauf le contenu, précisément ce que l'écran devait tracer.
Chacune a sa carte au kanban et son entrée dans todo-features.md.
Compteurs du kanban recomptés : Urgent 4, Migration v3 3, Bugs 5, À tester 6,
Planifié 20, Bascule prod 7, Fait récemment 36.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recette d'import documentée (MigrationController lit un Mongo vivant, pas les
fichiers de migration-data/), résultats des comptages, et les deux réserves :
l'export a 4 mois alors que la prod tourne encore sur Mongo, et les 20
sections orphelines sont du contenu MDLF réel dont le sort doit être tranché
avec le client — recréer les 2 configurations, ou acter la perte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trois cartes « Bascule prod » se ferment sans une ligne de code : l'export
Mongo, lu plutôt que supposé, montre qu'il n'y avait rien à perdre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux points où suivre la doc à la lettre aurait produit un correctif
inopérant ou destructeur, tous deux consignés pour ne pas être rouverts :
- « Supprimer SectionEvent.IconResourceId » (lot B) : ce champ n'existe pas.
La ligne visée appartient à la classe imbriquée MapAnnotation, partagée par
trois types de section et lue par cinq contrôleurs.
- « Cas PDF dans getElementForResource » (lot E) : cette fonction retourne
CachedCustomResource avant son switch, qui est donc du code mort. Le vrai
dispatcher en a deux.
Également : C1 montre que le « prérequis levé le 10/08 » du backfill n'était
vrai que d'un chemin de création sur deux, et le fournisseur de carte en web
est tranché (Leaflet) avec la correction de ce que l'option impliquait
réellement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le garde-fou et la persistance au fil de l'eau sont alternatives, pas
cumulables : si chaque étape part à la saisie, le garde-fou n'a plus
d'objet. La persistance impose en outre de créer le parcours dès la 1re
étape — parcours à moitié remplis en base, « Annuler » qui n'annule plus
rien — soit la sémantique qu'apporte le rail d'étapes de l'option A. Elle
rejoint donc DB4, avec le terrain relevé : les endpoints GuidedStep
existent déjà, le backend persiste les questions imbriquées, et il n'y a
volontairement pas d'endpoint QuizQuestion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
STATUS.md et v1-plan.md portaient plusieurs affirmations périmées, toutes
revérifiées dans le code.
Ce qui tombe :
- §4 : les 9 repos sont propres et synchronisés (DOCS en est un). L'étape 1
du lot A est terminée, à ne pas re-planifier.
- §3 : diagnostic manager_api_new fermé — 139 `part` pour 153 fichiers, les
14 orphelins hors graphe de compilation. Et ils étaient trois
déclencheurs de génération, pas un : mymuseum-visitapp et tablet-app en
avaient aussi.
- §1bis : la piste Dart du build tablet-app (ContentGeoPoint) est écartée —
les deux références sont dans des blocs commentés. Le problème est
purement Gradle.
Ce qui se déplace :
- Rotation des secrets → lot I (I0), repos privés auto-hébergés. Le lien L1
reste entier : elle précède I3, donc la fin du lot H. La boucle du graphe
de dépendances disparaît.
Ce qui apparaît :
- §1bis / §5bis : mymuseum-visitapp ne construit plus son APK (Gradle/NDK,
pas Dart) et le POC Ray-Ban ne compile plus — kElevenLabsApiKey et
kElevenLabsVoiceId absents de constants.dart, jamais committés.
kanban.html : carte « travail non committé » close, carte des secrets
déplacée en Bascule prod, nouvelle carte pour le build mymuseum, cartes
tablet-app et client généré réécrites. Compteurs revérifiés par script.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Import initial de la documentation : statut, roadmap, plans V1/V2,
specs verticales (creche, sport), audits securite, plan de test,
analyse concurrentielle et maquettes de design.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
