# Upgrade Baltique OS Core 2.2.0

## Wymagany punkt startowy

Zalecany punkt startowy:

```text
Baltique OS Core 2.1.0.1
```

Instalator 2.2.0 jest skumulowany i próbuje odświeżyć dostępne warstwy bazowe, ale przed wdrożeniem należy potwierdzić działanie logowania administratora oraz kopię bezpieczeństwa.

## 1. Backup

Przed nadpisaniem plików wykonaj:

1. pełny dump MySQL;
2. backup całego katalogu aplikacji;
3. backup katalogu `storage`;
4. kopię poza hostingiem OVH;
5. zapis bieżącego `core_version`, `schema_version` i SHA256 wdrażanej paczki.

Nie kontynuuj, dopóki backup nie istnieje i nie jest możliwy do odczytania.

## 2. Staging

Najpierw wdróż paczkę na kopii środowiska. Nie zaczynaj od żywej kliniki.

## 3. Wgranie plików

Wypakuj ZIP do katalogu głównego Baltique OS i nadpisz pliki, zachowując strukturę:

```text
app/
public_html/
database/
cron/
tools/
docs/
storage/
```

Paczka nie nadpisuje `app/config.php` i nie zawiera danych pacjentów.

## 4. Uprawnienia storage

Potwierdź możliwość zapisu przez PHP:

```text
storage/keys
storage/patient_identity_intake
storage/logs
```

Katalog `storage` nie może być publicznie serwowany przez WWW.

## 5. Wymagane rozszerzenia PHP

Sprawdź:

```text
PDO MySQL
mbstring
sodium lub OpenSSL
fileinfo
JSON
```

Do pełnego OCR potrzebne są skonfigurowane adaptery używane przez istniejący Lab OCR Engine, np. `pdftotext` i/lub Tesseract, jeżeli są dostępne na hostingu.

## 6. Uruchomienie upgrade’u

Zaloguj się jako `admin` albo `superadmin` i otwórz:

```text
/upgrade_2_2_0.php
```

Kliknij:

```text
Uruchom upgrade 2.2.0
```

Upgrade:

- tworzy tabele i kolumny kompatybilnie;
- generuje prywatny klucz tożsamości/adresu na serwerze;
- rejestruje moduły i trasy;
- ustawia safety guards;
- zapisuje Migration Ledger;
- może wykonać jeden kontrolowany skan normalizacji.

## 7. Klucz szyfrowania

Po udanym upgrade sprawdź istnienie:

```text
storage/keys/patient_identity.key
```

Wymagania:

- plik czytelny wyłącznie dla konta aplikacji;
- rekomendowane prawa `0600`;
- backup szyfrowany i przechowywany poza publicznym WWW;
- utrata klucza oznacza utratę możliwości odczytu PESEL/paszportu oraz pełnego adresu.

Nie kopiuj klucza do repozytorium ani paczek release.

## 8. Jednorazowa walidacja

Uruchom kolejno:

```text
/system_clinical_experience_220.php
/system_codebase_normalization.php
/system_runtime_preflight.php
```

Nie uruchamiaj pełnego Preflight wielokrotnie na hostingu współdzielonym. Respektuj cooldown i OVH Query Guard.

## 9. Test Smart Intake

Na staging wykonaj:

1. ręczne dodanie syntetycznego pacjenta;
2. PESEL z prawidłową sumą kontrolną;
3. paszport dla pacjenta zagranicznego;
4. pełny adres zamieszkania;
5. dokument/zdjęcie OCR;
6. Live Camera Intake;
7. ręczne porównanie danych z dokumentem;
8. odrzucenie sesji bez tworzenia pacjenta;
9. kontrolę duplikatu identyfikatora;
10. kontrolę szyfrowania kolumn `identifier_ciphertext` i `address_ciphertext`.

## 10. Test dokumentów

Wygeneruj dokument testowy i potwierdź, że zawiera:

```text
imię i nazwisko
data urodzenia
PESEL lub numer paszportu
adres zamieszkania
kod pacjenta
sprawę/procedurę/SITE
```

Następnie przetestuj immutable signed snapshot oraz Consent Vault.

## 11. Test języka

Dla pacjenta PL i EN potwierdź:

- portal;
- Patient Care Guide;
- drafty komunikacji;
- wybór dokumentów;
- blokadę dokumentu EN, jeżeli zatwierdzony Content Block EN nie istnieje.

## 12. Test AI badań

Na danych syntetycznych potwierdź:

- wykrycie braków/odchyleń;
- routing do chirurga lub anestezjologa;
- utworzenie Work Queue;
- draft PL/EN;
- brak automatycznego clearance;
- brak zmiany GO/HOLD;
- brak automatycznej wysyłki.

## 13. Test lokalizacji i ról

Sprawdź:

- Gdańsk;
- Sopot;
- Online;
- `Wszystkie lokalizacje` dla uprawnionego konta;
- ukrytą lokalizację planowaną;
- bezpośredni URL panelu technicznego dla chirurga — powinien być zablokowany;
- admin/superadmin — powinien mieć dostęp.

## 14. Test motywów i urządzeń

Sprawdź Dark/Light/System na:

- desktopie;
- tablecie;
- telefonie;
- PWA;
- Chrome/Edge/Safari/Firefox według przyjętego browser matrix.

## 15. Rollback

Rollback plików:

1. włącz maintenance mode;
2. przywróć katalog aplikacji z backupu;
3. przywróć zgodny dump MySQL, jeżeli migracja została wykonana;
4. przywróć `storage` wraz z kluczem tożsamości;
5. wyczyść cache przeglądarki/PWA;
6. uruchom podstawowe smoke tests.

Nie próbuj ręcznie usuwać pojedynczych tabel 2.2.0 z żywej bazy bez zatwierdzonego planu migracyjnego.

## 16. Warunek dopuszczenia do UAT

- upgrade zakończony bez component failure;
- Runtime Preflight bez niewyjaśnionego `critical fail`;
- klucz szyfrowania chroniony i objęty backupem;
- Smart Intake i adres przetestowane;
- brak auto-send i auto-decision;
- role i lokalizacje zweryfikowane;
- staging backup/restore potwierdzony.