BACKLOG.md

Rama main · réplica de lectura del repositorio original.

# Backlog

Ce qui est ouvert, rien d'autre : ce qui est fait est dans BACKLOG-FAIT.md, mot pour mot.
Une piste notée ailleurs (rapport de mutualisation de nico579-commons, issues, mémoire de
session) est aussi listée ici, avec un renvoi : le BACKLOG est l'endroit où l'on regarde pour
savoir ce qui reste. Dernier nettoyage : 2026-10-07 (décisions du jour : Electron écarté, audit laissé en l'état).

## À décider ou à faire

- **Test hebdomadaire des fournisseurs de lidar2map : il reste la clé de fi-maanmittauslaitos.**
  Le workflow « Smoke providers » (lundi) était rouge chaque semaine depuis le 2026-08-17, sans alerte.
  Réparé le 2026-10-07 (lidar2map 1.60.2) : de-sh (le serveur n'envoie pas son certificat intermédiaire,
  embarqué désormais), es-euskadi (le service veut le nom de la couverture, plus l'index) et ca-quebec
  (c'était le test, qui prenait une feuille voisine hors zone). Reste fi : la clé du secret
  `FI_NLS_API_KEY` est refusée (HTTP 403, « invalid authorization »). Clé gratuite à renouveler
  (maanmittauslaitos.fi/rajapinnat/api-avaimen-ohje), à mettre dans le secret du dépôt lidar2map, puis
  retirer fi de `--skip` dans `.github/workflows/smoke.yml`. Aucune alerte n'est envoyée quand ce
  workflow échoue (issue automatique ou message : non décidé).

- **Signature de code des exécutables.** Candidature SignPath Foundation soumise le 2026-08-29, en
  attente de réponse.

- **Recherche de ville commune, avec autocomplétion (lidar2map, hike2gpx).** Demandé par Nico le
  2026-10-22 : aligner hike2gpx sur lidar2map, avec autocomplétion, dans le commun, et favoriser les
  villes proches de la zone affichée. Aujourd'hui, les deux applications font chacune la leur.
  lidar2map complète au fil de la saisie : en France par la Géoplateforme
  (`data.geopf.fr/geocodage`, `autocomplete=1`), ailleurs par Nominatim, restreint au pays choisi.
  hike2gpx (0.2.3, PR hike2gpx#28) cherche à la validation seulement : les communes françaises par
  `geo.api.gouv.fr`, puis Nominatim pour le reste du monde. gpxsolar ne fait que du géocodage
  inverse et n'est pas concerné.
  Point à corriger au passage : la politique de Nominatim interdit l'autocomplétion sur son service
  public (« you must not implement such a service on the client side using the API »). lidar2map
  l'enfreint hors de France. L'outil courant pour ça est Photon (`photon.komoot.io`), le géocodeur
  OSM de Komoot conçu pour la saisie au fil de l'eau.
  Proposition :
  - un module du commun, côté serveur, qui relaie (User-Agent identifiable, pas de dépendance au
    CORS) : la Géoplateforme en France, Photon ailleurs ;
  - un composant de page commun (`/nico579-ville.js`, comme le bandeau de mise à jour), avec
    délai de frappe, réponses périmées ignorées et petit cache ;
  - la proximité comme priorité, pas comme filtre : la page envoie le centre de la carte, et les deux
    services savent faire remonter les lieux proches (`lat`/`lon`). Depuis le Var, « Mad » propose
    alors Madriat avant Madrid, mais « Madrid » reste trouvable. Restreindre aux pays voisins aurait
    caché Madrid à quelqu'un qui prépare un voyage depuis chez lui ; lidar2map garde en plus son
    sélecteur de pays, qui reste un vrai filtre ;
  - Nominatim reste possible pour une recherche validée, une requête à la fois, jamais à la frappe.
  Ordre : le commun d'abord, puis hike2gpx, puis lidar2map, lors de la passe finale sur les projets.

- **Enfants qui meurent avec leur application : brancher `nico579_commons.enfants` dans tous les projets.**
  Demandé par Nico le 2026-10-20, après trois moteurs BRouter de hike2gpx restés orphelins (console
  fermée, processus tué), jusqu'à 768 Mo chacun. Le module du commun (0.6.0, PR nico579-commons #24)
  fait mourir un enfant avec son application, de quelque façon qu'elle meure : job Windows, ligne de vie
  et groupe de processus sous Linux et macOS, éprouvé en CI sur les quatre systèmes.
  `enfants.demarrer()` remplace `subprocess.Popen`, `enfants.lancer()` remplace `subprocess.run`.
  Les bornes du commun vont jusqu'à `<1` depuis le 2026-10-20 (décision 7 du 2026-09-29) : adopter
  le module, c'est monter son verrou à 0.6.0 (`uv pip compile ... --upgrade-package nico579-commons`).
  Seul gpx2elev 0.6.4, déjà sur PyPI, dit encore `<0.7` : sa borne `<1` y arrivera avec sa prochaine
  release.
  hike2gpx est le premier branché (BRouter, créateur de tuiles, import Geofabrik), fait le
  2026-10-20 (hike2gpx #15 ; gpx2elev 0.6.4 a dû relever sa borne du commun, `<0.7`, pour que les
  deux s'installent ensemble). Relevé du même jour pour les autres : blink2video, les ffmpeg de `merge_daily.py`
  (`runtime.demarrer` et les `runtime.lancer` des fusions ; même vocabulaire, seul le module change), et
  les verbes que lance le superviseur « start » (`blink_cli.py`), à décider ; gpxsolar, le calcul lancé
  par `subprocess.Popen` (`self._proc`, déjà dans son propre groupe pour le bouton Arrêter) ; lidar2map
  et gpx2elev ne lancent aucun processus ; watch2notif seulement des commandes brèves (pare-feu,
  appairage). Ne jamais y passer ce qui doit survivre à l'application : Redémarrer (`relance`), le
  démarrage automatique, la mise à jour, le navigateur.

- **Issue #40 (MCas86) : lire de lui-même le clip qui vient d'être filmé.** Proposé le 2026-10-20
  pour un écran mural (Raspberry Pi, Chromium en kiosque) : système armé, mouvement, enregistrement,
  puis lecture une seule fois. Principe accepté le même jour, codage reporté par Nico. Comportement
  convenu avec MCas86 le même jour : une fenêtre surgissante par-dessus la vue en cours, qui reste
  intacte dessous ; les clips arrivés ensemble lus l'un après l'autre, du plus ancien au plus
  récent ; la fenêtre se ferme d'elle-même après le dernier, avec un bouton Fermer pour arrêter
  avant. Son « instant » voulait dire « dès que le clip est reçu » : le délai d'une à deux minutes
  lui convient.
  Ce qui existe : « armé » va de soi, puisque seuls comptent les clips de détection (`kind` « clip »,
  jamais les enregistrements du direct) ; la page voit déjà arriver les nouveaux clips
  (`/api/passages` toutes les 60 s, comparé à `total_known.clip`). À faire, côté page seulement : une
  case « Lire les nouveaux clips à leur arrivée », retenue par navigateur ; la fenêtre et son
  lecteur, logés dans l'élément en plein écran s'il y en a un (`#ronde` pendant la ronde, la case
  d'un direct agrandi), sans quoi ils resteraient invisibles ; une lecture muette, car le son exige
  un clic (sauf Chromium lancé avec `--autoplay-policy=no-user-gesture-required`) ; un sondage
  resserré, vers 10 s, quand la case est cochée. Aucun appel de plus vers Blink, donc rien pour les
  batteries. Délai réel : une à deux minutes après la fin du clip pour le cloud (relève à la minute),
  dix minutes par défaut pour l'USB, qui attend en plus la fin de la ronde.

## En attente d'un retour ou d'un cas réel

- **Audit du 2026-10-02 (0.15.7) : 13 constats restants, aucun correctif prévu.**
  Décision de Nico du 2026-10-07 : on en reste là ; à traiter seulement si l'un se présente.
  Le dossier est `Documents\blink\audit\2026-10-02` (ignoré par git, jamais `git add -A` ;
  son `changements.patch` de 246 Ko est une donnée, à ne jamais appliquer sans ordre). Analysé le
  2026-10-06 sur la 0.18.1 : les scripts de l'audit rejoués en mesure seule, rapport, aucune
  correction. Déjà corrigés : B02 (PR #72), O04 (FFmpeg figé), O05 (clip USB réel), B03 et B13
  (0.18.2), B10 (0.18.3). Restent, tous reproduits et
  sans cas reel connu, a traiter si l'un se presente :
  B01 reconstruction echouee qui reduit semaine/mois (se repare seul au passage
  suivant reussi, verifie) ; B04 verrou vide ou `.purge` abandonne jamais repris ;
  B05 reponse 416 sans Content-Length (client en attente) ; B06 sauvegarde
  obsolete qui efface `source_deleted` ; B07 sessions HTTP non fermees apres une
  reconnexion echouee ; B08 file WebRTC pleine qui perd le signal de fin ; B09
  launchctl refuse annonce comme installe (macOS) ; B11 marqueurs de passage
  concurrents qui se remplacent ; B12 deux preparations de mise a jour dont la
  seconde efface la premiere ; B14 identite de processus illisible = verrou
  repris (CHOIX ASSUME du 2026-09-29 pour les pannes apres redemarrage : ne pas
  inverser sans accord) ; O01 types RTP > 127 au 9e profil H.264 ; O02 retour a
  zero des PTS MPEG a 33 bits.
  Si l'un se présente, B05 et B07 sont les plus plausibles en usage réel. Rien ne se corrige sans
  demande de Nico (audit veut dire rapport).

- **Issue #55 (Björn) : « USB storage only detects clips from one camera ».** Cause trouvée et
  corrigée en 0.15.7 : le Sync Module écrit les noms de caméra en ASCII (le ü est supprimé) et
  blinkpy les cherchait avec ü. La règle réelle pour les autres accents n'est pas confirmée ;
  attendre le retour de Björn avant de fermer.

- **Issue #40 (Markus) : le nombre d'images par ligne change d'une vue à l'autre à taille de
  fenêtre égale.** Markus pense que cela dépend de la largeur de la ligne d'informations du haut. À
  vérifier : si cela se confirme, c'est un défaut de mise en page, pas un choix. Tri, taille et
  masquage sont en 0.16.0.

- **Vignettes : une borne sur la file d'attente de serve.** Le reste de l'entrée, faite en 0.18.0 :
  `send_thumb()` laisse chaque requête en attente occuper un fil du serveur. Le test à froid de Joël
  sur ses vrais clips dira si elle est encore utile.

- **Icône sous GNOME Wayland : la voir dans une vraie session.** Livrée en 0.18.0 et essayée dans la
  VM Ubuntu 26.04 avec un gnome-shell sans écran (enregistrement auprès du watcher, GetLayout,
  Event) ; le rendu dans une vraie session graphique n'a pas été vu.

- **Tester-XR.exe affiche une "blink2video version" perimee dans son
  rapport.** Source : reddit/cutthin, auteur de la demande initiale de prise
  en charge du Sync Module XR et des tests sur materiel reel, 2026-08-31. Le
  rapport du testeur XR (r2, tag xr-local-storage-test-r2) annoncait "blink2video
  version: 0.10.6" alors que l'utilisateur confirmait tourner sous 0.10.08.
  Confirme via `gh release list` : le tag r2 a ete publie le
  2026-08-31T10:01Z, alors que v0.10.7 et v0.10.8 sont sortis apres (12:23Z
  et 12:39Z le meme jour) sans rebuild du testeur. Ce n'est pas une erreur
  de l'utilisateur : diagnostic_xr.py:88 lit `runtime.VERSION` au moment du
  build PyInstaller de Tester-XR.exe (`build_xr_tester.py`/`xr_tester.spec`),
  qui ne sont references ni dans `deploy.py` ni dans
  `.github/workflows/*.yml` (verifie, zero occurrence) - ca redivergera a
  chaque bump tant que ce n'est pas rattache. Deux corrections possibles,
  pas exclusives : rebuild+republish Tester-XR a chaque version (mecanique
  a ajouter au pipeline), ou faire lire au testeur la version reelle du
  blink2video.exe voisin plutot que sa propre runtime.VERSION figee au
  build.
  Toujours ouvert au 2026-10-07 : `diagnostic_xr.py` lit encore `runtime.VERSION` figée au build, et
  ni `deploy.py` ni les workflows ne reconstruisent le testeur.

## À ne faire que si la demande revient

- **Integration Home Assistant native.**
  Source : reddit/MoneySquare6212, r/blinkcameras, 2026-08-19. Ecarte pour
  l'instant (repondu sur Reddit) : un vrai chantier a part (config flow,
  modele d'entites, HACS), pas une extension de ce qui existe. Note ici
  pour ne pas l'oublier si la demande revient.

- **Optimisations identifiees (pas des bugs, pas urgentes).**
  Registre reecrit en entier a chaque clip (quadratique sur un lot) ;
  known_identities() reparcourt tout a chaque vignette (cache par mtime
  utile) ; telechargements cloud charges entierement en memoire
  (response.read(), a chunker) ; cache _DURATIONS qui ne purge jamais ses
  anciennes cles ; dependances non epinglees alors que le code touche des
  attributs prives de blinkpy ; bootstrap qui reutilise l'environnement
  global au lieu de rester isole ; plusieurs helpers JSON divergents,
  a centraliser (meme esprit que safe_name, deja fait en 28.64).

- **Flux par camera pour Frigate / Home Assistant (RTSP via go2rtc).**
  Source : reddit/wperez3825, 2026-09-28, en reponse au "Direct continu" de
  la 0.14.6 ("great news for Blink Minis since they're plugged in").
  Demande : exposer chaque camera en flux, par exemple via go2rtc, pour que
  Frigate et Home Assistant l'enregistrent et l'affichent. Analyse du
  2026-09-28 : faisable, mais un Sync Module ne traite qu'une commande a la
  fois (voir MODULE_SLOT, serve.py), donc au mieux un direct par systeme
  Blink en meme temps ; deux directs simultanes sur un meme compte jamais
  essayes. Travail : adresse stable par camera protegee par une cle fixe
  (comme le jeton de webhook), relance continue cote serveur (elle vit
  aujourd'hui dans la page), flux en MPEG-TS plutot qu'en MP4 fragmente pour
  recoller les sessions de ~6 min, page de doc go2rtc. A essayer d'abord :
  deux directs en meme temps sur deux systemes, et go2rtc branche sur
  /live-mse. Mis de cote par Nico pour plus tard.

- **Armement par camera et par horaire (issue #40), pas retenu pour
  l'instant.**
  Source : MarkusKress, 2026-09-29, lui-meme "tres specifique, sans
  importance". Armer et desarmer des cameras choisies a des heures fixes,
  avec verification de l'etat au demarrage de blink2video. L'armement manuel
  existe deja (/api/arm, serve.py) ; ce qui manque est le planning, une
  tache de fond qui ne doit jamais laisser une camera dans le mauvais etat,
  et qui entre en conflit avec les horaires de l'application Blink. Question
  posee a Markus : que fait sa solution quand une camera ne repond pas a
  l'heure d'armement. A ne construire que si la demande se repete.

## Différences voulues entre les applications (à ne pas « corriger »)

- **Deux contextes TLS.** `blink_tls.py` donne à blinkpy un contexte strict avec le bundle certifi ;
  `_bootstrap_tls.py` de lidar2map remplace la fabrique HTTPS de tout le processus avant l'amorçage :
  deux mécanismes. `AGENTS.md` demande la prudence sur le TLS de blink2video (le relais du direct
  présente un certificat auto-signé, exception à ne jamais étendre).
- **`end_headers` de blink2video** : CSP à nonce, absente des autres applications.
- **`web_bridge.js`** : un helper de 12 lignes et sept méthodes communes, le reste est l'API de chaque
  application.
- **Mise à jour de blink2video** : depuis la 0.23, l'installateur commun (phase 2 du plan
  `PLAN-INSTALLATEUR-COMMUN-2026-10-08.md`). Restent propres à blink2video : le second temps
  détaché (`update --commun`), les processus à attendre lus des fiches, les compositions à
  relancer. L'ancienne permutation et `update --finaliser` restent pour la transition (une
  0.22 qui installe la 0.23, une permutation interrompue, un dossier parent protégé) ; à retirer
  en phase 3, vers janvier 2027.
- **B14 de l'audit** : identité de processus illisible = verrou repris, choix assumé du 2026-09-29 pour
  les pannes après redémarrage, à ne pas inverser sans accord.
- **Sélecteur FR / EN et panneau Réglages de blink2video** (décision du 2026-10-07). Les trois autres
  applications ont le sélecteur commun (`/nico579-langue.js`, route `/api/langue`, choix gardé côté
  serveur) et le bouton ⚙ commun. blink2video garde les siens : sa langue est gardée par navigateur
  (`localStorage`, un téléphone et un PC peuvent différer) et recopiée au serveur pour le menu de
  l'icône ; sa page porte une CSP à nonce et son serveur ne sert aucun fichier commun ; il a deux
  groupes FR / EN (en-tête et fenêtre de connexion) et son propre panneau, déjà riche, avec la
  vérification des mises à jour et le démarrage automatique. Les unifier changerait son comportement
  pour un gain nul.