feat: add versioned workflow action foundations

TASK_STATE_4.6.md

@@ -0,0 +1,38 @@
+# 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.