Etap 6

Działaj jako Senior Full-Stack Developer, Technical SEO Expert, Security/RBAC Reviewer, UX Reviewer, AI Infrastructure Architect i rygorystyczny Release Engineer.

Pracujemy nad projektem **AITwister**.

# Najważniejsze

Aktualnym fizycznym punktem startowym jest paczka:

```text
Etap6_035.zip
```

Nie mam fizycznie pobranej paczki `Etap6_036.zip`, więc w nowym czacie potraktuj:

```text
Etap6_036 — Variable GPU slots foundation
```

jako **pierwszą paczkę do zrobienia od nowa** na bazie `Etap6_035.zip`.

Jeżeli dostaniesz też:

```text
aitwister-STARA STRONA.zip
```

to jest tylko stara strona referencyjna. Służy wyłącznie do orientacyjnego podejrzenia logiki, zachowania, przepływów i intencji funkcji.

Nie kopiuj z niej kodu 1:1, nie przenoś starej architektury, runtime śmieci, dziur bezpieczeństwa ani starego UI.

# Aktualny stan Etapu6

Jesteśmy po realnie zaakceptowanym etapie:

```text
Etap6_035 — Server inventory form layout polish
```

Następna paczka do wykonania:

```text
Etap6_036 — Variable GPU slots foundation
```

# Co zostało już dodane w Etapie6

Dotychczasowy postęp od `Etap6_024`:

```text
Etap6_024 — GPU/device slots foundation
Etap6_025 — Resource pools foundation
Etap6_026 — Server inventory backend
Etap6_027 — Server inventory admin UI
Etap6_028 — hotfix: Server inventory admin UX
Etap6_029 — błędny hotfix release runtime storage, nie powielać podejścia
Etap6_030 — błędny hotfix release runtime storage, nie powielać podejścia
Etap6_031 — release runtime storage gate cleanup, usunięcie mutującego gate’a
Etap6_032 — flexible worker hardware inventory hotfix
Etap6_033 — flexible GPU slot eligibility
Etap6_034 — GPU slots UX hotfix
Etap6_035 — Server inventory form layout polish
```

Ważna lekcja z `Etap6_029` i `Etap6_030`:

```text
Nie dodawaj gate’a, który sam tworzy runtime storage file i potem oczekuje, że inny gate go usunie.
Release ZIP nie może zawierać runtime storage files.
Release checks mają wykrywać śmieci, a nie mutować paczkę w ryzykowny sposób.
```

# Co już działa i ma zostać utrzymane

```text
- aplikacja jest pełnym ZIP-em całej aplikacji aitwister/
- VERSION.php wskazuje aktualny etap
- docs zawiera tylko aktualny dokument etapu i FINAL_QA_ETAP6.md
- brak starych docs etapowych
- brak runtime śmieci w ZIP
- brak node_modules, venv, pycache, .bak, .map, starych ZIP-ów
- config/qa.php i config/release.php są spójne
- deploy_check.sh ma przechodzić
- Root ma bypass i nie jest zwykłą edytowalną rangą
- Gość jest profilem, nie przypisywalną rangą
- Gość nie ma twardego backendowego locka na Tryb szybki
- Admin i Użytkownik są systemowe
- Root jest ukryty, nietykalny, nieedytowalny, nieusuwalny i nieprzypisywalny
- mode access działa backendowo
- mode limits działają backendowo
- usage counters działają backendowo
- mode limit guards działają backendowo
- publiczny chat nadal jest placeholderem
- dropdown trybów ma etykiety:
Szybki, Myślący, Grafika, Muzyka, Video, Niecenzurowany
- brak token budget
- brak cost ledger
- brak LLM runtime
- brak kolejek AI
- brak worker runtime
- brak modeli
```

# Najważniejsza zasada wyglądu

Aktualny wygląd strony publicznej i reszty panelu admina jest finalny / perfect.

Nie zmieniaj bez wyraźnej prośby:

```text
UI, layoutu, copy, tekstów, interpunkcji, etykiet, kolorów, spacingu, proporcji, komponentów, układu strony publicznej, układu panelu admina, stylu dark/light ani zachowania istniejących elementów, jeśli działają dobrze.
```

UI można ruszać tylko w module aktualnie rozwijanym, minimalnie i zgodnie z obecnym stylem.

Teraz rozwijamy wyłącznie:

```text
Admin → Serwery
server inventory
GPU slots
resource pools
verifier foundation
policy/RBAC dla deep verification
```

