homelab-codex-ws/docs/sessions/2026-08-06.md

---
okf: "0.1"
type: session-log
visibility: private
status: active
updated: 2026-08-06
links: []
---

# Session log 2026-08-06

## Session 13:20

Produkcyjna weryfikacja pierwszego cyklu safe-cleanup na LUSTRO (R1/R2/R3, deploy
2026-08-05) oraz pierwszy pełny cykl HITL: approval → dispatch → wykonanie na nodzie →
`action_result` → `completed`. Sesja supervised, checkpointy zatwierdzane przez operatora,
approvale wykonywane wyłącznie przez operatora. Incydent źródłowy:
`docs/incidents/2026-07-30-ollama-solaria-vanish.md`.

### Commits

Ta sesja **nie wprowadziła żadnych commitów poza niniejszym logiem** — zero zmian w kodzie
i konfiguracji repo. Cała praca to recon read-only + kontrolowane zapisy runtime na
LUSTRO i VPS (kanarki testowe, plik akcji), wszystkie sprzątnięte lub udokumentowane niżej.

Poprzedni log sesji: `67aa092 docs: session 2026-08-05 22:47` — potwierdzony na
`origin/master` (ahead/behind 0/0) na starcie sesji.

### Files changed

Brak — poza tym plikiem.

---

## KROK 1 — safe-cleanup na LUSTRO: obie gałęzie potwierdzone produkcyjnie

### Stan wyjściowy

Marker `/opt/homelab/state/last-docker-cleanup` = `1785925612` (2026-08-05 12:26:52 CEST),
**sprzed deployu** (obraz node-agenta utworzony 22:42:05 CEST). Bramka
`_cleanup_rate_ok()` (`CLEANUP_INTERVAL_SECS = 86_400`) trzymała pierwszy cykl nowego kodu
do 12:26:52 dnia 2026-08-06. Brak linii cleanup w logach do tego momentu był więc
zachowaniem poprawnym, nie awarią.

Kod w runtime zweryfikowany: `md5(/app/src/node_agent.py)` == `md5(repo HEAD)` =
`c9ac64e10b42b3e0ed9e4c168579bfaa`, brak wykonywalnego `containers.prune()`,
`NODE_TYPE=sd_card`.

Pułapka interpretacyjna: logi kontenera node-agent są w **UTC**, host w CEST. Pozorna
6-godzinna dziura w logach to nocny `halt` (root cron `30 23 * * * /usr/sbin/halt`,
boot 06:30) — LUSTRO ma duty cycle jak SOLARIA, zgodnie z `inventory/topology.yaml`
(`duty_cycle: nightly`).

### Test w oknie prune

Do okna przygotowano trzy kontenery `exited` pokrywające obie gałęzie filtra:

| Kontener | Polityka / label | Oczekiwane | Wynik |
|---|---|---|---|
| `prune-disposable` | `restart=no`, brak compose | usunięty | ✅ usunięty |
| `prune-canary` | `restart=unless-stopped`, brak compose | zachowany | ✅ przeżył |
| `node-exporter` (realny serwis) | `restart=always`, brak compose | zachowany | ✅ przeżył |

Log z okna (12:27:49 CEST / 10:27:49 UTC):

```
INFO    - Pruned dangling images (0 MB reclaimed)
WARNING - Removed 1 disposable stopped container(s): prune-disposable (kept 2 managed)
```

Marker zaktualizowany na `1786012069`. `kept 2` = `prune-canary` + `node-exporter`.
Wszystkie kontenery produkcyjne nietknięte.

**Werdykt:** obie gałęzie filtra działają na produkcji — gałąź ochronna (kontener zatrzymany
przez operatora z polityką restartu przeżywa prune; dokładny scenariusz incydentu ollamy)
oraz gałąź usuwania (filtr nie jest no-opem, faktycznie kasuje jednorazowe resztki).

### Korekta wniosku z 2026-08-05

