feat(kb): SPLIT home-assistant/DESIGN.md -> decision + incident

kb/decisions/ha-configs-as-code.md — decyzje projektowe HA configs-as-code
kb/incidents/2026-07-22-ha-dwie-instancje.md — sekcja "Incident log":
dwie instancje HA sterujace domem rownolegle po migracji

Incydent byl dotad wtopiony w dokument decyzyjny; teraz jest adresowalny
jako osobny wpis type: incident. Tresc nietknieta.

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

kb/decisions/ha-configs-as-code.md

@@ -1,3 +1,13 @@
+---
+okf: "0.1"
+type: decision
+visibility: private
+status: active
+updated: 2026-07-30
+links:
+  - ../incidents/2026-07-22-ha-dwie-instancje.md
+---
+
 # Home Assistant configs-as-code — design decisions
 
 Status: **phase 1 (partial)**. `scripts/ha/deploy.sh` implements the write
@@ -134,37 +144,6 @@ copied into the repo.
   the existing Telegram bot / approval-queue pattern from
   `services/control-plane/`.
 
-## Incident log
-
-### 2026-07-22 — two HA instances controlling the house in parallel
-
-**Symptom**: automations firing twice from a single physical trigger — e.g.
-`turn_on_led_nad_blatem_1` firing the same day from the same button press,
-`mirror_on` at 04:30 and `gniazdka_w_lazience_on` at 05:00 all firing on
-both instances.
-
-**How detected**: comparing `last_triggered` from `restore_state` across the
-two instances showed identical automation IDs firing at the same times on
-both — the container on piha (`homeassistant5`, HA 2026.4.3, location_name
-`KEN`, mounted at `/home/pi/homeassistant/config`) never actually stopped
-running after the migration to the RPi4/HAOS instance at 192.168.31.7; it
-stayed alive and MQTT-connected, so both were independently reacting to the
-same physical events.
-
-**Root cause**: `instances.yaml` had `ken` pointed at the piha container —
-that was the pre-migration instance, not the real one. The actual home
-instance had already moved to Home Assistant OS on a dedicated RPi4
-(192.168.31.7:8123, ingress `ha.kapala.org` via NPM, confirmed HAOS via
-observer :4357, HACS installed, 118 automations), but the repo never
-followed the move.
-
-**Decision**: 192.168.31.7 (HAOS/RPi4) is canonical `ken`. The piha
-container is renamed `ken-legacy` in `instances.yaml`, `status: archived`.
-Plan: archival import for historical reference → `docker stop` (not `rm`)
-→ one week of observation → decide on `docker rm`. See `docs/backlog.md`
-for the ha-diag-agent re-pointing and wind-down follow-ups this incident
-generated.
-
 ## Decyzje operatora po audycie 2026-07-23
 
 Zobacz `docs/audyt-automatyzacji-2026-07-23.md` (sekcja "Do decyzji operatora",

kb/incidents/2026-07-22-ha-dwie-instancje.md

@@ -0,0 +1,43 @@
+---
+okf: "0.1"
+type: incident
+visibility: private
+status: active
+updated: 2026-07-30
+links:
+  - ../decisions/ha-configs-as-code.md
+---
+
+# 2026-07-22 — dwie instancje HA sterujace domem rownolegle
+
+## Incident log
+
+### 2026-07-22 — two HA instances controlling the house in parallel
+
+**Symptom**: automations firing twice from a single physical trigger — e.g.
+`turn_on_led_nad_blatem_1` firing the same day from the same button press,
+`mirror_on` at 04:30 and `gniazdka_w_lazience_on` at 05:00 all firing on
+both instances.
+
+**How detected**: comparing `last_triggered` from `restore_state` across the
+two instances showed identical automation IDs firing at the same times on
+both — the container on piha (`homeassistant5`, HA 2026.4.3, location_name
+`KEN`, mounted at `/home/pi/homeassistant/config`) never actually stopped
+running after the migration to the RPi4/HAOS instance at 192.168.31.7; it
+stayed alive and MQTT-connected, so both were independently reacting to the
+same physical events.
+
+**Root cause**: `instances.yaml` had `ken` pointed at the piha container —
+that was the pre-migration instance, not the real one. The actual home
+instance had already moved to Home Assistant OS on a dedicated RPi4
+(192.168.31.7:8123, ingress `ha.kapala.org` via NPM, confirmed HAOS via
+observer :4357, HACS installed, 118 automations), but the repo never
+followed the move.
+
+**Decision**: 192.168.31.7 (HAOS/RPi4) is canonical `ken`. The piha
+container is renamed `ken-legacy` in `instances.yaml`, `status: archived`.
+Plan: archival import for historical reference → `docker stop` (not `rm`)
+→ one week of observation → decide on `docker rm`. See `docs/backlog.md`
+for the ha-diag-agent re-pointing and wind-down follow-ups this incident
+generated.
+