homelab-upgrade/TASK_STATE_4.6.md

Task state — etap 4.6

Cel

Odwzorować istniejący łańcuch aktualizacji aplikacji jako wersjonowany workflow v2, zachowując wszystkie obecne bramki, kopie, verify, STOP i ścieżki naprawcze. To jest proponowana nazwa podetapu 4.6: docs/IMPLEMENTATION.md opisuje etap 4, ale nie numeruje jeszcze jego podetapów.

Kontekst i decyzje

• Etapy 1–3 są zakończone; etap 4 ma już zamknięty rejestr akcji uprzywilejowanych, politykę, ledger, dispatcher oraz nieaktywną domyślnie akcję docker.imagePrune.
• docker.imagePrune nie należy do domyślnego workflow aktualizacji i nie może zostać do niego dodany w tym etapie.
• Nowy workflow pozostaje niepodłączony do produkcyjnego drivera, loopa claimów, harmonogramu, HTTP i UI. Nie uruchamiamy VM103 ani prawdziwych poleceń Dockera.
• Istniejący łańcuch aktualizacji pozostaje źródłem zachowania do portu; nie refaktorujemy go przy pierwszym odwzorowaniu.

Plan

1. Najpierw sporządzić krótką, testowalną tabelę odwzorowania obecnego łańcucha: źródłowy handler/krok, jego wejście i wynik, bramka/STOP, następny krok oraz odpowiednik node'a workflow. Czytać wyłącznie pliki obecnego łańcucha, definicje StepName, istniejące node'y v2 i rozszerzenie privilegedAction.
2. Zaprojektować minimalny, wersjonowany dokument workflow dla pojedynczego składnika aplikacji. Musi obejmować przynajmniej: obserwację/status, wybór obrazu, ocenę ryzyka i STOP, sprawdzenie kopii, backup, apply dry-run, apply, verify oraz jawne przejścia do STOP/repair/rollback zgodne z obecnym zachowaniem.
3. Utrwalić dokumenty i ich zależności jako normalne wersje katalogu workflow, z pełnym snapshotem instancji. Wszystkie akcje wymagające uprawnień przechodzą przez privilegedAction i politykę; nie dodawać pola na dowolną komendę, shell ani argumenty Docker.
4. Dodać wyłącznie deterministyczne testy: publikacja/utworzenie instancji, ścieżka sukcesu, każda bramka STOP, verify → repair, nieudany drugi verify → STOP oraz zapis właściwych attemptów i eventów. Użyć fejków executora/modelu/registry; nie wywoływać prawdziwego Dockera.
5. Dopiero po odebraniu statycznego odwzorowania rozważyć osobny podetap podłączenia workflow do claim loopa. Nie łączyć tego z 4.6.

Kryteria odbioru

• Każde przejście istniejącego łańcucha ma jednoznaczny odpowiednik w opublikowanym workflow i testach.
• Snapshot zachowuje dokładne wersje workflow, funkcji i polityki, a replay odtwarza tę samą pozycję oraz historię attemptów.
• STOP, backup i verify nie są omijane; imagePrune pozostaje nieosiągalny z domyślnego workflow.
• Produkcyjny driver i harmonogram zachowują dotychczasowe zachowanie.
• npm run check przechodzi.

Ukończono

• Odczytano implementację aktywnego łańcucha kroków, StepName, kontrakty workflow v2 oraz rozszerzenie privilegedAction.
• Zapisano testowalną tabelę odwzorowania i nierozstrzygnięte różnice semantyczne w docs/WORKFLOW-UPDATE-MAPPING.md.
• Nie utworzono node'ów workflow i nie zmieniono migracji.

Następny dokładny krok

Na podstawie docs/WORKFLOW-UPDATE-MAPPING.md zaprojektować minimalny, wersjonowany dokument workflow v2 dla pojedynczego składnika i zapisać go wyłącznie jako dokument projektowy. Musi obejmować status, wybór obrazu, ocenę ryzyka z STOP, backup check, backup, apply dry-run, apply, verify oraz jawne przejścia do STOP/repair/rollback; nie tworzyć jeszcze kodu node'ów, migracji ani połączenia z driverem.