Wczorajszy test kanarka na SOLARII (przeżył 151 s) **nie dowodził działania filtra** —
SOLARIA ma `NODE_TYPE=lte_node` (mitygacja M1), gdzie `run_safe_cleanup()` kończy się
`return` przed jakimkolwiek prune. Ten test potwierdził M1, nie R1. Dowód dla R1 powstał
dopiero dziś na LUSTRO.

### Stan cleanupu na flocie

| Node | NODE_TYPE | Cleanup |
|---|---|---|
| PIHA | `sd_card` | ✅ działa (2026-08-05 16:27 CEST: `kept 0 managed`) |
| LUSTRO | `sd_card` | ✅ działa (2026-08-06 12:27:49, jw.) |
| SOLARIA | `lte_node` (M1) | wyłączony w całości, brak markera |
| VPS | `lte_node` (M1) | wyłączony w całości, brak markera |

M1 nadal zdjęte do zrobienia na SOLARII i VPS — do tego czasu te nody nie sprzątają
Dockera wcale.

---

## KROK 2 — dlaczego crash-loop watchtowera nie generował akcji

Eventy płynęły poprawnie: `evt-lustro-<ts>-containers_not_running-watchtower.json` co ~60 s,
11 317 plików w `events/lustro/` na VPS (node-agent rsyncuje z `--remove-source-files`,
stąd pusty katalog lokalny). To nie był problem transportu ani emisji.

**Przyczyna:** `supervisor.reconcile()` iteruje wyłącznie po `desired_state["services"]`
ładowanym z `hosts/<node>/services.yaml` (`supervisor.py:380`). `hosts/lustro/services.yaml`
deklaruje `node-agent`, `node-exporter`, `piper-tts` — watchtowera tam nie ma. Brak wpisu
w desired state ⇒ brak driftu ⇒ brak rekomendacji. Ponad 11 tys. eventów dead-enduje.
Observer natomiast **zna** `lustro/watchtower` (incydent `inc-1786007596-lustro-watchtower`,
status `unhealthy`) — rozjazd dotyczy wyłącznie supervisora.

Wykluczone: `shadow_mode` (dotyczy tylko `HA_DIAG_SHADOW_MODE`, ścieżka HA-diag),
`duty_cycle` (tłumi wyłącznie liveness node'a), progi/cooldown (`containers_not_running`
jest w `CONTAINER_RESTART_TRIGGERS`, dedup po stabilnym ID).

Konsekwencja druga: akcja wstawiona ręcznie do `pending/` dla serwisu spoza desired state
żyje jeden cykl supervisora. `_cancel_resolved_pending_actions()` (`supervisor.py:560`)
skasował ją po 15 s z powodem `service_removed_from_desired_state`. Kasowanie dotyczy
**wyłącznie `pending/`** — `approved/` i `running/` są z założenia nietykalne. Dlatego
akcja ręczna dla watchtowera trafiła ostatecznie prosto do `approved/`.

---

## KROK 3 — dwa pełne cykle HITL

Wszystkie znaczniki UTC (CEST = +2). Pętla executora: 10 s. Pętla node-agenta: 60 s.

### Cykl 1 — `node-exporter` (ścieżka w pełni organiczna)

| Etap | Timestamp | Δ |
|---|---|---|
| `docker stop node-exporter` (trigger) | 10:22:49 | — |
| event → observer → incydent `inc-1786011821-lustro-node-exporter` | ~10:23:41 | +52 s |
| supervisor: `Generated recommendation` → `pending/` | 10:24:00.66 | +71 s |
| approval operatora (`mv` → `approved/`) | ~10:38:5x | — |
| executor: `Executing action` → `running/` | 10:39:00.650 | ≤10 s |
| executor: `Dispatched … to node-agent on lustro` | 10:39:00.657 | +7 ms |
| node-agent: rsync-pull + bramki + `docker restart` | 10:39:23.15 | +22,5 s |
| event `action_result` (`success: true`) | 10:39:23.293 | +0,14 s |
| executor: `completed` | 10:39:30.752 | +7,5 s |

