Aplikacja `@report`

Zakres weryfikacji

Treść zachowana z obecnego źródła. Publikacja dokumentacji nie oznacza ponownego potwierdzenia wszystkich komend, przykładów i deklaracji możliwości.

Poziom: początkujący, średniozaawansowany i ekspert.

@report jest granicą systemu skierowaną do człowieka. Kompilator nie kończy jej na kliencie TypeScript ani komunikacie w konsoli. Buduje samodzielną aplikację WWW ze stanem połączenia, bezpiecznym widokiem danych i gotowym punktem uruchomienia.

flowchart LR
    SERVER["zadanie @server"] -->|"WebSocket + MessagePack"| REPORT["zadanie @report"]
    REPORT --> GEN["generator aplikacji"]
    GEN --> AUTO["panel automatyczny"]
    GEN --> CONFIG["widok deklaratywny"]
    GEN --> CUSTOM["adapter autora"]
    AUTO --> BROWSER["gotowa aplikacja WWW"]
    CONFIG --> BROWSER
    CUSTOM --> BROWSER

Co otrzymuje początkujący

Wystarczy zadanie z pustym ciałem:

task HomePanel(observations: chan<HomeObservation>) @report {}

Po junexis build . powstaje działający panel zawierający nazwę raportu, stan połączenia, ostatnią wartość, czas aktualizacji i historię ograniczoną do 50 wpisów. Rozłączenie nie jest ukrywane za ostatnim poprawnym pomiarem. Użytkownik widzi stany oczekiwania, aktywnego połączenia, utraty świeżości, ponownego łączenia, niezgodnego kontraktu i błędu renderowania.

junexis check .
junexis build .
junexis run . --duration 30

To jest pełny rezultat pierwszego kroku, a nie ćwiczenie typu „Hello World”. Panel odbiera dane z rzeczywiście uruchomionego zadania serwerowego.

Co zmienia średniozaawansowany

Widok można ułożyć bez przejmowania infrastruktury aplikacji:

junexis report scaffold . --declarative

Plik user/report/view.json wybiera panele, pola, etykiety, jednostki i układ. Build sprawdza, czy wskazane zadania i pola istnieją. Odrzuca także nieznany format, duplikat oraz niebezpieczną ścieżkę. Pusta lista pól nadal korzysta z renderera automatycznego, więc eksperyment nie odbiera działającego panelu.

Co kontroluje ekspert

Ekspert może dostarczyć adapter TypeScript/DOM, React albo Vue:

junexis report scaffold . --framework react

Pliki w user/report należą do autora i nie są nadpisywane przez kolejny build. Adapter otrzymuje typowane punkty mount, onObservation i onConnection, ale nadal korzysta z tego samego transportu, lifecycle i wersji kontraktu. Zależności autora są scalane w kontrolowany sposób; nie mogą zastąpić skryptów budowania ani zależności należących do generatora.

Co trafia do artefaktu

Build zapisuje źródła i kontrakty aplikacji:

out/report/
├── index.html
├── index.ts
├── report.css
├── browser.ts
├── runtime.ts
├── types.ts
├── deploy.ts
├── report-view.ts
├── report-view-contract.ts
├── report-adapter-contract.ts
├── user-adapter.ts
├── package.json
├── tsconfig.json
├── serve.mjs
└── junexis-report-manifest.json

Podczas junexis package powstaje dodatkowo minimalny runtime zawierający HTML, CSS, manifest, serve.mjs i gotowy dist/browser.js. Zweryfikowany System Bundle uruchomił natywny serwer i panel z rozpakowanego ZIP-a, bez checkoutu źródeł, Go, npm, TypeScriptu ani bundlera. Lokalny serwer statyczny panelu nadal korzysta z Node.js dostarczonego przez profil wykonawczy paczki.

Jakość i bezpieczeństwo

Automatyczne próby w prawdziwym Chrome potwierdziły:

jasny i ciemny motyw z kontrastem WCAG AA,
obsługę klawiatury i widoczny fokus,
układ dla szerokości 390 px,
respektowanie prefers-reduced-motion,
ograniczanie historii oraz dużych wartości,
widoczny cykl stale → reconnecting → rejoined,
odrzucenie niezgodnej wersji wire contract.

Odbiór za pomocą czytnika ekranu, Firefox, WebKit i systemowy tryb forced colors są następnymi rozszerzeniami macierzy jakości. Nie należy ich mylić z brakiem samej aplikacji: działający pion Chrome na Windows x64 jest zweryfikowany.

Następny krok

Wykonaj przepis na interfejs i raport, a następnie zobacz, jak panel zamyka ścieżkę moduły → SQLite → restart → @report.

Aplikacja @report