Le miroir GitHub n'est pas encore synchronisé : les liens pointent sur git.etm-powersync.fr.
INTERFACE.md n'est plus dans le dépôt public : la forme des méthodes NymeaEnergy.* se lit sur
la box (JSONRPC.Introspect) ; GetOptimizerStatus n'est pas réservée à l'administrateur.
Orthographe anglaise unifiée : optimizer, optimization.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ry3vBrJT1tHdxAaXdCWi6L
Prévision PV, « Et un optimiseur ? » : le protocole existe et est publié,
la connexion est en test (« en cours de développement » n'était plus
exact) ; lien vers la section. FAQ, open source : « socle
(powersync-core) », ancien nom, devient le moteur d'énergie
(etm-powersync-energy-plugin-etm) ; protocole ouvert, optimiseur de
référence et suite de conformité mentionnés. Accueil : liens vers
« Comment le moteur décide » et la section Optimiseur. Trois langues.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le canal testing sert powersync-plugin-openmeteo 1.15.2+etm1 (publié le
2026-09-08 à 09:49, avant le Contrat A). Cette version envoie les coordonnées
du site sans arrondi ; l'arrondi à deux décimales n'existe que depuis etm2,
et etm2 à etm16 ne sont dans aucun canal.
La fiche OpenMeteo, la page Prévision PV et la FAQ (trois langues) disaient
« arrondies à environ 1 km » sans condition. Elles le qualifient maintenant
par version, et la fiche porte un avertissement en tête : version décrite à
partir de 1.15.2+etm2.
PORTING_STATUS reste `testing` : c'est exact. TODO : retirer ces
avertissements quand etm16 ou suivant entre dans testing.
Vérifié comme en CI : génération, --check et mkdocs build --strict passent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nouvelle page fonctionnalites/prevision-pv (FR/DE/EN, dans la nav) : courbe
horaire jusqu'à la fin du lendemain par plan, correction de température et
plafond onduleur (modèles déterministes publics, aucun apprentissage),
« plafond optimiste », « une heure sans donnée est un trou, jamais un zéro »,
fourchette météo (qualifie la météo seulement), météo horaire, mise en
service, règle centrale de la Community (affiché et enregistré localement,
jamais utilisé pour décider), consommation de base « à venir », données qui
sortent, optimiseur seulement comme interface prévue.
Tarifs (3 langues) : section BETA « tarif saisi », exposé et non utilisé pour
décider ; les tarifs dynamiques restent en roadmap.
FAQ (3 langues) : réponse « données » réécrite avec la liste de ce qui sort ;
« Predict AI », `optimizer-plugin` et « socket Unix » retirés ; la prévision
physique passe dans Community, Pro garde les prévisions apprises.
Accueil : « sans dépendance au cloud ». Tableau des fonctionnalités : trois
lignes. Fiche OpenMeteo : lien vers la page, plafond appliqué par le moteur.
Sources : INTERFACE.md et DESIGN_PREVISION_PV.md (feature/forecast-protocol-1.1),
CONTRACT_A v4, CONSIGNE-app-etm66-prevision.md. Aucune donnée du banc.
Vérifié comme en CI : génération, --check et mkdocs build --strict passent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La doc ne décrivait la gamme nulle part. Elle gagne, dans les trois langues, une
entrée « Community et Pro, quelle différence ? » alignée sur la décision du
2026-10-14 : deux niveaux, la couche prédictive intégrée dans Pro, et aucun
abonnement sur aucun des deux.
La seule mention de « Predict AI » déjà présente dans ces FAQ (§ Open Core)
reste telle quelle : elle y nomme une fonction du `powersync-optimizer`, pas un
niveau de gamme — c'est précisément ce que la décision conserve.
L'arbitrage tarifaire et la prédiction sont annoncés en **roadmap**, comme sur
le site : la frontière Open Core existe déjà, les fonctions qu'elle sépare ne
sont pas toutes livrées.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
82 pages .de.md et 82 .en.md. La volumétrie explique la forme : 95 % du volume
est GÉNÉRÉ (74 013 mots contre 3 506 rédigés, mesuré sur 107 pages). On ne
traduisait donc pas 77 500 mots — on traduit la prose, et le vocabulaire des
générateurs fait le reste.
Prose traduite à la main : accueil, installation (4), fonctionnalités (4),
tarifs, référence, dépannage, FAQ, intégrations (2), api/index, et les 6 fiches
appareils qui portent une vraie prose + compatibilite.md. Les blocs générés ne
sont JAMAIS recopiés dans une traduction : le script de pose les reprend
verbatim du fichier français via des placeholders, pour qu'une traduction ne
puisse pas désynchroniser un bloc généré.
Les 49 fiches légères n'ont rien à traduire : leur tagline vient d'amont et est
DÉJÀ en anglais (« Connects nymea to powerfox. »). Constat, pas renoncement.
Localisation ≠ traduction, et tarifs.md en est l'exemple à connaître : la
version FR parle de Tempo et du signal RTE, la DE de §14a EnWG et de SMARD,
l'EN des deux. Ce ne sont pas des traductions l'une de l'autre, et c'est
volontaire — les signaux tarifaires sont nationaux. Aucune des deux n'est
annoncée comme livrée : les deux sont Roadmap, et les pages le disent.
Référence régénérée : en-têtes et libellés en anglais (Field/Type/Notes,
Supported models, Settings, Read-only, Brand / Model…). Conséquence assumée et
signalée : les pages FR en ligne changent aussi.
README.md (il était VIDE) : la règle du 95 % généré en tête, la frontière de
décision du multi-langue avec sa mesure, pourquoi SCAFFOLD existe, et le piège
--strict/navigation.instant.
TODO : multi-langue clos, et trois points ouverts qui en restent — les tagline
vivent dans les meta.json de 5 autres dépôts (forme à ajouter : tagline_de /
tagline_en), les stubs traduits restent des stubs (la dette éditoriale a triplé
en surface, pas en fond), api/types.md n'a pas besoin de variante. Le P1
openmeteo est corrigé sur constat : il EST dans PORTING_STATUS depuis, et une
ligne commentée contradictoire y traîne encore.
Vérifié : mkdocs build --strict vert sur les trois langues, 322 pages HTML,
contenu traduit relu dans le HTML produit, et les deux générateurs rendent
« Doc à jour » en --check.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
