پرش به مطلب اصلی

مستندسازی از Figma

از lore:figma-to-doc زمانی استفاده کنید که ورودی‌تان بصری است: فایل‌های طراحی، ماک‌آپ، یا هر چیزی با یک لینک Figma.

lore:figma-to-doc <figma-url-or-file-key>

چه می‌کند​

  1. منابع را جمع می‌کند. کامنت‌های بحث فایل و حاشیه‌نویسی‌های Dev Mode آن را می‌گیرد؛ یعنی ویژگی annotations روی نودها، که قابلیت واقعی حاشیه‌نویسی Figma است و با متن معمولی طراحی فرق دارد. این‌ها دو منبع جداگانه‌اند و هر دو خوانده می‌شوند. منابع مورد اعتماد پیکربندی‌شده را هم برای مطالب مربوط به صفحه‌های در محدوده جست‌وجو می‌کند. همه‌چیز، از کامنت‌ها و حاشیه‌نویسی‌ها تا یافته‌های هر منبع مورد اعتماد، در یک سرشماری منبع قابل حسابرسی ثبت می‌شود و هر سطر رسید پشتش را همراه دارد، تا هیچ منبعی بی‌سروصدا رد نشود.

    واکشی از مسیر یک اسکریپت کاوش می‌گذرد که پاسخ خام را پیش از هر تفسیری ذخیره می‌کند و حاشیه‌نویسی‌ها را بر پایه‌ی وجود آرایه‌ی annotations انتخاب می‌کند، نه بر پایه‌ی نام فیلدی درون آن. آن ساختار مستند نشده و تغییر هم کرده است: تکیه بر یک نام فیلد، یک‌بار یک تغییر ساختار را به «۰ حاشیه‌نویسی، تأیید شد که نیست» تبدیل کرد و هر قاعده‌ی کسب‌وکاری که طراحان نوشته بودند پاک شد. وقتی پاسخ ذخیره‌شده حاشیه‌نویسی‌ای دارد که تجزیه از دستش داده، کاوشگر همین را اعلام می‌کند و این خواندن ناموفق است، نه صفر.

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

  3. سیم‌کشی پروتوتایپ را می‌خواند. فلوهای پروتوتایپ فایل (flowStartingPoints) و آرایه‌ی interactions[] هر فریم را می‌گیرد؛ این شواهد ناوبری ماشین‌خوان برای Main Flow یک سناریوست، به‌جای حدس‌زدن فلو از روی نام فریم‌ها. زمان‌بندی انیمیشن (مدت، easing، نوع ترنزیشن) عمداً به‌عنوان نویز نمایشی نادیده گرفته می‌شود و فقط معنای ناوبری نگه داشته می‌شود، مثلاً ترنزیشن overlay ⇐ یک دیالوگ. شمارش فلوها و اینتراکشن‌ها، حتی وقتی صفر است، در سرشماری منابع ثبت می‌شود.

  4. تصاویر را استخراج می‌کند. فریم‌های منفرد را (نه ترکیب‌های کل section) با وضوح ۲× خروجی می‌گیرد و زیر دایرکتوری تصاویر استاتیک، با نام‌گذاری بر اساس فیچر و وضعیت، ذخیره می‌کند. فریم‌ها بر اساس دستگاه (از روی عرض و نامشان) دسته‌بندی می‌شوند؛ واریانت‌های موبایل و تبلت به زیرمسیرهای mobile/ و tablet/ هدایت می‌شوند. وقتی همه‌ی فریم‌ها آمدند، در یک پاس فشرده می‌شوند: معمولاً حدود ۷۰٪ کوچک‌تر، با همان ابعاد و بدون تفاوت قابل‌دیدن. این فایل‌ها در ریپازیتوری شما کامیت و توسط سایتتان سرو می‌شوند، پس این تنها نقطه‌ای است که آن حجم پس گرفته می‌شود. ابزار فشرده‌سازی فایلی را که نتواند در محدوده‌ی کف کیفیتش فشرده کند اصلاً بازنویسی نمی‌کند، پس «کوچک‌تر» هیچ‌وقت بی‌سروصدا معنی «بدتر» نمی‌دهد؛ و اگر روی آن ماشین هیچ بهینه‌سازی نصب نباشد، اجرا همین را می‌گوید و تصاویر را دست‌نخورده می‌گذارد، به‌جای ادعای صرفه‌جویی‌ای که نکرده.

  5. مستندات را می‌نویسد. صفحه‌های Figma را به بخش‌های سند، گروه‌های فریم را به سناریوهای شماره‌دار (سناریو ۱، سناریو ۲، …)، حاشیه‌نویسی‌ها را به قواعد کسب‌وکار، واریانت‌های کامپوننت را به تفاوت‌های نقش، و اینتراکشن‌های پروتوتایپ را به گام‌های Main Flow نگاشت می‌کند، و برای هر بخشی که دو یا چند لبه‌ی اینتراکشن دارد یک دیاگرام فلوی Mermaid می‌افزاید. وقتی طراحی فریم موبایل یا تبلت دارد، یک بخش کوتاه نمای موبایل و تبلت فقط تفاوت‌ها با دسکتاپ را ثبت می‌کند (اسکرین‌شات‌های موبایل با نصف عرض نمایش داده می‌شوند تا تصاویر عمودی گوشی کل صفحه را نگیرند).

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

استخراج سنگین واگذار می‌شود​

برای فایل‌های بزرگ، کار سنگین (کامنت‌ها، حاشیه‌نویسی‌ها، فهرست فریم‌ها و خروجی‌گرفتن تصاویر فریم) را ساب‌اجنت lore:figma-extractor انجام می‌دهد، که یک خلاصه‌ی فشرده از قواعد کسب‌وکار و مسیر تصاویر برمی‌گرداند. این کار context جلسه‌ی اصلی را تمیز نگه می‌دارد. اسکیل‌ها و ساب‌اجنت‌ها را ببینید.

مدیریت شکاف‌ها​

  • اطلاعات غایب به‌جای حدس، به یک نشانگر صریح [CLARIFICATION NEEDED: …] تبدیل می‌شود.
  • فریم‌های هر فیچر مستندشده در برابر وضعیت‌هایی که استفاده‌ی واقعی تولید می‌کند بررسی می‌شوند: خالی، خطا، بارگذاری، رد دسترسی. وضعیتی که طراحی نشان نمی‌دهد به یک پرسش شفاف‌ساز تبدیل می‌شود، نه یک صفحه‌ی اختراعی.
  • متن جای‌گزین و Lorem-Ipsum باعث درخواست محتوای واقعی می‌شود.
  • وقتی یک حاشیه‌نویسی و یک کامنت در تضادند، حاشیه‌نویسی ترجیح داده می‌شود و تضاد با شما در میان گذاشته می‌شود.
  • سیم‌کشی پروتوتایپ به‌عنوان نیت طراحی، نه رفتار تأییدشده در نظر گرفته می‌شود: هرجا یک لبه‌ی اینتراکشن با یک حاشیه‌نویسی Dev Mode تضاد داشته باشد، حاشیه‌نویسی برنده است و واگرایی گزارش می‌شود.

اعتبارنامه‌ها​

توکن Figma از محیط یا اینتگریشن متصل خوانده می‌شود. هرگز در چت درخواست، بازتاب، یا در فایلی نوشته نمی‌شود.