- .env.example committe, documente toutes les variables (auth, uploads, timeouts) avec
instructions pour generer un hash bcrypt.
- .env local (gitignore) pour docker compose : attention, echapper chaque \$ en \$\$ dans le hash
bcrypt sinon docker compose l'interprete comme de la substitution de variable et le tronque
silencieusement (verifie : $2a$10$xxx devenait $2a$10 tronque sans l'echappement).
- Nouveau mode "cloud_compare" (en plus de "const_height") : comparaison entre une surface
superieure et une limite inferieure, avec appariement de densite avant le niveau 0 puis
decimation synchronisee x2 sur 5 etapes. UI : selecteur de mode + upload double avec labels
explicites (surface superieure / limite inferieure).
- Remplissage des trous de scan (interpolation Delaunay bornee par max-edge-length) avant chaque
calcul de volume, dans les deux modes. -VOLUME n'ayant aucune option native pour ca (verifie dans
les sources CloudCompare), on rasterize+comble+exporte en nuage avant de le passer a -VOLUME.
Override utilisateur possible pour la distance max, afin de ne pas combler les parties concaves
du contour de l'objet mesure.
- Fix critique : CloudCompare formate les grands nombres avec une virgule comme separateur de
milliers ("Volume: 14,244.46") ; le parsing tronquait silencieusement a la premiere virgule
(14 244 devenait 14). Trouve en testant avec un vrai nuage industriel.
- Validation avec 2 vrais nuages utilisateur : le mode Z constant donnait ~50m3 (plan de reference
sans rapport avec la base reelle de l'amas, nuage contenant du contexte environnant) ; le nouveau
mode comparaison donne ~14 244m3, stable a +/-4% meme a 16x de decimation.
- CLAUDE.md mis a jour avec tous ces findings (limitation -VOLUME/LEAVE_EMPTY, technique de
contournement, piege du separateur de milliers, architecture du mode 2 nuages).
- Grille de calcul du volume adaptee dynamiquement au pas spatial de chaque niveau (au lieu d'une
grille fixe derivee du niveau 0) : evite l'effondrement artificiel du "matching cells %" observe
des le premier niveau de decimation (99% -> 58% -> 13% -> 3% -> 0.9% -> 0.2%), qui refletait un
desalignement grille/densite plutot qu'une vraie perte d'information.
- Authentification HTTP Basic sur toute l'app (UI + API), identifiants en env (AUTH_USERNAME /
AUTH_PASSWORD_HASH hashe bcrypt), desactivable en dev local si non definis. /health reste public
pour le healthcheck Docker/Coolify.