Jobs i Workflows

Rozdzielenie pojęć

Job jest najmniejszą dzierżawioną jednostką dokładnie jednej typowanej operacji: wywołania narzędzia, providera, transformacji, approvala lub walidatora. Workflow jest wersjonowanym grafem zależności, który określa kolejność, równoległość, warunki, checkpointy i kryterium ukończenia całego procesu.

Rozdzielenie pozwala zatrzymać lub powtórzyć pojedynczy krok bez utraty historii. Umożliwia też przypisanie różnych ról: jeden agent planuje, inny tworzy treść, adapter wykonuje, walidator ocenia, a człowiek zatwierdza skutek.

Karta modułu

Pole	Kontrakt
Cel	uczynić pracę trwałą, obserwowalną, wznawialną i rozliczalną.
Wejścia	definicja workflow, parametry run, artifact inputs, policy context, trigger lub intencja.
Wyjścia	stany nodes/jobs, artifacts, receipts, checkpoints, raport końcowy.
Zależności	Broker, Scheduler, registries, Artifact Store, Approval Broker, Audit.
Uprawnienia	workflow nie nadaje capabilities; każdy node jest oceniany osobno.
Autonomia	automatyczna orkiestracja i bezpieczne retry w zatwierdzonych granicach.
Walidacja	schema DAG, brak cykli, kompletne wejścia/wyjścia, terminalne kryterium i polityki wyjątków.
Awaria	checkpoint, pause/cancel, lease recovery i reconciliation per node.

Definicja workflow

Wersjonowana definicja zawiera nazwę domenową i cel; typowane parametry startowe; nodes z dokładnymi kontraktami I/O; edges sukcesu, błędu, warunku i kompensacji; zasady równoległości; budżet czasu, kosztu, energii i providerów; kryteria pause, cancel, retry i escalation; wymagane approvals bez możliwości osłabienia polityki nadrzędnej; definicję raportu końcowego, retencję, testy i fixtures.

flowchart LR
    A["Waliduj dane"] --> B["Zbuduj warianty"]
    B --> C1["Walidator techniczny"]
    B --> C2["Walidator domenowy"]
    C1 --> D{"Oba OK?"}
    C2 --> D
    D -->|tak| E["Preview"]
    D -->|nie| F["Replan / poprawka"]
    F --> B
    E --> G["Review człowieka"]
    G -->|zaakceptuj| H["Osobny job skutku"]
    G -->|popraw| F

Stany i przejścia

Job przechodzi przez stany: created, validated, queued, leased, waiting_approval lub ready, running, a potem succeeded, failed albo uncertain. Długie zadanie może otrzymać pause_requested, zapisać checkpoint i przejść do paused. Anulowanie jest kooperacyjne; nie zakłada cofnięcia skutku. Po wykonaniu treść może oczekiwać na review i odrębną promocję/publikację.

Workflow ma stan własny, wyliczany z nodes, ale nie maskuje szczegółów. Jeden node uncertain może blokować końcowy sukces nawet wtedy, gdy pozostałe dwadzieścia się udało. Każde przejście rejestruje poprzedni i nowy stan, aktora, powód, czas oraz integralność.

Leasing i konkurencja

Worker zdobywa lease atomowo z owner ID, losowym tokenem i expiry. Heartbeat przedłuża ważność, ale tylko dla tego samego attempt. Dwa procesy nie mogą wygrać tego samego lease. Stary token po restartcie jest odrzucany. Scheduler może rezerwować zasoby, lecz rezerwacja nie pozwala wykonać joba bez capability i grantu.

Kolejki są co najmniej per priorytet, projekt i klasa zasobu. Fairness zapobiega zagłodzeniu małych zadań przez długie renderowanie. Zadania alarmowe mogą preemptować zasób, jeśli adapter wspiera bezpieczny checkpoint; nie zabijają procesu w sposób pozostawiający nieznany efekt.

Checkpoint i wznowienie

Checkpoint jest artefaktem, nie flagą w pamięci procesu. Zawiera stan algorytmu lub aplikacji, wersję adaptera, input hashes, postęp i metodę weryfikacji. Wznowienie tworzy nowy attempt związany z tym checkpointem. Jeśli wersja aplikacji lub wejście się zmieniło, checkpoint jest odrzucany albo migrowany przez jawne narzędzie.

Przykładowe workflow

Raport zarządczy: import danych → walidacja kompletności → obliczenia deterministyczne → analiza odchyleń przez model → kontrola źródeł → generacja dokumentu → review. Model nie wylicza kwot, które można obliczyć kodem; interpretuje wynik sprawdzonej transformacji.

Materiał wideo: brief → lista ujęć → ingest mediów → proxy → montaż candidate → audio → color → render preview → techniczny QC → review → render master → draft publikacji. Każdy artefakt ma lineage, a publikacja pozostaje oddzielna.

Incydent IT: alert → deduplikacja → logi read-only → hipotezy → bezpieczne testy → candidate config → test w izolacji → approval maintenance → wdrożenie → health checks → obserwacja → zamknięcie. Brak poprawy prowadzi do wcześniej zdefiniowanego rollbacku lub ręcznego recovery.

Przykładowe polecenia

• „Zatrzymaj render po bieżącej klatce i wznów jutro po 22:00.”
• „Pokaż, które kroki raportu blokuje brak danych i kto jest właścicielem wejścia.”
• „Powtórz tylko walidację techniczną, bez ponownego generowania pliku.”
• „Anuluj wysyłkę, zachowaj draft i wszystkie załączniki.”

Walidacja

Przed aktywacją workflow przechodzi test schema, test braku cykli, test wszystkich portów I/O, symulację ścieżek błędów, limity równoległości i kontrolę nieosiągalnych nodes. Wykonanie jest poprawne dopiero, gdy wymagane nodes terminalne są sukcesem, artefakty przechodzą swoje walidatory, a skutki mają receipty. Raport wskazuje także kroki pominięte i powód.

Błędy, ryzyka i awaria

Ryzykiem jest workflow zbyt ogólny, który przenosi dowolność do promptu, oraz workflow zbyt sztywny, który nie radzi sobie z brakiem danych. Rozwiązaniem są typowane porty i jawne gałęzie replanowania. Drugie ryzyko to lawina triggerów; Gateway stosuje deduplikację, rate limit i correlation key. Trzecie to retry operacji zewnętrznej; idempotency jest właściwością adaptera.

Po awarii broker odtwarza graf i terminalne stany z trwałej bazy. Wygasłe leases są rekoncyliowane. Nodes czysto obliczeniowe mogą wrócić do kolejki, a niepewne skutki zewnętrzne wymagają sprawdzenia. Workflow kończy się jako recovery_required, jeżeli nie można dowieść stanu krytycznego węzła.