Przebiegi przekrojowe

1. Od rozmowy do zadania i follow-up

Cel: zamienić rozmowę z klientem w notatkę, decyzje, tasks i draft wiadomości bez fałszywych zobowiązań.

sequenceDiagram
    participant C as Rozmowa
    participant V as Voice/ASR
    participant A as Analiza
    participant H as Człowiek
    participant T as Task system
    participant M as Kanał
    C->>V: audio + consent
    V->>A: transcript + confidence
    A->>H: candidate summary/tasks
    H->>T: approval exact tasks
    A->>H: draft follow-up
    H->>M: separate send approval

Wejściem jest audio artifact, consent i kontekst kontaktu. ASR oznacza niepewne nazwy, kwoty i daty. Ekstraktor wiąże każde zadanie z timestampem. Jeśli rozmówca powiedział „ktoś to wyśle”, owner pozostaje nieustalony. Po korekcie człowiek zapisuje tasks. Wiadomość jest odrębnym draftem; approval tasków nie wysyła jej. Walidacja sprawdza source linking, kompletność i destination. Przy awarii audio zachowuje status zgodnie z retencją, a wynik jest częściowy.

2. Od incydentu kamery do reakcji

Cel: ograniczyć false alarm i dostarczyć operatorowi zweryfikowany kontekst.

Kamera tworzy detections, Sensor Gateway dodaje drzwi/kontrolę dostępu, correlator deduplikuje je do incydentu. Vision wybiera reprezentatywny klip z maską prywatności. Reguły wyliczają severity na podstawie strefy i harmonogramu. Dla wysokiego severity Norbi uruchamia zatwierdzoną drabinę telefoniczną. Operator potwierdza albo zamyka alarm. Fizyczne działanie ma osobny interlock i capability. Brak streamu generuje camera_offline, nie spokojny status. Walidacja porównuje model z per-camera benchmarkiem i mierzy false alarms na godzinę.

3. Od briefu do opublikowanego materiału

Cel: zachować prawa, wersje i rozdzielić twórczość od publikacji.

Brief i brand kit są artifact inputs. Rights checker weryfikuje licencje i zgody. Creative Agent tworzy koncepcje; wybrana staje się candidate project w Adobe/DaVinci/Blender. Preview render ma watermark i techniczny QC. Człowiek reviewuje. Master render używa exact project hash. Approval treści zmienia stage na approved. Osobny publication workflow wiąże channel account, destination, caption, timing i exact master. Platform receipt ustala published. Jeśli upload się przerwie, reconciliation sprawdza platform asset ID, aby nie opublikować duplikatu.

4. Od issue do promocji kodu

Cel: naprawić problem bez agentowego zapisu main.

Repository Guard attests base i tworzy worktree. Agent reprodukuje błąd, stosuje typed patch i uruchamia testy. Candidate commit oraz evidence są zamrażane. Review ocenia diff i ryzyko. Promotion approval wiąże expected main, candidate, base, diff hash i testy. Dedykowany promotion tool ponownie sprawdza stan i wykonuje jedyną dozwoloną mutację. Push/tag/deploy nie wynikają z promocji. Gdy main zmienił się po review, candidate ma stan stale i wymaga ponownej integracji/testów.

5. Od urlopu do opublikowanego grafiku

Cel: obsłużyć nieobecność bez ujawniania przyczyny i naruszeń prawa pracy.

Pracownik składa request w PWA. HR record przechowuje pełny typ, a scheduling projection tylko availability. Solver generuje warianty i sprawdza pokrycie, umowy, odpoczynek i kwalifikacje. Kierownik decyduje o wniosku; wybrany change set przechodzi walidację współbieżnych zmian. Publish adapter zapisuje grafik. Notification workflow informuje dotknięte osoby i zbiera potwierdzenia. Brak potwierdzenia uruchamia eskalację. Ostatni opublikowany grafik pozostaje source of truth przy awarii.

6. Od awarii do zdalnego recovery

Cel: przywrócić system najmniej destrukcyjną metodą.

Monitoring wykrywa brak heartbeat i potwierdza go przez Management Node, UPS i KVM. Control Plane, jeśli żyje, pause dispatch i revoke grants. Operator przegląda evidence i wybiera runbook. Kolejność: graceful recovery, WoL dla wyłączonego hosta, KVM diagnosis, krótki ATX, długi reset, smart plug jako ostatnia linia. Po boot wykonywane są integrity checks, restore test i reconciliation jobs. Dispatch wraca przez read-only/canary. Agent może przygotować instrukcję, ale nie zatwierdza własnego power-cycle.

7. Od faktury do płatności

Cel: oddzielić ekstrakcję i uzgodnienie od nieodwracalnego skutku finansowego.

Faktura z kanału trafia do Artifact Store, jest skanowana i klasyfikowana. Parser wydobywa dane z confidence; kod sprawdza sumy. System porównuje kontrahenta, zamówienie i historię duplikatów. Candidate accounting record może być automatyczny w dojrzałej klasie. Payment proposal zawiera beneficiary identity, rachunek ze źródłem, amount, currency, invoice IDs i due date. Człowiek zatwierdza exact payload w niezależnym kanale. Po przerwaniu nie ma retry: bank reconciliation sprawdza transaction ID/status.

8. Od pomysłu do nowego agenta

Cel: rozszerzać system bez samonadania władzy.

Norbi wykrywa powtarzalny proces i proponuje spec roli. Agent Factory tworzy candidate manifest, workflow, test set i adversarial cases. Ewaluacja mierzy jakość oraz odmowy. Shadow otrzymuje rzeczywiste intencje bez skutków. Review pokazuje capabilities diff i known failures. Oddzielny governance approval aktywuje wersję dla wąskiej grupy. Rollout ma circuit breaker. Sam agent nie ma activate_agent ani możliwości modyfikacji policy.

Wspólne kryterium sukcesu

Każdy przebieg kończy się dopiero, gdy rezultat, walidacja i rzeczywisty skutek są spójne. Raport ma odpowiedzieć: co było celem; jakie dane użyto; co wykonano; czego nie wykonano; jakie approvals obowiązywały; jakie warnings pozostały; gdzie jest artifact/receipt; co zrobić, jeśli wynik jest błędny.