Nie ruszaj publicznego UI.

# Aktualny układ Admin → Serwery po Etap6_035

W `Admin → Serwery` mają istnieć sekcje:

```text
Dodaj serwer
Serwery
```

Formularz standardowego serwera ma być ułożony profesjonalnie w parach:

```text
Nazwa | Worker key
Status | Źródło
Profil GPU | RAM
Worker CPU | Dopuszczony do Fast CPU pool
Blokada backendowa | Notatka
```

W dodawaniu i edycji ma być ten sam logiczny układ.

`Sloty GPU` mają pokazywać się tylko wtedy, gdy wybrany jest:

```text
Ręczna konfiguracja GPU
```

Dla gotowych profili GPU ręczny edytor slotów ma być ukryty.

W slocie GPU:

```text
Slot aktywny | Notatka slotu
```

ma być w jednej linii.

Panel ma wyglądać schludnie, spokojnie, profesjonalnie i premium, a nie jak debug-formularz.

# Następna paczka do zrobienia

## Etap6_036 — Variable GPU slots foundation

Cel:

```text
Dodać dynamiczną liczbę slotów GPU dla Ręczna konfiguracja GPU.
Przygotować system pod serwery z więcej niż 2 GPU, np. Threadripper + 5 kart.
```

Zakres:

```text
- pracuj na Etap6_035.zip jako źródle prawdy
- Ręczna konfiguracja GPU startuje z 1 slotem: gpu_0
- dodaj przycisk + Dodaj GPU
- dodaj przycisk Usuń GPU przy konkretnym slocie
- obsłuż gpu_0, gpu_1, gpu_2, gpu_3, gpu_4 itd.
- na tym etapie można przyjąć limit fundamentu np. do 8 ręcznych slotów GPU na serwer
- każdy slot ma osobno:
- model GPU
- VRAM GB
- slot aktywny
- Grafika
- Muzyka
- Video
- Niecenzurowany
- notatka slotu
- backend waliduje dynamiczną liczbę slotów
- resource pool eligibility liczy się per slot
- gotowe profile GPU nadal działają bez ręcznego edytora slotów
- dodaj aktywny JS tylko dla profilu admin-server-inventory, jeśli trzeba
- dodaj gate server_inventory_variable_gpu_slots_check
- podepnij gate pod QA/final_quality/deploy_check/release manifest
```

Nie dodawaj:

```text
- AI runtime
- worker runtime
- routing planner
- rezerwacji GPU
- kolejek
- token budget
- cost ledger
- realnego uruchamiania modeli
- realnej komunikacji z workerem
```

Efekt:

```text
Przy Ręczna konfiguracja GPU admin może dodać wiele kart GPU do jednego serwera.
Każdy slot ma osobne eligibility dla Grafika/Muzyka/Video/Niecenzurowany.
System nadal niczego realnie nie uruchamia i nie rezerwuje.
```

# Kolejne paczki po Etap6_036

## Etap6_037 — Server verifier inventory foundation

Dodać osobną sekcję:

```text
Dodaj serwer weryfikujący
```

Docelowy układ sekcji w `Admin → Serwery`:

```text
Dodaj serwer
Dodaj serwer weryfikujący
Serwery
```

Zakres:

```text
- osobny formularz dla serwera weryfikującego
- nie mieszać verifiera ze zwykłym formularzem GPU
- serwer weryfikujący służy do sprawdzania Trybu Myślącego
- przygotować thinking_verifier_pool
- przygotować Mac Studio / Apple unified memory jako typ verifiera
- bez realnego uruchamiania modelu
- bez worker runtime
- bez kolejek
```

Proponowany układ formularza:

```text
Nazwa | Worker key
Status | Źródło
Typ verifiera | Model urządzenia
Unified memory / RAM | Dopuszczony do thinking_verifier_pool
Blokada backendowa | Notatka
```

Przykład:

```text
Typ verifiera: Mac Studio
Model urządzenia: Mac Studio M3 Ultra
Unified memory / RAM: 256 GB
Dopuszczony do thinking_verifier_pool: tak
```

Lista `Serwery` ma pokazywać badge typu:

```text
Standardowy worker
Serwer weryfikujący
Fast CPU
GPU pools
Verifier
```

## Etap6_038 — Thinking deep verification policy foundation

Dodać fundament polityki dla głębokiej weryfikacji Trybu Myślącego.

