The climate cards landed with the endpoint migration, but only as two more
folded dumps of key/value pairs. What a driver opens that tab for in January is
one number, and it was three taps down inside a card called Climate.
So currentTemperature and targetTemperature join the headline readings, beside
the pair of electric ranges and for the same stated reason: neither figure
answers the question on its own. A cabin at 12° means nothing until you know it
is climbing towards 21°, and the gap between them is how long to leave the
scraper in the boot. Being derived from headlineMetricSpecs, both are arrangeable
the moment they exist — a car's saved order of readings can name them without
anything else being told they are there, and a test now says so rather than
leaving it to be noticed when a PATCH starts rejecting a key.
The unit is fixed at Celsius, because Toyota Connected is the European service
and there is no imperial reading to convert from. That is a default and not a
claim: a payload that names its own unit is still believed over it, the way
every other reading here works, so a service that one day reports Fahrenheit is
labelled Fahrenheit rather than relabelled into a wrong Celsius.
The two apps needed the two labels in three languages each and nothing else.
That is the shape working: a section is an id the app localizes and a reading is
a key it localizes, so a card added on the server arrives in both clients
already folded, already arrangeable, already translated. The one thing the Web
App did need was a corrected comment — the note explaining why cards fold still
said Toyota reports eight sections, and it is the argument for folding them, so
it should count the ten there now are.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
