Pierwsze formalne utrwalenie wymagañ zebranych od Primarch'a (AS-0). Dokument obejmuje wymagania na Aplikację Hub NeXus, Orkiestrator, aplikącję ARC oraz ogólne zasady UX. &Zr;ródłem każdego wymagania jest bezpośrednia dyspozycja w sesji czatu (AS-0).
łańcuch autorytetu
Poziom
źródło
Opis
Ocena AS
AS-0
Primarch (użytkownik)
Dyspozycje w sesjach czatu — oryginalne i niezmodyfikowane
AS-0
AS-1
docs/NEXUS_APP_REQUIREMENTS.html
Ten dokument — pierwsze formalne utrwalenie wymagañ AS-0
Wymagania dotyczące ekranu głównego po zalogowaniu („NeXus Hub”).
REQ-HUB-001 KRYTYCZNY
Dashboard z kartami aplikacji po zalogowaniu
Po zalogowaniu użytkownik trafia do dashboardu (nie do bezpośrednio otwartej aplikacji). Dashboard wyświetla karty wszystkich aplikacji (use case'ów), do których użytkownik ma dostęp. Zastępuje dotychczasowe „logowanie do workspace’u”.
AS-0 — 2026-05-03T18:08:14Z — „rather than login from a pickup into a workspace, i would like to login into a dashboard with state of the system, some stats and cards leading to apps i have access to and roles in”
REQ-HUB-002 KRYTYCZNY
Karty dla WSZYSTKICH use case'ów z pipeline'ami
Dashboard musi wyświetlać karty dla każdego use case posiadającego zbudowane pipeline'y w systemie. Nie tylko ARC — również Nesto, Endo AI, Gaia Edge, Orion Edge i inne. Stan każdej aplikacji (aktywna, w budowie, zablokowana) musi być widoczny na karcie.
AS-0 — 2026-05-03T21:02:52Z — „i need to create cards in the dashboard for ALL usecases, showing their state. all apps which have built pipelines”
REQ-HUB-003 KRYTYCZNY
Role RBAC widoczne na kartach aplikacji
Karty aplikacji muszą wyświetlać role RBAC dostępne dla użytkownika w danej aplikacji. Przełącznik roli musi być dostępny z poziomu dashboardu, umożliwiając administratorowi widok perspektyw różnych ról.
AS-0 — 2026-05-03T18:08:14Z — „RBAC roles available should be shown clearly on the cards”; 2026-05-03T15:42:07Z — „i want RBAC switch for my admin role to see different views for different roles”
REQ-HUB-004 WYSOKI
Status rozwoju use case'u na kartach
Każda karta aplikacji musi wyświetlać status rozwoju use case'u (np. beta, produkcja, w budowie) pobrany z dokumentacji use case'u w systemie.
AS-0 — 2026-05-03T18:08:32Z — „and their status of development from usecase”
REQ-HUB-005 WYSOKI
Pigułki komponentów: nazwa w kolorze środowiska, wersja widoczna, typ środowiska tylko na hover
Każda karta aplikacji musi wyświetlać pigułki (pills) dla każdego komponentu. Pigułka musi: (1) wyświetlać nazwę komponentu w kolorze odpowiadającym typowi środowiska (docker=niebieski, bare-metal=pomarańczowy, cloud=fioletowy), (2) wyświetlać numer wersji obok nazwy, (3) typ środowiska (docker/bare-metal/cloud) wyświetlać WYŁĄCZNIE na najechaniu myszką (tooltip lub hover-reveal) — nie jako stały element pigułki.
AS-0 — 2026-05-04T18:48:41Z — „component versions and deployment type on each card”; 2026-05-05 — „pills contain name of a component IN THEIR RESPECTIVE COLOR and a version number, the type of component env is to be displayed only on mouse over the pill”
REQ-HUB-006 WYSOKI
Lista use case'ów na kartach
Każda karta aplikacji musi wyświetlać listę use case'ów dostępnych w danej aplikacji.
AS-0 — 2026-05-04T19:01:34Z — „what is the requirements re list of use cases displayed”
REQ-HUB-007 WYSOKI
Link do dokumentacji use case'u na karcie
Każda karta aplikacji musi posiadać bezpośredni link do dokumentacji use case'u. Nie przez orkiestrator — bezpośrednio z karty dashboardu.
AS-0 — 2026-05-03T21:03:22Z — „app cards also must have links to documentation of the use case, i do not want to go through orchestrator to see pipeline docs”
REQ-HUB-008 WYSOKI
Link do Orkiestratora z dashboardu
Dashboard musi zawierać widoczny link/przycisk do Orkiestratora. Po otwarciu Orkiestratora z poziomu dashboardu, Orkiestrator NIE wyświetla kart aplikacji — od razu ustawia się na widok pipeline'ów dla wybranej aplikacji lub org.
AS-0 — 2026-05-03T18:12:43Z — „think how link to orchestrator is to be wired into the dashboard”; 2026-05-04T19:01:34Z — „orchestrator NOT DISPLAYING cards and setting up to app/orch when entering from dashboard”
REQ-HUB-009 WYSOKI
Żywy monitoring zasobów systemowych i health check
Dashboard musi wyświetlać żywe dane o zasobach serwera (CPU, RAM, dysk) oraz ogólny health check systemu. Dane pobierane z /health/resources.
AS-0 — 2026-05-03T18:12:43Z — „i would like some live system machines resources showing, overall health check”
REQ-HUB-010 WYSOKI
Szczegóły roadmap use case'ów i ekosystemu NeXus
Dashboard musi wyświetlać elementy roadmap — dla każdego use case'u i dla całego ekosystemu NeXus. Może być prezentowane jako sekcja statyczna z danymi z dokumentacji use case'ów.
AS-0 — 2026-05-03T18:12:43Z — „some dev roadmap details for usecases and for the overall NeXus ecosystem”
REQ-HUB-011 WYSOKI
Polling 10 sekund
Interwiał odświeżania dashboardu (polling) musi wynosić 10 sekund (nie 30).
AS-0 — sesja 2026-05-03 — zmiana interwiału z 30000ms na 10000ms potwierdzona implementacją
REQ-HUB-012 ŚREDNI
Przełącznik języka PL/EN
Ekran dashboardu (i cala aplikacja) musi posiadać przełącznik języka PL/EN. Domyślny język: polski. Wszystkie teksty etykiet kart, nagłówków i przycisków muszą być tłumaczone.
AS-0 — 2026-05-03T19:09:46Z — „i want a language switch”; 2026-05-03T15:42:07Z — „i want to see language switch on that screen”
REQ-HUB-013 ŚREDNI
Wersja aplikacji widoczna na dashboardzie
Bieżąca wersja systemu musi być widoczna na dashboardzie. Numer wersji pochodzi z /health API. Umożliwia weryfikację czy zmiany zostały wdrożone.
AS-0 — 2026-05-03T19:09:46Z — „i want versioning so i can see current version and know if you applied changes”
REQ-HUB-014 ŚREDNI
Skiny (motywy) — glassmorphism, interaktywne
Aplikacja musi obsługiwać kilka skór (motywów). Orkiestrator dziedziczy aktywny skin. Skiny muszą być na poziomie glassmorphism, wszystkie elementy interaktywne. FAB przycisk "N" cykluje po dostępnych skinnach (akcja "Motyw").
AS-0 — 2026-05-03T18:11:54Z — „i want several skins, copy those from wormwood orchestrator and add some more with proper glassmorphism”; 2026-05-03T18:29:53Z — „orchestrator should carry the skin”
REQ-HUB-015 ŚREDNI
FAB przycisk "N" z 4 akcjami
Pływający przycisk akcji (FAB) na dashboardzie oznaczony jest literą "N". Po kliknięciu rozszerza się do 4 opcji: Hub (powrót do hub), Orkiestrator (otwiera orkiestrator), Logi (panel logów), Motyw (zmiana skinu).
AS-0 — sesja 2026-05-03 — zmiana FAB z "+" i "Run Pipeline/New Entity/Refresh Data" na "N" z 4 akcjami Hub/Orkiestrator/Logi/Motyw
REQ-HUB-016 KRYTYCZNY
Brak trybu demo — tylko prawdziwe dane
Wszystkie demo_mode: true muszą być zastąpione prawdziwymi danymi. Żadnych zaślepek, żadnych mock danych. Jeśli dane są niedostępne, aplikacja musi wyświetlić błąd — nie fikcyjne dane.
AS-0 — 2026-05-03T14:39:22Z — „i do not want demo mode i want real data”
REQ-HUB-017 WYSOKI
Wyszukiwarka kart aplikacji
Dashboard musi posiadać pole wyszukiwania (search box) filtrujące karty aplikacji w czasie rzeczywistym po nazwie aplikacji, domenie lub opisie. Wyszukiwanie działa po stronie klienta — bez dodatkowych żądań API. Karta jest ukrywana jeśli żadne z jej pól nie pasuje do frazy wyszukiwania.
AS-0 — 2026-05-05 — „i distinctly remember requesting search box for the cards”
REQ-HUB-018 WYSOKI
Widget RAID Log na dashboardzie
Dashboard musi wyświetlać widget RAID Log (Risks, Actions, Issues, Decisions) z możliwością filtrowania po typie. Dane pobierane z /omnissiah/raid. Widget wyświetlany w bocznej kolumnie dashboardu obok roadmapy.
Dashboard musi wyświetlać widget Roadmap pokazujący postęp milestones dla każdego use case'u i całego ekosystemu NeXus. Dane pobierane z /omnissiah/projects. Przy braku danych z API — fallback statyczny z dokumentacji use case'ów. Widget wyświetlany w bocznej kolumnie dashboardu.
AS-0 — 2026-05-03T18:12:43Z — „some dev roadmap details for usecases and for the overall NeXus ecosystem”; 2026-05-04T22:27:45Z — „i distinctly remember requesting roadmap widget”
REQ-HUB-020 KRYTYCZNY
Każda pigułka musi zawierać numer wersji — brak pigułek bez wersji
Żadna pigułka komponentu nie może być wyświetlona bez numeru wersji. Dotyczy to pigułek na kartach hub oraz wszędzie indziej w aplikacji. Pigułki bez wersji są zabronione. Dodatkowy zakaz: pigułki komponentowe mogą pojawiać się wyłącznie w sekcji komponentów na kartach aplikacji — nie na globalnym pasku dashboardu, nie w nagłówkach ani stopkach niezwiązanych z kartą.
AS-0 — 2026-05-04T21:17:45Z — „no pills are allowed without version numbers. but i also want pills on cards”; 2026-05-04T21:11:42Z — „hallucinated pills on top”; 2026-05-04T19:41:54Z — „pills no versions”
REQ-HUB-021 KRYTYCZNY
Karty hub muszą zawierać nazwę klienta
Każda karta aplikacji na dashboardzie hub musi wyświetlać nazwę klienta (właściciela use case'u). Nazwa klienta pochodzi z pola client w _USECASE_META i jest przekazywana przez API jako część obiektu usecase. Karty bez przypisanego klienta nie wyświetlają pola — brak fallbacku na wartości domyślne. Wartości: pyrometrix/pfp → Pyrometrix Ltd., gaia-edge/orion-edge → Code Zero, nesto → Nesto Group, arc/aer/aes/edr/freelance → UV, ca-kb → Johny, endo/endo-ai → Pryzmat Media, plato → Akademia Mistrzow.
Hub topbar musi zawierać dwa odrębne przyciski Liber — Liber Navigator i Liber Cogitatus
Topbar hub musi zawierać dwa oddzielne linki dokumentacji, które są wizualnie i funkcjonalnie rozróżnialne:
Liber Nav (id="btn-liber-nav"): otwiera Liber Navigator — archiwum polityk ROTC i dokumentacji UV. URL: http://localhost:8900/tools/liber_navigator/index.html. Otwiera w nowej karcie. Title tooltip: „Liber Navigator — UV Policy Archive (ROTC)”.
Liber Cog (id="btn-liber-cog"): otwiera Liber Cogitatus — rejestr otwartych problemów i defektów. URL: LIBER_COGITATUS.html. Otwiera w tej samej karcie. Title tooltip: „Liber Cogitatus — Open Issues & Defects”.
Jeden przycisk oznaczony tylko „Liber” bez rozróżnienia jest NIEZGODNY z wymaganiem — naruszenie odkryte 2026-05-08 (ISSUE-070).
Oba przyciski muszą być widoczne jednocześnie w topbarze. Styl: klasa hub-docs-link.
AS-0 — 2026-05-08 — „that requirement there is for Liber Navigator, documentation of ROTC. you are free to add another button for Liber Cogitatus, but they are to be distinct”
REQ-HUB-023 WYSOKI
Liber Navigator musi być utrzymywany jako działająca usługa środowiskowa
Liber Navigator jest odrębną usługą webową serwującą archiwum polityk ROTC/UV. Musi być dostępny pod adresem http://localhost:8900 na każdym środowisku deweloperskim i testowym. Wymagania:
Usługa musi odpowiadać HTTP 200 na GET http://localhost:8900/tools/liber_navigator/index.html
Wyniki Gate 11 Sekcja 32 muszą zawierać weryfikację dostępności usługi Liber Navigator
Brak odpowiedzi HTTP 200 = FAIL sekcji 32 = blokada zamknięcia sprintu
Skrypt startowy środowiska (start_ui.ps1) musi uruchamiać Liber Navigator jeżeli nie działa
AS-0 — 2026-05-08 — „this also means you are to maintain the Liber Navigator app running on the environment”
REQ-NAV — Nawigacja i Powrót do Hubu
REQ-NAV-001 KRYTYCZNY
Widget/przycisk powrótu do hubu z poziomu aplikacji
Każda aplikacja (ARC, Nesto, etc.) musi posiadać widoczny element UI umożliwiający powrót do dashboardu hub. Może to być pływający widget. Powrót nie może wyświetlać białego tła.
AS-0 — 2026-05-03T19:39:15Z — „what about the widget in an app to allow navigation back to the dashboard”; 2026-05-03T18:45:04Z — „how do i navigate back from the app to the dashboard? some floating widget is necessary”; 2026-05-03T20:40:43Z — „return from app to hub shows white background still i reported that issue”
REQ-NAV-002 KRYTYCZNY
Przycisk powrót do hubu w Orkiestratorze
Orkiestrator (WORMWOOD_APP.html) musi posiadać przycisk powrótu do hubu. Skin jest dziedziczony z sesji (skin persistence).
AS-0 — 2026-05-03T21:02:52Z — „orchestrator must have also back to hub button and skin persistence”
REQ-NAV-003 WYSOKI
Pipeline'y widoczne w Orkiestratorze dla każdej aplikacji
Orkiestrator musi wyświetlać pipeline'y ze wszystkich aplikacji w systemie. Pipeline'y ARC, Nesto, Endo AI i innych muszą być widoczne. Po wejściu z karty konkretnej aplikacji Orkiestrator filtruje do pipeline'ów tej aplikacji.
AS-0 — 2026-05-03T21:02:52Z — „i want now to see ARC pipeline in there. the pipelines must display in the orchestrator”; 2026-05-04T20:19:58Z — „pipelines, components, their versions on Nexus AND PER APP”
REQ-ORCH — Orkiestrator
Wymagania dotyczące widoku Orkiestratora (WORMWOOD_APP.html) z poziomu NeXus Hub.
REQ-ORCH-001 KRYTYCZNY
Spójne stylowanie Orkiestratora z aktywnym skinem dashboardu
Orkiestrator musi dziedziczyć i stosować aktywny skin dashboardu. Nagłówek, panel boczny i elementy UI Orkiestratora muszą być wizualnie spójne z dashboardem. Nagłówek losowy/niezgodny z aktywnym skinem jest niedopuszczalny.
AS-0 — 2026-05-04T21:11:42Z — „orchestrator fucked up. random header style, no consistent styling with dashboard skin”; 2026-05-03T18:29:53Z — „orchestrator should carry the skin”
REQ-ORCH-002 KRYTYCZNY
Brak kart spoza zatwierdzonego zakresu w Orkiestratorze
Orkiestrator może wyświetlać wyłącznie karty pipeline'ów dla wybranej aplikacji. Halucynowane karty, karty aplikacji hub ani inne elementy spoza zakresu są ZABRONIONE w widoku Orkiestratora.
AS-0 — 2026-05-04T21:11:42Z — „forbidden cards” w opisie błędów Orkiestratora
REQ-ORCH-003 WYSOKI
Kontekst aplikacji przy wejściu z karty hub
Po kliknięciu „Orkiestrator” z karty konkretnej aplikacji na hubie, Orkiestrator otwiera się z filtrem ustawionym na tę aplikację. Nie wyświetla kart wyboru aplikacji — bezpośrednio pokazuje pipeline'y wybranej aplikacji.
AS-0 — 2026-05-04T19:01:34Z — „orchestrator NOT DISPLAYING cards and setting up to app/org when entering from dashboard”
REQ-UX — Ogólne zasady UX
REQ-UX-001 KRYTYCZNY
Pełne wykorzystanie przestrzeni ekranu
Widoki muszą wykorzystywać całą dostępną przestrzeń ekranu. Niedopuszczalne jest, aby 70% ekranu było puste. Scrollbary nie powinny być widoczne gdy zawartość mieści się w viewporcie.
AS-0 — 2026-05-03T14:44:23Z — „the view does not use all of the available space”; 2026-05-03T19:16:37Z — „there should not be any visible scrollbars when 70% of the screen is unused”
REQ-UX-002 KRYTYCZNY
Żadnych halucynowanych widoków / pustych stron
Każda strona/widok musi wyświetlać realne dane lub czytelny komunikat o ich braku. Niedopuszczalne są puste widoki, spinner bez wyniku lub strony prowadzące donikąd.
AS-0 — 2026-05-03T14:44:23Z — „most of the pages lead to hallucinated views”
REQ-UX-003 WYSOKI
Język polski jako domyślny w całym UI
Cały interfejs użytkownika musi być po polsku. Etykiety, komunikaty błędów, stany puste, nagłówki — wszystko po polsku. Angielski dostępny przez przełącznik języka.
Nagłówek aplikacji musi wyświetlać nazwę profilu zalogowanego użytkownika.
AS-0 — 2026-05-03T14:39:22Z — „add profile name to page header”
REQ-UX-005 WYSOKI
Możliwość wyjścia z profilu (wylogowanie)
Aplikacja musi zapewniać wyraźny mechanizm wylogowania się z aktywnego profilu/org. Nie może być sytuacji, w której jedynym wyjściem jest odświeżenie strony.
AS-0 — 2026-05-03T14:39:22Z — „need a way to exit the profile”
REQ-UX-006 WYSOKI
Styled scrollbary
Gdy scrollbary są konieczne, muszą być ostylizowane zgodnie z aktywnym skinem — nie natywne szare paski przeglądarki.
AS-0 — 2026-05-03T19:16:37Z — „scroll bars are not styled”
REQ-UX-007 WYSOKI
Wysoka jakość skinowania — glassmorphism, wszystko interaktywne
Skiny muszą być na poziomie produkcyjnym. Glassmorphism. Każdy element interaktywny — przyciski, karty, menu — musi mieć efekty hover/active. Jakość co najmniej równa z istn iejącymi demonstratorami (Pyrometrix, UseMeJobs SPA).
AS-0 — 2026-05-03T18:29:53Z — „very weak skinning, i want this improved 3 orders of magnitude. all elements are to be interactive”
REQ-AUTH — Autentykacja i autoryzacja
REQ-AUTH-001 KRYTYCZNY
Zaimplementowana autentykacja
Logowanie musi działać przez prawdziwą autentykację — POST /orgs/authenticate z email i org_slug. Nie może być zastosowana żadna droga na skróty omijająca login.
AS-0 — 2026-05-03T15:37:52Z — „the auth is not implemented”; 2026-05-03T14:39:22Z — „need auth and account defs”
REQ-AUTH-002 WYSOKI
Definicje kont i aplikacji
System musi obsługiwać wiele aplikacji (arc, nesto, endo-ai). Po zalogowaniu użytkownik widzi karty aplikacji, do których ma dostęp. API /orgs/user-hub?email=X zwraca przypisania użytkownika.
AS-0 — 2026-05-03T14:39:22Z — „need auth and account defs”
REQ-ARCH — Architektura i terminologia
Wymagania architektoniczne i terminologiczne dotyczące całego systemu NeXus.
REQ-ARCH-001 KRYTYCZNY
Jeden punkt wejścia do NeXus — brak trybu direct-connect
Istnieje DOKŁADNIE JEDEN widok NeXus (ekran Hub). Nie ma trybu bezpośredniego połączenia z aplikacją z pominięciem Hub. Użytkownik zawsze trafia najpierw na Hub, a następnie może wybrać aplikację. Wielokrotne równoległe „widoki NeXus” są zabronione.
AS-0 — 2026-05-04T19:59:50Z — „THERE SHOULD ONLY BE ONE EXACTLY ONE NEXUS VIEW. THERE IS NO NEED FOR ANY FUCKING DIRECT CONNECT. I SENT TO SEE NEXUS, i can pick an app later if i want to.”
REQ-ARCH-002 KRYTYCZNY
Terminologia: „app” zamiast „org” w całym systemie
Termin „org” (organization) musi zostać całkowicie zastąpiony przez „app” (aplikacja) we wszystkich elementach UI: etykietach, komunikatach, URL-ach (gdzie możliwe), dokumentacji i kodzie. Dotyczy to również prefiksu URL — /arc-ui/ jest historycznym artefaktem i musi zostać uogólnione.
AS-0 — 2026-05-04T20:19:58Z — „i want ORG term purged”; 2026-05-04T22:24:26Z — „what is arc-ui in the link? where does it come from?”
REQ-ARCH-003 KRYTYCZNY
Brak hardkodowanych URL specyficznych dla aplikacji
Żadne linki w NeXus nie mogą być zakodowane na twardo dla konkretnej aplikacji (np. /arc-ui/, org_slug=arc). Routing musi być dynamiczny i oparty na aktualnie wybranej aplikacji. Prefix URL musi być neutralny (np. /nexus/ lub /ui/).
AS-0 — 2026-05-04T20:19:58Z — „the links are not to be fucking org specific like arc-ui is now”; 2026-05-04T22:27:45Z — „why do i care when you fucked up? there is no such thing as pre-existing error”
REQ-ARCH-004 WYSOKI
LLD — dokumentacja metod i przepływów danych przez ekrany NeXus
Musi istnieć dokument LLD (Low Level Design) opisujący wszystkie metody JavaScript/Python i ich relacje, wraz z przepływami danych przez cztery główne ekrany: (1) Login, (2) Hub Dashboard, (3) Orkiestrator, (4) Wejście do aplikacji. LLD jest obowiązką dokumentacją AS-2 niezbędną przed jakimkolwiek nowym rozwojem.
AS-0 — 2026-05-04T20:19:58Z — „i want an LLD defined with all of the methods and their relations and data flows through NeXus screens: login, dashboard, orchestrator, app enter”; 2026-05-04T20:01:29Z — „where is LLD? where is complete documentation of all of the methods which are to be created in the code”
REQ-GATE — Widoki bramek (Gate Views)
REQ-GATE-001 KRYTYCZNY
Widok awaiting_approval — przyciski zatwierdź/odrzuć
Gdy pipeline zwraca status awaiting_approval, UI musi wyświetlić dedykowany widok z przyciskami "Zatwierdź" i "Odrzuć". Przyciski muszą wywoływać stosowne akcje na API.
AS-0 — sesja 2026-05-03 — implementacja loadView() z routingiem na renderGateView() dla statusów bramek
REQ-GATE-002 KRYTYCZNY
Widok awaiting_human — formularz wejścia ręcznego
Gdy pipeline zwraca status awaiting_human, UI musi wyświetlić formularz umożliwiający ręczne wprowadzenie danych wymaganych przez pipeline.
AS-0 — sesja 2026-05-03 — wiring _gateStatuses check w loadView()
REQ-GATE-003 KRYTYCZNY
Widok revision_requested — feedback i ponowne wysyłanie
Gdy pipeline zwraca status revision_requested, UI musi wyświetlić dostarczoną informację zwrotną (feedback) oraz umożliwić ponowne wysłanie danych po korekcie.
AS-0 — sesja 2026-05-03 — wiring _gateStatuses check w loadView()
REQ-ARC — Wymagania specyficzne dla use case ARC
REQ-ARC-001 WYSOKI
GSuite OAuth — prawdziwy odczyt e-maili
Integracja e-mail w ARC musi używać prawdziwego Google GSuite OAuth (node GSuiteAuth + GmailRead) — nie GmailShadow, nie demo. Token jest przechowywany lokalnie i automatycznie odświeżany.
AS-0 — 2026-05-03T14:06:52Z — „i do not want GmailShadow to be part of the app. we need a GSuite auth node”
REQ-ARC-002 WYSOKI
Przycisk integracji Gmail widoczny w UI
W widokach e-mailowych (Panel, E-maile) musi być widoczny przycisk/status integracji z Gmail. Użytkownik musi być w stanie sprawdzić czy integracja działa i ją ponownie skonfigurować jeśli wygasa token.
AS-0 — 2026-05-03T20:46:56Z — „i still see mock data, i see no button to integrate google”
REQ-ARC-003 WYSOKI
9 elementów nawigacji zgodnych z ARC Sidebar.tsx
Nawigacja ARC musi zawierać dokładnie 9 elementów zgodnych z oryginalnym ARC Sidebar.tsx: Panel, Leady, Faktury, Oferty, E-maile, Klienci, Projekty, Kalendarz, Bank. Ustawienia jako element dodatkowy.
AS-0 — sesja 2026-05-03 — wymaganie parytetu z archive/AER/ i oryginalnym ARC repo; plik .github/instructions/uv-wormwood-spa.instructions.md § ARC Reference Fidelity
REQ-ARC-004 ŚREDNIIMPLEMENTED
Chameleon — formularzowy UI dla entity classes
Formularze ARC muszą używać Chameleon jako silnika renderowania formów. Adapter arc_chameleon_adapter.py konwertuje schematy entity class do formatów Chameleon. Implemented NX-S5:renderFormSection() in NEXUS_APP.html uses arcToChamelon(); pipeline arc-new-lead-form (12-field prospect-lead schema) renders ChameleonV2 form on sidebar click.
AS-0 — 2026-05-03T18:45:04Z — „weak space usage. are you using Chameleon?”; sesja 2026-05-03 — wielokrotne odwołania do Chameleon jako silnika form
REQ-MULTI — Wiele aplikacji w NeXus
REQ-MULTI-001 KRYTYCZNY
Wiele aplikacji widocznych na ekranie hub
Ekran hub musi wyświetlać wiele aplikacji jednocześnie — nie tylko ARC. Każda org z pipeline'ami musi mieć swoją kartę. Minimum: ARC, Nesto, Endo AI.
AS-0 — 2026-05-03T15:42:07Z — „i want to see multiple apps in the Nexus connection view”
REQ-MULTI-002 WYSOKI
Dwie ścieżki wejścia do aplikacji: formularze (Chameleon) albo widok statystyk pipeline'ów
Wejście do aplikacji musi obsługiwać dwie ścieżki w zależności od tego czy aplikacja ma formularze (has_forms: True) czy nie. Aplikacje z formularzami (np. Nesto) renderują flow jako formularze Chameleon. Aplikacje bez formularzy (np. Pyrometrix, Gaia Edge) renderują widok statystyk pipeline'ów — nie próbują renderować Chameleon, którego nie mają. Obie ścieżki są pełnoprawnym widokiem — żadna nie jest fallbackiem ani błędem.
AS-0 — 2026-05-05 — „what should happen when you click on a flow which has no forms? it makes no sense to render an app with no forms”
REQ-FLOW — Widok pipeline'ów (aplikacje bez formularzy)
Wymagania dotyczące widoku dla aplikacji bez formularzy Chameleon. Zamiast próbować renderować Chameleon, wyświetlany jest użyteczny widok statystyk i historii uruchomień.
REQ-FLOW-001 KRYTYCZNY
Domyślny widok no-forms: statystyki pipeline'ów jako klikalny panel
Dla aplikacji bez has_forms: True domyślny widok po wejściu musi pokazywać: (1) trzy liczniki — aktywne / draft / wszystkie pipeline'y, (2) listę pipeline'ów jako klikalne wiersze. Każdy wiersz zawiera: slug, domenę, status, liczbę węzłów oraz czas ostatniego uruchomienia. Kliknięcie wiersza otwiera widok szczegółu pipeline'u (REQ-FLOW-002). Obecny stan (tabela statyczna bez onclick) nie spełnia tego wymagania.
AS-0 — 2026-05-05 — „some stats on flow runs?”
REQ-FLOW-002 KRYTYCZNY
Widok szczegółu pipeline'u: historia uruchomień
Kliknięcie pipeline'u na liście otwiera widok szczegółu zawierający: (1) nagłówek ze slug, domeną i statusem, (2) tabelę ostatnich 10 uruchomień z kolumnami: data, status (success/failed/running), czas trwania, wyzwalacz. Dane pobierane z /pipelines/{id}/runs?limit=10. Brak uruchomień — explicit komunikat „Brak uruchomień”, nie pusta tabela.
AS-0 — 2026-05-05 — „some stats on flow runs?”
REQ-FLOW-003 WYSOKI
Widok szczegółu pipeline'u: karta statystyk zbiorczych
Powyżej tabeli uruchomień muszą znajdować się 4 karty statystyk: (1) łączna liczba uruchomień, (2) wskaźnik sukcesu (%), (3) średni czas trwania, (4) czas ostatniego uruchomienia. Wartości obliczane po stronie klienta z danych z /pipelines/{id}/runs. Brak danych — karty pokazują „--”, nie ukrywają się.
AS-0 — 2026-05-05 — „some stats on flow runs?”
REQ-FLOW-004 WYSOKI
Widok szczegółu pipeline'u: przycisk „Otwórz w Orkiestratorze”
Każdy widok szczegółu pipeline'u musi zawierać przycisk „Orkiestrator” który otwiera IA_ORCHESTRATOR.html z parametrem ?org={org_slug} oraz &pipeline={pipeline_slug} tak aby Orkiestrator otworzył się bezpośrednio na tym pipeline'u. Skóra (skin) musi być dziedziczona z bieżącej sesji.
AS-0 — 2026-05-05 — „link to orchestrator?”
Stan implementacji
Stan na moment tworzenia dokumentu (2026-05-04). &Zr;ródło: docs/NEXUS_APP.html, scripts/seed_arc_pipeline.py, kod backend.
ID
Tytuł
Status
Uwagi
REQ-HUB-001
Dashboard z kartami po zalogowaniu
ZAIMPL.
NX-S18-WP7: /orgs/apps/catalog (16 appów) → renderHubCards(); /orgs/user-hub tylko dla overlay roli
REQ-HUB-002
Karty dla wszystkich use case'ów
ZAIMPL.
NX-S18-WP7: doHubLoginWithJwt() + doHubLogin() pobierają /orgs/apps/catalog (16 wpisów) jako główne źródło kart; /orgs/user-hub tylko dla overlay role/key
REQ-HUB-003
Role RBAC na kartach
ZAIMPL.
hub-badge-role wyświetla o.role na każdej karcie
REQ-HUB-004
Status rozwoju use case'u
ZAIMPL.
status_code + status_label z app_catalog DB przez /orgs/apps/catalog
REQ-HUB-005
Pigłki: nazwa w kolorze, wersja, env na hover
ZAIMPL.
data-env-label tooltip via CSS ::after; data-env color rules; validComps filtruje bez wersji
REQ-HUB-006
Lista use case'ów na kartach
ZAIMPL.
ucListHtml renderuje uc.use_cases; wymaga uzupełnienia _USECASE_META o pole use_cases
REQ-HUB-007
Link do dokumentacji use case'u na karcie
ZAIMPL.
hub-card-action-docs z href do NEXUS_USECASE_*.html na każdej karcie
REQ-HUB-008
Link do Orkiestratora
ZAIMPL.
FAB akcja "Orkiestrator"; brak wiring WORMWOOD_APP dla konkretnej org
REQ-HUB-009
Żywy monitoring zasobów
ZAIMPL.
/health/resources wyświetlane na dashboardzie
REQ-HUB-010
Roadmap
ZAIMPL.
Widget zawsze widoczny; statyczny fallback w renderRoadmaps() .then() i .catch()
REQ-HUB-011
Polling 10s
ZAIMPL.
Zmieniono 30000 → 10000ms
REQ-HUB-012
Przełącznik języka PL/EN
ZAIMPL.
toggleLang(), _i18n obiekty PL/EN, #hub-lang-toggle, searchbox placeholder aktualizowany
renderGateView() formularze z human_input_schema; _gateHumanInput()
REQ-GATE-003
revision_requested
ZAIMPL.
renderGateView() edycja poprzednich danych + ponowne wysyłanie
REQ-ARC-001
GSuite OAuth
ZAIMPL.
GSuiteAuth + GmailRead executory aktywne
REQ-ARC-002
Przycisk integracji Gmail
ZAIMPL.
#gmail-status-widget w sidebarze; renderGmailStatusWidget(orgSlug) dla arc; reconnectGmail()
REQ-HUB-017
Wyszukiwarka kart aplikacji
ZAIMPL.
#hub-search + filterHubCards() wdrożone
REQ-HUB-018
Widget RAID Log
ZAIMPL.
_raidStaticFallback 8 wpisów; widget zawsze widoczny
REQ-HUB-019
Widget Roadmap
ZAIMPL.
Widget zawsze widoczny; renderRoadmaps() z fallbackiem statycznym
REQ-HUB-020
Każda pigłłka musi zawierać wersję
ZAIMPL.
validComps filtruje bez wersji; data-env-label tooltip; prefix v
REQ-HUB-021
Karty hub — nazwa klienta
ZAIMPL.
NX-S18-WP7: pole client z config_json w app_catalog DB; hub-card-client pod domain; brak fallbacku
REQ-HUB-022
Dwa odrębne przyciski Liber w topbarze
OTWARTE
id=btn-liber-nav (localhost:8900, nowa karta) + id=btn-liber-cog (LIBER_COGITATUS.html); Gate 11 S12 weryfikuje oba; jeden przycisk „Liber” = NIEZGODNY
REQ-HUB-023
Liber Navigator jako działająca usługa środowiskowa
OTWARTE
HTTP 200 na localhost:8900/tools/liber_navigator/index.html; Gate 11 S32 weryfikuje dostępność; brak = FAIL S32 = blokada sprintu
REQ-ORCH-001
Spójne stylowanie Orkiestratora
ZAIMPL.
boot(): czyta sessionStorage['na-session-skin'] (zapisany przez hub przed nawigacją). Mapuje na nexus-theme w localStorage przed nexus-core.js. Parametr ?skin= w URL nie jest używany — NEXUS_LLD.md §20. UWAGA: kod wymaga aktualizacji (remedium PROD-SKIN-002).
REQ-ORCH-002
Brak kart spoza zakresu
ZAIMPL.
?org= w URL → sel-org auto-select → loadPipelines(); widok kart hub pominięty
REQ-ORCH-003
Kontekst aplikacji w Orkiestratorze
CZĘŚCIOWO
Hub nawigacja przekazuje ?org=SLUG&token=JWT do WORMWOOD_APP.html (skin via sessionStorage['na-session-skin'] — bez ?skin= w URL). WORMWOOD_APP boot() odczytuje ?token=, zapisuje w sessionStorage[nexus-jwt], usuwa z URL (history.replaceState). authHdrs() zastępuje apiKey()/apiHdrs(). BROKEN w sesji JWT (2026-05-13): nexus-login.key nie jest zapisywane w JWT flow. FIX zaplanowany w NX-S18-WP6 (NEXUS_LLD.md §19).
REQ-ORCH-004
Zero input od użytkownika dla API key
OTWARTE
NX-S18-WP6: JWT-first auth (Option A). Backend: require_jwt_or_api_key() dep w wormwood/auth.py, swap we wszystkich routes_pipelines/orgs/rule_editor/bi/arc. Frontend: authHdrs() w WORMWOOD_APP, token pass w 3 ścieżkach nav. Spec: NEXUS_LLD.md §19. Engine :19 + Hub :13.
REQ-ARCH-001
Jeden punkt wejścia NeXus
ZAIMPL.
#li-base-row ukryty (display:none); Enter → doHubLogin() zamiast doLogin()
Export (Save): Every pipeline must be exportable as a self-contained JSON descriptor file.
The descriptor contains: slug, name, version, domain,
status, description, graph (nodes + edges), style_tokens,
exported_at (ISO 8601), exported_by (org slug), and a top-level
descriptor_version field ("1.0") for forward-compatibility.
Export is available from the pipeline detail view (WORMWOOD_APP / Orchestrator) as a button that triggers
a browser file download of {slug}_v{version}.json.
AS-0 — 2026-05-05 — „app descriptor file requirements and add support to it, both ways, save and load”
REQ-DESC-002 KRYTYCZNY
Import (Load): A descriptor JSON file can be imported into any org. Import is available from
the WORMWOOD_APP pipeline list as an “Import Pipeline” button. On upload the system:
(1) validates descriptor_version and required fields;
(2) checks for slug collision in the target org — if collision, creates as {slug}-imported-{timestamp};
(3) sets imported pipeline status = "draft" regardless of source status;
(4) records imported_from in description field;
(5) returns the created pipeline object.
Import endpoint: POST /pipelines/import (multipart/form-data or JSON body).
AS-0 — 2026-05-05 — „app descriptor file requirements and add support to it, both ways, save and load”
Status lifecycle: Every pipeline has a status field with three states:
draft (being edited, not executable), active (live, executable, only one active
version per slug allowed), archived (historical, read-only). Transitions:
draft → active (Publish), active → archived (Deactivate),
archived → draft (Restore as new draft). No other transitions are valid.
The database already has this field; this requirement governs the UI controls and API enforcement.
AS-0 — 2026-05-05 — „versioning and publishing process, similar to PowerAutomate versioning and turning on and off versions”
REQ-VER-002 KRYTYCZNY
Version history per slug: When a pipeline is published (draft → active), the current
active version (if any) is automatically archived first. This preserves full history.
The pipeline list in WORMWOOD_APP shows all versions of each slug grouped under a collapsible row,
with version number, status badge (DRAFT / ACTIVE / ARCHIVED), and publish date.
Each version row has individual action buttons.
AS-0 — 2026-05-05 — „turning on and off versions”
REQ-VER-003 KRYTYCZNY
Version bump on edit: When the graph of an active pipeline is edited in the
Orchestrator, the system automatically creates a new draft clone with version incremented by
patch (e.g. 1.0.0 → 1.0.1). The original active version is preserved unchanged. The user edits the
new draft and publishes when ready. This prevents in-place modification of live pipelines.
AS-0 — 2026-05-05
REQ-VER-004 WYSOKI
API endpoints required:
POST /pipelines/{id}/publish — draft → active (archives current active)
POST /pipelines/{id}/deactivate — active → archived
POST /pipelines/{id}/restore — archived → new draft clone (bumped version)
POST /pipelines/{id}/fork — any status → new draft clone (bumped version)
GET /pipelines/history?org_slug={slug}&base_slug={base_slug} — all versions of a pipeline slug
GET /pipelines/{id}/descriptor — download descriptor JSON (REQ-DESC-001)
POST /pipelines/import — import descriptor JSON (REQ-DESC-002)
AS-0 — 2026-05-05
REQ-VER-005 WYSOKI
WORMWOOD_APP UI controls per pipeline row:
Status badge pill (DRAFT in amber / ACTIVE in green / ARCHIVED in grey)
Draft: [Publish] [Edit] [Export] [Delete]
Active: [Deactivate] [Fork] [Export] (no Delete — active pipelines are protected)
Archived: [Restore] [Export] (read-only, no Edit)
Publish action requires confirmation dialog showing: “Publishing v{X} will archive current active v{Y}. Continue?”
AS-0 — 2026-05-05
REQ-VER-006 SREDNI
Base slug concept: All pipeline versions with the same logical identity share a
base_slug field (equals the original slug, without version suffix). This enables
the history endpoint and grouped display. When forking, base_slug is inherited from the parent.
For existing pipelines, base_slug defaults to slug.
The DB migration adds a base_slug column to _tbl_orch_pipelines
(nullable, default = slug value, indexed).
AS-0 — 2026-05-05
REQ-VER-007 SREDNI
Execution guard: The pipeline executor (POST /pipelines/{id}/run) must
reject execution of pipelines with status != "active" with HTTP 409 and message:
“Pipeline is not active (status: {status}). Publish it before running.”
Exception: test runs explicitly passed force=true query param are allowed for draft
pipelines only (for development testing).
AS-0 — 2026-05-05
REQ-DESC / REQ-VER — Status 2026-05-05
ID
Opis
Status
Uwagi
REQ-DESC-001
Export pipeline as descriptor JSON
CZĘŚCIOWO
Backend: GET /pipelines/{id}/descriptor zaimplementowany 2026-05-05. UI: przycisk Export w WORMWOOD_APP OCZEKUJE (zakres REQ-VER-005).
REQ-DESC-002
Import descriptor JSON
CZĘŚCIOWO
Backend: POST /pipelines/import zaimplementowany 2026-05-05. UI: przycisk Import w WORMWOOD_APP OCZEKUJE (zakres REQ-VER-005).
REQ-DESC-003
Descriptor schema v1.0
ZAIMPL.
Schema defined and enforced in routes_pipelines.py GET /pipelines/{id}/descriptor.
REQ-VER-001
Status lifecycle: draft/active/archived
CZĘŚCIOWO
Backend: pola DB + wymuszanie API zaimplementowane 2026-05-05. UI: przejścia statusów w WORMWOOD_APP OCZEKUJĄ (REQ-VER-005).
REQ-VER-002
Version history grouped by base_slug
CZĘŚCIOWO
Backend: GET /pipelines/history?org_slug&base_slug zaimplementowany. UI: widok pogrupowany w WORMWOOD_APP OCZEKUJE.
migrate_add_base_slug.py executed. 85 rows backfilled. Index created.
REQ-VER-007
Execution guard on non-active pipelines
ZAIMPL.
trigger_run rejects non-active pipelines with 422. force=true bypass available for drafts.
REQ-ENV — Environments per App & Environment Management
REQ-ENV-001 KRYTYCZNY
Health status on hub cards
Every hub card displays a live health indicator for the app's current active environment.
The indicator shows one of four states: ONLINE (green), DEGRADED (amber),
OFFLINE (red), UNKNOWN (grey, when unreachable or not configured).
Health is polled on the same 10-second interval as other hub data (/health/resources).
The indicator is a coloured dot + label, positioned in the card header beside the app name.
Clicking the indicator navigates directly to the environment health detail on the App Management page.
AS-0 — 2026-05-06 — „health status on cards”
REQ-ENV-002 KRYTYCZNY
Environment definitions per app
Each app (org) supports multiple named environments (e.g. production, staging,
dev, demo). Each environment has its own:
name — display label (user-editable)
slug — machine identifier
version — currently deployed pipeline/app version (may differ from other environments)
status — running / stopped / degraded / unknown
url — endpoint URL for that environment instance
created_at, last_deployed_at
Environments are stored in a new DB table _tbl_org_environments linked to the org by org_slug.
The hub card shows the production environment by default; other environments are visible on the App Management page.
AS-0 — 2026-05-06 — „environments definition per app, different environments can have different versions”
REQ-ENV-003 KRYTYCZNY
Environment lifecycle actions
Each environment supports the following management actions, available from the App Management page
and selectively from the hub card RMB menu (REQ-RMB-001):
Spin up new instance — provision a new environment copy with a given name and base version
Start — start a stopped environment
Stop — gracefully stop a running environment
Restart — stop then start (with confirmation for production)
Backup data & config — snapshot current data and configuration; backup stored with timestamp; downloadable
Upgrade version — deploy a higher version to this environment (confirmation required; shows diff of pipeline changes)
Downgrade version — revert to a previous version (confirmation required; shows what will be lost)
Each action is exposed via a dedicated API endpoint under /orgs/{org_slug}/environments/{env_slug}/.
Destructive actions (stop, downgrade on production) require a confirmation dialog stating the exact impact.
AS-0 — 2026-05-06 — „spin a new instance, start, stop, restart, backup data and config, upgrade or downgrade version”
REQ-ENV-004 WYSOKI
API endpoints for environment management
GET /orgs/{org_slug}/environments — list all environments for an org
POST /orgs/{org_slug}/environments — create / spin up new environment
GET /orgs/{org_slug}/environments/{env_slug} — environment detail + health
POST /orgs/{org_slug}/environments/{env_slug}/start
POST /orgs/{org_slug}/environments/{env_slug}/stop
POST /orgs/{org_slug}/environments/{env_slug}/restart
POST /orgs/{org_slug}/environments/{env_slug}/backup — returns backup ID + download URL
POST /orgs/{org_slug}/environments/{env_slug}/upgrade — body: {"target_version": "x.y.z"}
POST /orgs/{org_slug}/environments/{env_slug}/downgrade — body: {"target_version": "x.y.z"}
GET /orgs/{org_slug}/environments/{env_slug}/backups — list backups
AS-0 — 2026-05-06
REQ-MGMT — App Management Page
REQ-MGMT-001 KRYTYCZNY
Card click leads to App Management page (not app)
Clicking the main body of a hub card navigates to the App Management page for that org,
not directly to the app. This is the new default navigation target.
The App Management page URL is: /nexus-ui/APP_MGMT.html?org={org_slug}.
Access to the live application itself is available:
via an “Open App” button on the App Management page
via a dedicated “Open App” item in the card RMB menu (REQ-RMB-001)
The old direct-to-app card behaviour is removed from the default click action.
AS-0 — 2026-05-06 — „card should lead to the app management page by default”
REQ-MGMT-002 KRYTYCZNY
App Management page content
The App Management page (APP_MGMT.html) is a full SPA with the following sections:
Header — org name, client name, current active environment selector, health dot
Environments panel — list/grid of all environments with status, version, last deployed, action buttons per environment (REQ-ENV-003)
Pipeline versions — grouped version history for this org (REQ-VER-002)
Backups — list of available backups per environment with download and restore actions
Settings — RMB menu customisation (REQ-RMB-004), org metadata, API keys
Open App button — prominent CTA linking to the live application for the selected environment
The page inherits the active skin from hub session via sessionStorage['na-session-skin'] (written by hub before navigation). No ?skin= URL param is used — see NEXUS_LLD.md §20.
AS-0 — 2026-05-06 — „leading to app itself is either from app management page or from a button/rmb menu on the card”
REQ-MGMT-003 WYSOKI
Navigation: hub → management → app
Navigation hierarchy: Hub → App Management → App (live).
App Management page has a “Back to Hub” button (same pattern as Orchestrator).
The live app opens in a new tab from App Management, so returning to management is trivial.
Deep-linking is supported: APP_MGMT.html?org=arc&env=staging opens the management page
pre-selected to the staging environment.
AS-0 — 2026-05-06
REQ-RMB — Right-Click Context Menu on Hub Cards
REQ-RMB-001 KRYTYCZNY
RMB context menu on hub cards
Every hub card responds to right-click (contextmenu event) with a custom context menu.
The menu is styled in the active Nexus skin and dismisses on click-outside or Escape.
Default items present on all cards (non-removable):
Open App — opens live app for the active environment in a new tab
Open Management — navigates to App Management page
Open Orchestrator — opens WORMWOOD_APP for this org
View Docs — opens use-case documentation page
Below the defaults, a dynamic section shows app-specific actions configured per org
(REQ-RMB-003). A separator divides the two sections.
AS-0 — 2026-05-06 — „a bunch of most often used functions dynamic for each app should be on the RMB”
REQ-RMB-002 KRYTYCZNY
Dynamic RMB items — per-app configuration
Each org has a stored list of RMB quick-action items. Each item has:
label — display text
action_type — one of: url, pipeline_run, env_action (start/stop/restart/backup)
action_target — URL or pipeline slug or environment action slug
icon — optional short icon label or symbol
order — integer sort position
enabled — boolean; disabled items are hidden from the menu but preserved in settings
Items are stored in a new DB table _tbl_org_rmb_items linked by org_slug.
Retrieved via GET /orgs/{org_slug}/rmb-items and cached in the hub session.
AS-0 — 2026-05-06 — „dynamic for each app”
REQ-RMB-003 WYSOKI
Environment actions in RMB
Environment lifecycle actions (REQ-ENV-003) can be added as dynamic RMB items.
When an env_action type item is activated from the RMB menu, a confirmation mini-dialog
appears inline (not full-page navigation) confirming the action before executing.
The result (success / failure) is shown as a toast notification on the hub.
AS-0 — 2026-05-06
REQ-RMB-004 WYSOKI
App Settings — RMB menu management
The Settings section of the App Management page (REQ-MGMT-002) includes a RMB Menu Editor:
Drag-and-drop reordering of dynamic items
Toggle enabled/disabled per item (hidden from menu but not deleted)
Add new item — form with label, action type selector, target, icon
Delete item (with confirmation)
Preview pane showing how the RMB menu will look with current settings
Changes are saved via PUT /orgs/{org_slug}/rmb-items (full replacement of the list).
A “Reset to defaults” action restores only the non-removable system defaults.
AS-0 — 2026-05-06 — „in the app settings it should be possible to add or demo or manage order of items in RMB”
REQ-RMB-005 SREDNI
RMB demo mode
The RMB Menu Editor includes a Demo Mode toggle per item. When demo mode is active for an item,
activating it from the RMB menu shows the confirmation / action flow as a walkthrough without executing
the real backend action. This is used to demonstrate app capabilities to stakeholders without triggering
live environment changes. Demo mode items are visually tagged with a DEMO pill in the menu.
AS-0 — 2026-05-06 — „add or demo or manage order of items in RMB”
Nawigacja roli — przyciski w powloce aplikacji
REQ-NAV-004 KRYTYCZNY
Role-contextual action buttons in app shell header
The app shell header (visible inside any workspace, next to the “Hub” / Back button) must
display role-contextual action buttons based on the authenticated user’s role for the current org:
Admin role: a Manage button that navigates to
APP_MGMT.html?org={current_org}&skin={current_skin} —
the App Management page for this org. Must be the same URL that hub card click produces.
Product Owner role: an Edit button that opens
WORMWOOD_APP.html?org={current_org}&skin={current_skin} —
the Orchestrator pipeline canvas for this org — in a new tab.
Users with both roles see both buttons.
Users with neither role (viewer, operator) see neither button.
Roles are resolved from S.role set during enterWorkspace(). The role is
sourced from the /orgs/user-hub response field role for the matching org.
Accepted role values for the Admin button: admin, owner.
Accepted role values for the Edit button: product_owner, owner.
Both buttons must be styled consistently with the existing Back to Hub button (same height, ghost style,
separated by a vertical divider). The Manage button uses a settings/gear icon; the Edit button uses a
pipeline/node icon.
AS-0 — 2026-05-06 — „each app, next to back to hub button needs Edit button available to admins which leads to Orchestrator … admin gets manage button, product owner gets edit button”
Zarzadzanie uzytkownikami — NeXus RBAC
REQ-USR-001 KRYTYCZNY
NeXus platform RBAC model
NeXus must enforce a role-based access control model at the platform level.
Roles are defined per user per org (a user may be Admin in one org and Viewer in another).
The following roles must be supported:
Owner — all permissions; inherits Admin + Product Owner rights
Admin — can manage environments, backups, users for the org; sees Manage button
Product Owner — can view and edit pipelines in the Orchestrator; sees Edit button
Operator — can execute pipelines and view dashboards; no management access
Viewer — read-only access to all views; cannot execute or modify
Role assignments are stored in _tbl_nexus_user_org_roles (user_email, org_id, role).
The /orgs/user-hub API must return the resolved role for each org in the role field.
All UI surfaces (app shell buttons, sidebar items, env action buttons) must gate visibility on these roles.
AS-0 — 2026-05-06 — „we need a requirement for user management page opening from NeXus dashboard, with RBAC for NeXus”
REQ-USR-002 KRYTYCZNY
User management page accessible from NeXus hub
The NeXus hub dashboard must provide access to a User Management page, accessible only
to users with the Admin or Owner role on at least one org. Entry points:
Hub topbar — avatar/profile dropdown includes a “User Management” link (visible only to Admins/Owners)
Direct URL: USER_MGMT.html served under /nexus-ui/
The hub-level User Management page shows all orgs the logged-in user administers. For each org it allows:
View current users and their roles
Invite a new user by email (creates a pending invite or immediately adds with specified role)
Change role of existing user
Remove user from org
API: GET /orgs/{org_slug}/users, POST /orgs/{org_slug}/users,
PUT /orgs/{org_slug}/users/{email}, DELETE /orgs/{org_slug}/users/{email}.
The page is a standalone SPA registered under /nexus-ui/USER_MGMT.html.
AS-0 — 2026-05-06 — „user management page opening from NeXus dashboard with RBAC for NeXus”
REQ-USR-003 WYSOKI
Per-app user management in App Management view
The App Management page (APP_MGMT.html) must include a Users tab/section
visible only to users with the Admin or Owner role for the current org. This section allows:
View all users assigned to this org with their roles
Add user: email + role selector (dropdown of roles from REQ-USR-001)
Edit role: change role of existing user inline
Remove user from this org (with confirmation dialog)
Changes are saved immediately via the user management API endpoints defined in REQ-USR-002.
The section is hidden entirely (not just disabled) for non-admin users.
Admins managing their own role see a warning: “You cannot demote yourself.”
AS-0 — 2026-05-06 — „user management from app management view for each app”
Nesto — Role-Variant App UX (App-Level RBAC)
REQ-NESTO-001 KRYTYCZNY
Nesto role-variant form sets — each user type sees only their capabilities
The Nesto workspace must present a distinct form set, navigation structure, and visual style
for each user role. Roles are resolved from S.nestoRole set at workspace entry from the
user’s assigned Nesto role. The following role variants must be supported:
HR Admin — full 10-field worker intake form + worker queue (all workers in
DocumentsPending / InValidation states) + document completeness dashboard + ability to edit/reassign
records. Can submit on behalf of workers.
Style: dense, data-table-heavy, administrative palette.
HR Manager — decision queue only: workers in PendingReview state.
Decision variant form: worker summary, compliance scorecard (17 rules), document thumbnails,
Approve / Reject / Request More Info buttons, mandatory note on reject/request.
Cannot create worker records or edit intake fields.
Style: approval-focused, green/red decision emphasis.
Document Admin — OCR review queue: documents flagged for manual review
(confidence < 0.85). Per-document: extracted fields editable, confidence score displayed,
confirm / override / reject buttons. Cannot approve workers or execute government forwarding.
Style: document-centric, confidence bar visualisation.
Operations Lead — full pipeline status dashboard: all workers across all
lifecycle stages (Draft → Complete), aggregate metrics (SLA breaches, forwarding failures,
pending review count, 30-day throughput), escalation actions (re-trigger stuck pipelines).
Read access to all decision history. Cannot approve or create records.
Style: management dashboard, charts and KPI widgets.
Compliance Officer (Auditor) — read-only full audit trail: all worker
records across all statuses, all HRDecision entities, all ValidationResult entities, full
ForwardResult history. Export to CSV. No mutation capability.
Style: audit log table, strict read-only indicators.
Shared forms (visible across multiple roles, scoped by permission):
Worker status tracker (own record only for Submitter; all records for HR Admin / Ops Lead)
Notification preferences (own profile, all roles)
Document upload form (Submitter + HR Admin; HR Manager sees read-only thumbnails)
Role is determined from the Nesto-specific role stored in _tbl_nexus_user_org_roles
for the Nesto org. The ChameleonV2 form renderer receives the role as a parameter and selects the
appropriate schema variant. Unknown or missing Nesto role → Submitter variant as safe default.
Each variant must have a visually distinct sidebar navigation set — only menu items relevant to
that role’s capabilities are shown. The nav items are driven by the role-appropriate
nesto-nav-menu pipeline variant (one pipeline per role, or one pipeline with
role-scoped filtering).
AS-0 — 2026-05-08 — „in case of Nesto, each user type, like Worker, HR Manager etc, is to have THEIR OWN SET OF FORMS, differently styled, containing their app capabilities only, plus shared ones. this should be distinguished by login and role assignment”
REQ-NESTO-002 KRYTYCZNY
Hub card RBAC-flavor pills — direct role-scoped entry to Nesto app
The Nesto org card on the hub dashboard must display per-role access pills for every
Nesto RBAC role assigned to the logged-in user. Each pill is a button that opens the Nesto workspace
directly pre-configured for that role variant (bypassing the default single-entry-point).
Pill rendering rules:
One pill per role assigned to the user for the Nesto org, derived from
/orgs/user-hub response field nesto_roles (array of role strings)
Pills are rendered inside the card footer action area (.hub-card-actions),
below the existing action links, separated by a divider labelled “Open as:”
Maximum 3 pills shown inline; if user has > 3 roles, remaining shown in a “+N more”
dropdown expanding on click
Pills are only shown for the Nesto org card — generic orgs retain the existing
single “Open App” link behaviour
If user has exactly one Nesto role, no pills section is shown — the standard
“Open App” link opens the app in that single role variant automatically
API change required:/orgs/user-hub response for the Nesto org must
include "nesto_roles": ["hr_admin", "hr_manager"] alongside the existing "role"
field. For non-Nesto orgs, nesto_roles is absent or empty.
AS-0 — 2026-05-08 — „there should also be relevant pills on app card in dashboard to allow direct access to app in each RBAC flavor”
REQ-NESTO-003 KRYTYCZNY
Admin/Owner role-switch via profile menu inside Nesto workspace
Users with Admin or Owner NeXus role for the Nesto org must be able to
switch their active Nesto app role without logging out, via a role-switcher control
in the app shell profile/avatar dropdown menu inside the Nesto workspace.
Behaviour:
The profile dropdown (top-right avatar) includes a “View as role:” sub-menu when
the current org is Nesto and the user’s NeXus role is admin or
owner
The sub-menu lists all 6 Nesto role variants (Submitter, HR Admin, HR Manager, Doc Admin,
Ops Lead, Auditor), with a checkmark on the currently active variant
Selecting a role variant immediately reloads the Nesto workspace in that variant:
navigation set, sidebar, forms, and data scope all update to reflect the selected role
The active role is stored in S.nestoRole (session state, not persisted to DB)
so it resets to the user’s primary assigned role on next login
A visible indicator is shown in the topbar when the user is viewing a non-primary role:
e.g., a badge “Viewing as: HR Manager” in amber, with a “Reset to my role”
link that restores the default
Admin/Owner retain full data access regardless of the active view role — the switch
is a UX view filter, not an actual permission reduction
This switcher is not shown to users without Admin/Owner NeXus role
This enables administrators to QA all role variant views and train end-users without separate
test accounts.
AS-0 — 2026-05-08 — „admin and owner have all role access and should have ability to change logged role through their profile menu”
Wormwood — Data Schema Editor
REQ-SCHEMA-001 KRYTYCZNY
Entity class editor — create, view, edit, delete entity class schemas
The Wormwood Orchestrator (WORMWOOD_APP.html) Classes tab must provide a
full CRUD interface for entity class schemas stored in deltaPrism. Currently this tab is read-only.
Required capabilities:
List view: all entity classes for the selected org, showing class_slug, field count,
retention policy, and last-modified timestamp. Filter by org.
Create: "New Class" button opens a form with: class_slug (unique within org),
display label, org selector, retention_days (nullable = no retention), description field.
Slug must be validated: lowercase, hyphens only, 3-60 chars, unique. Save calls
POST /orgs/{slug}/schema/classes.
Field editor: per-class table of fields with inline add/edit/delete rows.
Each field has: name, label (display), BDT selector (from registered BDTs — see REQ-SCHEMA-002),
required (boolean), default value. Fields may be reordered by drag-and-drop.
Changes to fields call PUT /orgs/{slug}/schema/classes/{class_slug}.
Delete: entity class deletion requires confirmation modal showing
“This will break any FormNode, ListViewNode, or pipeline referencing this class.”
Calls DELETE /orgs/{slug}/schema/classes/{class_slug}. Blocked if any active
pipeline references this class (API returns 409; UI shows blocker list).
API endpoints required (Wormwood):GET /orgs/{slug}/schema/classes,
POST /orgs/{slug}/schema/classes,
PUT /orgs/{slug}/schema/classes/{class_slug},
DELETE /orgs/{slug}/schema/classes/{class_slug}.
All require X-API-Key header. 409 response when deletion is blocked.
AS-0 — 2026-05-08 — „requirements for wormwood for data schema editor, which, between other things, would allow to edit things like data classes, which feed into Form Node”
REQ-SCHEMA-002 KRYTYCZNY
Business Data Type editor — define and manage BDT registry
The Wormwood Orchestrator Properties tab (currently read-only rows) must provide a
BDT (Business Data Type) browser and editor. BDTs are the canonical type system that entity class
fields must reference (per NEXUS_BDT_REGISTRY.md rule: no raw primitive types allowed).
Required capabilities:
BDT list: all registered BDTs, grouped by category (Monetary, Score, Status,
Temporal, Identity, Custom). Columns: name, python_type, lifecycle class, unit, nullable, constraint summary.
Edit BDT: all fields editable except name. Warning shown if the BDT is referenced
by any entity class field: “{N} fields in {M} entity classes reference this type.
Constraint changes will be validated against existing data on next deltaPrism schema sync.”
Delete BDT: blocked if referenced by any entity class field. API returns 409
with list of referencing fields; UI shows blocker table.
Usage count badge: each BDT row shows how many entity class fields reference it.
API endpoints required (Wormwood):GET /schema/bdts,
POST /schema/bdts,
PUT /schema/bdts/{name},
DELETE /schema/bdts/{name}.
Global scope (not per-org). All require X-API-Key.
AS-0 — 2026-05-08 — „that should include editing business data types”
REQ-SCHEMA-003 WYSOKI
FormNode schema preview — live ChameleonV2 form preview from entity class
When a FormNode is selected on the Orchestrator pipeline canvas, the node inspector
side-panel must include a “Preview Form” section that renders a live
ChameleonV2 form preview using the entity class schema referenced by that FormNode’s
class_slug parameter.
Behaviour:
Fetches the entity class schema from GET /orgs/{slug}/schema/classes/{class_slug}
Renders the ChameleonV2 form using the same arcToChamelon() adapter used in NEXUS_APP.html
Preview is non-submittable (inputs enabled for visual inspection only; submit button disabled with tooltip “Preview only”)
Role selector shown above the preview: dropdown of available ChameleonV2 schema variants for this class (if any). Default = no filter (all fields visible)
If class_slug is unset or class not found, side-panel shows: “No entity class configured for this FormNode. Set class_slug in node parameters.”
This allows engineers and Product Owners to verify that a FormNode will render the expected
ChameleonV2 form without executing the pipeline.
AS-0 — 2026-05-08 — „data schema editor which would allow to edit things like data classes, which feed into Form Node”
REQ-SCHEMA-004 WYSOKI
Schema validation — entity class fields must reference registered BDTs
The entity class editor (REQ-SCHEMA-001) must enforce the BDT assignment rule from
NEXUS_BDT_REGISTRY.md: no field may use a raw primitive type without BDT assignment.
Enforcement:
The field editor’s type selector is a BDT dropdown (not a primitive dropdown).
It lists all registered BDTs grouped by category. Searching by name or description is supported.
A field without a BDT assigned cannot be saved. The Save button is disabled and shows a
tooltip: “All fields must have a Business Data Type assigned.”
The BDT dropdown shows the underlying python_type as a secondary label to aid selection
(e.g., “PLN_Amount — float”, “ISO_Date — str”)
If a selected BDT is subsequently deleted (ISSUE-069 prevention): the entity class editor
highlights orphaned fields with a warning icon and requires re-assignment before saving
API enforcement: the POST /orgs/{slug}/schema/classes and
PUT endpoints reject payloads containing fields with unregistered BDT names
(HTTP 422 with field-level error details).
Wherever a URL or link is displayed in any NeXus SPA surface (APP_MGMT environment cards, env URL field,
RMB item editor action target, User Management invite links, pipeline webhook URLs, etc.), the following
rules apply when the URL is longer than 48 characters:
The displayed text is truncated with a trailing … (CSS text-overflow: ellipsis)
Full URL is shown in a title tooltip on hover
A copy-to-clipboard button (“⎘” or clipboard icon) appears
inline to the right of the truncated URL. Clicking it copies the full URL to the clipboard and shows
a transient “Copied” confirmation (tooltip or toast, 1.5 s duration).
The copy button is always visible (not just on hover) when the URL is truncated
Implementation: a shared urlCell(url) helper function returns the HTML fragment
(truncated span + copy button) to be used wherever URLs are rendered. The helper must handle
null / empty URLs gracefully (no copy button shown; displays “—”).
This requirement applies to all three SPAs: NEXUS_APP.html, APP_MGMT.html,
WORMWOOD_APP.html, and any future SPAs under /nexus-ui/.
AS-0 — 2026-05-06 — „wherever a link is displayed it should be truncated when too long but have a copy to clipboard button”
REQ-HEALTH — Workspace Health Checks
REQ-HEALTH-001 KRYTYCZNY
Workspace health endpoint per org
System musi wystawiać endpoint GET /orgs/{org_slug}/health zwracający zagregowany stan zdrowia workspace'u: status (running / degraded / stopped), wersję deploymentu, czas ostatniego healthy check, oraz listę komponentów z ich stanami. Backend agreguje dane z aktywnych środowisk org. Brak środowisk → status unknown. Endpoint wymaga X-API-Key. Odpowiedź: JSON z polami org_slug, status, version, last_check, components (array).
AS-0 — 2026-05-07 — „add requirements for workspace health checks and of environment and display state on the cards in the dashboard and inside the app management page”
REQ-HEALTH-002 KRYTYCZNY
Stan zdrowia workspace'u na kartach hub
Każda karta aplikacji na dashboardzie hub musi wyświetlać stan zdrowia workspace'u jako kolorowy wskaźnik (.hub-card-health-dot). Kolory: zielony = running, żółty = degraded, czerwony = stopped, szary = unknown. Wskaźnik jest odświeżany co 10 sekund przez polling GET /orgs/{org_slug}/health. Kliknięcie wskaźnika otwiera APP_MGMT.html?org={slug}. Wskaźnik musi wyświetlać tooltip z tekstem stanu (np. "Działa", "Zdegradowany") po najechaniu.
AS-0 — 2026-05-07 — „display state on the cards in the dashboard”
REQ-HEALTH-003 WYSOKI
Stan zdrowia workspace'u w APP_MGMT — sekcja Health
Strona zarządzania aplikacją (APP_MGMT.html) musi zawierać dedykowaną sekcję "Zdrowie Workspace'u" z: (1) banerem statusu zagregowanego (running / degraded / stopped) z kolorem i ikoną, (2) tabelą komponentów ze stanem każdego z nich, wersją i czasem ostatniego sprawdzenia, (3) przyciskiem "Odśwież" wywołującym natychmiastowe odpytanie GET /orgs/{org_slug}/health. Sekcja jest odświeżana automatycznie co 30 s gdy jest widoczna (lub co 10 s gdy status ≠ running). Brak danych = komunikat "Brak danych zdrowia — odśwież manualnie".
AS-0 — 2026-05-07 — „display state on the cards in the dashboard and inside the app management page”
ID
Opis
Status
Uwagi
REQ-ENV-001
Health status on hub cards
OTWARTE
Requires environment health polling endpoint + card indicator UI
USER_MGMT.html SPA; invite/role change/remove; Admin & Owner only
REQ-USR-003
Per-app user management in APP_MGMT
OTWARTE
Users tab in APP_MGMT; add/edit/remove; hidden for non-admins
REQ-UX-008
Long URL truncation + copy-to-clipboard
OTWARTE
Truncate >48 chars; full URL in title tooltip; clipboard icon; 1.5s Copied toast; shared urlCell() helper
REQ-HEALTH-001
Workspace health endpoint per org
OTWARTE
GET /orgs/{org_slug}/health — Wormwood-side; aggregates env status; returns status/version/components JSON
REQ-HEALTH-002
Health state on hub cards
OTWARTE
.hub-card-health-dot; 4 colors; 10 s poll; click → APP_MGMT; tooltip on hover
REQ-HEALTH-003
Health section in APP_MGMT
OTWARTE
Health section tab; component table; refresh button; auto-refresh 10/30 s; graceful empty state
REQ-NESTO-001
Nesto role-variant form sets
OTWARTE
6 role variants (Submitter/HR Admin/HR Manager/Doc Admin/Ops Lead/Auditor); distinct nav, forms, styles per role; ChameleonV2 schema variant parameter; shared forms scoped by permission
REQ-NESTO-002
Hub card RBAC-flavor pills
OTWARTE
Per-role entry pills on Nesto card; URL ?nestoRole={slug}; user-hub API returns nesto_roles array; max 3 inline + overflow; single-role = no pills
REQ-NESTO-003
Admin/Owner role-switch in profile menu
OTWARTE
View-as switcher in avatar dropdown (Nesto only); all 6 variants listed; S.nestoRole session state; amber topbar badge + reset link; Admin/Owner only
REQ-SCHEMA-001
Entity class editor — CRUD for deltaPrism schemas
OTWARTE
WORMWOOD_APP Classes tab: New/Edit/Delete entity classes; field editor with BDT assignment; 409 block if referenced by active pipeline; retention_days config; API POST/PUT/DELETE /orgs/{slug}/schema/classes
REQ-SCHEMA-002
BDT editor — define and manage Business Data Types
OTWARTE
WORMWOOD_APP Properties tab: BDT CRUD; lifecycle class selector; numeric/string constraint forms; usage count badge; 409 block if referenced; API POST/PUT/DELETE /schema/bdts
REQ-SCHEMA-003
FormNode schema preview in Orchestrator
OTWARTE
Node inspector side-panel: live ChameleonV2 preview for FormNode; role selector for variant preview; non-submittable; empty state if class_slug unset
REQ-SCHEMA-004
Schema validation — BDT assignment mandatory
OTWARTE
Field editor BDT dropdown (not primitive selector); all fields must have BDT; Save blocked without BDT; API 422 for unregistered BDT names
REQ-SCHEMA-005
Schema change history audit log
OTWARTE
Collapsible history per class/BDT; immutable entries; timestamp/user/change_type/diff; API GET .../history; 100-entry pagination
REQ-AUTH — Authentication & RBAC
Wymagania dotyczące uwierzytelniania użytkowników platformy przez Google OAuth 2.0 i kontroli dostępu opartej na rolach (RBAC). ISSUE-073 RESOLVED 2026-05-11 — dokumentacja łańcucha AS-0 uzupełniona, implementacja OAuth 2.0 zweryfikowana w Gate 11 S34/S35 (149/149 PASS, 2026-05-25). REQ-AUTH-001, REQ-AUTH-002, REQ-RBAC-001, REQ-RBAC-002: ZAIMPLEMENTOWANE. REQ-AUTH-005: PLANOWANE (MVP WP3 — backend zaimplementowany, DoD nie spełniony). REQ-AUTH-006, REQ-AUTH-007: OTWARTE. Patrz także: REQ-RBAC-001..003.
REQ-AUTH-001 KRYTYCZNYZAIMPLEMENTOWANE
Logowanie przez Google OAuth 2.0 — bez hasła
Platforma NeXus NIE może używać lokalnych haseł. Jedynym dozwolonym mechanizmem uwierzytelniania jest Google OAuth 2.0 z PKCE (Proof Key for Code Exchange).
Przycisk „Sign in with Google” w ekranie logowania inicjuje przepływ OAuth.
Silnik generuje URL autoryzacyjny z code_challenge (S256) i redirectuje przeglądarkę do Google.
Po autoryzacji Google redirectuje do /auth/callback z kodem autoryzacyjnym.
Silnik wymienia kod na tokeny, weryfikuje id_token, tworzy lub aktualizuje rekord NexusPlatformUser w bazie danych.
Silnik podpisuje Nexus JWT i redirectuje do SPA z #token={jwt} w URL.
User Stories
US-AUTH-001-1: Jako użytkownik chcę zalogować się do NeXus klikając przycisk Google — bez tworzenia lokalnego hasła — aby uniknąć zarządzania oddzielną para haseł.
US-AUTH-001-2: Jako użytkownik chcę być przekierowany do hubów po pomyślnym logowaniu — nie z powrotem na ekran logowania — aby móc używać systemu.
US-AUTH-001-3: Jako użytkownik chcę widzieć czytelny komunikat błędu gdy logowanie nie powiedzie się, aby wiedzieć co się stało.
Kryteria akceptacji
AC-001-01: Kliknięcie „Sign in with Google” otwiera Google OAuth w tej samej karcie. Nie otwiera pop-up.
AC-001-02: Po wyborze konta Google użytkownik ląduje na stronie hubów (nie na ekranie logowania).
AC-001-03: Tokeny OAuth są wymieniane wyłącznie po stronie serwera (silnik). Przeglądarka nigdy nie widzi access_token Google.
AC-001-04: Błędy logowania (token_exchange_failed, invalid_state, account_deactivated) wyświetlają czytelny komunikat po polsku w SPA.
AS-0 — 2026-05-11T13:11:12Z — „how do we manage user access? how do we protect logins? why si there no google auth?” + 2026-05-11T13:17:12Z — „users registering through google auth login, with no app added, can't do anything now” + 2026-05-11T19:21:37Z — „login does not work, after chosing account i land back on the login screen”
REQ-AUTH-002 KRYTYCZNYZAIMPLEMENTOWANE
Nexus JWT — struktura i czas życia
Po pomyślnym OAuth silnik emituje JWT podpisany kluczem NEXUS_JWT_SECRET (HS256). Payload JWT zawiera:
sub — ID użytkownika w tabeli nexus_platform_user
email — adres email z konta Google
name — imię i nazwisko z profilu Google
role — nexus_user lub nexus_admin
iat, exp — czas wystawienia i wygaśnięcia (8h)
Token jest przechowywany w sessionStorage pod kluczem nexus-jwt. Po zamknięciu karty token jest kasowany (brak persist).
User Stories
US-AUTH-002-1: Jako użytkownik chcę być zalogowany przez cały dzień pracy bez powtarzania logowania (sesja 8h), aby móc pracować bez przerw.
US-AUTH-002-2: Jako użytkownik chcę być wylogowany automatycznie gdy zamknę kartę przeglądarki, aby chronić bezpieczeństwo na współdzielonych stacjach roboczych.
Kryteria akceptacji
AC-002-01: JWT zawiera pola: sub, email, name, role, iat, exp.
AC-002-02:exp − iat = 28800 (8 godzin).
AC-002-03: Token przechowywany w sessionStorage['nexus-jwt']. Po zamknięciu karty brak tokena w nowej karcie.
AC-002-04: Wygasły token skutkuje automatycznym przekierowaniem na ekran logowania.
AS-0 — 2026-05-11T13:17:12Z — „users registering through google auth login, with no app added, can't do anything now, until they get access to apps”
REQ-AUTH-003 KRYTYCZNYZAIMPLEMENTOWANE
RBAC — widoczność nawigacji na podstawie roli
Nawigacja główna (top nav) wyświetla grupy wyłącznie na podstawie roli z JWT:
Stan
Widoczne grupy nawigacyjne
Nie zalogowany
Brak — widoczna tylko marka NEXUS
nexus_user
Documentation (User Manual, Node Registry)
nexus_admin
Strategy, Architecture, Use Cases, Platform, Documentation
Grupy nawigacyjne posiadają atrybut data-nav-access (admin lub user). Funkcja _applyNavRbac(role) w SPA steruje widocznością przy każdej zmianie stanu logowania.
AS-0 — 2026-05-11 — „i am the superadmin of the system, i should have access to everything including rbac”
REQ-AUTH-004 KRYTYCZNYZAIMPLEMENTOWANE
NEXUS_ADMIN_EMAILS — statyczne nadawanie roli administratora
Silnik odczytuje zmiennej środowiskową NEXUS_ADMIN_EMAILS (lista emailów oddzielona przecinkami). Przy każdym logowaniu, jeżeli email użytkownika występuje na liście, rola jest wymuszana na nexus_admin — niezależnie od wartości w bazie danych. Mechanizm jest idempotentny (wielokrotne logowania nie tworzą duplikatów). Aktualna wartość: m.lubkowski@ou-uv.com.
AS-0 — 2026-05-11 — „i am the superadmin of the system”
REQ-AUTH-005 WYSOKIPLANOWANE
Panel zarządzania użytkownikami — Admin UI
User Stories
US-AUTH-005-1: Jako nexus_admin chcę widzieć tabelę wszystkich zarejestrowanych użytkowników platformy (email, imię i nazwisko, aktualna rola, data ostatniego logowania, status aktywności), aby wiedzieć kto ma dostęp do systemu.
US-AUTH-005-2: Jako nexus_admin chcę zmienić rolę dowolnego użytkownika z nexus_user na nexus_admin lub odwrotnie, aby kontrolować poziom dostępu do dokumentacji i panelów administracyjnych.
US-AUTH-005-3: Jako nexus_admin chcę dezaktywować konto użytkownika (zablokować możliwość logowania bez usuwania danych historycznych), aby cofnąć dostęp bez utraty audit trail.
US-AUTH-005-4: Jako nexus_admin chcę ponownie aktywować dezaktywowane konto, aby przywrócić dostęp bez wymagania ponownej rejestracji przez Google.
Kryteria akceptacji
AC-005-01: Zakładka „Użytkownicy” w APP_MGMT.html widoczna wyłącznie gdy JWT zawiera role=nexus_admin. Brak zakładki dla roli nexus_user.
AC-005-02:GET /auth/users zwraca listę wszystkich NexusPlatformUser w JSON. Pola: id, email, display_name, nexus_role, is_active, last_login_at, created_at. HTTP 403 dla tokena z rolą nexus_user.
AC-005-03: Tabela użytkowników w UI wyświetla wszystkie pola z AC-005-02. Puste last_login_at → „Nigdy”. Status aktywności jako wizualny znacznik.
AC-005-04:PATCH /auth/users/{id}/role z body {"role":"nexus_admin"} lub {"role":"nexus_user"} aktualizuje nexus_role w bazie i zwraca zaktualizowany rekord. HTTP 422 dla nieprawidłowej wartości roli.
AC-005-05:PATCH /auth/users/{id}/active z body {"is_active":false} ustawia flagę. Użytkownik z is_active=false przy próbie OAuth → HTTP 403, kod account_deactivated. SPA wyświetla czytelny komunikat.
AC-005-06: Administrator nie może zdegradować własnego konta (zmienić roli dla id równego własnemu sub z JWT). Próba → HTTP 409, kod cannot_demote_self. UI blokuje przycisk przed wywołaniem API.
AC-005-07: Administrator nie może zdezaktywować własnego konta. Próba → HTTP 409, kod cannot_deactivate_self. UI blokuje przycisk przed wywołaniem API.
AC-005-08: Zmiana roli lub statusu aktywności jest natychmiast odzwierciedlona w tabeli. Toast potwierdzenia przy sukcesie; komunikat błędu przy niepowodzeniu.
AC-005-09: Wszystkie endpointy /auth/users* wymagają Authorization: Bearer {jwt}. Brak lub nieprawidłowy token → HTTP 401.
Ograniczenia
Dezaktywacja NIE usuwa danych — rekord zostaje z is_active=false.
NEXUS_ADMIN_EMAILS (REQ-AUTH-004) działa równocześnie — email na liście zawsze wymusza nexus_admin niezależnie od nexus_role w bazie.
Dezaktywowany użytkownik z NEXUS_ADMIN_EMAILS — flaga is_active=false ma pierwszeństwo i blokuje logowanie mimo występowania na liście.
Panel dostępny wyłącznie z APP_MGMT.html — nie z głównego dashboardu Hub.
Endpointy API (do implementacji)
Metoda
Ścieżka
Auth
Opis
GET
/auth/users
nexus_admin JWT
Lista wszystkich NexusPlatformUser
PATCH
/auth/users/{id}/role
nexus_admin JWT
Zmiana roli; blokada self-demotion (409)
PATCH
/auth/users/{id}/active
nexus_admin JWT
Zmiana is_active; blokada self-deactivation (409)
Lokalizacja UI: Nowa zakładka „Użytkownicy” w APP_MGMT.html. Widoczna wyłącznie przy role=nexus_admin. Mockupy: NEXUS_APP_MOCKUPS.html sekcja „User Management Panel” (krok 3 łańcucha dokumentacyjnego).
AS-0 — 2026-05-11T16:06:56Z — „so here is still the problem with the layout and rbac. i am the superadmin of the system, i should have access to everything including rbac to grant roles and users” + 2026-05-11T19:25:56Z — „what bout user management, RBAT management on Nexus and app level? has these been documented ALL THE WAY FROM AS-0 level?”
REQ-AUTH-006 WYSOKIOTWARTE
RBAC na poziomie aplikacji (per-app roles)
Poza globalną rolą platformy, użytkownik może posiadać różne role w poszczególnych aplikacjach (np. viewer/editor/admin w ARC, Nesto itp.). Role per-app są przechowywane w tabeli org_user (kolumna role). Karty dashboardu Hub muszą wyświetlać aktualną rolę użytkownika w danej aplikacji.
AS-0 — 2026-05-03T18:08:14Z — „RBAC roles available should be shown clearly on the cards”
REQ-AUTH-007 ŚREDNIOTWARTE
Obsługa błędów OAuth — komunikaty użytkownikowi
Wszystkie scenariusze błędów OAuth muszą być obsłużone z czytelnymi komunikatami (nie technicznymi). Znane kody błędów: token_exchange_failed, invalid_state, no_code, no_email, db_error. SPA musi mapować te kody na przyjazne komunikaty języka naturalnego.
AS-0 — 2026-05-11T19:21:37Z — „login does not work, after chosing account i land back on the login screen” (sesja debugowania OAuth; kody błędów token_exchange_failed, invalid_state, no_code, no_email, db_error zidentyfikowane jako wymagające czytelnych komunikatów w języku naturalnym)
REQ-RBAC — Role-Based Access Control
Wymagania dotyczące kontroli dostępu opartej na rolach na poziomie platformy i aplikacji. Wszystkie wymogi RBAC muszą być weryfikowane przez Gate 11. Status: OTWARTE — ISSUE-073 (implementacja częściowa, DoD nie spełniony).
REQ-RBAC-001 KRYTYCZNYZAIMPLEMENTOWANE
Role platformowe — nexus_admin i nexus_user
Platforma NeXus definiuje dwie role na poziomie platformy:
Rola
Uprawnienia
nexus_user
Dostęp do dokumentacji użytkownika (User Manual, Node Registry). Brak dostępu do dokumentacji architektonicznej, commercials, use cases, panelów administracyjnych.
nexus_admin
Pełny dostęp do wszystkich grup nawigacyjnych i dokumentacji. Dostęp do APP_MGMT.html ze zakładką Użytkownicy. Możliwość zmiany ról innych użytkowników.
Domyślna rola nowego użytkownika: nexus_user. Rola może być zmieniona przez nexus_admin przez panel zarządzania (REQ-AUTH-005) lub statycznie przez NEXUS_ADMIN_EMAILS (REQ-AUTH-004).
User Stories
US-RBAC-001-1: Jako użytkownik zarejestrowany przez Google chcę mieć dostęp do dokumentacji użytkownika, aby móc uczyć się używać platformy.
US-RBAC-001-2: Jako nexus_admin chcę mieć dostęp do wszystkich obszarów systemu, aby móc administrować platformą.
US-RBAC-001-3: Jako użytkownik z rolą nexus_user nie chcę widzieć dokumentów strategicznych i komercyjnych, dostępnych tylko dla administratorów.
Kryteria akceptacji
AC-RBAC-001-01: Nowy użytkownik po pierwszym logowaniu ma rolę nexus_user w bazie danych.
AC-RBAC-001-02: JWT zawiera pole role z wartością nexus_user lub nexus_admin.
AC-RBAC-001-03: Użytkownik z NEXUS_ADMIN_EMAILS otrzymuje nexus_admin przy każdym logowaniu — niezależnie od rekordu w bazie.
AS-0 — 2026-05-11T13:17:12Z — „well, we need registration and app level RBAC, as well as Nexus RBAC. users registering through google auth login, with no app added, can't do anything now, until they get access to apps. in the future they wil lbe able to crete their own app and spin environemtns to run them, but we do not have subscriptions now, so user with no RBAC can log into Nexus with google and maintain their profile”
REQ-RBAC-002 WYSOKIZAIMPLEMENTOWANE
RBAC — gating dostępu do dokumentacji
Dokumentacja platformy musi być ukryta za logowaniem z kontrolowanym dostępem opartym na rolach:
Dokument / Sekcja
Wymagana rola
User Manual, Node Registry
nexus_user lub nexus_admin
Architecture, Use Cases, Strategy, Platform, Commercials
nexus_admin tylko
Ekran logowania
Brak logowania wymagane
Niezalogowany użytkownik widzi wyłącznie markę NEXUS w nawigacji. Grupy nawigacyjne są ukryte do momentu potwierdzenia JWT z odpowiednią rolą.
User Stories
US-RBAC-002-1: Jako właściciel systemu chcę być pewien, że dokumentacja architektoniczna i komercyjna jest dostępna wyłącznie dla administratorów, aby chronić informacje biznesowe.
US-RBAC-002-2: Jako nexus_user chcę mieć dostęp do dokumentacji użytkownika po zalogowaniu, aby uczyć się używać systemu.
Kryteria akceptacji
AC-RBAC-002-01: Niezalogowany użytkownik nie widzi żadnych grup nawigacyjnych — tylko logo NEXUS.
AC-RBAC-002-02: Zalogowany nexus_user widzi grupy: Documentation (User Manual, Node Registry). Grupy Strategy, Architecture, Use Cases, Platform są niewidoczne.
AC-RBAC-002-03: Zalogowany nexus_admin widzi wszystkie grupy: Strategy, Architecture, Use Cases, Platform, Documentation.
AS-0 — 2026-05-11T14:12:55Z — „docs should be behind login, and actually only available with certain level of RBAC access. user manual for building Nexus app and description of Nexus nodes etc can be made available to users logged in, but architecture etc, usecases, commercials are to be available to admin sonly for now”
REQ-RBAC-003 WYSOKIOTWARTE
Role na poziomie aplikacji (per-app roles)
Poza globalną rolą platformy, użytkownik może posiadać różne role w poszczególnych aplikacjach. Role per-app są przechowywane w tabeli org_user (kolumna role).
Rola per-app
Opis
owner
Pełny dostęp, możliwość usunięcia aplikacji
admin
Dostęp do konfiguracji pipelineów, zarządzanie użytkownikami aplikacji
editor
Możliwość edycji konfiguracji i uruchamiania pipelineów
viewer
Wyłącznie widok danych i wyników, brak możliwości modyfikacji
Karty dashboardu Hub muszą wyświetlać aktualną rolę użytkownika w danej aplikacji. Użytkownik bez roli per-app w danej aplikacji nie może do niej uzyskać dostępu.
User Stories
US-RBAC-003-1: Jako zalogowany użytkownik bez przypisanej roli w żadnej aplikacji chcę widzieć komunikat „Nie masz dostępu do żadnych aplikacji”, aby rozumieć swój status.
US-RBAC-003-2: Jako użytkownik z rolą viewer w ARC chcę widzieć kartę ARC z badge'em viewer, aby wiedzieć jaki mam poziom dostępu.
Kryteria akceptacji
AC-RBAC-003-01: Karty aplikacji na dashboardzie Hub wyświetlają aktualną rolę użytkownika w tej aplikacji.
AC-RBAC-003-02: Użytkownik bez roli per-app widzi komunikat „Brak aplikacji” (nie błąd).
AC-RBAC-003-03: Dostęp do orkiestratora aplikacji wymaga roli co najmniej viewer w tej aplikacji.
AS-0 — 2026-05-11T13:17:12Z — „we need registration and app level RBAC, as well as Nexus RBAC. users registering through google auth login, with no app added, can't do anything now, until they get access to apps” + 2026-05-03T18:08:14Z — „RBAC roles available should be shown clearly on the cards”