‏Storybook Workbench: ممیزی رابط اپ‌های وایب‌کدشده

به نوشتهٔ Evil Martians، یه ایجنت هوش مصنوعی می‌تونه ظرف یه بعدازظهر یه وب‌اپ کامل بسازه که قابل‌قبول به‌نظر برسه و اجرا هم بشه. مشکل این‌جاست که بعدش نمی‌دونی از ۴۶۹ فایل کامپوننت توی پوشهٔ src/ کدوم‌ها ساختاری‌ان و کدوم‌ها بن‌بست‌هایی‌ان که ایجنت سه پرامپت قبل رهاشون کرده. Storybook Workbench جواب همین مسئله‌ست.

این ابزار مجموعه‌ای از اسکیل‌هاست که ایجنت کدنویس رو موقع ممیزی کامپوننت‌ها هدایت می‌کنه و هرکدوم رو به استوری قابل مشاهده تبدیل می‌کنه. مخاطبش مهندس‌ها، طراح‌ها یا بنیان‌گذارهایی‌ان که یه پروتوتایپ ساخته‌شده با ایجنت رو تحویل گرفتن، دارن دیزاین سیستم رو به کد می‌برن، یا حواسشون به مصرف توکن و صورت‌حساب هست.

نویسنده‌ها می‌گن کدنویسی ایجنتی باعث شده طراحی به داخل کدبیس بیاد و کم‌کم جای فیگما رو به‌عنوان منبع حقیقت بگیره. نتیجه اینه که آدم‌ها روی کدی کار می‌کنن که یا خوندنش رو بلد نیستن یا خیلی توش خبره. اپ وایب‌کدشده آشفتگی رو نامرئی می‌کنه: دیف پول‌ریکوئست رو می‌بینی، ولی نمی‌بینی ایجنت کامپوننت مرده جا گذاشته یا نه — و چون ایجنت‌ها سریع‌تر از پاک‌سازی تولید می‌کنن، آشغال تلنبار می‌شه.

روی همون اپی که مثال زدن، فهرست‌برداری عدد بزرگی برگردوند: از ۴۶۹ فایل کامپوننت، ۴۳۸ تاش واقعی بود و ۳۱ تا مرده — تعریف‌شده ولی هیچ‌جا import نشده. این کد مرده هم پخش یکنواخت نبود؛ نوزده تا از اون ۳۱ تا صفحه یا فلوی کاملی بودن که قبلاً جایگزین شده بودن. تیم می‌گه سه جور پوسیدگی نامرئی رو توی هر کدبیس ایجنتی دیده: کامپوننت مرده، هم‌زیستی چند دیزاین سیستم توی یه کدبیس، و حالت‌های کامپوننت که به‌شکل شرط نوشته شدن و فقط موقع رندر جداگانه دیده می‌شن.

انتخاب Storybook هم دلیل داره: کامپوننت رو بیرون از اپ میزبان و هر بار در یک حالت رندر می‌کنه. معمولاً ازش به‌عنوان ابزار مستندسازی کتابخانهٔ کامپوننت استفاده می‌شه، ولی به گفتهٔ این تیم برای ممیزی فرانت‌اند تولیدشده با AI خیلی مفیدتره، چون نشون می‌ده رابط بر اساس کد واقعاً چه کاری می‌کنه.

داخل بسته، اسکیل‌ها یکی از چهار کار رو انجام می‌دن — آنبورد، ارکستراسیون، ناوبری یا گزارش — و همه با /sb. شروع می‌شن. موقع نصب، یه باندل از ترمینال با ایجنت دلخواهت نصب می‌شه ولی فقط برای اسکیلی که اجرا می‌کنی کانتکست می‌ده؛ یعنی باندل یه حلقه‌ست، نه یه منو. از هاب اصلی می‌بینی بر اساس وضعیت ریپو چی‌کار باید بکنی و دستور پیشنهادی بعدی چیه.

سه کاربرد عملی داره. اول ممیزی رابط: اسکیل‌ها کدبیس رو با اسکریپت‌های قطعی شل و پایتون اسکن می‌کنن و گزارش JSON می‌دن، بعد رَپِرهای Storybook همه‌چی رو بصری رندر می‌کنن. دوم عمل کردن روی یافته‌ها: چون خروجی ساختاریافته‌ست، می‌شه دادش به MCP لینِر و تیکت ساخت یا PDF گرفت؛ اسکیل sb-figma هم سینک دوطرفه با فیگما رو انجام می‌ده. سوم بهبود مستمر با sb-audit که دوره‌ای گزارش‌ها رو تازه می‌کنه و برگشتن مقادیر هگز خام یا توکن تعریف‌نشده رو علامت می‌زنه.

خروجی نهایی یه کاتالوگ رندرشده از هر کامپوننت در هر حالت مهمه — لودینگ، خالی، خطا و پرشده — به‌علاوهٔ نقشهٔ فلوهای سرتاسری، فهرست مسیرها و باگ‌های واقعی دسترس‌پذیری. توی همون نمونه، حدود شش کامپوننت باگ‌دار پیدا شد که توی اپ در حال اجرا نامرئی بودن؛ از جمله یه واریانت بَج با نسبت کنتراست ۳.۸۷ که زیر آستانهٔ ۴.۵ استاندارد WCAG AA بود. هیچ‌کدوم باعث شکست بیلد نمی‌شدن، ولی همه‌شون کاربر رو زمین می‌زدن. یافته‌ها هم با مهر زمانی توی .storybook/audit/findings.md ذخیره می‌شن.

نکات کلیدی:

• Storybook Workbench مجموعه‌ای از اسکیل‌های ایجنتی برای ممیزی رابط و ساخت استوری‌هاست
• توی نمونهٔ داخلی: ۳۱ کامپوننت مرده از ۴۶۹ تا، که نوزده‌تاش صفحه یا فلوی رهاشده بود
• شش باگ دسترس‌پذیری پیدا شد که هیچ بیلدی گیرشون نمی‌انداخت
• خروجی JSON ساختاریافته‌ست، پس می‌شه تیکت ساخت یا با فیگما سینک کرد
• زمان ممیزی از حدود سه روز به چند ساعت رسید