**Approval → completed: 30,1 s.**

### Cykl 2 — `pi-watchtower-1` (akcja utworzona ręcznie, zatwierdzona przez operatora)

| Etap | Timestamp | Δ |
|---|---|---|
| operator zapisuje akcję do `approved/` | 11:08:38 | — |
| executor: `Executing action` → `running/` | 11:08:40.829 | +2,8 s |
| executor: `Dispatched … (container=pi-watchtower-1)` | 11:08:40.838 | +9 ms |
| node-agent: `Restarted container 'pi-watchtower-1'` | 11:08:51.002 | +10,2 s |
| event `action_result` (`success: true`) | 11:08:51.002 | — |
| executor: `completed` | 11:09:00.909 | +9,9 s |

**Approval → completed: 20,1 s.** Watchtower wrócił do crash-loopa — zgodnie z założeniem;
sukcesem było przejście pipeline'u i poprawny `action_result`, nie uzdrowienie kontenera.

### Bramki agenta

- **Whitelista typu** i **node scoping** — przeszły; logują się tylko przy odrzuceniu,
  więc dowodem przejścia jest sama egzekucja.
- **Self-restart guard** — nie dotyczył (cel ≠ `node-agent`).
- **Idempotencja** — zadziałała na żywo i wielokrotnie:
  `Action … already processed — skipping (idempotency)`, markery
  `/opt/homelab/state/processed-actions/<action_id>.done`.

### Obserwacja uboczna: regeneracja i auto-cancel

O 10:39:48 (18 s po udanym restarcie) supervisor **wygenerował ponownie** akcję dla
node-exportera, bo world state jeszcze pokazywał `unhealthy` (opóźnienie observera).
O 10:40:49 sam ją skasował (`drift_resolved_auto`). Podwójnego restartu nie było, ale
istnieje ~60-sekundowe okno, w którym po udanej remediacji potrafi powstać duplikat.

---

## KROK 4a — rekomendacja ws. poluzowania bramek HITL

**Rekomendacja: jeszcze nie, ale wąskie poluzowanie jest obronialne po trzech warunkach.**

Za:
- Pipeline przeszedł end-to-end dwukrotnie, w tym raz w pełni organicznie (event →
  observer → supervisor → approval → executor → node-agent → wynik).
- Czas maszynowy to 20–30 s; wąskim gardłem jest wyłącznie człowiek (dziś ~15 i ~30 min).
- `container_restart` jest tanie i odwracalne, wykonanie jest scoped do node'a, whitelisty
  jednego typu akcji i guardu self-restartu; egzekutor nigdy nie wchodzi na node po SSH.
- Kolejka sama się czyści: `drift_resolved_auto` kasuje akcje, które przestały być
  potrzebne, więc opóźniony approval nie powoduje zbędnego restartu.
- Idempotencja obroniła się w warunkach bojowych (patrz defekt dispatch niżej).

Przeciw:
- Próbka: 2 wykonania, 1 node, 1 typ akcji, obie ścieżki udane. **Ani razu nie zaobserwowano
  ścieżki porażki** (`success: false`), timeoutu akcji w `running/`, ani odrzucenia przez
  bramkę node/whitelisty. Dowód dotyczy szczęśliwej ścieżki.
- Restart nie leczy przyczyn źródłowych. Watchtower ma 1000+ restartów dziennie — automat
  restartowałby go w kółko, maskując problem. Bez budżetu restartów (np. max 3/24 h na
  serwis, potem eskalacja do `alert_only`) auto-remediacja produkuje pętlę zamiast naprawy.
- Otwarty defekt dispatch (niżej) w trybie automatycznym oznacza, że jedynym zabezpieczeniem
  przed powtórnym wykonaniem jest marker idempotencji per `action_id`. Wystarczy nowy
  `action_id` na ten sam objaw, by restart poszedł ponownie.
- Okno duplikatu (~60 s) po udanej remediacji — dziś skasowane w porę, ale to kwestia
  wyścigu, nie gwarancji.
