Dokumentace: noc 11.→12. 6. — v2 aktivní, robustnostní trojice, EV forecast, CI opravy

- planning-changelog.md: záznam 2026-06-12 (přepnutí na v2, noční polštář /
  PV front-load / denní rampa s tabulkou, EV usage forecast, zimní posouzení)
- planning.md: default PLANNING_ENGINE_VERSION=v2 + sekce robustnosti
- refactor-clean-planner.md: Fáze 3 = v2 AKTIVNÍ
- ev-charging.md: EV spotřební forecast (sběr/statistiky/aktivace)
- consumption.md: bazál odečítá bazén
- deployment-self-hosted.md: tři CI vady + self-install deploy.sh + stop před flyway

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/04-modules/consumption.md

@@ -165,3 +165,10 @@ TUV_DEFAULT_POWER_W=2000                       # fallback pokud není měřeno
 - [ ] TUV teplota zásobníku: přidat čidlo do Loxone pro přesnější řízení
 - [ ] Bazální spotřeba: zpřesnit odečítání TUV výkonu (ON/OFF × čas vs pevný výkon)
 - [ ] Sezónní korekce predikce spotřeby (léto vs zima) – fáze 2
+
+## Odečet měřených řízených zátěží (update 2026-06-12)
+
+Bazál = `load_power_w` − EV (`telemetry_ev_charger`) − TČ (`telemetry_heat_pump`)
+− **bazén (`telemetry_pool_pump`)** — doplněno v `fn_update_baseline_stats`
+(R__003). Ruční chod čerpadla (vysávání) se tak přiřadí zařízení, ne bazálu;
+30d EMA okno historický šum vyplaví samo.

docs/04-modules/ev-charging.md

@@ -309,3 +309,29 @@ WHERE s.code = 'home-01';
 - [ ] UI pro nastavení deadline a target SoC uživatelem (před odjezdem)
 - [ ] Notifikace pokud deadline nelze splnit (nedostatek kapacity WB nebo energie)
 - [ ] Zoe SoC estimace z kumulativní energie session – přesnost ověřit
+
+---
+
+## EV spotřební forecast — týdenní rytmus vozidla (2026-06-12)
+
+Cíl: target SoC a deadline session z reálného užívání místo fixních defaultů
+(pondělí služebka ~150 km → skoro plná; konec týdne míň; víkendová session
+s pondělním deadline → v2 nabije v levných víkendových slotech — vyplyne z cen).
+
+**Sběr (bez buzení auta):** při příjezdu/odjezdu (auto vzhůru) Tesla API →
+`ems.ev_vehicle_obs` (odometer km — API vrací MÍLE, převod v `tesla_client`;
+SoC). Páry odjezd→příjezd → `ems.ev_trip` (km z odometru, kWh z ΔSoC ×
+kapacita; nabíjení cestou → `charged_away`, kWh se nepočítá). Job 00:50
+`fn_update_ev_usage_stats` → `ems.ev_usage_stats` per (vozidlo, DOW):
+avg/stddev kWh, km, hodina prvního odjezdu.
+
+**Použití:** `fn_ev_next_departure` (příští typický odjezd: DOW s ≥4 vzorky
+a ≥3 km) + `fn_ev_required_soc` (P80 spotřeby dne + 10 p.b., clamp
+[`min_target_soc_pct`, 100]) → `fn_ev_session_transition` při příjezdu
+(fallback defaulty; ruční patch `fn_ev_session_apply_patch` vždy vyhrává).
+
+**Aktivace per vozidlo** (po ~měsíci dat):
+`update ems.asset_vehicle set target_soc_forecast_enabled = true where code = 'tesla-my';`
+
+Tesla napojení (SoC při příjezdu → `soc_at_connect_pct`): `docs/tesla-fleet-api.md`.
+Registry wallboxu: `docs/04-modules/modbus-registers-teltocharge.md`.

docs/04-modules/planning.md

