Jakość
Co sprawdzamy zanim wersja trafia do odbiorcy i zanim uznamy ją za bezpieczną do dalszych aktualizacji.
Porównujemy desktop, wide desktop i mobile. Sprawdzamy overflow, widoczność nawigacji, rytm sekcji, długość nagłówków i to, czy responsive faktycznie zmienia kompozycję, a nie tylko układa wszystkie elementy w ten sam pionowy stos. Dodatkowo kontrolujemy, czy pierwszy viewport pokazuje sensowny fragment wartości strony zamiast wielkiego nagłówka i pustego tła.
Każda publiczna strona ma własny intent, H1, title, description, canonical, meta keywords i linkowanie wewnętrzne. Treść musi wnosić nową informację, a nie tylko powtarzać firmowy slogan. SEO nie może być oddzielone od realnego HTML i dostępności. Metadane są porównywane z faktycznym H1 i rolą strony, aby nawigacja, treść, canonical i structured data nie opisywały różnych rzeczy.
Fresh install i update poprzedniej wersji muszą prowadzić do tego samego aktualnego stanu, z wyjątkiem świadomych zmian użytkownika. Migracje aktualizują stare factory defaults, ale nie nadpisują wartości, które właściciel strony faktycznie edytował. Osobny test symuluje poprzedni stan danych, ponieważ świeża instalacja sama w sobie nie wykryje błędnej migracji i pozostawionych starych defaultów.
Wydanie
Finalny pakiet musi być spójny wizualnie, technicznie i treściowo oraz gotowy na aktualizację bez utraty świadomych zmian użytkownika. Release obejmuje nie tylko ZIP, ale również stan stron, SEO, media, Global Text i ścieżkę migracji.
Każdy ważny obraz ma własną rolę, crop, ALT, TITLE i responsywne warianty. Nie liczymy cropu tego samego pliku jako nowego major media. Przed wydaniem sprawdzamy decode, proporcje, ostrość, krawędzie oraz zachowanie obrazu na mobile. Major media są porównywane po source lineage i signature, więc resize, crop albo zmiana formatu nie tworzą sztucznie nowego assetu.
Global Text jest źródłem factory-controlled copy. Dzięki temu poprawki językowe i przyszłe migracje nie wymagają szukania tekstów w wielu szablonach PHP. Brak klucza lub błędny JSON musi mieć bezpieczny fallback zamiast białego ekranu. W razie błędu JSON strona powinna użyć last-known-good albo packaged fallback i wyraźnie zachować możliwość dalszej naprawy bez fatal error.
Po każdej poprawce ponownie sprawdzamy obszary, które mogły zostać naruszone: mobile, layout, media, linki, SEO i state. Zmiana nie jest zaakceptowana, jeśli usuwa jeden defekt kosztem wcześniejszego działającego zachowania. Regresja obejmuje również pozycję header/footer, cookie UI i ścieżki kontaktowe, ponieważ globalne elementy mogą zostać przypadkowo naruszone przez lokalną poprawkę.
QA
Ta wersja strony nie uruchamia marketingowych ani analitycznych trackerów. Lokalny zapis służy wyłącznie do zapamiętania Twojego wyboru.