Release 0.4.0

Zones, electrical heat sources, windows with ventilation, wind exposure
and recovery, and exchange between adjacent zones, all observational.
docs/MODEL.md documents the equations, units, coefficient meanings,
priors and bounds, learning conditions, forecast assumptions, validation
method and results, and limitations. README gains a configuration guide
for zones, heat sources and windows, the new diagnostics and the
accuracy comparison against the base model. CHANGELOG has upgrade notes
(config entry version 3, rollback needs the backup, renamed Status
attributes). ROADMAP marks the Milestone 2 items now covered; AUDIT
records the design decisions and evidence. AGENTS.md lists the new
modules and the convention that new model terms start at zero and must
beat the base model out of sample before being relied on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ROADMAP.md

@@ -10,7 +10,7 @@ Success means predictable comfort, understandable decisions, safe operation and
 
 ## Current baseline — v0.2.1
 
-> **Current release: 0.3.0** — Milestone 0 reliability work and the first part of Milestone 1 on top of this
+> **Current release: 0.4.0** — Milestone 0 reliability work, part of Milestone 1 and the first part of Milestone 2 on top of this
 > baseline; see [CHANGELOG.md](CHANGELOG.md). The lists below describe 0.2.1.
 
 **Implemented (experimental):**
@@ -104,14 +104,14 @@ recording volatile attributes, and tests against HA 2025.12.0 and 2026.2.3.
 
 **Objective:** Improve forecasts with genuinely useful features, not just more inputs.
 
-- [ ] Compare existing per-room linear model with a multi-zone RC model including inter-room heat exchange.
-- [ ] Address multiple sensors within a single physical room; configurable room grouping, aggregation and comfort priorities.
+- [x] Compare existing per-room linear model with a multi-zone RC model including inter-room heat exchange. *(0.4.0: layered zone model with neighbour exchange; base model scored alongside on every forecast. Exchange between zones sharing one boiler is weakly identifiable and reported as such.)*
+- [x] Address multiple sensors within a single physical room; configurable room grouping, aggregation and comfort priorities. *(0.4.0: zones with sensor weights, comfort weights and target offsets.)*
 - [ ] Distinguish air/room thermal mass and radiator lag where observable; avoid overfitting unidentifiable parameters.
 - [ ] Add optional Recorder history import/backfill for **indoor sensor + physical relay** history; do not assume old HA Recorder data still exists.
 - [ ] Add outdoor forecast data with future timestamps (forecast provider selectable) and compare forecast-based versus constant-outdoor assumptions.
-- [ ] Experiment with wind/cloud cover as optional covariates; retain them only if held-out forecast error improves. Solar gains may require orientation/irradiance or a useful proxy.
+- [ ] Experiment with wind/cloud cover as optional covariates; retain them only if held-out forecast error improves. Solar gains may require orientation/irradiance or a useful proxy. *(0.4.0: wind speed, direction and gusts for open windows, optional and judged by `improvement_vs_base`; clouds and solar still open.)*
 - [ ] Expose source reliability and provider comparison: normalized units, update age, outages and sensor offsets.
-- [ ] Handle shifts in room usage, opened windows, sensor relocation and season changes without unstable feedback.
+- [ ] Handle shifts in room usage, opened windows, sensor relocation and season changes without unstable feedback. *(0.4.0: opened windows handled by a separate ventilation layer; electrical loads by heat sources. Sensor relocation and seasons still open.)*
 - [ ] Benchmark RAM, CPU and event-loop latency on Raspberry Pi 5. Prefer standard-library/small scientific dependencies and avoid heavy inference runtimes.
 
 **Exit criteria:** Model complexity justified by reproducible forecast improvements over v0.3.0; stable fitting and manageable HAOS resource usage. Retain the simpler model as fallback where it performs better.
@@ -174,12 +174,17 @@ Items 1–3 of the original backlog are done (see AUDIT.md and CHANGELOG.md 0.2.
    room out, or optionally keep its last value for up to 24 hours). Before live
    control, decide a minimum `weight_coverage` and the outdoor-temperature outage
    policy, which still pauses.
-3. Milestone 1 (rest, 0.3.x): let the Forecast Error sensors collect a few weeks
-   of heating data and review per-room bias; a dashboard example; forecast
-   timestamps/provenance; a fixed-parameter baseline; explanations for the proposed
-   action; an actual-policy forecast that simulates Generic Thermostat.
-4. Only then consider richer weather inputs and the live-control **design**; do not
-   implement live control without separate authorization.
+3. Configure zones, the UPS heat source and the windows on HAOS; after a week of
+   heating review `improvement_vs_base`, per-zone bias and which coefficients are
+   identified. Switch off optional terms that do not help.
+4. Milestone 1 (rest): a dashboard example; forecast timestamps/provenance;
+   explanations for the proposed action; an actual-policy forecast that simulates
+   Generic Thermostat.
+5. Milestone 2 (rest): learned response times (compare candidate time constants
+   out of sample), a wall-mass state if recovery data shows it is needed, Recorder
+   backfill, weather forecasts, and a Raspberry Pi 5 resource benchmark.
+6. Only then consider the live-control **design**; do not implement live control
+   without separate authorization.
 
 ## Definition of done for each milestone