# Raport walidacji — Baltique OS Core 2.2.0

## Status wydania

```text
FORMAL BUILD CLOSURE: PASS
STATIC RELEASE VALIDATION: PASS
PURE DETERMINISTIC TESTS: PASS
ARCHIVE VALIDATION: wykonywana podczas budowy artefaktu końcowego
LIVE OVH / LIVE MYSQL VALIDATION: NIE WYKONANO
CLINICAL PRODUCTION APPROVAL: WYMAGA UAT I SIGN-OFF
```

Wydanie zostało formalnie zamknięte jako kontrolowany pakiet wdrożeniowy dla środowiska staging, a następnie — po przejściu checklisty — dla pilota klinicznego. Walidacja buildowa nie zastępuje testu migracji na kopii docelowej bazy, UAT personelu, przeglądu prawnego ani akceptacji klinicznej.

## Identyfikacja wydania

- wersja: `2.2.0`;
- nazwa: `Clinical Experience, Identity, Smart Intake & Governed AI Release`;
- zalecany punkt startowy: `2.1.0.1`;
- migracja: `234_core_2_2_0_clinical_experience_identity_smart_intake_governed_ai`;
- instalator: `/upgrade_2_2_0.php`;
- główny panel: `/system_clinical_experience_220.php`.

## Wyniki automatyczne

| Kontrola | Wynik |
|---|---:|
| Static validator 2.2.0 | PASS |
| Checki static validatora | 116/116 |
| Deterministyczne testy czystych funkcji | 12/12 PASS |
| Parsowanie składni PHP całego drzewa źródłowego | 926/926 PASS |
| JavaScript syntax check | 31/31 PASS |
| Integralność nawiasów CSS | 140/140 PASS |
| Prywatny klucz tożsamości w źródle | NIE |
| `app/config.php` w pakiecie | NIE |
| `.env` w pakiecie | NIE |
| dump bazy / backup w pakiecie | NIE |
| oryginalny zestaw zdjęć Magdaleny w pakiecie | NIE |

## Zakres testów deterministycznych

Sprawdzono bez połączenia z bazą:

1. prawidłowy PESEL, suma kontrolna i data urodzenia;
2. odrzucenie nieprawidłowego PESEL;
3. wymagane pola adresu;
4. normalizację polskiego kodu pocztowego;
5. formatowanie adresu;
6. deterministyczny HMAC/fingerprint adresu;
7. odczyt danych tożsamości przez parser OCR;
8. odczyt ulicy;
9. odczyt numeru budynku;
10. odczyt numeru lokalu;
11. odczyt kodu pocztowego;
12. odczyt kraju.

## Kontrole bezpieczeństwa i governance

Potwierdzono statycznie:

- szyfrowanie numeru PESEL/paszportu oraz pełnego szczegółowego adresu;
- blind index/HMAC zamiast plaintext lookup;
- strukturalne pola routingu adresowego bez pełnego jawnego adresu;
- rozdzielenie `identity_verified` i `address_verified`;
- obowiązkowy human review danych OCR i Live Camera Intake;
- brak automatycznego utworzenia pacjenta z OCR;
- brak automatycznej diagnozy, clearance, GO/HOLD/NO-GO i wysyłki zaleceń;
- odpowiedzi do pacjenta powstają jako drafty wymagające zatwierdzenia;
- osobne zgody dla kontaktu i marketingu przez Facebook/Instagram;
- osobny język pacjenta dla portalu, komunikacji, dokumentów i zgód;
- zakaz traktowania automatycznego tłumaczenia dokumentów klinicznych jako źródła prawdy;
- jawne oznaczenie syntetycznej przewodniczki;
- wyłączony klon głosu;
- techniczne trasy administracyjne chronione dla admin/superadmin;
- brak automatycznego push do personelu/pacjenta bez governance.

## Model adresu pacjenta

Wydanie wprowadza kanoniczny adres pacjenta:

```text
kraj
kod pocztowy
miejscowość
województwo / region
ulica
numer budynku
numer lokalu
dodatkowa linia adresu
```

Pełny payload adresowy jest przechowywany w `address_ciphertext`. `address_hash` umożliwia kontrolę duplikatów bez jawnego adresu. W dokumentach zatwierdzony kontekst może korzystać z `{{patient.address_formatted}}`.

## Granice walidacji

Nie wykonano w środowisku budowy:

- migracji na żywej bazie OVH;
- migracji na kopii aktualnej produkcyjnej bazy użytkownika;
- testu restore po wdrożeniu;
- testu z realnym pacjentem;
- pełnego testu przeglądarek i urządzeń;
- testu obciążeniowego i limitów zapytań OVH;
- formalnego przeglądu klinicznego reguł laboratoryjnych;
- formalnego przeglądu prawnego dokumentów i zgód EN;
- audytu bezpieczeństwa wykonywanego przez niezależny podmiot;
- publikacji natywnych aplikacji Android/iOS w sklepach.

## Wymagane warunki przed pilotem klinicznym

1. pełny backup oraz potwierdzony restore na staging;
2. upgrade 2.2.0 na kopii docelowej bazy;
3. jeden kontrolowany Runtime Preflight;
4. test PESEL, paszportu, adresu, OCR i Live Camera Intake;
5. sprawdzenie szyfrowania oraz praw pliku `storage/keys/patient_identity.key`;
6. UAT ról klinicznych i administracyjnych;
7. zatwierdzenie reguł laboratoryjnych przez chirurga i anestezjologa;
8. zatwierdzenie wersji PL/EN dokumentów oraz zgód;
9. test Communication Hub jako draft-only;
10. test Patient Care Guide PL/EN i synthetic disclosure;
11. test wydajności oraz liczby zapytań na docelowej infrastrukturze;
12. formalny sign-off clinical, operations, privacy/security i release owner.

## Decyzja buildowa

```text
Wydanie 2.2.0 jest formalnie zamknięte jako kompletny, zwalidowany statycznie artefakt wdrożeniowy.
Nie jest automatycznie dopuszczone do realnej pracy klinicznej bez wykonania powyższych działań staging/UAT/governance.
```