docs(backlog): zamkniecia po reconie 2026-07-02 + followupy z rozbrajania min

Zamkniete: bug B (ghost kontenery — zniknely), pending poll-Prometheus-watchdog
(potwierdzony), miny #1/#2/#3 z inwentaryzacji. Dodane followupy: wpisy hostowe
forgejo/mosquitto, mem_limit mosquitto@VPS, mosquitto per-host (chelsty-infra),
broker :1883 w topology, pi-watchtower-1 restart-loop, alias lustro, mem_limit
fleet-prometheus. Ocena joplin-db postgres:18 zdezaktualizowana (PG18 GA).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/backlog.md

@@ -34,7 +34,9 @@ historia incydentów, out-of-band watchdog.
 5. ✅ ZROBIONE (2026-06-30, commit `62d6fc0`) — brain-watchdog: drugie wejście — poll
    Prometheus `/api/v1/alerts` (`firing`) → Telegram. Architektura A: dwa niezależne tory,
    mózg NIETKNIĘTY, debounce per-alert (klucz alertname:node w state.json). 12 testów pass.
-   PENDING: potwierdzenie end-to-end przy pierwszym realnym firing.
+   PENDING zamknięty 2026-07-02: poll POTWIERDZONY reconem (obraz zbudowany po `62d6fc0`,
+   `PROMETHEUS_URL` w `.env` i w env kontenera, zero poll failed) — patrz
+   `docs/infra/inventory-verify-2026-07-02.md`.
 6. Rotacja tokenu HAOS w domowym prom (plaintext).
 7. Przepięcie observer / panel `agents.okit.pl` na Prometheus jako źródło — największy
    znak zapytania przy cutoverze.
@@ -44,19 +46,6 @@ historia incydentów, out-of-band watchdog.
 
 ## Aktywne
 
-### brain-watchdog: brak logu PROMETHEUS_URL przy starcie
-
-**Data**: 2026-06-30
-**Źródło**: sesja 2026-06-30 (`docs/sessions/2026-06-30-prometheus-liveness.md`)
-**Problem**: log startowy brain-watchdoga nie wypisuje `PROMETHEUS_URL` — utrudnia
-potwierdzenie, że polling jest aktywny. Diagnoza "działa" opiera się na braku błędów
-i zawartości `.env`, nie na logach. Pierwszy realny firing to jedyne pełne end-to-end
-potwierdzenie.
-**Fix**: dorzucić przy starcie jedną linię logu: `PROMETHEUS_URL set, polling enabled`
-lub analogicznego `disabled` — tak jak robione dla `HEALTHCHECKS_URL`.
-
----
-
 ### Gotchas (z 2026-06-30 — migracja kapala.org → Cloudflare/wildcard)
 
 **Data**: 2026-06-30
@@ -156,21 +145,6 @@ czy jest osiągalny po Tailscale z VPS, i czy ma sens go scrape'ować mimo LTE
 
 ---
 
-### Ghost kontenery w panelu (Problem B — pozostałość po project-name divergence)
-
-**Data**: 2026-06-24 (wykryte), pozostaje otwarte po fixie Problemu A (2026-06-26)
-**Źródło**: sesja 2026-06-24 + 2026-06-25 + 2026-06-26
-**Problem**: martwe kontenery ze starych project-name'ów
-(`8547b46c0317_control-plane-supervisor`, `12bd3059a70f_control-plane-observer` itp.)
-są raportowane przez observera jako `error` → `System Status ERROR` w panelu mimo
-zdrowego realnego mózgu.
-**Status**: destrukcyjny deploy (Problem A) NAPRAWIONY (`3b71707`, patrz Zamknięte), ale
-ghosty z poprzednich rozjazdów wciąż wiszą.
-**Fix**: `docker rm` ghostów na VPS; rozważyć czyszczenie kontenerów z obcym
-project-name przy deployu.
-
----
-
 ### Supervisor nie enqueue'uje akcji remediacji przy `error`-state
 
 **Data**: 2026-06-25 (powtórka sygnału z 2026-06-19)
@@ -182,6 +156,9 @@ Podejrzane: supervisor może nie reagować na error-state jeśli źródłem są
 (błędne project-name), nie realne health-check failures.
 **Fix**: zbadać osobno — sprawdzić, czy supervisor otrzymuje właściwe eventy od observera,
 czy ma własną logikę de-duplifikacji blokującą enqueue.
+**Update 2026-07-02**: ghost kontenery (bug B) zniknęły z VPS — jeśli objaw wróci,
+hipoteza "źródłem są ghosty" jest już nieaktualna. UWAGA: ślepy supervisor na SATURN
+(brak mountu repo, patrz sesja 2026-07-02) to INNY przypadek — nie mylić z tym bugiem.
 
 ---
 
