Jakość i kontrole#

Ta strona opisuje, jak sprawdzamy Fyndi przed wypuszczeniem zmiany: jakie bramki muszą być zielone, czego pilnuje bramka dokumentacji i co da się sprawdzić tylko na prawdziwym urządzeniu.

Bramki i kontrole#

Zasada jest jedna: każda kontrola, której nie da się zaczerwienić, nie pilnuje niczego. Dlatego każda bramka ma własny test samej siebie (mutuje drzewo tak, by kontrola musiała zgłosić problem) i tylko wtedy liczy się jako bramka.

Podstawowe narzędzia (wszystkie działają na tym samym kodzie, który idzie na produkcję, a nie na makietach):

Rozdział odpowiedzialności jest sztywny: jedna reguła ma jedno miejsce w kodzie. Jeśli ta sama reguła istnieje w dwóch plikach, to nie jest zabezpieczenie, a zaproszenie do rozjazdu — dlatego strażnicy delegują szczegółowe reguły do jednej bramki i pilnują tylko tego, że ta bramka nadal istnieje i nadal umie czerwienić.

Jak uruchomić kontrole#

Skrócony przebieg jest tym, co realnie uruchamia się przy każdej zmianie; pełny — z audytem animacji i pomiarami — chodzi według harmonogramu, bo trwa minuty, a nie sekundy. Kontrola, która nie ma --self-test, jest traktowana jako niesprawdzona.

Co pilnuje bramka dokumentacji#

Bramka tools/ci/check-user-docs.py ma 10 reguł i własny zestaw kilkunastu mutacji w self-teście. Nie ocenia stylu — pilnuje tego, co da się sprawdzić maszynowo:

1. Każda funkcja ze spisu funkcji ma stronę w obu językach, a jej kotwica naprawdę istnieje w tekście.
2. Każdy obraz wskazany w treści i w spisie funkcji leży na dysku.
3. Każdy odsyłacz wewnętrzny trafia w istniejącą stronę i istniejącą kotwicę.
4. Nie ma stron-sierot: każdy plik jest wymieniony w spisie stron (źródle menu bocznego).
5. Każda pozycja z katalogu ekranu Ustawień aplikacji ma swoje odzwierciedlenie w spisie funkcji.
6. Polska i angielska wersja mają identyczny zestaw stron i komplet etykiet.
7. Skan treści pod kątem sekretów, adresów wewnętrznych i danych, których nie wolno publikować — trafienie blokuje publikację.
8. Każda strona ma stopkę wersji, nie zawiera znaczników „do uzupełnienia” ani nieznanych tokenów.
9. W trybie wydania: wersja aplikacji w spisie funkcji jest zgodna z wersją w konfiguracji Androida.
10. Arkusz stylów nie zawiera pułapki komentarza, która po cichu wycina reguły.

Reguła 5 jest tą, która wymusza aktualność treści, a nie tylko jej spójność: nowa opcja na ekranie Ustawień bez zdania w dokumentacji czerwieni kontrole. Bez niej „dokumentacja jest aktualna” znowu byłoby obietnicą.

Czego bramka nie sprawdzi: czy zdanie jest prawdziwe. To zostaje człowiekowi i osobie weryfikującej zmianę.

Weryfikacja na urządzeniu#

Nie każda rzecz wynika z liczb. To, co zależy od prawdziwego telefonu, sprawdzamy na emulatorze uruchomionym na serwerze, w kolejności od instalacji do kadru:

1. uruchomienie emulatora i instalacja tego samego pliku APK, który jest wydany,
2. założenie konta testowego przez API i jego sprzątnięcie po testach (na produkcji nie zostają konta testowe),
3. ustawienie pozycji w mieście z konkretnej trasy, żeby punkt był w zasięgu,
4. ustawienie motywu i pory dnia w preferencjach aplikacji, bez klikania po ekranie,
5. wykonanie jednej akcji i wtedy zrobienie jednego kadru — nie „kilku z rzędu”,
6. wygaszenie emulatora na koniec, żeby nie zjadał pamięci serwera produkcyjnego.

Czego emulator nie pokaże: widoku AR. Sesja AR wymaga usług rozszerzonej rzeczywistości zainstalowanych na urządzeniu, a tych na emulatorze nie ma — dlatego kadry z widoku AR pochodzą z prawdziwego telefonu. To nie luka w kontroli, a jawna granica: widok AR opisujemy tak, żeby dało się go sprawdzić bez zrzutu ekranu.

Przykładowe wyniki pełnej kontroli (stan z konkretnych dni — liczby zmieniają się z każdym wydaniem): logika mapy i znaczników w aplikacji 95/95 sprawdzeń, znaczniki na stronie 224/224, reguła „znajdźka nie jest stopem trasy” 86/86 tras, dodanie znajdźki jako stopu odrzucane przez API, audyt odstępów postaci: 83 bryły w 60 zestawach, żaden element nie wisi w powietrzu.

Opis zgodny z aplikacją 0.120.1 (zaktualizowano 2026-09-26).