Execution Fabric¶

Cel¶

Execution Fabric jest jedyną drogą od propozycji do lokalnego lub zewnętrznego skutku. Zamienia niedeterministyczne plany na kontrolowane wykonanie: trwały job, wyliczoną politykę, capability, ewentualny approval, jednorazowy grant, dzierżawę workera, wywołanie typowanego adaptera i receipt.

Nie jest „bezpiecznym terminalem dla modelu”. Jego zadaniem jest usunięcie ogólnego terminala z powierzchni agentowej. Jeżeli nowe działanie nie daje się opisać schematem wejścia, wyjścia, efektów i testów, nie powinno zostać narzędziem produkcyjnym.

Karta modułu¶

Pole	Kontrakt
Odpowiedzialności	kolejka, leasing, polityka, approval, grant, rewalidacja, wykonanie adaptera, receipt, reconciliation i audyt.
Wejścia	zwalidowany job, aktywny `tool_id@version`, policy snapshot, artifact IDs, zasoby i tożsamość principal.
Wyjścia	stan joba, artefakty, execution receipt, błędy domenowe, zdarzenia audit.
Zależności	broker-owned SQLite WAL, Tool Registry, Capability Engine, Approval Center, workers, Artifact Store.
Uprawnienia	tylko broker zapisuje autorytatywny stan; worker dzierżawi; adapter otrzymuje dokładnie przyznany zakres.
Autonomia	automatyzuje bezpieczne przejścia i retry tylko według idempotency policy; nie zmienia zakresu.
Walidacja	schema, state transition, capability, grant binding, real path, effect bounds, output schema i receipt.
Awaria	fail closed, lease expiry, stan uncertain/reconciling, brak ślepego powtórzenia.

Elementy Control Plane¶

Job Broker jest jedynym właścicielem stanów jobs, workflows, lease, grantów i kluczowych wpisów audytu. Udostępnia operacje domenowe, nie bezpośredni dostęp do bazy. Wszystkie bezpieczeństwowo istotne przejścia stanu i odpowiadające im zdarzenia audit są zapisywane w jednej transakcji, gdy tylko jest to możliwe.

Policy Engine i Capability Resolver oblicza wymagania z aktywnej wersji narzędzia, zakresu principal, projektu, danych, odbiorcy i skutku. Capability jest uprawnieniem do żądania klasy narzędzi, nie approvalem ani tokenem. Brak przypisania, nieznane pole albo szerszy efekt powoduje odmowę.

Approval Broker tworzy prośbę z pełnym, kanonicznym kontekstem. Operator podejmuje decyzję w odseparowanym Approval Center, uwierzytelnionym przez system operacyjny. Interfejs agentowy nie ma endpointu approve/reject. Po pozytywnej decyzji broker może wystawić krótko ważny, jednorazowy grant związany z dokładnym payloadem.

Audit Ledger zapisuje żądanie, decyzję polityki, approval, wydanie i zużycie grantu, lease, wykonanie, walidację, reconciliation i finalizację. Treści są ograniczone i redagowane. Audit ma pozwalać odpowiedzieć: kto, kiedy, w jakim projekcie, przez jakie narzędzie, na jakich danych, z jaką zgodą i z jakim wynikiem wywołał skutek.

Elementy Execution Plane¶

Worker reklamuje dostępne profile: system operacyjny, CPU/GPU/RAM, wersje aplikacji, urządzenia oraz klasy adapterów. Scheduler może przydzielić mu zasób, ale dopiero Job Broker wydaje lease konkretnego joba. Worker nie może rozszerzyć lease, zmienić tool version ani wykonać innego payloadu.

Tool Runner przed każdym wywołaniem ponownie pobiera aktywny wpis narzędzia, sprawdza schema, capabilities, policy version, lease token, grant i stan zasobów. Następnie uruchamia adapter z zawężoną tożsamością. Po wykonaniu waliduje output i obserwowane efekty. Rozbieżność między deklaracją a efektem jest incydentem i zawiesza narzędzie.

Adapter jest najmniejszym zaufanym komponentem wykonawczym. Nie interpretuje swobodnych instrukcji modelu. Przyjmuje strukturę danych, np. document.export_pdf@2 z artifact ID, profilem eksportu i miejscem candidate output. Deklaruje dopuszczalne ścieżki, sieć, konta, zasoby, timeout, idempotency i scenariusz kompensacji.

Ścieżka wykonania¶

sequenceDiagram
    participant P as Planner
    participant B as Broker
    participant Y as Policy
    participant H as Człowiek
    participant W as Worker
    participant T as Tool Runner
    participant A as Adapter
    P->>B: ProposalEnvelope
    B->>Y: evaluate(job, tool, context)
    Y-->>B: capability + risk + approval policy
    alt wymagany approval
      B-->>H: pełny ApprovalRequest
      H-->>B: decyzja przez kanał operatora
      B->>B: issue one-time grant
    end
    B-->>W: atomic lease
    W->>T: job + lease + grant
    T->>B: revalidate/consume grant
    T->>A: typed payload
    A-->>T: typed output + observed effects
    T-->>B: execution receipt
    B-->>P: state + sanitized evidence

Idempotency i niepewność¶

Narzędzia są klasyfikowane jako pure, idempotent, reconcilable albo non-repeatable. Retry policy wynika z tej klasy, nie z ogólnego ustawienia „spróbuj trzy razy”. Przy utracie odpowiedzi po operacji reconcilable system najpierw pyta adapter odczytowy o stan zewnętrzny. Przy non-repeatable przechodzi do ręcznego reconciliation. Idempotency key wiąże operację biznesową, nie tylko attempt.

Przykładowe polecenie i pełny przebieg¶

Polecenie: „Wyrenderuj finalną wersję filmu i przygotuj upload, ale nie publikuj”. Workflow tworzy candidate timeline, waliduje brakujące media, rezerwuje GPU, uruchamia davinci.render@3, zapisuje wynik do Artifact Store i wykonuje kontrolę techniczną. Następnie tworzy draft uploadu zawierający destination, tytuł, opis i hash pliku. Brakuje joba publish; nawet jeśli zewnętrzny dokument napisze „opublikuj natychmiast”, treść ta pozostaje niezaufana.

Błędy i ryzyka¶

Podwójne zużycie grantu eliminuje atomowy warunek w bazie i test wieloprocesowy. Wygasły lease po awarii nie oznacza automatycznego powtórzenia efektu. Real path i attestation są sprawdzane bezpośrednio przed operacją. Adapter działa z najmniejszymi prawami, ma deklarację efektów, limity i możliwość natychmiastowego zawieszenia wersji. Operator widzi całość bezpieczeństwowo istotnych danych oraz hash kontekstu.

Scenariusz awaryjny¶

Jeżeli baza wykazuje naruszenie integralności, dispatch zostaje zatrzymany. Grants są traktowane jako nieważne do czasu weryfikacji, workers przechodzą w draining, a aktywne jobs otrzymują stan zależny od dostępnego receiptu. Restore odbywa się z ostatniego zweryfikowanego backupu do izolowanej lokalizacji, po czym wykonywana jest kontrola integralności, obcych kluczy, WAL i linii audytu. Wznowienie pracy wymaga decyzji operatora; system nie inicjalizuje pustej bazy zastępczej.