@@ -304,6 +281,46 @@ Długoterminowo: `agent.sh new` powinien odmawiać jeśli żądana gałąź jest
 
 ## Zamknięte
 
+### Ghost kontenery w panelu (Problem B) — ZNIKNĘŁY (potwierdzone reconem 2026-07-02)
+
+**Data**: 2026-06-24 (wykryte), 2026-07-02 (zamknięte)
+**Źródło**: sesje 2026-06-24/25/26; recon `docs/infra/inventory-verify-2026-07-02.md`
+**Było**: martwe kontenery ze starych project-name'ów
+(`8547b46c0317_control-plane-supervisor` itp.) raportowane przez observera jako
+`error` → `System Status ERROR` w panelu mimo zdrowego mózgu.
+**Zamknięte**: recon 2026-07-02 — 24 kontenery na VPS, ZERO hash-prefixed.
+Prawdopodobnie recreate'y z kolejnych deployów je zmiotły. Zero akcji ręcznej.
+Rozważenie czyszczenia obcych project-name przy deployu — już nieaktualne
+(fix A `3b71707` blokuje źródło divergence).
+
+---
+
+### brain-watchdog: poll Prometheus — POTWIERDZONY (recon 2026-07-02)
+
+**Data**: 2026-06-30 (pending), 2026-07-02 (zamknięte)
+**Źródło**: recon `docs/infra/inventory-verify-2026-07-02.md`
+**Było**: log startowy nie wypisuje `PROMETHEUS_URL` → brak pewności, że polling
+aktywny; diagnoza opierała się na `.env` i braku błędów.
+**Zamknięte**: recon potwierdził — obraz zbudowany po `62d6fc0`, `PROMETHEUS_URL`
+w `.env` I w env kontenera, zero `poll failed` w logach. Poll aktywny.
+Jednolinijkowy log startowy (`polling enabled/disabled`) pozostaje opcjonalną
+kosmetyką; pełne end-to-end (firing → Telegram) potwierdzi pierwsza realna awaria.
+
+---
+
+### Miny #1/#2/#3 z weryfikacji inwentaryzacji — ROZBROJONE (2026-07-02)
+
+**Źródło**: `docs/infra/inventory-verify-2026-07-02.md`, sesja
+`docs/sessions/2026-07-02.md` (tam szczegóły i lekcje).
+- **#1 PIHA checkout**: gałąź wciąż `task/kb-gmail-import` po resecie z 2026-06-30
+  (reset --hard przesuwa gałąź, nie przełącza) → `checkout master && pull`,
+  30 commitów nadrobione.
+- **#2 control-plane na SATURN**: supervisor ślepy (brak mountu repo) →
+  `docker compose down`, wolumeny zachowane. Jedyny mózg = VPS.
+- **#3 owner_node**: forgejo→piha, mosquitto→vps (commit `886bc85`).
+
+---
+
 ### 🔴 KRYTYCZNY — `deploy.sh vps` niszczył control-plane — NAPRAWIONE (commit `3b71707`)
 
 **Data**: 2026-06-24 (wykryte), 2026-06-25 (incydent w produkcji), 2026-06-26 (naprawione)
