docs(backlog): bug checkpoint observera (leksykalne porównanie ścieżek zatruwa węzeł) + bug deploy-local.sh rozkłada control-plane na ghostach

docs/backlog.md

@@ -560,3 +560,45 @@ mapy uid/gid.
   capabilities.yaml (żeby deploy mógł weryfikować/wymuszać spójność).
 - Agenci NIE powinni montować prywatnego .ssh użytkownika — zawsze dedykowany
   katalog z własnym kluczem pod właściwym uid (wzorzec z fixa 2026-07-10).
+
+## Bug: checkpoint observera po ścieżce leksykalnej — kruchy, zatruwa węzeł na zawsze (2026-07-12)
+
+**Objaw.** PIHA była "martwa" dla observera ~34 dni mimo działającego node-agenta.
+Eventy dojeżdżały na VPS (7344 plików w /opt/homelab/events/piha/), ale observer
+ich NIE konsumował — `last_seen` nie drgnął, shadow-read logował
+`SHADOW_LIVENESS_MISMATCH node=piha event=dead prom=up` z rosnącym wiekiem.
+
+**Root cause.** `observer_checkpoint.json` trzyma per-węzeł ostatnio przetworzoną
+ŚCIEŻKĘ i porównuje ją LEKSYKALNIE (stringowo), awansując tylko "do przodu".
+Checkpoint PIHA utknął na `evt-unknown-1781254800-ha_update_available-homeassistant-951.json`
+(event z HA, który wpadł do katalogu piha/ z node="unknown"). Nowe eventy nazywają się
+`evt-piha-<ts>-...`, a leksykalnie **"evt-piha-…" < "evt-unknown-…"** (bo `p` < `u`),
+więc KAŻDY nowy event był uznawany za starszy niż checkpoint i pomijany.
+
+**Fix doraźny (zastosowany).** Usunięcie wpisu `piha` z node_checkpoints + restart
+observera → 7344 eventy przetworzone, `last_seen_age` spadł z 2 082 036 s (~24 dni)
+do 19 s, status=online/fresh, mismatch zniknął.
+
+**Fix systemowy (DO ZROBIENIA).** Porównanie po ścieżce jest z gruntu kruche —
+wystarczy JEDEN plik o "większej" nazwie (inny node w katalogu, inny prefiks) żeby
+trwale zablokować węzeł. Checkpoint powinien opierać się na **timestampie** (jest
+w nazwie: `evt-<node>-<unixts>-<type>`) albo mtime pliku, nie na kolejności alfabetycznej.
+Dodatkowo: zbadać, czemu eventy z node="unknown" (HA) trafiają do katalogu innego węzła.
+
+## Bug: deploy-local.sh control-plane pada na ghost-kontenerach i zostawia mózg rozłożony (2026-07-12)
+
+**Objaw.** `bash deploy-local.sh` przerwał się w połowie:
+`Error response from daemon: No such container: 5ee6fec5455d_control-plane-ui` →
+deploy abort → **ZERO kontenerów control-plane** (`docker ps -a` pusty). Mózg całkowicie
+down. Zdarzyło się DWA RAZY tego samego dnia. Ratunek: ponowny `deploy-local.sh`
+(gdy ghost już zniknął, compose stawia czysto).
+
+**Root cause (podejrzenie).** Ten sam COMPOSE_PROJECT_NAME divergence / ghost
+hash-prefixed containers, co przy `deploy.sh vps` (naprawione guardem 3b71707).
+Compose próbuje Recreate kontenera pod nazwą `<hash>_control-plane-ui`, której Docker
+już nie zna → błąd → `set -e` przerywa deploy w połowie.
+
+**Fix (DO ZROBIENIA).** deploy-local.sh powinien być odporny: cleanup ghostów przed
+recreate (`docker compose down --remove-orphans` albo jawne usunięcie hash-prefixed
+kontenerów), ewentualnie jawny `-p` (COMPOSE_PROJECT_NAME) żeby nazwy były deterministyczne.
+Deploy mózgu NIE MOŻE zostawiać control-plane w stanie zero-kontenerów.