Przejdź do treści

Control Center

Cel

Control Center jest lekką, responsywną aplikacją webową/PWA do rozmowy, obserwowania pracy, przeglądania dowodów i podejmowania decyzji. Nie jest wizualnym terminalem ani jedną ścianą metryk. Każdy widok odpowiada konkretnemu obiektowi domenowemu i pokazuje stan z brokera.

Interfejs ma działać na dużym monitorze i telefonie, z klawiaturą, czytnikiem ekranu oraz słabym łączem. Operacje konsekwencyjne są odróżnione od odczytu kolorem, językiem i wymaganym potwierdzeniem. UI nie przechowuje reusable approval credential i nie może wyprodukować grantu.

Karta modułu

Pole Kontrakt
Odpowiedzialności prezentacja stanu, wyszukiwanie, filtrowanie, input intencji, review, bezpieczne przekazanie do Approval Center.
Wejścia zsanityzowane read models, role użytkownika, project scope, stream zdarzeń, artifact previews.
Wyjścia intent/proposal request, filtry, komentarze review, nawigacja do approvala; brak bezpośredniego execution.
Zależności Control Plane API, uwierzytelnienie, Artifact preview, lokalny operator channel.
Uprawnienia widoki per rola/projekt; consequential action tworzy request, nie wykonuje skutku w UI.
Autonomia UI może grupować i priorytetyzować; nie ukrywa krytycznego ryzyka ani security-relevant content.
Walidacja accessibility, responsive, stale-state detection, role isolation, CSRF/replay, complete approval disclosure.
Awaria read-only offline snapshot z wyraźnym czasem; blokada nowych decyzji, gdy stan nie jest świeży.

Nawigacja docelowa

Widok Główna odpowiedź
Chat czego potrzebuje użytkownik i co Norbi proponuje?
Jobs co jest wykonywane, zablokowane lub niepewne?
Projects jaka jest granica danych, uczestników i celu?
Sites jakie witryny/aplikacje mają candidate, preview i deployment?
Workflows jaki graf procesu działa i gdzie się zatrzymał?
Agents które role i wersje są aktywne, shadow lub zawieszone?
Tools jakie efekty potrafi wykonać system i na jakich zasadach?
Plugins z jakich pakietów pochodzą narzędzia i jaki mają supply chain?
Providers jakie modele/usługi są dostępne i dla jakich danych?
Models profile, benchmarki, sprzęt, wersje i stan routingu
Approvals jaka dokładnie decyzja należy do człowieka?
Artifacts jakie wejścia/wyniki istnieją, w jakiej wersji i na jakim etapie?
Memory jakie rekordy kontekstu mogą wpływać na zadania i skąd pochodzą?
Resources CPU/GPU/RAM/storage/licencje, kolejki i rezerwacje
Accounts metadane kont, zgody i zakresy — bez sekretów
Executions poszczególne attempts, tool calls i receipty
Workers urządzenia wykonawcze, enrollment, health i drain
Automations aktywne triggery, limity i ostatnie zdarzenia
Channels telefon, e-mail, komunikatory i route conversation/project
Audit Log niezmienny ciąg decyzji i skutków

Wzorzec strony obiektu

Każdy obiekt ma nagłówek z ID, stanem, projektem, właścicielem, wersją i ostatnią zmianą. Dalej występują zakładki: Overview, Timeline, Inputs/Outputs, Policy, Evidence, Related. Akcje dostępne dla roli są jawne; brak akcji nie jest zastępowany ukrytym menu. Hash i pełny JSON są dostępne ekspertowi, ale zwykły użytkownik widzi także opis skutku prostym językiem.

Approvals

Karta approvala pokazuje:

  • etap: wykonanie, wysłanie, publikacja, aktywacja, instalacja, promocja czy odzyskiwanie;
  • aktora i narzędzie z wersją;
  • dokładne dane wejściowe, changed paths, artifact hashes;
  • konto, odbiorcę/destination i klasyfikację;
  • przewidywane skutki, odwracalność, koszt i czas;
  • wyniki testów, ostrzeżenia i plan awaryjny;
  • expiry i informację, że zmiana danych unieważni decyzję.

Przycisk zatwierdzenia nie uruchamia adaptera w żądaniu HTTP. Przekazuje decyzję do izolowanego kanału operatora, po czym UI obserwuje nowy stan. Wielokrotne kliknięcie nie może wykonać efektu ponownie.

Mobile-first

Na telefonie dolna nawigacja obejmuje Home, Chat, Jobs, Approvals i More. Home pokazuje tylko rzeczy wymagające uwagi, status instalacji oraz najważniejsze wyniki. Tabele stają się kartami z najważniejszymi polami. Pełne security disclosure approvala pozostaje dostępne bez ucinania, nawet jeśli wymaga przewinięcia. Gest nie zastępuje krytycznego potwierdzenia.

Przykładowe polecenia

  • „Pokaż tylko jobs z niepewnym skutkiem z ostatnich 24 godzin.”
  • „Porównaj dwa artefakty i przejdź do pierwszej różnicy.”
  • „Wyjaśnij prostym językiem, dlaczego ten approval jest wymagany.”
  • „Przełącz worker renderujący w draining po zakończeniu aktualnego joba.”

Pełny przebieg

Użytkownik wpisuje w Chat prośbę o przygotowanie i wysłanie oferty. Norbi pokazuje plan z dwoma etapami: utworzenie candidate i osobne wysłanie. Po generacji karta Artifact zawiera preview, walidację sum i źródła danych. Użytkownik akceptuje treść, ale system nie wysyła. Powstaje ApprovalRequest dla konkretnego konta, odbiorcy, tematu, body i załącznika. Po decyzji job przechodzi przez Execution, a UI pokazuje receipt platformy. Jeśli odpowiedź jest niejednoznaczna, status to uncertain i pojawia się zadanie reconciliation.

Walidacja i awaria

Testy obejmują role, projekty, klawiaturę, focus, czytnik ekranu, kontrast, 320 px, slow network, odświeżenie na approvalu, dwa równoległe okna, stale state i utratę sesji. Krytyczne dane nie są ucinane ellipsis bez możliwości rozwinięcia.

Przy utracie połączenia UI pokazuje timestamp ostatniego snapshotu i przechodzi read-only. Draft użytkownika może zostać lokalnie zachowany, ale approval i consequential requests są blokowane. Po odzyskaniu połączenia stan jest pobierany od nowa; UI nie odtwarza automatycznie kliknięć.