---
name: wdroz
description: >
  Pełny pipeline wdrożenia na serwer Home Assistant: pre-flight
  (lint, test, stan gita), polski commit, push, make deploy, weryfikacja
  po deployu i postępowanie gdy `ha core check` padnie. Użyj gdy zmiany
  mają trafić na serwer HA. Triggers: wdróż, wdrożenie, deploy, wypchnij
  na serwer, make deploy, release.
allowed-tools: "Bash(make lint), Bash(make test), Bash(make status), Bash(make logs), Bash(git status), Bash(git log *), Bash(git diff *)"
---

# Wdróż — pipeline deployu na serwer HA

Kontekst: `docs/wdrozenie.md` + CLAUDE.md §Komendy. `make deploy` to
SSH na serwer → `git pull --ff-only` → `ha core check` → `ha core restart`,
**fail-fast**: padnięty check = brak restartu.

## 1. Pre-flight (przerwij przy pierwszym błędzie)

1. `make lint` oraz `make test` — CI odpala to samo; nie pushuj czerwonego.
2. `git status` — brak przypadkowych plików w commicie; deploy pulluje
   gałąź `HA_BRANCH=main`, więc zmiany muszą być zmergowane do `main`
   zanim `make deploy` je zobaczy.
3. Sklasyfikuj zmiany:
   - **platformy** (`sensor:`, `rest:`, `template:`, `shell_command:`,
     `input_*`…) → pełny `make deploy` (encje nie powstaną bez restartu);
   - **tylko `lovelace/`** → push + `make pull` + reload Lovelace w UI
     (Developer Tools → YAML), bez restartu;
   - **tylko `docs/` / `tests/` / `.claude/`** → push + `make pull`,
     bez restartu.

## 2. Commit i push

- Opis commita **po polsku**, zwięzły imperatyw w stylu repo;
  `Docs:` prefix dla zmian czysto dokumentacyjnych.
- Push; przy błędzie sieci ponów z backoffem.

## 3. Deploy

- `make deploy`.
- Pull na serwerze padł? Makefile wymaga czystego drzewa na serwerze
  (`git diff --quiet`) — `make status` pokaże, czy ktoś edytował pliki
  bezpośrednio na HA. Nigdy nie naprawiaj przez ręczną edycję na serwerze
  (złamie `--ff-only`); uporządkuj przez gita.

## 4. Gdy `ha core check` padnie

- **Bez paniki:** restartu nie było, HA nadal działa na starej konfiguracji.
- Odczytaj błąd z outputu (wskazuje plik/klucz), napraw lokalnie →
  `make lint` → commit → push → ponów `make deploy`.
- Brak szybkiego fixa → `git revert` felernego commita, push, `make deploy`
  — serwer wraca do działającego stanu, a fix robisz bez presji.

## 5. Weryfikacja po deployu

1. `make status` — HA wstało, `git log` serwera = lokalny HEAD.
2. `make logs` — `ERROR`, `Invalid config`, nazwa zmienianego pakietu.
3. Nowe/zmienione encje istnieją (Developer Tools → States).
   Pamiętaj: „Reload YAML" NIE tworzy encji platformowych — tylko pełny
   restart (patrz CLAUDE.md §Wzorce).
4. Nowy `shell_command` na harmonogramie? Nie czekaj do jutra — wywołaj
   ręcznie (Developer Tools → Actions) i sprawdź skutek (stan encji,
   `input_text.*_ostatni_fetch` itp.).

## 6. Uczciwe raportowanie

Coś z weryfikacji nie gra → zgłoś wprost z treścią błędu. Nie zamykaj
wdrożenia „na zielono", bo brak sygnału wygląda identycznie jak sukces.