# Baltique OS Core 0.78.0 — Acceptance Tests

Testy należy wykonać po uruchomieniu `/upgrade_0_78_0.php` na środowisku z realną bazą.

## A. System / migracje

1. Otwórz `/system_enterprise_078.php`.
   - Oczekiwane: wszystkie krytyczne checks mają status `OK`.
2. Otwórz `/system_migration_ledger.php`.
   - Oczekiwane: istnieje wpis `086_core_0_78_enterprise_integration_stabilization` ze statusem `applied`.
3. Otwórz `/system_module_registry.php?status=legacy`.
   - Oczekiwane: legacy moduły są oznaczone i mają wskazane replacement module.

## B. OR Readiness

1. Wybierz dzień z co najmniej trzema pacjentami operacyjnymi.
2. Uruchom skan OR Readiness.
3. Uruchom ten sam skan ponownie.
4. Sprawdź tabelę/widok dnia.
   - Oczekiwane: liczba pacjentów nie rośnie po drugim skanie.
   - Oczekiwane: jeden `readiness_source_key` odpowiada jednemu statusowi dnia.

## C. Digital Twin

1. Otwórz `/or_digital_twin_optimizer.php`.
2. Uruchom symulację wariantów dnia.
   - Oczekiwane: brak błędu `Unknown column simulation_date`.
   - Oczekiwane: powstaje baseline i co najmniej jeden wariant alternatywny.
   - Oczekiwane: warianty zawierają delay, PACU, zespół, koszt, ryzyko, satysfakcję i score.

## D. Safe Auto-Apply

1. Otwórz `/or_safe_auto_apply_engine.php`.
2. Wybierz najlepszy scenariusz lub `najlepszy Digital Twin`.
3. Uruchom preflight.
   - Oczekiwane: powstaje run z akcjami `planned` albo `blocked`.
   - Oczekiwane: konflikty sali, zespołu i PACU blokują automatyczne apply.
4. Jeżeli run jest `ready`, wykonaj apply.
   - Oczekiwane: zmiany są zapisane do TheatreFlow.
5. Wykonaj rollback.
   - Oczekiwane: plan wraca do stanu sprzed apply.

## E. OR Mobile Push

1. Otwórz `/or_mobile_push_escalation_center.php` bez VAPID key.
   - Oczekiwane: przycisk rejestracji jest zablokowany, brak błędu `atob` w konsoli.
2. Wklej nieprawidłowy klucz.
   - Oczekiwane: system odrzuca klucz opisowym komunikatem.
3. Wklej poprawny VAPID public key.
   - Oczekiwane: urządzenie zapisuje się w tabeli push w schemacie dual.

## F. Podpisane dokumenty

1. Wygeneruj dokument pacjenta z Operative Path.
2. Podpisz dokument na tablecie/formularzu.
3. Otwórz archiwum podpisanych dokumentów.
   - Oczekiwane: widoczny jest pełny snapshot dokumentu, nie pusta karta.
   - Oczekiwane: snapshot ma SHA-256.
   - Oczekiwane: dokument źródłowy ma status `signed_locked` albo odpowiedni status blokady.

## G. End-to-end kliniczny

1. Pacjent po kwalifikacji trafia do ścieżki operacyjnej.
2. System generuje zadania, badania, dokumenty i płatności.
3. Dokumenty są składane z Content Blocks i Rules Matrix.
4. Pacjent podpisuje wymagane zgody.
5. GO/HOLD/NO-GO oraz OR Readiness są obliczane z danych w bazie.
6. Digital Twin proponuje wariant dnia.
7. Safe Auto-Apply wykonuje preflight przed zmianą TheatreFlow.
8. OR Live, Staff Mobile i Push pracują na tym samym dniu operacyjnym.
9. Po operacji powstaje wypis i opieka pooperacyjna.
10. Marketing/NPS otrzymuje pacjenta dopiero po spełnieniu reguł klinicznych i zgód komunikacyjnych.

Oczekiwany wynik: system prowadzi pacjenta jako jeden workflow, bez przepisywania danych ręcznie między modułami.