Miroir strict de pk/LabTrajectoryModel.kt (Android v1.5.0) :
- js/pk/lab-trajectory-model.js : courbe hybride M(t)×ρ(t) ancrée sur les
labs — passage EXACT garanti, ρ log-linéaire, garde #61 (lab hors
fenêtre d'action pas un ancrage), E2 seul, fenêtre [1er ; dernier lab],
< 2 labs → vide, indépendante de la calibration (sinon double
correction). JAMAIS dans levelAt/alertes.
- UI : chip 'Tracé labs' (off par défaut) dans la rangée modèles +
scroll horizontal CONFINÉ à la rangée (miroir du fix Android) ;
couleur #c2185b dashed ; leçon #63 Android-miroir — clé 'LAB' SKIPPÉE
de la boucle légende (sinon légende TFS dupliquée).
- 11 tests miroirs de LabTrajectoryModelTest.kt (132 verts total).
- WEB_VERSION = 1.5.0 + CHANGELOG [1.5.0] + docs (§4/§8, README).
Détail d'exécution épingle: les deux problèmes du portage ont été
attrapés par node --check/E2E avant release (imports ESM faux —
labIsSignificant vit dans pk-calibration.js, pas pk-engine.js).
Le premier déploiement NAS a échoué avec « exec /docker-entrypoint.sh:
exec format error » : image arm64 (buildée sur Mac Apple Silicon) exécutée
sur un hôte amd64. Le test réel l'a épiné : container-test.sh accepte
désormais un paramètre PLATFORM (build cross-arch SANS émulation — le
Dockerfile n'a aucun RUN — puis run émulé + E2E complet) :
bash scripts/container-test.sh <port> linux/amd64
→ validé vert sur linux/amd64 (healthcheck durci, E2E complet).
Docs §10 : leçon cross-arch (les 2 procédures de build — sur le serveur
cible ou multi-arch push via buildx), statut : les DEUX archs testées ;
note : l'« io_setup() failed » sous émulation Rosetta est inoffensif.
- §10 : v1.4.10 = première release Gitea web (zip vérifié par
téléchargement via scripts/publish-release.py, construit par git archive
AU TAG) ; farewell en attente de la création du repo
- §10 : statut conteneur = build + run réels validés localement (colima) ;
container-test en configuration durcie vert ; deux problèmes du premier
test documentés (tmpfs /tmp requis en read-only, case header_json curl)
- README : lien releases + statut conteneur
Conteneurisation (site 100 % statique — l'image ne détient AUCUNE donnée,
vie privée identique) :
- Dockerfile : nginxinc/nginx-unprivileged:alpine (uid 101, port 8080,
pas de root), healthcheck wget intégré, labels OCI
- nginx.conf : no-cache systématique (cohérence du jeu de fichiers à
chaque mise à jour d'image, coût nul : ~600 Ko + gzip sur l'asset PK),
gzip, en-têtes de sécurité, deny des dotfiles
- .dockerignore : runtime uniquement (docs/ inclus — dialog changelog) ;
local-test-data exclu en filet de sécurité
- docker-compose.yml : read_only + tmpfs (/var/cache/nginx, /run, /tmp —
les temporaires de nginx-unprivileged, constat au premier test réel)
+ no-new-privileges
Nouveaux tests avant release :
- scripts/container-test.sh : build + run DURCI (config compose) +
healthcheck healthy + endpoints 200 + headers (no-cache/nosniff/DENY/
no-referrer) + gzip réel + MIME strict des modules ES + fichiers cachés
non servis + image propre (pas de node_modules/npm) + docs/ embarqué +
E2E playwright complet CONTRE LE CONTENEUR (HRT_E2E_BASE)
- scripts/e2e.mjs : mode externe HRT_E2E_BASE (pilote un site déjà déployé
— conteneur inclus, serveur local non démarré)
- scripts/check.sh --release : supplée les 9 vérifications (version ↔
changelog ↔ tag ↔ arbre propre + test conteneur si daemon)
Runtime Docker local installé pour le CI-like (colima 2 CPU / 2 Go) :
premier build + run réel = 2 problèmes testés et corrigés (tmpfs /tmp,
key case header_json curl). CONTAINER TEST OK en configuration durcie.