@@ -808,10 +808,15 @@ Plánovač má dvě implementace, přepínané env proměnnými (`backend/app/co
 
 | Env | Default | Význam |
 |-----|---------|--------|
-| `PLANNING_ENGINE_VERSION` | `v1` | Aktivní engine pro daily i rolling plán |
+| `PLANNING_ENGINE_VERSION` | **`v2`** (od 2026-06-12; v deploy compose) | Aktivní engine pro daily i rolling plán |
 | `PLANNING_ENGINE_COMPARE_ENABLED` | `false` | Shadow režim: druhá verze se počítá paralelně, diff se ukládá do `planning_run.solver_params.comparison` (status `comparison`) |
 
 - **v1** = `solve_dispatch_two_pass` (heuristické fáze/okna/kotvy + penalty; popsáno výše v tomto dokumentu).
 - **v2** = `services/planning/solver_v2.py`: objective = jen reálné peníze (cash + degradace − terminal SoC value z `asset_battery.planner_terminal_soc_value_factor`); tvrdá pravidla (CLAUDE.md 5/6/7/19), EV deadline (placený slack), TUV look-ahead, provozní režimy. SQL masky `allow_charge`/`allow_discharge_export` **ignoruje**.
 - Router: `_solve_dispatch_for_version` v `planning_engine.py`; chyby v2 jdou do standardní failure pipeline (`fn_planning_run_fail`).
+- **Robustnost v2 — „nejistota jako cena"** (parametry v DB, žádná okna):
+  noční SoC polštář (`night_baseload_buffer_wh`, slack za buy slotu), PV-risk
+  front-load v sell<0 (`planner_pv_risk_frontload_czk_kwh`, V090), denní SoC
+  rampa (`safety_soc_target_wh` × `planner_safety_soc_risk_factor`, V091).
+  Detail: hlavička `solver_v2.py` + changelog 2026-06-12.
 - Regresní brána a měření: `scripts/harness/README.md` (golden replay, economics report, penalty audit, `solver_v2_eval.py`); plán refaktoru: `docs/refactor-clean-planner.md`.

docs/deployment-self-hosted.md

@@ -179,3 +179,26 @@ Kompletní postup (zastavení služeb, `down`, smazání volume `db_data`, jen `
 - `deploy/docker-compose.yml` — šablona runtime Compose (kopíruje se do `/opt/ems-deploy`).
 - `.gitea/workflows/deploy.yml` — napojení na runner + job kontejner.
 - `docs/database-reset-and-restore.md` — zahození dat Postgres/Timescale a import zálohy.
+
+
+## CI/deploy opravy 2026-06-11/12 (container mód runneru, slabý server)
+
+Tři nezávislé vady, které od 6. 6. blokovaly auto-deploy (runy 358–369):
+
+1. **Secret `EMS_CI_FLYWAY_URL`** mířil na `localhost` — DB poslouchá na
+   `EMS_DB_BIND` (10.200.200.1). Validate flyway běží s `--network host`.
+2. **Bind mounty v container módu**: docker CLI v jobu mluví s HOSTOVSKÝM
+   daemonem → `-v` cesty checkoutu neexistují → flyway dostal prázdné adresáře
+   („applied migration not resolved locally"). Fix: `docker create` +
+   `docker cp` do **`/sql`** (ne `/flyway/sql` — image tam má VOLUME, který by
+   kopii zastínil) — `scripts/ci_flyway_validate_remote.sh`.
+3. **Pending repeatables**: flyway 12 validate selže na nové/změněné R__ —
+   ignorovat `*:pending` (CI skript i `deploy/deploy.sh`; immutabilitu
+   verzovaných hlídá `ci_check_migration_immutability.sh`).
+
+Dále: workflow deploy step si **sám instaluje čerstvý `deploy.sh`** z checkoutu
+(opravy skriptu se propagují bez ručního zásahu) a `deploy.sh` **stopne
+backend/frontend/postgrest PŘED flyway** — slabý server se s běžícím stackem
++ buildem dusil tak, že flyway nedostal spojení k DB (run 369: 9,5 min → EOF).
+Výpadek app vrstvy během deploye = navržená degradace (Loxone fallback,
+TeltoCharge failsafe).

docs/planning-changelog.md

@@ -5,6 +5,35 @@ Formát: **datum (ISO)** · stručný důvod · soubory · chování / ověřen
 
 ---
 
+## 2026-06-12 — v2 AKTIVNÍ v produkci + robustnostní trojice „nejistota jako cena"
+
+**Přepnutí (847015f):** `PLANNING_ENGINE_VERSION` default **v2** v deploy compose; v1 běží
+jako shadow peer. První živé srovnání (11. 6. večer): v1 kvůli relax řetězci potlačil
+evening push a nedoprodal špičku 3.92 — v2 prodal na 13.5kW stropu, o 28.8 Kč lépe.
+Rollback: `PLANNING_ENGINE_VERSION=v1` v `/opt/ems-deploy/.env`.
+
+**Trojice mechanismů proti chybě predikce (vše ceny, ne okna; parametry v DB):**
+
+| Mechanismus | Chrání před | Implementace |
+|---|---|---|
+| **Noční SoC polštář** (e464b11) | chyba predikce noční spotřeby → drahý noční nákup | soft floor `min_soc + night_baseload_buffer_wh[t]` (R__063, klesá k 0 do rána); porušení placené buy cenou slotu. Bonus: těsnější LP zrychlil extrémní fixtures z 10 s na 0.3–2.6 s |
+| **PV-risk front-load** (2932d48) | večerní mrak v okně sell<0 (v1 řešil rampou) | prémie za držení energie dřív v neg slotech; `asset_battery.planner_pv_risk_frontload_czk_kwh` (V090) |
+| **Denní SoC rampa** (e0410f9) | nenadálý odběr za kladných cen (KV1 ráno 11 % a prodává) | deficit pod `safety_soc_target_wh` (R__063 rampa reserve→reserve+noc, 6–19 h) platí nájem `buy×faktor`/slot; `planner_safety_soc_risk_factor` (V091, default 0.05) |
+
+Eval gate po každém kroku: v2 lepší než v1 na všech fixtures (+221.9 Kč) drženo.
+Solver testy 17; plná sada 274 passed / 4 xfailed (+1 předexistující reg340).
+
+**EV spotřební forecast (4095f0f):** týdenní rytmus vozidla (odometer+SoC při
+příjezdu/odjezdu z Tesla API, žádné buzení) → `ev_usage_stats` per DOW →
+`fn_ev_required_soc` / `fn_ev_next_departure` → target+deadline session
+(za flagem `target_soc_forecast_enabled`). Detail: `docs/04-modules/ev-charging.md`.
+
+**Zimní posouzení:** vlastní zimní data neexistují (telemetrie od 3/2026); 2 zimy raw
+OTE: spready 2.1–3.2 Kč (vs jaro 4–5.2), neg dny ~0 → klíč je TČ track. v2 bez
+sezónních oken (v1 měl 17h/5–11h/AM-PM = jarní slunce).
+
+---
+
 ## 2026-06-11 — Refaktor „Čistý plánovač“: harness, dekompozice, solver_v2 (Fáze 0–3)
 
 **Kontext:** Ekonomický audit potvrdil systémový problém heuristické vrstvy: na neg-sell dnech Σ heuristických penalt v objective 13× převažuje reálný cashflow; GAP actual vs perfect-hindsight oracle za 29 dní home-01 = **2 185 Kč ≈ 27 %**. Plný plán a stav: `docs/refactor-clean-planner.md`.

docs/refactor-clean-planner.md

@@ -24,7 +24,7 @@ ale řízená náhrada jádra plánovače za regresním harnessem.
 | 0 | Ekonomický harness: golden replay gate, fixtures z reálné DB, economics report (actual vs oracle), penalty audit | ✅ hotovo |
 | 1 | Dekompozice `planning_engine.py` → `services/planning/` (constants/types/forecast/db_io/heuristics), fasáda, identita chování | ✅ hotovo |
 | 2 | Penalty audit, stale testy → xfail, rozšíření fixtures (extrémní dny) | ✅ hotovo |
-| 3 | `solver_v2` (čisté jádro) + router verzí + shadow porovnání | ✅ hotovo (kód); **čeká na shadow data z produkce** |
+| 3 | `solver_v2` (čisté jádro) + router verzí + shadow porovnání | ✅ **v2 AKTIVNÍ v produkci od 2026-06-12** (v1 = stín); + robustnostní trojice (changelog 2026-06-12) |
 | 4 | Slupka: FE výkon + responsivita | ✅ první vlna (viz `docs/audits/`) |
 
 ## Jak se pracuje (závazná pravidla)