feat(ha/ken): porzadki po audycie — pimirror z archiwum, konwencje, backlog

Odtworzone graceful shutdown pimirror (audyt pkt 14, jedyna realna strata
migracji): nowa automatyzacja "Pimirror: graceful shutdown przed odcieciem
zasilania" (1785164185794.yaml) wciska przycisk shutdown przed twardym
cieciem zasilania o 23:35, dajac istniejacemu ACK-flow ("Magic Mirror OFF on
ACK") szanse zamknac Pi grzecznie zamiast zawsze odcinac prad na sile.
Zaadaptowane wzgledem legacy: entity_id zamiast device automation, oryginalna
encja button.rpi_pimirror_* jest dziś unavailable — uzyto aktualnej
button.rpi_pimirror2_* (potwierdzone w storage-export/ken).

Spisana konwencja na przyszlosc (audyt pkt 17) w DESIGN.md: entity_id zamiast
device automations, alias PL z prefiksem funkcjonalnym, description z
"managed-by: repo" — bez hurtowej migracji istniejacych automatyzacji.

Backlog: deploy.sh --delete (kasacje wspolnym torem dry-run/LIVE zamiast
recznych curl DELETE) i brakujacy trigger na zmiane input_number.klima_salon_tolerancja
w automatyzacji ON klimy.

Walidacja: normalizator round-trip (byte-identical), 4 pakiety testow offline
(normalize/split/deploy_api/import_api) pass, dry-run deploy.sh na zywym ken
(check_config valid, brak driftu) — bez LIVE deployu.

docs/backlog.md

@@ -102,6 +102,46 @@ historia incydentów, out-of-band watchdog.
 
 ## Aktywne
 
+### `scripts/ha/deploy.sh --delete`: brak wspólnego toru kasacji automatyzacji
+
+**Data**: 2026-07-27
+**Źródło**: sesja porządków po audycie (`task/ha-porzadki`); kontekst bezpośredni:
+kasacja pkt 10 (`36b43e5`, para Tymka/powitanie-test/notify-router/para-prototyp)
+zrobiona pętlą ręcznych `curl DELETE` po API zamiast przez repo tooling.
+**Problem**: `deploy.sh` ma tylko WRITE (`POST /api/config/<domain>/config/<id>`) —
+zgodnie z DESIGN.md ("Deploy path") i istniejącym wpisem w tym backlogu (sekcja
+"Cutover HA ken", krok 4) DELETE obiektów usuniętych z repo jest poza zakresem,
+drift-check tylko ostrzega (`warnings`), nigdy nie kasuje. Efekt: jedyna droga
+usunięcia automatyzacji z żywej instancji to ręczne wywołanie API, bez
+drift-check/`check_config`/verify, czyli bez żadnej z gwarancji, które deploy.sh
+daje dla write.
+**Fix**: `deploy.sh <instance> --delete <plik...>` (albo `--delete` jako tryb pracy
+na plikach usuniętych z repo, wykrytych przez `drift_warnings`) z tym samym rytmem
+co write: dry-run domyślny, `--dry-run`/LIVE jak dziś, `DELETE
+/api/config/<domain>/config/<id>` per obiekt, verify (GET → oczekiwane 404) zamiast
+porównania treści. Scope jak przy write: automations/scripts/scenes.
+
+---
+
+### HA ken: `input_number.klima_salon_tolerancja` nie ma triggera — zmiana nie przelicza progu
+
+**Data**: 2026-07-27
+**Źródło**: sesja porządków po audycie (`task/ha-porzadki`), przy okazji przeglądu
+`1784804667795` dla konwencji automatyzacji (pkt 17)
+**Problem**: `"Klima salon: włącz chłodzenie i synchronizuj cel"` (`1784804667795`)
+ma trigger `id: sync` na `input_number.klima_salon_temp_docelowa` (zmiana celu od
+razu przelicza próg), ale brak odpowiednika dla `input_number.klima_salon_tolerancja`
+— to ta sama klasa buga co "trigger brzegowy bez lustrzanego warunku" z audytu
+(sekcja 3, wzorzec `klima_salon` z fixu `faa2e2a`), tylko po stronie triggerów, nie
+warunków: zmiana tolerancji na dashboardzie nic nie przelicza do najbliższej
+naturalnej zmiany `sensor.thsalon_temperature`.
+**Fix**: dodać trigger `state` na `input_number.klima_salon_tolerancja` do gałęzi
+`sync` (albo do analogicznej gałęzi w automatyzacji OFF, jeśli tolerancja wpływa też
+na próg wyłączenia) w `1784804667795`, tak samo jak istniejący trigger na
+`_temp_docelowa`.
+
+---
+
 ### HA ken: guard TRV kalibracji przed sezonem grzewczym (~2026-09)
 
 **Data**: 2026-07-23

services/home-assistant/DESIGN.md

@@ -210,6 +210,27 @@ poprawki oczywistych bugów, audyt 2.6 i 2.3):
   turn_off_lights_in_kuchania = on` (double-click wyłącza tę automatyzację;
   „anyway" teraz cofa się przed tym stanem zamiast go unieważniać po 15 min).
 
+## Konwencje automatyzacji
+
+Ustalone po audycie 2026-07-23 (`docs/audyt-automatyzacji-2026-07-23.md`, sekcja 6
+"Spójność stylistyczna", pkt 17 checklisty operatora — decyzja: TAK). Obowiązuje dla
+**nowych** automatyzacji od teraz; istniejące **nie są migrowane hurtowo** (patrz
+sekcja 4.1 audytu — konsolidacja/rename `entity_id` wymaga osobnej mapy referencji
+krzyżowych, to osobny task, nie efekt uboczny porządków).
+
+- **`entity_id`, nie device automations.** `device_id`/encja-UID (32-znakowy hex) są
+  nieczytelne w YAML-u i kruche przy wymianie sprzętu — nowe urządzenie generuje nowy
+  `device_id`, a automatyzacja umiera po cichu (dokładnie ten mechanizm ubił parę
+  Tymka i ukrył rename `occusalon`, patrz audyt 4.1). Nowe automatyzacje używają
+  `action:`/`trigger:`/`condition:` z `entity_id:` jawnym.
+- **Alias po polsku, z prefiksem funkcjonalnym.** Format `"<Funkcja>: <opis>"`, np.
+  `"Klima salon: włącz chłodzenie i synchronizuj cel"`, `"Pimirror: graceful shutdown
+  przed odcięciem zasilania"`. Jeden język w aliasie (nie mieszanka PL/EN jak w
+  automatyzacjach z audytu 6).
+- **`description:` zawiera `managed-by: repo`.** Odróżnia automatyzacje autorskie
+  repo od tych z UI/migracji; przy okazji miejsce na kontekst (skąd odtworzone, jakie
+  encje zaadaptowano — patrz przykład `1785164185794.yaml`).
+
 ## Open questions
 
 - What actually drives the phase-3 operational agent (a new agent process

services/home-assistant/config/ken/automations/1785164185794.yaml

@@ -0,0 +1,15 @@
+actions:
+- action: button.press
+  target:
+    entity_id: button.rpi_pimirror2_rpi_shutdown_pimirror2_command
+alias: 'Pimirror: graceful shutdown przed odcięciem zasilania'
+conditions:
+- condition: state
+  entity_id: switch.tasmota_2
+  state: 'on'
+description: 'Wciska przycisk graceful-shutdown pimirror2 przed twardym odcięciem zasilania o 23:35 ("Mirror OFF"), żeby Pi zdążył się bezpiecznie wyłączyć zanim zgaśnie prąd. Istniejący automat "Magic Mirror OFF on ACK" (MQTT dom/pimirror-ack "went-halt") odcina zasilanie switch.tasmota_2 ok. 2 min po ACK — "Mirror OFF" 23:35 zostaje jako pas bezpieczeństwa, gdyby ACK nie przyszedł (Pi zawieszony/offline). Odtworzone z ken-legacy (automations/1703105565821.yaml "Turn OFF pimirror"): legacy używał device automation (press przycisku + delay 1 min + turn_off switch bezpośrednio, bez zapisanego triggera — prawdopodobnie wywoływane ręcznie); tu: entity_id zamiast device_id, bez duplikowania wyłączenia zasilania (robi to już istniejący ACK-flow), trigger czasowy zamiast braku triggera. Adaptacja encji: legacy/oryginalny button.rpi_pimirror_dom_rpi_shutdown_pimirror_command jest unavailable na ken (fixtures/ken-states-2026-07-27.yaml) — użyto aktualnego button.rpi_pimirror2_rpi_shutdown_pimirror2_command (potwierdzone w storage-export/ken/core.entity_registry.yaml). managed-by: repo'
+id: '1785164185794'
+mode: single
+triggers:
+- at: '23:28:00'
+  trigger: time