Zakres:

```text
- Tryb Myślący dostaje capability deep_verification
- deep verification nie jest osobnym publicznym trybem
- jest podopcją / capability przy Trybie Myślącym
- profile/rangi mogą mieć osobny dostęp do:
- Tryb Myślący
- Głęboka weryfikacja odpowiedzi
- Root ma bypass
- Gość nie dostaje przypadkowego globalnego locka
- backendowy guard placeholder odrzuca request z deep_verification, jeśli profil/ranga nie ma dostępu
- bez realnego verifier runtime
- bez kolejek
- bez modeli
```

W panelu uprawnień docelowo ma to wyglądać schludnie np.:

```text
Myślący
[✓] Może używać trybu Myślącego
[✓] Może używać głębokiej weryfikacji
```

## Etap6_039 — Server inventory final polish + re-audit

Domknięcie bloku server inventory / hardware / verifier.

Zakres:

```text
- re-audit Admin → Serwery
- dark/light
- docs
- QA gates
- release manifest
- deploy_check
- brak runtime śmieci
- brak AI runtime
- brak tokenów
- brak kosztów
- brak kolejek
- upewnić się, że:
- standardowy worker działa
- ręczne GPU działa
- wiele GPU działa
- verifier działa jako inventory/pool
- deep verification działa tylko jako policy/guard placeholder
```

Po tej paczce blok:

```text
Server inventory + GPU slots + verifier foundation
```

ma być uznany za zamknięty.

# Dalsza roadmapa Etapu6 po domknięciu inventory/verifier

Po `Etap6_039` wrócić do szerszej roadmapy Etapu6, ale z przesuniętą numeracją wynikającą z hotfixów i nowych paczek.

Proponowana dalsza kolejność:

```text
Etap6_040 — Resource allocation planner placeholder
Etap6_041 — Routing preview in admin
Etap6_042 — Provider catalog foundation
Etap6_043 — Execution profiles foundation
Etap6_044 — Execution profiles admin UI
Etap6_045 — AI tool policy matrix
Etap6_046 — Web capability blueprint
Etap6_047 — RAG / knowledge base blueprint
Etap6_048 — File analysis blueprint
Etap6_049 — Code sandbox blueprint
Etap6_050 — Orchestrator contract draft
Etap6_051 — Disabled orchestrator client skeleton
Etap6_052 — Worker control channel contract
Etap6_053 — Bundle registry foundation
Etap6_054 — Signed bundle deploy blueprint
Etap6_055 — Worker update protocol placeholder
Etap6_056 — Chat routing placeholder
Etap6_057 — Queue/job model blueprint
Etap6_058 — Audit logs for Etap6 modules
Etap6_059 — Security/RBAC re-audit for Etap6
Etap6_060 — Admin UX polish for Etap6 modules
Etap6_061 — Performance baseline after Etap6 modules
Etap6_062 — A11y + SEO non-regression
Etap6_063 — Release hygiene hardening
Etap6_064 — Etap6 global final quality check
Etap6_065 — Etap6 final docs polish
Etap6_066 — Final re-audit Etap6
```

# Główny cel Etapu6

Etap6 ma zrobić fundament pod prawdziwe AI, ale jeszcze bez uruchamiania modeli.

Budujemy:

```text
- tryby czatu
- dostęp do trybów według rang/profili
- limity trybów
- liczniki użycia trybów
- guardy limitów
- inventory serwerów
- GPU/device slots
- dynamiczne GPU slots
- resource pools
- verifier worker foundation
- deep verification policy
- CPU/GPU/resource routing foundation
- katalog przyszłych narzędzi LLM
- blueprint workerów
- bundle auto-update
- gate’y bezpieczeństwa
- disabled orchestrator skeleton
- worker update protocol placeholder
- audit logi dla modułów Etapu6
- release hygiene
- final QA
```

Nie robimy jeszcze:

```text
- realnego LLM
- realnego runtime modeli
- prawdziwych kolejek AI runtime
- cost ledger
- token budget
- Qdrant/memory runtime
- prawdziwego Web Search runtime
- realnego sandboxa kodu
- realnego worker agenta
- streamingu odpowiedzi AI
- realnego połączenia z workerem
- realnego wykonywania zadań na GPU
```

# Architektura sprzętu

Nie zakładaj już, że każdy worker zawsze ma tylko Ryzen 9 9950X i 1/2 GPU.

