لم ينجح أيٌّ من تلك الإصلاحات بعد إعادة تحميل الصفحة

تم إصلاح المسارات. وأُعيدت كتابة نقطة نهاية الحالة. وصُحِّح تنسيق البيانات. كل تغيير مؤكَّد في المستودع، ومرئي في الملف، تماماً كما كان مقصوداً.

أعدتُ تحميل المتصفح. لم يتغيَّر شيء.

نفس الطاولة المعطَّلة. نفس اللوحة الفارغة.

ما الذي كان يحدث فعلياً

المنصة تعمل محلياً داخل Docker — مجموعة من الحاويات، كلٌّ منها يشغِّل خدمة، ومتصلة عبر إعداد مشترك. تطبيق الويب الأمامي مُركَّب عبر volume: ملفات المصدر على القرص تُربط مباشرةً بالحاوية. وأداة البناء Vite تراقب تغييرات الملفات وتعيد تحميل المتصفح تلقائياً.

باستثناء أنها لم تكن تراقب.

على Windows مع Docker الذي يعمل فوق WSL2 — طبقة التوافق مع Linux التي يستخدمها Windows للحاويات — لا تنتقل إشعارات أحداث نظام الملفات التي يعتمد عليها Vite للكشف عن التغييرات بشكل صحيح عبر حدود الافتراض. نظام الإشعارات في Linux يبلِّغ عن التغيير. Windows لا يمرِّره. Vite لا يرى تحديث الملف أبداً. والمتصفح يستمر في تقديم الكود الذي كان موجوداً سابقاً.

الإصلاح كان سطراً واحداً في إعدادات Vite: usePolling: true. بدلاً من انتظار إشعار بالتغييرات، يفحصها Vite كل 300 ميلِّي ثانية. أقل كفاءة بقليل. لكنه يعمل.

محرك الطاولات — الخدمة الخلفية التي تدير حالة اللعبة الفعلية — كان لديه نسخته الخاصة من المشكلة نفسها. الخدمات الخلفية في هذه الـ stack لا تعمل في وضع watch. تغييرات الكود تتطلب إعادة تشغيل الحاوية يدوياً. سلوك معياري لخدمة بمستوى الإنتاج. يكفي أن تعرف أنه عليك إعادة التشغيل.

الشيء الآخر الذي كان خاطئاً

بعد حلِّ مشاكل البيئة، ظهر باغ ثالث: مسار الطاولة كان فيه auth guard يرسل المتصفح دائماً إلى صفحة تسجيل الدخول.

ليس لأن المستخدم لم يكن مسجَّل الدخول. كان مسجَّلاً. الـ guard كان يفحص قيمة سياق TanStack Router لم تُملأ مطلقاً — الـ router مُهيَّأ بدون context provider، لذا كان context.auth دائماً undefined. الـ guard يقرأ "غير موثَّق"، فيعيد التوجيه إلى تسجيل الدخول. وتسجيل الدخول يرى جلسة موثَّقة، فيعيد التوجيه إلى الـ lobby. والمتصفح يدخل في حلقة.

سطر واحد تغيَّر. حُدِّث الـ guard ليقرأ مباشرةً من authentication store، وهو نفس النمط الذي يستخدمه كل مسار آخر في التطبيق. أُصلح.

ماذا يتطلَّب هذا من الشخص الجالس أمام لوحة المفاتيح

الإصلاحات كانت صحيحة. النظام لم يكن يلتقطها. تلك الملاحظة — أن الكود الصحيح والكود الذي يعمل شيئان مختلفان — تطلَّبت معرفة بيئة التطوير معرفةً كافيةً لطرح السؤال الصحيح.

الـ agent يستطيع كتابة الإصلاح. ويستطيع تتبُّع الباغ بمجرد أن تصفه. لكنه لا يستطيع أن يلاحظ أن المتصفح يقدِّم نسخة مخزَّنة من الكود قبل تغيير الإعدادات. تلك الملاحظة بشرية.

معرفة النظام معرفةً كافيةً لتشخيص لماذا لا يأخذ الإصلاح الصحيح مفعوله — هذا هو الجزء الذي لا يُؤتمَت.

بعد إعداد polling، وبعد إعادات تشغيل الحاويات، وبعد إصلاح auth guard: حُمِّلت الطاولة. ظهرت المقاعد. عُرض diaog الـ buy-in. وأخذت كروت الـ lobby ارتفاعها الصحيح. كل شيء عمل.

المنشور التالي يغطِّي شكل integration testing بمجرد أن أصبح لدينا نظام يعمل لاختباره — ولماذا تبدو هذه المرحلة متشابهة بصرف النظر عمَّا إذا كان الـ AI أم البشر هم من كتبوا الكود.

لرؤية وجهة نظر المؤسِّس في التنقُّل عبر هذا النوع من عمليات التصحيح — ما الذي يتطلَّبه دور الـ human-in-the-loop فعلياً عندما يكون الـ AI قد كتب معظم قاعدة الكود — هي على The Salty Korean.

Stay salty.