# Baltique OS — Premium Harmony 2.15.2

## Zakres wydania

To wydanie łączy kompletny kod Baltique OS 2.10.1 z jasnym motywem Premium Harmony 2.15.2. Motyw jest domyślną warstwą wszystkich ekranów personelu i publicznych ekranów pacjenta/dostawcy.

Ekran po zalogowaniu wykorzystuje dokładnie tę samą kremowo-lawendową atmosferę co ekran logowania. Główne akcje mają głęboki lawendowy kolor o wysokim kontraście; róż pozostaje jedynie dyskretnym akcentem marki. Zieleń, bursztyn i czerwień są zarezerwowane dla znaczenia stanów klinicznych.

Wydanie nie dodaje ciężkich fotografii ani map do ekranów operacyjnych. Warstwa jest oparta na lekkim CSS i nie obciąża zmiany lokalizacji, piętra, sali ani pacjenta.

## Kontrola kompletności interfejsu

Automatyczny audyt źródeł objął:

- 677 publicznych plików PHP;
- 249 rozpoznanych ekranów, w tym 229 ekranów wspólnej powłoki i 25 ekranów samodzielnych;
- 12 801 elementów interfejsu: 4 217 kontrolek, 1 626 ramek i 6 958 bloków tekstowych;
- 547 unikalnych klas używanych przez ekrany;
- 1 069 używanych reguł zawierających historyczne kolory.

Wynik końcowy:

- 249/249 ekranów objętych Premium Harmony;
- 0 ekranów bez warstwy motywu;
- 0 ekranów zaklasyfikowanych jako ryzykowne;
- 0 elementów z niekontrolowanym kolorem inline;
- 0 niesemantycznych historycznych reguł koloru bez nadpisania Premium Harmony;
- brak błędów składni w kontrolowanych plikach PHP i JavaScript;
- brak poziomego przewijania w laboratorium 1440 px i 390 px;
- wszystkie mobilne elementy dotykowe poza natywnymi polami wyboru mają minimum 44 px.

Szczegółowe wyniki znajdują się w `reports/premium_harmony_215/`. Laboratorium kontrolne jest w `tools/premium_harmony_visual_lab.html`; nie jest trasą publiczną aplikacji.

## Instalacja pełnej paczki

1. Wykonaj jedną spójną kopię bazy, plików aplikacji i katalogu `storage` poza hostingiem.
2. Najpierw wdrażaj na kopii testowej. Zachowaj własne `app/config.php`, sekrety integracji i dane `storage`.
3. Wgraj zawartość pełnej paczki, zachowując strukturę katalogów. Dokument główny hostingu powinien wskazywać na `public_html`.
4. Wyczyść OPcache/PHP oraz cache CDN. Wersja 2.15.2 ma nowy identyfikator zasobów `h2152`.
5. Jeżeli baza ma rdzeń starszy niż 2.10.1, wykonaj instrukcję `DEPLOYMENT_2_10_1.md` i uruchom zbiorczy `/upgrade_2_10_1.php`.
6. Wykonaj nowy `/system_runtime_preflight.php`.
7. Przejdź testy akceptacyjne poniżej na kopii testowej, a dopiero potem zaplanuj przełączenie produkcyjne.

## Obowiązkowy test akceptacyjny przed realnym pacjentem

- Logowanie, wylogowanie, reset hasła, role i ograniczenia dostępu.
- Rejestracja pacjenta, rezerwacja, zgody, dokumenty i ścieżka konsultacji.
- Szpital na żywo: zmiana lokalizacji, wszystkie piętra, sala, łóżko, pacjent, zadania i alerty.
- Poradnia, blok operacyjny, opieka pooperacyjna, magazyn i zamówienia.
- Widok pacjenta, przewodnik opieki i publiczny portal dostawcy.
- Kamera Smart Intake na docelowych urządzeniach i przeglądarkach.
- E-mail/SMS/WhatsApp, płatności oraz integracje — na kontach testowych.
- Backup, odtworzenie kopii, dziennik audytu, retencja plików i procedura awaryjna.
- Czytelność pulpitu 1440 px, laptopa, tabletu i telefonu; jasny oraz celowo wybrany ciemny motyw.

## Granica weryfikacji

Audyt źródeł obejmuje każdy rozpoznany ekran i każdą rodzinę ramek, kontrolek oraz tekstów. Kontrola wizualna obejmuje reprezentatywny render wszystkich głównych rodzin komponentów. Ekranów zależnych od zalogowanej roli, danych konkretnej bazy, zewnętrznych płatności, wiadomości lub urządzenia nie można zatwierdzić end-to-end poza docelowym środowiskiem. Dlatego decyzja GO wymaga pomyślnego testu akceptacyjnego na kopii wdrożenia.

## Wycofanie

W razie błędu przywróć pliki i bazę z tej samej kopii czasowej. Nie cofaj wyłącznie numeru `core_version` i nie łącz bazy po migracji z plikami starszego rdzenia.