تحديث منتج KENSAI: أدلة اختبارات الليل تستبدل مقاييس الطمأنة
بدأ يوم 26 أبريل بنوع الفشل الذي يجب على الأنظمة المفيدة أن تحفظه بدل أن تنعّمه: حزمة اختبارات freemium الليلية لم تنجح. الفائدة الحقيقية أن الفشل أصبح الآن دقيقًا بما يكفي لإصلاحه.
ماذا أثبت التشغيل الليلي
سجّلت cron receipt بتاريخ 26 أبريل حزمة KENSAI freemium الكاملة من مستودع المنصة. النتيجة لم تكن مجرد build أحمر غامض، بل كانت خريطة فشل واضحة: انتهى pnpm test بالكود 1 بعد 636 اختبارًا، منها 310 فاشلة و243 ناجحة و83 متخطاة.
فئة الفشل المسيطرة كانت اختبارات تعتمد على API وتتوقع خدمة على 127.0.0.1:4000 بينما لم تكن الـ API متاحة أصلًا، فظهرت رفضات اتصال وassertions بحالة صفر. هذا ليس لغزًا في المنتج، بل خلل في preflight وفي orchestration للخدمة.
ما الذي كان مفقودًا
تم تسجيل فجوتين إضافيتين بدل إخفائهما. الحزمة الجذرية لم تعرّف pnpm test:e2e، لذلك لم يكن لدى الـ runner مدخل e2e ثابت. كما فشل أمر التغطية فورًا لأن @vitest/coverage-v8 كان مفقودًا. بدأ fallback مباشر عبر Playwright، لكن كثافة أخطاء auth/admin ومهل التحقق ذات الدقيقة الواحدة جعلته ضجيجًا أكثر من كونه إشارة مفيدة.
- تمت ملاحظة 636 اختبارًا في الحزمة الجذرية: 310 فشلت، 243 نجحت، و83 تم تجاوزها.
- سبب الفشل الرئيسي كان غياب الـ API على 127.0.0.1:4000، وليس تراجعًا مجهولًا في المنتج.
- غياب سكربت e2e وغياب مزود التغطية لـ Vitest أصبحا الآن عناصر إصلاح صريحة.
لماذا يُعد هذا تحديث منتج
تشغيل اختبارات فاشل لا يعني تقدمًا تلقائيًا. لكنه يصبح تقدمًا عندما يأتي مع أرقام دقيقة، وأنماط أخطاء مهيمنة، وأدوات مفقودة، ومسار إصلاح واضح. نظام الجودة يعرف الآن الفرق بين سلوك تطبيق مكسور وبنية تحتية لم تبدأ أصلًا.
هذا مهم لـ KENSAI لأن ادعاءات الأمان أمام العملاء تعتمد على حقيقة تشغيلية مملة لكنها صادقة. إذا كان مسار freemium يحتاج إلى API، فيجب على الـ runner أن يشغّلها أو يتحقق منها قبل بدء الاختبارات. وإذا كانت التغطية بوابة إلزامية، فيجب تثبيت مزودها. وإذا كان e2e جزءًا من قصة الإصدار، فهو يحتاج إلى سكربت حقيقي لا مجرد عرف ضمني.
مسار الإصلاح التالي
تسلسل الإصلاح واضح الآن: إضافة أو استعادة سكربت جذر test:e2e، وتثبيت مزود التغطية، وجعل runner الخاص بـ freemium يشغّل الـ API على المنفذ 4000 ويتحقق من صحتها قبل تنفيذ الاختبارات المعتمدة عليها. ما عدا ذلك مجرد مسرح.
هذا هو المعيار الذي يجب أن تحافظ عليه KENSAI: الاحتفاظ بالقياس غير المريح، وتسمية الشروط المسبقة المكسورة، وتحويل التشغيل الأحمر إلى قائمة إصلاح قصيرة.
الخلاصة
المعيار المفيد بسيط: لا تصبح الادعاءات حقيقية إلا عندما تصطف الشروط المسبقة والأثر والمسار معًا. عمل اليوم يبقي هذا المعيار ظاهرًا.
اجعل بوابات الجودة تثبت شروطها المسبقة بنفسها
تصبح KENSAI أقوى عندما يشرح كل build أحمر ما إذا كان المنتج قد فشل، أو فشل الـ harness، أو أن البيئة لم توجد أصلًا.
KENSAIKENSAI — AI-Powered Security Intelligence