أمضت فرق البرمجيات عقوداً في بناء الحتمية داخل سلاسل أدواتها. ملفات القفل لمديري الحزم. صور القاعدة المُثبَّتة للحاويات. البناء القابل للتكرار للمصنوعات المُجمَّعة. المبدأ مفهوم جيداً: نفس المدخلات يجب أن تُنتج نفس المخرجات، دائماً، على أي جهاز، في أي وقت.

تسليم التصميم لم يُطبِّق هذا المبدأ قط. كان بطبيعته عملية بشرية وبالتالي غير حتمية. مصمّم يشرح التصميم لمطوّر. المطوّر يُفسِّره. يتفاوت التفسير بحسب الشخص واليوم ووضوح التعليق المكتوب في Zeplin. لا يمكن إعادة تشغيله. لا يمكن اختباره. لا يمكن مقارنته.

في عالم وكلاء الكود بالذكاء الاصطناعي، التسليم غير الحتمي بات مشكلة هندسية من الدرجة الأولى. تُعالجها figmascope بحزمة سياق مجمَّدة ومحمولة.

لماذا الأدوات الحالية غير حتمية للوكلاء

تمنحك Zeplin وAvocode أرقاماً مستخرجة من Figma — أبعاد الطبقات وقيم الألوان وأحجام الخطوط. لكنها تقدّمها كواجهة مستخدم قابلة للتصفح، لا كمصنوعة قابلة للقراءة آلياً. وكيل يُشار إلى Zeplin يجب التنقل في واجهة مستخدم للعثور على القيم، وهو هشّ ومُقيَّد بمعدل الطلبات ومعتمد على كيفية كتابة التعليقات التوضيحية.

يذهب Figma Dev Mode أبعد: يمنحك مقتطفات كود مُولَّدة مُضمَّنة من التصميم. لكن المقتطفات عديمة الحالة — تُولَّد عند الطلب، غير مُصنَّفة بالإصدارات. لا توجد حزمة يمكن تثبيتها. لا يوجد ملف يمكن مقارنته. إذا حدَّث المصمم التصميم، يتحدث عرض Dev Mode بصمت. لا تعرف متى تغيّر التصميم الأساسي بالنسبة لما صدَّرته آخر مرة.

لقطات الشاشة هي الحالة الأسوأ: بيانات بكسل صرفة، غير حتمية تماماً في التحليل، تُنتج استنتاجات هيكل مختلفة في كل مرة.

اتصالات MCP المباشرة — الأدوات التي تمنح الوكلاء وصولاً API في الوقت الفعلي لملف Figma — غير حتمية بتعريفها. الملف يتغير بينما الوكيل يقرأه. تشغيل الوكيل الساعة 9 صباحاً وتشغيله الساعة 2 ظهراً يرى مدخلات مختلفة. لا يمكنك إعادة إنتاج تشغيل التاسعة لأن المصدر تغيّر.

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

الحزمة كوحدة تجميع

النموذج الذهني الصحيح لتصدير figmascope هو مصنوعة التجميع. تماماً كما يأخذ المُجمِّع الكود المصدري ويُنتج ثنائياً حتمياً — نفس المصدر ونفس الإعدادات ونفس الثنائي — يأخذ figmascope حالة ملف Figma ويُنتج حزمة حتمية: نفس حالة الملف، نفس الحزمة، في كل مرة.

الحزمة لقطة مجمَّدة. تُلتقط نسخة محددة من التصميم وتُسلسَل كل خاصية ذات صلة: التخطيط المكاني وهوية المكوّنات وارتباطات الرموز ومحتوى السلاسل والتسلسل الهرمي. بمجرد التصدير، الحزمة ثابتة. ملف Figma يمكن أن يتغير؛ الحزمة لا. إذا أردت دمج هذه التغييرات، تُعيد التصدير وتحصل على حزمة جديدة.

هذا هو نموذج وحدة التجميع. ملف التصميم هو المصدر. الحزمة هي المصنوعة. الوكلاء يستهلكون المصنوعات، لا المصدر.