- `_get_container_name()` po cichu zwraca nazwę serwisu, gdy brak `services/<svc>/docker-compose.yml`.
  Dla watchtowera dałoby to `watchtower` zamiast `pi-watchtower-1` — akcja wygenerowana
  organicznie zakończyłaby się `failed`. W trybie automatycznym to stały szum porażek.

Warunki wstępne do poluzowania:
1. Naprawa wycieku plików dispatch (niżej) — inaczej automat stoi na jednej bramce.
2. Budżet restartów per serwis + eskalacja do `alert_only` po jego wyczerpaniu.
3. Poluzowanie tylko dla `container_restart` i tylko dla serwisów obecnych w desired state;
   `redeploy` i `disk_cleanup` zostają w pełnym HITL.

---

## KROK 4b — root cause crash-loopa watchtowera

Log kontenera, każde uruchomienie:

```
level=error msg="Error response from daemon: client version 1.25 is too old.
Minimum supported API version is 1.40, please upgrade your client to a newer version"
```

`pi-watchtower-1` (`containrrr/watchtower`, obraz `c352868a1654`, kontener utworzony
2025-04-15) rozmawia z socketem Dockera przez API 1.25. Demon na LUSTRO wymaga minimum
1.40 i odrzuca połączenie, watchtower kończy się `exit 1`, `restart=always` uruchamia go
ponownie — cykl ~60 s. Licznik restartów kasuje się przy nocnym `halt`/boot, stąd
„973 restarty" to dorobek jednego dnia pracy, a nie narastająca awaria.

Co by go naprawiło (do backlogu, **nie wykonane w tej sesji**):
1. `docker pull containrrr/watchtower:latest` + recreate — aktualne wydania negocjują
   nowsze API. Najprostsze.
2. Obejście: `DOCKER_API_VERSION=1.41` w env kontenera.
3. **Preferowane:** usunąć watchtowera z LUSTRO. To relikt spoza GitOps, a automatyczne
   podmienianie obrazów na edge'owym Pi kłóci się z modelem repo jako źródła prawdy.
   Jeśli ma zostać — dopisać go do `hosts/lustro/services.yaml`, bo dopiero wtedy stanie
   się widoczny dla supervisora.

Efekt uboczny do rozważenia niezależnie: watchtower generuje ~1440 eventów/dobę, które
nigdzie nie prowadzą, i jest głównym powodem, dla którego `events/lustro/` ma 11 tys. plików.

---

## Follow-upy

1. **Wyciek plików dispatch (nowy defekt, potwierdzony).** Executor tworzy
   `actions/dispatch/<node>/` z uprawnieniami **755** (`aerbot:aerbot`), a rsync-pull leci
   jako `oskar` (grupa `aerbot`) — brak prawa zapisu w katalogu, więc
   `--remove-source-files` nie kasuje źródła. Dla porównania `dispatch/piha` ma 775.
   Dodatkowo rsync zwraca wtedy kod 23, który node-agent traktuje jako benign
   (`returncode not in (0, 23, 24)`) → **cicha porażka, zero ostrzeżeń**. Skutek: LUSTRO
   re-pulluje te same akcje co 60 s i odbija się od bramki idempotencji — w nieskończoność.
   Docstring `pull_dispatched_actions()` twierdzi, że plik jest kasowany po pobraniu; nie jest.
   Fix: `mkdir(mode=0o775)` w executorze + osobna obsługa rc=23 przy `--remove-source-files`.
   Do czasu naprawy na LUSTRO trwa zombie re-pull dwóch plików co 60 s.
2. `_get_container_name()` — cichy fallback na nazwę serwisu przy braku
   `services/<svc>/docker-compose.yml`; produkuje akcje celujące w nieistniejące kontenery.
3. Okno ~60 s, w którym po udanej remediacji powstaje duplikat akcji (opóźnienie observera).
4. Root cause watchtowera — patrz KROK 4b.
5. Zdjęcie M1 (`NODE_TYPE=lte_node`) na SOLARII i VPS — do tego czasu zero cleanupu Dockera
   na obu nodach.
