docs(prévision PV): §28 — v: 2 est décidé, plus une hypothèse

Le brief 2 fixe le transport à v: 2 ; la note de §28 l'écrivait au
conditionnel. Elle dit maintenant l'ordre de livraison qui en découle :
ems (lecteur v1 et v2) avant openmeteo v2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Patrick Schurig 2026-10-12 12:25:54 +02:00
parent 89b78c6cf5
commit a45b10b457

View File

@ -1348,8 +1348,7 @@ pas un état du code.*
> **Ce que ces décisions déplacent, et qui n'est pas encore fait** : la correction de température
> et la publication du GTI brut / `temperature_2m` sont du travail **openmeteo** (dépôt
> `etm-powersync-plugins`) et un changement de forme du transport. **Si** `v` est incrémenté — la
> règle proposée au lot 0 §4 est de l'incrémenter à tout changement de forme —
> `ForecastStore::depuisTransport()` **refusera** la charge utile (`VERSION_x`) tant que ce dépôt
> n'aura pas appris à la lire : l'ordre de livraison est alors imposé, le lecteur avant ou en même
> temps que le producteur. Le plafond AC de site est du travail **`ems`**.
> `etm-powersync-plugins`) et un changement de forme du transport, qui passe à **`v: 2`**
> (brief 2 ; règle : `v` est incrémenté à tout changement de forme). Tant que ce dépôt n'a pas
> appris à lire la v2, `ForecastStore::depuisTransport()` la **refuse** (`VERSION_2`) : l'ordre de
> livraison est imposé — le lecteur (`ems`, v1 et v2) est déployé **avant** le producteur. Le plafond AC de site est du travail **`ems`**.