أربع خصائص للتسليم الحتمي

قابل للتصوير اللحظي. يجب أن تمثّل مصنوعة التسليم نقطة زمنية محددة. ليس "الحالة الراهنة لملف Figma" — تصديراً مُسمَّى مُصنَّفاً بالإصدارات. حزم figmascope تحمل _meta.json مع وقت التصدير وبصمة لما أُدرج. الحزمة لقطة لا عرض مباشر.

محمول. يجب أن تكون المصنوعة مكتفية بذاتها. بدون تبعيات على خدمات خارجية أو APIs مباشرة أو جلسات تسجيل دخول. حزمة figmascope هي ZIP من ملفات عادية — JSON وMarkdown وPNG. يمكنك نسخها وإرسالها بالبريد الإلكتروني وتثبيتها في git وإرفاقها بـ PR وتسليمها لمطوّر مبتدئ أو وكيل كود بدون أي إعداد.

قابل للتفتيش. المصنوعة الحتمية عديمة الفائدة إذا لم تستطع التحقق مما بها. كل ملف في الحزمة قابل للقراءة البشرية. CONTEXT.md هو Markdown. tokens.json هو هيكل شبيه بـ W3C. IR لكل شاشة هو JSON بأسماء حقول واضحة. يمكن للمهندس فتح الحزمة ومراجعة بالضبط ما أُخبر به الوكيل. هذا مختلف نوعياً عن "لصقت لقطة الشاشة وحصلت على بعض الكود."

قابل للتكرار. بنفس حالة ملف Figma، يجب أن يُنتج تصديران منفصلان حزماً مكافئة وظيفياً. ليس متطابقة بالبايت (الطوابع الزمنية تختلف)، لكن متطابقة دلالياً: نفس هياكل العقد ونفس قيم الرموز ونفس جرد المكوّنات. إذا صدَّرت مرتين من ملف غير متغيّر واختلفت الحزم دلالياً، فثمة خطأ ما. هذه الخاصية تسمح بالتحقق من خط أنابيب التصدير وضبط الانحدار في المُستخرج نفسه.

كيف يتجلى هذا عملياً

مصمّم يُنهي شاشات سبرينت. يُصدِّر حزمة. تُثبَّت الحزمة في المستودع جانباً مع التذكرة — أو مُرفقة بمشكلة Jira، أو في الدرايف المشترك، حسب سير عملك. في هذه النقطة، مصنوعة التسليم مُثبَّتة. الوكيل (أو المطوّر) يعمل من الحزمة، لا من ملف Figma المباشر.

في منتصف التنفيذ، يحدِّث المصمم ثلاث شاشات. لا مشكلة: حزمة المطوّر العاملة لم تتغير. الشاشات الجديدة تحصل على تصدير جديد. الآن لديك حزمتان ويمكنك مقارنتهما: ما الذي تغيّر بين التصميم الذي بدأ به المطوّر والتصميم الحالي. هذه بالضبط رؤية التغيير التي يستحيل تحقيقها مع سير العمل القائم على لقطات الشاشة أو الاتصالات المباشرة.

في سير العمل متعدد الوكلاء — وكيل يبني مكتبة المكوّنات، وآخر يبني تخطيطات الشاشات، وثالث يكتب الاختبارات — يحصل كل وكيل على نفس الحزمة كمصدر حقيقة. جميعهم يعملون من نفس حالة التصميم المجمَّدة. مخرجاتهم قابلة للتركيب لأن مدخلاتهم مشتركة وثابتة. هذا هو الشرط المسبق لتوليد واجهة مستخدم متعدد الوكلاء موثوق فعلاً.

مقارنة الحزم

لأن الحزمة ملفات عادية، تُقارَن مثل الكود. تصديران لنفس الملف عبر نسختين من Figma يمنحانك JSON diff يُخبرك بالضبط بما تغيّر:

هذه رؤية تغيير التصميم التي لا وجود لها في أي أدوات تسليم حالية. لدى Figma تاريخ إصداراتها الخاص، لكنه بصري وموجّه للمصمّمين. الـ diff للحزمة منظَّم وموجَّه للمطوّرين: بيانات تغيير قابلة للقراءة آلياً يمكنها دفع الاختبارات الآلية أو تحديث سجلات التغييرات أو تشغيل سير عمل CI.

CI/CD لتسليم التصميم

بمجرد أن يكون التسليم حتمياً، يتبع CI/CD بشكل طبيعي. يمكنك كتابة اختبارات تعمل مقابل حزمة: "يجب أن تتضمن هذه الشاشة مكوّن Button/Primary"، "يجب أن يكون هذا الرمز مربوطاً وليس قيمة مُرمَّزة"، "يجب أن يحتوي هذا السلسلة على مفتاح stringRef". هذه فحوصات تحليل ساكن مقابل بيانات منظّمة. تعمل في ميلي ثوانٍ. تعمل في خط أنابيب.

يمكنك أيضاً التحقق من إخراج وكيل توليد الكود مقابل الحزمة التي أُعطيت له. هل استخدم الوكيل الرموز أم رمَّز القيم الحرفية؟ هل ولَّد العدد الصحيح من حالات المكوّن المتكرر؟ هل استخدم قيم التباعد الصحيحة؟ هذه الأسئلة قابلة للإجابة حين يكون مصدر الحقيقة ملفاً منظَّماً لا PNG.

مقارنة MCP

اتصالات MCP المباشرة بـ Figma تكتسب شعبية. الجاذبية واضحة: الوكيل يرى دائماً أحدث تصميم، بدون خطوة تصدير، بدون إدارة حزم يدوية. لكن الاتصالات المباشرة تتاجر بالحتمية مقابل الراحة — ولوكلاء الذكاء الاصطناعي هذه المقايضة سيئة.

الاتصالات المباشرة تعني: سياق الوكيل يعتمد على وقت تشغيله. تشغيل الساعة 9 صباحاً والساعة 2 ظهراً يرى بيانات مختلفة إذا عمل المصمّم خلال النهار. لا يمكنك إعادة إنتاج التشغيل السابق. لا يمكنك الاختبار مقابل مدخل ثابت. لا يمكنك مراجعة ما أُخبر به الوكيل. إذا كان الكود المُولَّد خاطئاً، لا يمكنك التمييز بين "النموذج أنتج استنتاجاً سيئاً" و"التصميم تغيّر تحت الوكيل."

النموذج الصحيح هو: الاتصالات المباشرة لاستكشاف التصميم والتكرار (حيث تهمّ الحداثة)، الحزم الحتمية للتسليم والتوليد (حيث تهمّ قابلية التكرار). إنهما ليسا متنافسَين — يعملان في نقاط مختلفة من سير العمل.

التسليم لمطوّر مبتدئ

نفس الخصائص التي تجعل الحزم جيدة لوكلاء الذكاء الاصطناعي تجعلها جيدة للمطوّرين البشريين الجدد على قاعدة كود. مطوّر مبتدئ مُعطى حزمة لديه: المواصفة الكاملة في CONTEXT.md، وكل قيم الرموز في tokens.json، وكل مكوّن مُدرَج مع خصائصه، وكل سلسلة مع هويتها. لا يحتاج أن يكون في ملف Figma. لا يحتاج حساب Figma. لا يحتاج معرفة أي شاشة هي الموثوقة.

الحزمة أمر عمل كامل مكتفٍ بذاته. نفس ما سيتلقاه الوكيل. الاختلاف الوحيد هو أن الإنسان يقرأه والوكيل يعالجه برمجياً — لكن المصنوعة متطابقة.

هذا التوحيد — نفس المصنوعة، مستهلك بشري أو وكيل — هو النقطة. الحزمة هي وحدة التسليم. كل شيء آخر تفصيل تنفيذي.

انظر التسليم الحتمي في العمل مع Claude Code، وCursor، أو Aider. الجميع يبدأ من نفس تصدير figmascope.