6. 17 zwietrzałych akcji w `pending/` z czerwca i lipca (16× `alert-*`, `redeploy-vps-gokapi`)
   — nikt ich nie zamyka, zaśmiecają kolejkę operatora.
7. `events/lustro/` — 11 tys. plików, rosnące głównie przez watchtowera.

## Pominięte / niepewne

- Bramki node-scoping i whitelisty typu potwierdzone **tylko pośrednio** (przez udaną
  egzekucję), bez testu negatywnego.
- Ścieżka porażki (`action_result` z `success: false`) oraz timeout akcji w `running/`
  nie zostały przetestowane.
- Gałąź prune obrazów wykonała się na zerze — `0 MB reclaimed` przy 0 dangling images
  przed i po. Potwierdza, że kod się wykonuje, nie że potrafi cokolwiek odzyskać.
- Wycieknięte pliki dispatch na VPS usunięte ręcznie przez operatora na koniec sesji.
  Sam defekt (uprawnienia 755 + połknięty rc=23) pozostaje — wyciek wróci przy następnej
  akcji dispatchowanej na LUSTRO.
- Cykl HITL sprawdzony wyłącznie na LUSTRO. PIHA (jedyny inny node z aktywnym dispatch)
  nie był testowany.

## Sprzątanie

- `prune-canary` — usunięty po weryfikacji (12:29:25).
- `prune-disposable` — usunięty przez sam cleanup, zgodnie z zamysłem testu.
- Obraz `alpine` (ściągnięty na potrzeby kanarków) — usunięty.
- `node-exporter` — działa, podniesiony **przez pipeline HITL**, nie ręcznie.
- `actions/dispatch/lustro/` na VPS — opróżniony przez operatora (zombie re-pull ustał).
- LUSTRO na koniec: `node-agent` (healthy), `node-exporter` (up), `piper-tts` (up),
  `pi-watchtower-1` (restarting — bez zmian, świadomie).

### Narrative

> _user-provided summary_

---

## Session 15:25

Wdrożenie do runtime dwóch fixów zmergowanych na `master` (supervised, checkpointy
zatwierdzane przez operatora): dispatch `0o775` + rc=23 w executorze/node-agencie
(`52eca1c`) oraz zdjęcie mitygacji M1 na SOLARII i VPS (`1bab321`). Domyka follow-upy
#1 i #5 z sesji 13:20.

### Commits

Ta sesja **nie wprowadziła żadnych commitów** poza niniejszym logiem — deploy runtime,
zero zmian w kodzie. Wdrożone commity powstały wcześniej, na branchu
`task/dispatch-perms-m1`:

```
1bab321 revert(m1): zdjecie NODE_TYPE=lte_node na SOLARII i VPS po wdrozeniu R1
52eca1c fix(dispatch): inbox 0o775 + rsync rc=23 przestaje byc cichy
```

W trakcie sesji main checkout przesunął się o `75d9695 docs(recon): przyrostowka IMAP
gmail + fastmail` (druga sesja operatora, docs-only). Bez wpływu: `node_agent.py` ma to
samo `sha256 aec6cb03` w obu drzewach, więc SOLARIA — zdeployowana jeszcze z `1bab321` —
nie rozjechała się z VPS-em deployowanym z `75d9695`.

### Files changed

Brak — drzewo robocze czyste przez całą sesję, poza tym plikiem.

### Deploys

| Node | Serwis | Przed | Po | Wynik |
|---|---|---|---|---|
| SOLARIA | node-agent | `node_agent.py` `fee079e8`, obraz `438111e2` | `aec6cb03` == repo HEAD, obraz `bc28a30a` | OK |
| VPS | node-agent | `node_agent.py` `c21967d3`, obraz `27be875d` | `aec6cb03` == repo HEAD | OK |
| VPS | control-plane | `executor.py` `5ca0490e`, 4 obrazy z 2026-08-05 | `1c3b569f` == repo HEAD, 4 obrazy przebudowane | OK |