@@ -391,11 +408,16 @@ gromadzi historię. Anomaly detection = osobny świadomy projekt później (CC,
 ---
 ## Rozjazdy repo<->rzeczywistosc (z inwentaryzacji 2026-06-30)
 **Zrodlo**: `docs/infra/inventory-2026-06-30.md` (23 rozjazdy, pelna tabela tam).
+**Weryfikacja 2026-07-02**: `docs/infra/inventory-verify-2026-07-02.md` — bilans:
+20 wciaz aktualnych, 2 zmienione, 1 wyjasniony (storage SOLARIA = partycja Windows
+dual-boot, NIE rozjazd — zdjety z listy).
 Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka.
 
 ### Grupa A — czyste docs, zero ryzyka
-- **forgejo** `service.yaml owner_node`: saturn -> piha (biega na PIHA always-on)
-- **mosquitto** `service.yaml owner_node`: piha -> vps (biega na VPS, nie na PIHA)
+- ✅ ZROBIONE (2026-07-02, commit `886bc85`) — **forgejo** `service.yaml owner_node`:
+  saturn -> piha (biega na PIHA always-on)
+- ✅ ZROBIONE (2026-07-02, commit `886bc85`) — **mosquitto** `service.yaml owner_node`:
+  piha -> vps (biega na VPS, nie na PIHA)
 - **capabilities SATURN**: RAM 8 -> 14GiB; dysk sd-card 64GB -> /dev/sda 159GB
 - **capabilities SOLARIA**: CPU 24 -> 32 nproc
 - **`hosts/saturn/services.yaml`** nie istnieje — 5 kontenerow bez deklaracji
@@ -405,8 +427,10 @@ Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka.
 - **npm x2**: PIHA (LAN ingress :80/:443) + VPS (public). Repo zna jedna (owner=vps).
   Decyzja: zostawic oba (intentional, wildcard cert via NPM@PIHA) czy usunac PIHA?
   Jesli oba zamierzone -> dodac piha do service.yaml + hosts/piha.
-- **control-plane na SATURN**: biega (control-plane-ui UNHEALTHY) obok VPS. Repo zna tylko VPS.
-  Decyzja: dev-instance czy pomylka? Usuniecie odzyska zasoby + zlikwiduje UNHEALTHY.
+- ✅ ZROBIONE (2026-07-02) — **control-plane na SATURN**: `docker compose down`
+  (wolumeny zachowane). Supervisor byl SLEPY (brak mountu repo, WARNING loop
+  "Hosts directory /repo/hosts does not exist" co 30s) — zero ryzyka zdublowanych
+  remediacji przez te 3 dni. Jedyny control-plane = produkcyjny na VPS.
 - **ollama**: `service.yaml owner=solaria` ale NIE biega. Wdrozyc czy wyrzucic z repo?
 
 ### Grupa C — sprzatanie
@@ -415,13 +439,33 @@ Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka.
   albo curl w Dockerfile. (Przyczyna rozjazdu #6 znaleziona przy gaszeniu dysku.)
 - **homeassistant5 na PIHA** (HA "ken" :8123) niedeklarowany -> dodac do hosts/piha + topology
 - **VPS**: outline-postgres-1 anonimowy image (4e6e670bb069) -> named tag;
-  joplin-db postgres:18 (pre-release) -> postgres:17/16; humanai-landing/mailer/umami do repo
+  humanai-landing/mailer/umami do repo. ~~joplin-db postgres:18 -> 17/16~~
+  (ocena zdezaktualizowana 2026-07-02: PG18 GA od 09/2025, nie pre-release — bez akcji)
 - **PIHA: 33 shadow kontenery** poza GitOps (immich, vaultwarden, wikijs, actual,
   audiobookshelf, elasticsearch, grafana, prom, portainer, code-server, diskover...)
   -> audyt + stopniowo do hosts/piha/services.yaml
 - **zigbee2mqtt** topology mowi chelsty-infra, biega na PIHA -> poprawic topology
 - **stability-agent / node_exporter** owner_node single, biegaja wielomiejscowo -> per-host
 
+### Followupy z weryfikacji + rozbrajania min (2026-07-02)
+**Zrodlo**: `docs/infra/inventory-verify-2026-07-02.md` + sesja 2026-07-02.
+Zgloszone przy fixie owner_node (`886bc85`), swiadomie NIE ruszone — osobne decyzje.
+
+- **forgejo** brak wpisu w `hosts/piha/services.yaml`; **mosquitto** brak
+  w `hosts/vps/services.yaml` — schemat hostowy wymaga role/exposure/depends_on
+  (miny #2/#3/#16 z audytu).
+- **mosquitto na VPS bez mem_limit override** w `hosts/vps/runtime/` —
+  narusza konwencje CLAUDE.md (kazdy serwis VPS deklaruje mem_limit).
+- **drugi mosquitto na chelsty-infra** (offline'owa instancja) — pojedyncze
+  `owner_node` jej nie opisuje; wzorzec per-host jak stability-agent /
+  node_exporter (miny #17/#18).
+- **topology.yaml:75**: mosquitto zadeklarowany tez jako komponent ai-cluster —
+  rozstrzygnac, czyj jest broker :1883.
+- **pi-watchtower-1 na LUSTRO w restart-loopie** (nowe z reconu; node-agent healthy).
+- **alias `lustro` nie rezolwuje z SOLARII** (nowe z reconu).
+- **fleet-prometheus bez formalnego override mem_limit** w `hosts/vps/runtime/` —
+  limit siedzi w bazowym compose (kosmetyka).
+
 ### Po odchudzaniu PIHA (2026-07-02, faza 2 modulu 0)
 - **llm-gateway: zlokalizowac/zarchiwizowac zrodlo** — kod (wlasny FastAPI router ->
   Ollama@SOLARIA) moze zyc TYLKO w `/opt/llm-gateway` na PIHA, bez gita; przeszukanie