docs: plan phase D (migrations, Docker cleanup, cron, editable blocks) and rewrite TASK_STATE

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/IMPLEMENTATION.md

@@ -94,15 +94,26 @@ Etapy 4-7 powstawały równolegle w kilku sesjach (Codex, Gemini) bez koordynacj
 - **Modyfikacja przebiegu = nowa wersja na kolejny run.** Trwający run kończy się na swojej wersji (zgodne z niemutowalnością wersji i replayem — patrz Etap 1-2).
 - **BPMN**: ocena gotowej biblioteki BPMN zamiast własnego silnika grafu odbędzie się dopiero po zakończeniu Etapu 8. Do tego czasu zostaje obecny graf (`WorkflowDocumentV2` + Cytoscape).
 
-### Luki między wizją a stanem etapów 4-7 (zakres na Fazę C)
+### Luki między wizją a stanem etapów 4-7 (Faza C) — stan 2026-09-23
 
-Poniższe punkty wizji nie są jeszcze zrealizowane w kodzie:
-
-1. **Przepływ per aplikacja**: `app_config` nie wskazuje na konkretny workflow; istnieje jeden wspólny `COMPONENT_UPDATE_WORKFLOW_DOCUMENT_V2`. Generowanie przepływu przez Claude (szkic → walidacja → publikacja przez właściciela) nie istnieje.
-2. **Start, cancel i resume runu z API/UI**: HTTP API ma tylko `decisions` na istniejącej instancji; nic poza testami nie tworzy nowych instancji, nie ma endpointu do anulowania ani wznawiania z poziomu UI.
-3. **Podgląd na żywo**: oś czasu (`instance-timeline.tsx`) pokazuje bieżący węzeł jako tekst z ledgera, ale bez podświetlenia w grafie i bez odświeżania przez SSE (istniejący `change-hub.ts`/SSE serwuje inne części appki, nie jest jeszcze podpięty pod instancje workflow).
-4. **Ogólny węzeł „agent”**: model działa dziś tylko jako zamknięte akcje `model.repair`/`model.postUpgrade` w łańcuchu aktualizacji. Nie ma generycznego węzła workflow z profilem modelu, promptem i wynikiem `{event, summary, data}`, który dałoby się wpiąć w dowolne miejsce dowolnego przepływu.
+1. **Przepływ per aplikacja**: zrobione jako kopia szablonu (`update-<app>`, seed); nieedytowane przepływy idą za zmianami szablonu (historia skrótów szablonu). Generowanie przez Claude — nie ma.
+2. **Start, cancel, resume z API/UI**: zrobione (shadow/real, cancel, retry po restarcie).
+3. **Podgląd na żywo**: zrobione (graf instancji wycentrowany na bieżącym kroku, SSE).
+4. **Ogólny węzeł „agent”**: nie ma.
 
 ### Faza B — domknięcie poprawności łańcucha aktualizacji (zakończona 2026-09-22)
 
 Zamknęła 5 braków z Fazy A: STOP `forbidden_change` na `unexpected_change` w `apply_dry_run`/`apply`; prawdziwy retry/healthcheck w `verify` (reużywa `domain/verify.ts`); Codex MCP (`src/main/codex-mcp-stdio.ts`); fail-closed `maxCostUsd` w `model-dispatcher.ts`; test HTTP dla `.../decisions`. Deny-lista kroku `migrate`/`repair` nie wymagała zmiany kodu — dziedziczy ochronę z `app/executor/agent.ts` (nietkniętego przez etapy 4-7). Pełny opis w `TASK_STATE.md`; commity `b02f1aa..88790bc`.
+
+### Faza D — plan (zatwierdzony przez właściciela 2026-09-23)
+
+Decyzje: model sam wykrywa migracje w release notes i przygotowuje plan (compose, kroki, potrzebne dane); właściciel zatwierdza na bramce i podaje dane w dynamicznym formularzu (sekrety poza ledgerem); zatwierdzony diff compose wchodzi bez deny-listy (nigdy `homelab-upgrade`). Każdy workflow może mieć cron. Brak listy aplikacji pod absolutnym STOP (decydują `enabled`/`apply`).
+
+- **A** rollback na bramce po kontroli modelu; czytelne bloczki w grafie (ludzka nazwa, rodzaj, opis, `resolve_*` przy bramce).
+- **B** migracje: operacja `migration_plan` (opus, sesja `observe`, schemat `MigrationPlan`), bramka `gate_migration` z formularzem `inputs` (wartości w tabeli `workflow_run_inputs`, kasowane po użyciu), akcja `docker.migrate@1` w executorze (placeholdery `<secret:>`/`<input:>`, `.env` 0600, `compose config -q`), `post_upgrade` wykonuje `stepsAfter`.
+- **C** czyszczenie Dockera: akcje `docker.diskUsage@1`, `docker.imagePrune@2` (unused/until, build cache, nigdy wolumeny), `decisionContext` dla `destructive` z runnera, przepływy systemowe (bez aplikacji) startowane z UI, przepływ `docker-cleanup` zakładany przez UI (funkcja `assess_cleanup`, próg 10 GB).
+- **D** cron per workflow (tabela `workflow_schedules`, parser w `domain/cron.ts`, driver co minutę, te same blokady co ręczny start); rozłożenie aktualizacji w tygodniu; `docker-cleanup` `0 6,18 * * *` czyści sam przy < 10 GB.
+- **E** edytor: formularze per rodzaj węzła zamiast surowego JSON, opis tego, co blok wykona, skąd bierze dane i dokąd prowadzą zdarzenia; dodawanie/usuwanie węzłów.
+
+Kolejność: A → B → C → D → wdrożenie → `docker-cleanup` przez UI z cronem → E → test migracji na żywo (influx 1.8 → 1.11; migracja 2.x tylko na wyraźne polecenie właściciela, z kopią `/srv/appdata/grafana`).
+