Mechanizm: `scripts/deploy/deploy-service.sh --build-if-needed` dla node-agenta (ta sama
ścieżka co 2026-08-05). **Nie** użyto `scripts/deploy/deploy.sh <target>`: jest to
dyspozytor Saturn-side po SSH, deployujący *cały* node — na VPS ruszyłby npm, outline,
joplin i ai-cluster, czyli daleko poza zakres, a sesja toczyła się z SOLARII (`ssh solaria`
to połączenie do samego siebie).

`NODE_TYPE` po zdjęciu M1: SOLARIA `lte_node` → **`ai_node`** (jawnie w override),
VPS `lte_node` → **linia usunięta**, `NODE_TYPE=""` z base compose → `_resolve_node_type()`
zwraca `standard`. Log startowy potwierdza jedno i drugie (`type=ai_node`, `type=standard`),
czyli przewidywanie z commita `1bab321` co do pustego stringa było trafne.

Gate testowy: **pytest niedostępny w main checkoucie** (`.venv` bez pytest,
`~/.local/bin/pytest` ma zepsuty `_pytest`). Oparto się na wyniku sprzed merge'a
(node-agent 70 passed, control-plane 173 passed) plus `docker build` obu stacków przy
deployu. Follow-up 15:25/#4.

### Pierwszy cykl cleanup po zdjęciu M1

Na obu nodach marker `/opt/homelab/state/last-docker-cleanup` **nie istniał** (M1 blokował
zapis od 2026-08-04), więc `_cleanup_rate_ok()` zwrócił `True` i prune poszedł w pierwszym
cyklu, ~0,5 s po starcie — zgodnie z ostrzeżeniem w `1bab321`. Dlatego kolejność w każdym
kroku była: **najpierw tagi rollback, potem deploy.**

SOLARIA:
```
INFO - node-agent starting: node=solaria type=ai_node
INFO - Pruned dangling images (0 MB reclaimed)
INFO - No disposable stopped containers (kept 0 managed)
INFO - Pruned build cache (91 MB reclaimed)
```
VPS:
```
INFO - node-agent starting: node=vps type=standard
INFO - Pruned dangling images (0 MB reclaimed)
INFO - No disposable stopped containers (kept 0 managed)
INFO - Pruned build cache (239 MB reclaimed)
```

**Zero ubytków kontenerów na obu nodach** — `docker ps -a` przed vs po, diff nazw pusty
(SOLARIA 9/9, VPS 24/24). `humanai-mailer` i `humanai-landing` (bez definicji w repo)
nietknięte. Tagi `rollback-*` przeżyły prune.

Dwie prognozy przedwdrożeniowe wymagały korekty — obie z tego samego powodu, że
`docker images` pokazuje **rozmiar pozorny z warstwami współdzielonymi**, a nie realny
odzysk:

* **SOLARIA, „4 dangling ≈ 553 MB":** cztery obrazy faktycznie zniknęły (35 → 32, przy
  +1 nowym buildzie), ale `SpaceReclaimed` = **0 MB**. Ich warstwy są współdzielone z
  control-plane i kb-query. Realny odzysk obrazów ≈ 70 MB (17,89 → 17,82 GB); z build
  cache (606,1 → 510,5 MB) łącznie ≈ 165 MB.
* **VPS, „1 dangling 395 MB":** ten obraz to **żywy `outline-postgres-1`** — untagged, ale
  oznaczony `U` (in use). Docker odmawia usunięcia obrazu używanego przez kontener, więc
  prune go nie ruszył i **nie miał prawa ruszyć**. Realny odzysk to wyłącznie build cache
  239 MB (z 250,8 MB reclaimable).

Kontener `control-plane-ui` na SOLARII stoi w stanie `created` — poza zasięgiem prune'a
podwójnie: `_prune_stopped_containers()` listuje wyłącznie `status=exited`, a kontener ma
i tak label compose oraz `restart=unless-stopped`.

