510fe0b600
Session logi zostaja w docs/sessions/ (decyzja z etapu 1). Dodany wylacznie blok frontmattera: type: session-log, visibility: private, status: active, updated = data ostatniego commita pliku. Tresc nietknieta — kazdy plik to +9/-0 linii. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.3 KiB
2.3 KiB
| okf | type | visibility | status | updated | links |
|---|---|---|---|---|---|
| 0.1 | session-log | private | active | 2026-07-30 |
2026-07-30 — HA: legacy zamknięte, MCP read-only (faza 2a)
Legacy — finał
- Tydzień obserwacji czysty; kontener homeassistant5 już nie istniał przy próbie rm — usunięty przez nieustalony mechanizm (node-agent cleanup? remediation?). Katalog /home/pi/homeassistant NIETKNIĘTY (fałszywy alarm: 2>/dev/null maskował Permission denied — lekcja). Backlog: ustalić, co usunęło kontener (granice autonomii agentów); katalog do kasacji przy porządkach piha.
Faza 2a — własny MCP server (decyzja operatora: własny > hass-mcp)
- services/ha-mcp: 7 tools read-only strukturalnie (klient bez metod mutujących, WS allowlista, test grepujący za call_service), stdio, reuse ha_api/ha_ws, rejestracja w .mcp.json. 42 testy offline, smoke na żywym ken (1647 encji, 115 automatyzacji = zgodne z repo).
- Wtopa wdrożeniowa: venv żył w worktree, zginął przy merge-cleanup; fix: odtworzenie w głównym checkoucie. Backlog: run.sh bootstrap venva.
- Test bojowy (świeży CC, zero kontekstu): MCP wołany natywnie (5 calls), synteza hybrydowa MCP+repo — pełna mapa salonu z odwróconym indeksem encja→automatyzacje. Ujawniona luka: brak find_automations_using_entity (cross-ref robiony grepem). Backlog: dodać tool przed fazą 2b.
Znaleziska testu bojowego (klasy audytowej)
- Choinka/lampki (tasmota_12, zblampkiregal, tasmota_8) sterowane wyłącznie przez device_id — niewidoczne dla grep po entity_id; martwe od 26-29.07, automatyzacje cicho nie działają.
- DRUGA FALA martwych urządzeń 26-29.07 (switche choinki/regału + pilot 4button ponownie) — osobna od awarii 17.07; tłumaczy trend unavailable 305→377. Diagnoza sprzętowa: priorytet podniesiony, dwie daty padów.
- Task porządkowy device_id→entity_id (checklista pkt 17) dostał twardy dowód zasadności — do wykonania PO diagnozie sprzętowej.
Następne
- Diagnoza sprzętowa (fizyczna): dwie fale, z2m pokazuje część urządzeń żywych (baterie OK) — podejrzenie na most z2m↔HA / integrację.
- Faza 2b: propose_change/dry_run/request_approval przez kolejkę control-plane (pending→approved→executed) + Telegram. Osobna sesja.
- Tool find_automations_using_entity + bootstrap venva w run.sh.