Wdrozenie do runtime dwoch zmergowanych commitow (52eca1c, 1bab321), zero zmian
w kodzie. Deploy przez deploy-service.sh --build-if-needed, nie przez
deploy.sh <target>: ten drugi to dyspozytor Saturn-side po SSH deployujacy caly
node (na VPS ruszylby npm/outline/joplin/ai-cluster), a sesja toczyla sie z
SOLARII, gdzie `ssh solaria` to polaczenie do samego siebie.
Pierwszy cykl prune po zdjeciu M1 poszedl zgodnie z ostrzezeniem z 1bab321 —
markera last-docker-cleanup nie bylo na zadnym z nodow, wiec cleanup odpalil
~0,5 s po starcie. Zero ubytkow kontenerow (SOLARIA 9/9, VPS 24/24), humanai-*
nietkniete. Dwie prognozy wymagaly korekty, obie bo `docker images` pokazuje
rozmiar pozorny z warstwami wspoldzielonymi: na SOLARII 4 dangling zniknely, ale
SpaceReclaimed=0 (warstwy dzielone z control-plane i kb-query), a na VPS jedyny
dangling okazal sie zywym obrazem outline-postgres-1 (flaga U) i prune go nie
ruszyl — slusznie.
Test dispatch end-to-end: wszystkie 6 kryteriow spelnione. dispatch/lustro
755 -> 775 w momencie zapisu przez executora, plik akcji zniknal ze zrodla i nie
wrocil, oba zalegle pliki z 10:39 i 11:08 zdrenowaly sie przy okazji, a spam
"already processed — skipping" co 60 s ustal. Poszlo przez approved/, nie przez
approval operatora: supervisor auto-anulowal pending po 7 s jako
drift_resolved_auto, zanim operator zdazyl kliknac.
Klasyfikacja rc=23 pozostaje niezweryfikowana na zywo — LUSTRO ma nadal stary
node-agent (fee079e8), ktory fizycznie nie umie tego zalogowac (follow-up #3).
Refs docs/sessions/2026-08-06.md (follow-up #1, #5)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8031396f04