### Weryfikacja fixu dispatch end-to-end

Stan wejściowy zdjęty **przed** deployem control-plane (patrz follow-up 15:25/#1 — inaczej
`deploy-local.sh` by go zatarł):

| ścieżka | mode | |
|---|---|---|
| `actions/dispatch/piha` | 775 | historycznie działał |
| `actions/dispatch/lustro` | **755** | wyciek |
| `actions/deploy` | 755 | inbox deploy-runnera, bez podkatalogów |

**Korekta do sekcji „Sprzątanie" z sesji 13:20.** Zapis „`actions/dispatch/lustro/` na VPS
— opróżniony przez operatora (zombie re-pull ustał)" **nie odzwierciedla stanu
faktycznego**: o 13:16 oba pliki (z 10:39 i 11:08) nadal leżały w źródle, a LUSTRO
re-pullowało je co 60 s aż do 13:18:23. Katalog zdrenował się dopiero w wyniku poniższego
testu — i mógł, bo dopiero wtedy miał prawa `775`.

Mechanizm potwierdzony co do joty: inbox `aerbot:aerbot 755`, a ciągnie z niego
`VPS_EVENTS_USER=oskar` — uid **1002**, tylko *członek* grupy `aerbot` (gid 1000). Grupa ma
`r-x` bez `w`, więc `--remove-source-files` nie może zrobić unlinku:

```
13:15:13 INFO - Action container-restart-lustro-node-exporter already processed — skipping
13:15:13 INFO - Action container-restart-lustro-watchtower already processed — skipping
13:16:16 ... (to samo)   13:17:19 ... (to samo)
```

**Test HITL.** Cel zmieniony z `watchtower` na `node-exporter`: watchtower na LUSTRO jest
w crash-loopie (137 restartów, `restart=always` — root cause opisany w KROKU 4b sesji
13:20), więc nie dałby czystego sygnału. Nowe `action_id`
(`container-restart-lustro-node-exporter-dispatchfix`), bo recykling starego odbiłby się od
bramki idempotencji na LUSTRO i zawiesiłby akcję w `running` do timeoutu.

**Ścieżka: przez `approved/`, nie przez approval operatora.** Plik `pending` zapisany
13:16:56 UTC został auto-anulowany przez supervisora po **7 sekundach**
(`drift_resolved_auto` — `node-exporter` był zdrowy), zanim operator zdążył kliknąć. To
dokładnie zjawisko z sekcji „Obserwacja uboczna: regeneracja i auto-cancel" sesji 13:20,
tym razem szybsze (7 s vs 15 s). Zgodnie z ustaleniem przed testem druga kopia trafiła
prosto do `approved/`; cel testu to mechanika dispatchu, nie ścieżka approvalu. Pole
`status` w tej kopii zostało `cancelled` — bez znaczenia, executor kieruje się katalogiem,
nie polem.

Wynik — wszystkie sześć kryteriów spełnione:

1. **755 → 775** dokładnie w momencie zapisu przez executora (13:17:23) ✅
2. plik akcji **zniknął** ze źródła po pobraniu i **nie wrócił** w kolejnych cyklach ✅
3. **oba zaległe pliki zdrenowane przy okazji** — `dispatch/lustro/` całkowicie pusty ✅
4. spam `already processed — skipping` **ustał**: dwa pełne cykle (13:19:25, 13:20:28) z
   zerem trafień ✅
5. akcja `completed` przez `action_result` po 70 s, `node-exporter` z nowym uptime ✅
6. zero ERROR/WARNING w executorze, observerze, supervisorze i node-agentach — poza znanym,
   niezwiązanym crash-loopem watchtowera na LUSTRO ✅

`13:18:23 INFO - Restarted container 'node-exporter' for action
container-restart-lustro-node-exporter-dispatchfix`