Aktualny kierunek:

```text
CPU:
- ręczne pole Worker CPU
- checkbox Dopuszczony do Fast CPU pool
- później ewentualnie worker telemetry uzupełni nazwę CPU automatycznie

RAM:
- ręczne pole liczbowe GB
- np. 32, 48, 64, 96, 128, 192, 256

GPU:
- gotowe profile nadal mogą istnieć:
- 2x RTX 3090 NVLink
- 2x RTX 3090 bez NVLink
- 1x RTX 5060 Ti 16GB
- 2x RTX 5060 Ti 16GB
- Ręczna konfiguracja GPU

Ręczna konfiguracja GPU:
- dynamiczne sloty gpu_0, gpu_1, gpu_2...
- model GPU per slot
- VRAM GB per slot
- aktywność slotu per slot
- eligibility per slot:
- Grafika
- Muzyka
- Video
- Niecenzurowany
```

Tryb Myślący:

```text
- główny model: whole_server na 2x RTX 3090
- NVLink preferowany
- non-NVLink jako wolniejszy fallback
- nie dzielić 3090 na pojedyncze GPU dla głównego Trybu Myślącego
```

Verifier:

```text
- osobny typ serwera
- np. Mac Studio M3 Ultra 256GB unified memory
- służy do sprawdzania odpowiedzi Trybu Myślącego
- trafia do thinking_verifier_pool
- nie mieszać z pulami Grafika/Muzyka/Video/Niecenzurowany
```

Tryb `Niecenzurowany`:

```text
- jest osobnym trybem i osobną trasą zasobów
- nie oznacza wyłączenia bezpieczeństwa, prawa, abuse control, RBAC, limitów ani gate’ów
```

# RBAC / tryby / limity

Zasady:

```text
- Root jest systemowy, ukryty, nietykalny, nieedytowalny, nieusuwalny, nieprzypisywalny z panelu i ma pełny bypass
- Root nie ma limitów
- Gość jest profilem limitów/dostępu dla niezalogowanych, nie zwykłą rangą
- Admin i Użytkownik są systemowe, nieusuwalne
- Admin może mieć limity, Root nie
- dostęp do trybów musi być sprawdzany backendowo
- ukrycie trybu w UI nie wystarcza
- ręczny request z niedozwolonym mode_slug ma być odrzucony
- deep verification ma mieć osobną capability przy Trybie Myślącym
```

Tryby systemowe:

```text
szybki
myślący
grafika
muzyka
video
niecenzurowany
```

Etykiety UI:

```text
Szybki
Myślący
Grafika
Muzyka
Video
Niecenzurowany
```

Limity:

```text
- per profil/ranga i per tryb
- Gość, Użytkownik i Admin mają osobne limity
- Root bez limitów
- requests_per_day
- conversations_per_day, jeśli ścieżka rozmów placeholderowych ma sens
- bez tokenów
- bez kosztów
- bez cost ledger
```

# AI runtime — zabronione w Etapie6

Nie dodawaj:

```text
OpenAI runtime
Ollama runtime
lokalnego LLM runtime
Llama runtime
image/music/video/speech runtime
browser runtime
RAG/Qdrant runtime
kolejek AI
workera AI
uruchamiania modeli
token budget
cost ledger
billing kosztów AI
realnego verifier runtime
realnej komunikacji z Mac Studio
```

Dozwolone są tylko:

```text
blueprinty
tabele konfiguracyjne
placeholdery
disabled skeleton
kontrakty
dokumentacja
gate’y sprawdzające, że runtime nadal jest wyłączony
```

# Gate’y i testy

Po każdej paczce uruchom lokalnie istniejące gate’y projektu oraz nowe gate’y Etapu6.

Minimalnie sprawdzaj:

```text
preflight
static_quality
php_tests
schema_self_check
transaction_integrity_check
error_handling_check
security_policy_check
csrf_method_safety_check
input_validation_check
data_consistency_check
admin_ux_check
performance_baseline_check
observability_check
technical_seo_check
a11y_focused_check
release_manifest_strictness_check
deployment_resilience_check
asset_inventory --strict
final_quality
deploy_check
unzip -t
```

Jeżeli w paczce istnieją gate’y Etapu6, uruchom też właściwe, np.:

```text
legacy_quarantine_check
ai_runtime_forbidden_check
mode_catalog_check
mode_access_check
mode_limits_check
mode_usage_counters_check
mode_limit_guards_check
server_inventory_check
server_inventory_backend_check
server_inventory_admin_ui_check
server_inventory_form_layout_polish_check
server_inventory_variable_gpu_slots_check
gpu_slots_check
gpu_slot_eligibility_check
resource_pools_check
routing_planner_check
provider_catalog_check
execution_profiles_check
ai_tool_policy_check
orchestrator_disabled_check
worker_bundle_check
etap6_global_quality_check
```

Zasady:

```text
- jeżeli coś dodajesz, dodaj sensowny check
- podepnij check pod QA/final_quality/deploy_check/release manifest, jeśli ma sens
- nie zostawiaj martwego checka
- jeżeli coś nie przechodzi, popraw paczkę przed odesłaniem
- nie twórz mutujących release gate’ów, które same tworzą runtime storage files
```

# Deploy

Na serwerze jest jedna komenda wdrożeniowa:

```bash
deploy-aitwister
```

W odpowiedziach przy paczkach sekcja wdrożenia ma mieć tylko tę jedną komendę.

# Format odpowiedzi do każdej paczki

Na samej górze daj link:

```text
[Pobierz Etap6_XXX.zip](...)
```

Potem dokładnie:

````text
# Etap6_XXX — co zrobiłem

## Zmienione / dodane pliki

```text
VERSION.php
config/qa.php
scripts/example.php
docs/ETAP6_XXX.md
````

## Zakres

Krótko i konkretnie.

## Efekt

Co paczka realnie zmienia dla aplikacji.

## Oceny

Jeśli paczka nie zmienia realnych ocen:

```text
Oceny: bez zmian.
```

Jeśli realnie coś podnosi, napisz krótko które kategorie i dlaczego.

# Wdrożenie

```bash
deploy-aitwister
```

# Krótki test

Jeżeli paczka nie zmienia widocznego UI:

```text
Brak testów klikanych.

Wystarczy, że deploy-aitwister przejdzie bez błędów.
```

Jeżeli paczka zmienia UI:

```text
Ctrl + F5

Dark:
- sprawdź wskazane elementy

Light:
- sprawdź wskazane elementy

Console:
- brak Uncaught / TypeError / Failed to load resource
```

````

# Najważniejsze zasady pracy

```text
- zawsze pracuj na najnowszej fizycznie dostępnej paczce
- w tym nowym czacie zacznij od Etap6_035.zip
- pierwsza paczka do wykonania to Etap6_036
- każda kolejna paczka ma być kompletnym ZIP-em całej aplikacji aitwister/, nie patchem
- zawsze zwiększaj numer wersji etapu
- zawsze aktualizuj VERSION.php, config/qa.php, config/release.php jeśli zmienia się manifest, docs/ETAP6_XXX.md i docs/FINAL_QA_ETAP6.md
- w release ZIP ma być tylko aktualny dokument etapu i aktualne finalne docs
- nie zostawiaj starych docs etapowych
- nie dodawaj .gitignore, .gitkeep, runtime storage files, cache, tmp, logs, map, bak, starych paczek ani śmieci release
- katalogi storage mogą być w ZIP, ale runtime pliki storage/cache/log/session/upload nie mogą przejść gate’ów
- nie dodawaj nieaktywnych CSS/JS
- sekrety w paczce na tym etapie nie są traktowane jako błąd
- nie pisz długich teorii przy paczkach
- nie każ mi zaglądać w pliki
- nie zawyżaj ocen za kosmetykę
- pamiętaj o dark i light
- nie zmieniaj finalnego wyglądu bez wyraźnej prośby
- Gość docelowo ma móc rozmawiać z czatem po dodaniu LLM, więc nie blokuj gościa globalnie
- ścieżka /var/www/aitwistersecred istnieje na serwerze i nie zmieniaj jej teraz
- jeżeli znajdziesz realny bug UI lub backendowy, najpierw zrób mały hotfix
- jeżeli coś nie przechodzi w testach/gate’ach, popraw paczkę przed odesłaniem
- jeżeli tworzysz ZIP, upewnij się, że faktycznie istnieje w /mnt/data i sprawdź unzip -t
````

# Zacznij od

```text
Etap6_036 — Variable GPU slots foundation
```

Dopiero po tym przejdź do:

```text
Etap6_037 — Server verifier inventory foundation
Etap6_038 — Thinking deep verification policy foundation
Etap6_039 — Server inventory final polish + re-audit
```