# Raport walidacji — Baltique OS Core 2.7.0.1

## Zakres

Walidacja dotyczy overlayu naprawczego 2.7.0.1 oraz połączonego drzewa:

```text
pełny backup Baltique OS 2.6.1
+ overlay 2.6.2.1
+ overlay 2.7.0
+ naprawa 2.7.0.1
```

## Wyniki

| Kontrola | Wynik |
|---|---:|
| PHP lint plików overlayu 2.7.0.1 | PASS |
| PHP lint połączonego drzewa | 1064/1064 PASS |
| JavaScript połączonego drzewa | 40/40 PASS |
| Static validator 2.7.0.1 | 50/50 PASS |
| Test kontraktu starego schematu | PASS |
| Test kolejności repair → base upgrade | PASS |
| Symulacja schematu 2.6.2.1 → 2.7.0.1 | PASS |
| Bazowy test konsolidacji 2.7.0 | PASS |
| Bazowy test katalogu funkcji 2.7.0 | PASS |
| Bazowy test kontraktu schematu 2.7.0 | PASS |
| `app/config.php` w overlayu | NIE |
| `.env` w overlayu | NIE |
| dane pacjentów / dump bazy | NIE |

## Zweryfikowana przyczyna

Stary kontrakt `enterprise_site_consolidation_runs` nie posiadał `run_key`. Ponieważ tabela już istniała, `CREATE TABLE IF NOT EXISTS` z 2.7.0 nie zmieniło struktury. Naprawa adaptacyjna uzupełnia brakujące kolumny i backfilluje historyczne rekordy przed pierwszym zapisem 2.7.0.

## Dodatkowo wykryte i naprawione

- brak `alias_type` i `metadata_json` w historycznej `enterprise_site_aliases`;
- możliwy częściowy schemat `enterprise_module_unification_runs` po przerwanym upgrade;
- błędna kolejność argumentów `balt078_register_migration()` w bazowym release 2.7.0;
- pierwotna trasa `/upgrade_2_7_0.php` nie uruchamiała naprawy przed bazowym upgradem.

## Ograniczenie walidacji

Migracja nie została wykonana na żywej bazie MySQL użytkownika. W środowisku budowy nie był dostępny docelowy serwer MySQL/MariaDB. Wykonano deterministyczną symulację starego kontraktu tabel, pełny lint połączonego kodu i statyczną analizę kolejności migracji. Pierwsze uruchomienie musi odbyć się na stagingowej kopii bazy po wykonaniu backupu.