**Czego ten test NIE dowiódł.** Druga połowa fixu — klasyfikacja rc=23 z WARNING-iem — na
LUSTRO nie pojechała: node-agent tam ma nadal `fee079e8` (ten sam sha, który SOLARIA miała
przed dzisiejszym deployem). `grep -c "rc=23"` = 0 w logach LUSTRO dlatego, że stary kod
fizycznie nie umie tego zalogować, a nie dlatego, że jest dobrze. Follow-up 15:25/#3.

### Stan tagów rollback

| Node | Tag | Image ID |
|---|---|---|
| SOLARIA | `node-agent:rollback-pre-dispatchfix` | `438111e2` |
| SOLARIA | `node-agent:rollback-pre-r1` (z 2026-08-05) | `c80a711f` |
| VPS | `node-agent:rollback-pre-dispatchfix` | `27be875d` |
| VPS | `control-plane-executor:rollback-pre-dispatchfix` | `b878d835` |
| VPS | `control-plane-observer:rollback-pre-dispatchfix` | `4b79511d` |
| VPS | `control-plane-supervisor:rollback-pre-dispatchfix` | `357b70d1` |
| VPS | `control-plane-operator-ui:rollback-pre-dispatchfix` | `e522bbaa` |

Pierwsze tagi `rollback-*` na VPS w ogóle. Otagowano wszystkie cztery obrazy control-plane,
nie tylko executora — `deploy-local.sh` przebudowuje cały stack, więc każdy potrzebuje celu
rollbacku.

### Follow-upy (sesja 15:25)

1. **`deploy-local.sh` robi rekurencyjny `chown` + `chmod` na całym `/opt/homelab`** — do
   przeglądu, czy to w ogóle pożądane. Oba branche by dziś zadziałały: `sudo chown -R
   1000:1000` (wyzwalacz: `events/solaria/evt-solaria-1785946768-node_health-node.json`) i
   `sudo chmod -R 775` (wyzwalacze: `actions/dispatch/lustro`, `actions/deploy`). Ten drugi
   ustawiłby `dispatch/lustro` na 775 z zupełnie innego powodu niż fix w executorze,
   zacierając stan wejściowy testu, i nadałby 775 *plikom* w całym drzewie runtime (stąd
   `-rwxrwxr-x` na heartbeatach i JSON-ach akcji). **Świadoma decyzja operatora: nie
   naprawiać ręcznie.** Control-plane zdeployowano samym krokiem compose (`up -d --build
   --force-recreate`) — bez sudo, więc rozjazdy chown/chmod zostały nietknięte i czekają na
   przegląd. Dodatkowo `sudo` na VPS wymaga hasła, więc kanoniczna ścieżka i tak kończyłaby
   się handoffem (exit 5).
2. **Lokalny control-plane na SOLARII** (executor/observer/supervisor/ui, `dispatch/solaria/`
   z 2026-07-22) ma nadal executor z bugiem `0o755`. Nie jest dyspozytorem floty — log to
   same `Starting executor loop` — ale to drugi, niezdeployowany egzemplarz tego samego
   kodu. Osobna sesja.
3. **LUSTRO i PIHA bez dzisiejszego node-agenta.** LUSTRO: `fee079e8`. Bez fixu rc=23
   nadal *połykają* nieudany unlink — dziś to nie boli, bo executor już nie tworzy złych
   inboxów, ale każdy przyszły wyciek o innej przyczynie znowu będzie niewidoczny.
4. **Brak pytest w main checkoucie na SOLARII** — `deploy.sh <target>` przewróciłby się na
   gate (exit 2) bez `--no-gate`. Do naprawy, zanim ktoś sięgnie po kanoniczną ścieżkę
   deployu z tej maszyny.
5. **Duplikat akcji testowej** — `container-restart-lustro-node-exporter-dispatchfix.json`
   leży jednocześnie w `completed/` (właściwy przebieg) i w `cancelled/` (kopia z
   auto-anulowania sprzed approvalu). Pozostawione bez zmian — kosmetyka, żaden zapis
   produkcyjny nie był potrzebny.

### Narrative

> _user-provided summary_