Application Factory¶

Cel¶

Application Factory buduje małe aplikacje, panele i procesy PWA na potrzeby użytkownika lub branży. Nie zastępuje pełnego zespołu produktowego przy systemach krytycznych. Jej przewagą jest połączenie generatora z kontraktami danych, komponentami UI, testami, Artifact Store i Execution Fabric.

Rezultatem jest candidate aplikacji możliwy do uruchomienia w preview. Preview nie nadpisuje aplikacji aktywnej, nie instaluje zależności w systemie i nie publikuje hostingu.

Karta modułu¶

Pole	Kontrakt
Odpowiedzialności	analiza potrzeb, model danych, UX, code candidate, testy, preview, packaging i handoff.
Wejścia	cel biznesowy, użytkownicy/role, proces, dane, brand, wymagania offline, integracje i kryteria dostępności.
Wyjścia	spec, repo candidate, build artifacts, test report, preview artifact, deployment plan.
Zależności	Agent/Tool Factory, design system, code workers, browser/device test harness, Artifact Store.
Uprawnienia	tworzenie w worktree/candidate; brak main promotion, install, deploy, domain i publish.
Autonomia	może iterować implementację i testy; zmiana zakresu lub integracji wymaga decyzji.
Walidacja	build, unit/integration/e2e, accessibility, responsive, security, data migration i visual review.
Awaria	izolowany candidate, zachowane preview, brak wpływu na aktywną aplikację; recovery z checkpointu.

Typy aplikacji¶

Factory wspiera: formularze terenowe offline, panele kierownika, kioski magazynowe, trackery projektów, portale klienta, dashboardy kamer, wewnętrzne katalogi wiedzy, narzędzia ofertowe i dedykowane widoki Control Center. Aplikacja może korzystać z NORBI jako backendu workflow, ale nie dostaje bezpośredniego dostępu do bazy ani approval credentials.

Proces od potrzeby do kandydata¶

Discovery. Norbi opisuje role, najważniejsze decyzje, dane wejściowe, wyjątki i warunki offline. Powstaje mapa procesu i lista poza zakresem.
Kontrakt. Definiowane są encje, stany, uprawnienia, API, walidacje, retencja i eventy. Każdy zapis ma właściciela i regułę konfliktu.
UX. Factory tworzy ścieżki krytyczne mobile-first, stany pusty/loading/error/offline, klawiaturę, czytnik ekranu i confirmation dla skutków.
Candidate. Kod powstaje w worktree. Dependencies pochodzą z zatwierdzonego źródła. Sekrety są mockami/uchwytami.
Test. Build, schema, migracje, e2e, accessibility, responsive i security. Dane testowe są syntetyczne.
Preview. Użytkownik otrzymuje działającą wersję oraz listę różnic, ograniczeń i scenariuszy.
Promotion/deploy. Osobne decyzje wiążą exact candidate, testy, konfigurację, środowisko i rollback.

flowchart TD
    P["Proces i role"] --> D["Model danych"]
    D --> U["UX flows"]
    U --> C["Candidate code"]
    C --> T["Build + tests"]
    T --> Q{"Gates OK?"}
    Q -->|nie| C
    Q -->|tak| V["Preview"]
    V --> R["Review człowieka"]
    R --> X["Oddzielny plan wdrożenia"]

Aplikacje PWA¶

PWA przechowuje lokalnie tylko dane konieczne do pracy offline, zaszyfrowane tam, gdzie platforma na to pozwala, z krótką retencją i możliwością zdalnego unieważnienia sesji. Synchronizacja używa wersji rekordów i jawnych konfliktów. Service worker nie może cache'ować approval secrets, prywatnych załączników bez polityki ani odpowiedzi innych użytkowników.

Telefon inicjuje job albo przedstawia decyzję; nie uruchamia adaptera wykonawczego. Kamera telefonu może dostarczyć zdjęcie jako artifact input, ale plik przechodzi klasyfikację i nie staje się zaufaną obserwacją bez walidacji.

Przykładowe polecenia¶

„Zbuduj PWA dla pracownika terenowego: zlecenia, zdjęcia, podpis klienta i synchronizacja offline.”
„Przygotuj panel kierownika do zatwierdzania zamian grafiku i podglądu pokrycia zmian.”
„Zrób kiosk magazynowy obsługiwany skanerem, bez dostępu do danych finansowych.”
„Przygotuj preview portalu klienta, ale nie podłączaj domeny ani realnego logowania.”

Pełny przebieg¶

Dla PWA pracownika Factory zaczyna od stanów: assigned, accepted, en_route, on_site, blocked, completed i awaiting_review. Zdjęcia są artifact IDs z geotagiem tylko za zgodą. Tryb offline zapisuje zdarzenia z client timestamp i monotonic sequence; serwer rozstrzyga konflikty. Kierownik widzi wyjątki i może odrzucić zamknięcie z powodem. Test obejmuje utratę sieci w połowie uploadu, powtórną synchronizację, zmianę czasu urządzenia, odwołanego pracownika i próbę odczytu cudzego zlecenia.

Walidacja wyniku¶

Oprócz testów kodu wykonywane są scenariusze zadaniowe na desktopie i małym ekranie, dostępność klawiaturą, kontrast, rozmiar celu dotykowego, offline/online transition, błędy API, migracja danych i ograniczenia ról. Preview zawiera realistyczne dane, ale nie dane produkcyjne. Visual review sprawdza hierarchię, gęstość i krytyczne confirmation.

Ryzyka i scenariusz awaryjny¶

Najczęstsze ryzyko to szybka aplikacja, która omija model domenowy i przenosi reguły do UI. Factory wymaga kontraktu backendowego przed ekranami. Inne ryzyka to dependency sprawl, cache danych prywatnych i słaba obsługa konfliktów offline. Przy nieudanym wdrożeniu aktywna wersja pozostaje bez zmian albo rollout zatrzymuje się na canary; rollback używa poprzedniego artefaktu i kompatybilnej migracji. Dane utworzone przez nową wersję nie są kasowane automatycznie.