[citarf]

Constat

• Le portail chom-poc-data passe sur le nouveau run dès que ses champs sont publiés. Le job cone-members met ensuite environ 1 h à calculer les cônes, et pendant ce temps le catalogue (GET /api/weather-ai/products) renvoie cones: null.
• maps refuse, à juste titre, tout cône d'un autre run (feat(weather-ai): cônes cycloniques publics servis par le portail dans l'onglet Cyclones IA #150). Résultat : environ 1 h sans cônes à chaque cycle.
• Contrat portail vérifié (scripts/serving_weather_ai.py, lecture seule) : _cones_du_run ne rattache les cônes chargés (CONES) au catalogue que si run_id et snapshot_id sont ceux du run servi. produit(), timeline() et _cones_data() renvoient 404 sinon. Les runs historiques (?run_id=) ne servent jamais de cônes (« public cones are served for the live run only »). Une visite à froid pendant la fenêtre ne peut donc pas obtenir les cônes du run précédent. Cette PR couvre ce qui est faisable côté maps : une mémoire de session.

Comportement

• Le contrôleur garde en mémoire de session les derniers cônes validés (lastCones).
• Quand le run bascule (commitRun), si le nouveau run n'a pas encore ses cônes, ceux du run précédent sont conservés dans weatherAiCones.previous :
  • carte flottante : « Cônes du run 26/10 00Z : ceux du run affiché sont en cours de calcul. Contour en pointillés. », puis la mention de calibration et le calibration_status de leur run ;
  • onglet Cyclones IA : même mention dans la section cônes, et dans les mentions (attribution et licence de leur run) ;
  • rendu distinct : remplissage atténué (0,12/0,22 au lieu de 0,28/0,5) et contour en pointillés. L'infobulle des centres compte l'échéance depuis leur amorce et nomme leur run (« run précédent ») ;
  • les trajectoires restent celles du run courant.
• Dès que le catalogue annonce les cônes du run courant, le mécanisme existant prend le relais (withCatalogCones puis syncCones). Une fois ces cônes validés, ils remplacent les anciens et la mention disparaît.

Garde-fous (keepPreviousCones, cones.ts)

• Seulement les cônes du run affiché juste avant (un run sauté, par exemple onglet en veille, fait tout tomber).
• L'amorce du run affiché doit être postérieure de 12 h au plus à celle des cônes (PREVIOUS_CONES_MAX_AGE_MS). Une amorce inconnue fait tout tomber.
• validateCones est rejoué contre leur propre run (run_id, snapshot_id, calibration_status du catalogue de l'époque, mention exacte, limites d'échéance).
• Aucun repli si le nouveau run annonce déjà ses cônes. Si les cônes du run courant sont refusés ou en erreur, les anciens restent affichés, avec la raison du refus dans l'onglet.
• Jamais présentés comme ceux du run affiché : champ previous séparé, doc: null pour le run courant, et aucune info de cône ancien dans l'infobulle des trajectoires.
• Mode démo (fixture) et flag off : rien n'est gardé.

Limites

• Uniquement en session : il faut avoir chargé les cônes du run précédent (couche cônes active) avant la bascule. Après un rechargement de page pendant la fenêtre, il n'y a pas de cônes.

À faire côté portail (chom-poc-data, porté séparément)

Pour couvrir le chargement à froid, ajouter au catalogue un champ frère cones_previous :

• Catalogue GET /weather-ai/products (run en ligne seulement, pas sur ?run_id=) : cones_previous vaut null, ou bien la même projection que cones (_cones_public : product_id, run_id, valid_time, sha256, snapshot_id, attribution, license_notice, experimental, calibration_status, mention, cones_catalog), avec en plus init_time. Il n'est renseigné que si toutes les conditions suivantes sont réunies :

  1. cones vaut null (le run en ligne n'a pas de cônes validés) ;
  2. les cônes chargés (CONES) sont ceux du run immédiatement précédent dans l'historique servi ;
  3. l'écart entre amorces est de 12 h au plus ;
  4. le document a été validé au chargement, comme aujourd'hui (cones_contract.load, SHA-256 et VersionId).

  Concrètement, _cones_du_run reste inchangé, et un _cones_precedents(catalog) renvoie CONES quand entry.run_id != catalog.run_id et que les conditions 2 et 3 sont vraies.

• Données : GET /weather-ai/products/global-cyclone-cones-public/data?valid_time=<amorce>&cones_run_id=<run_id précédent> sert ce document seulement quand cones_run_id correspond au cones_previous courant, et répond 404 sinon. La réponse est identique à _cones_data. Variante possible : un product_id distinct, mais garder le même schéma de document reste plus simple pour maps.

• Côté maps, une fois ce champ servi : discoverProducts lit cones_previous et remplit weatherAiCones.previous au chargement à froid, avec les mêmes garde-fous (petite PR de suivi).

Staging

https://citarf-maps-cones-previous-run-infoclimat-numeric.infoclimat.workers.dev (version : https://a2ca2ce5-infoclimat-numeric.infoclimat.workers.dev)

Vérifications

• npx vitest run src/lib/tests/weather-ai-*.test.ts : 175 tests verts, dont les nouveaux de weather-ai-previous-cones.test.ts (garde-fous, rendu, mentions, bascule de run de bout en bout : gardés, puis remplacés, puis refus du run courant).
• npm run check : 0 erreur.
• eslint . : OK.
• prettier --check : les seuls avertissements portent sur deux fichiers que cette PR ne touche pas (src/lib/variable-categories.ts, docs/superpowers/plans/2026-05-31-refonte-ui-shell.md) ; ils existaient déjà sur main.
• Doc : .claude/rules/architecture.md mis à jour (§ cônes).

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	infoclimat-numeric	116f163	Commit Preview URL Branch Preview URL	Oct 27 2026, 06:08 PM