Archify: مخطط معماري تفاعلي لنظامك، تطلبه بجملة ويخرج مفحوصا في ملف واحد

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

Archify أداة مفتوحة المصدر تختصر هذا الطريق: تصف نظامك بجملة عادية داخل محادثة مساعد البرمجة الذي تستعمله، فيخرج لك مخطط تفاعلي في ملف واحد. وهي ليست أول أداة ترسم من الكلام، لكن ما يميزها أنها تفحص المخطط قبل أن تسلمه، فلا يصلك رسم متداخل الكلمات أو خارج عن حدود الشاشة. ظهرت في أبريل 2026، وتجاوزت 52 ألف نجمة على GitHub في أقل من خمسة أشهر.

ماذا تحصل عليه بالضبط؟

تكتب في المحادثة جملة كهذه:

Use Archify to draw: Browser -> API -> Redis cache -> PostgreSQL fallback.

فتحصل على ملف HTML واحد. تفتحه بالنقر المزدوج عليه في أي متصفح، فيعمل بلا خادم ولا حساب ولا اتصال بالإنترنت. وتستطيع إرساله لزميلك في البريد، أو وضعه في مستودع المشروع، أو فتحه على حاسوب آخر — سيعمل كما هو، لأن كل ما يحتاجه بداخله.

وداخل هذا الملف مخطط تتعامل معه لا صورة تنظر إليها. اضغط / لتبحث عن مكون باسمه فيضاء أمامك. وحين تركز على مكون، يظهر لك خياران: Upstream ليريك كل ما يصل إليه، وDownstream ليريك كل ما يصل هو إليه — مباشرة أو عبر وسيط — مع عدد المكونات والوصلات وأقصى عدد خطوات بينها. وبقية الوظائف على مفاتيح مفردة:

والتصدير يعطيك ما تحتاجه للنشر: صورة PNG تنسخ إلى الحافظة مباشرة، أو ملف SVG، أو مقطع WebM، أو بطاقة مشاركة بمقاس 1200×630 تصلح لملف README أو لمنشور على الشبكات. وإن تتبعت طريقا بعينه ثم صدرت، خرجت لك بطاقة تبرز ذلك الطريق ويبقى المخطط كاملا خلفه ليوضح السياق.

وكل حالة تصل إليها لها رابط ثابت تشاركه مع غيرك: #focus=<id> للتركيز على مكون، و#route=<from>~<to> لطريق بعينه، و#lens=<kind>~<kind> لمقارنة دورين، و#view=<view-id> لمحطة من الجولة الموجهة. فترسل لزميلك رابطا يفتح المخطط على النقطة التي تقصدها بالضبط، لا على أوله.

متى تحتاج هذه الأداة، ومتى لا تحتاجها؟

الأداة تنفع في مواضع، وتزيد عن الحاجة في مواضع أخرى.

تنفعك حين:

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

ولا تحتاجها حين:

• يكفيك رسم من خمسة صناديق في ملف README. هنا Mermaid أسرع وأخف.
• تريد أن تسحب المستطيلات بالفأرة وتضبطها بيدك. Archify ليس محرر رسم، والتعديل فيه يكون بالكلام لا بالسحب.
• تريد أداة تفحص نظامك وهو يعمل وتستخرج منه الخريطة تلقائيا. Archify لا يفعل ذلك؛ هو يرسم ما تصفه أنت أو يصفه المساعد بعد قراءة الكود.
• لا تستعمل مساعد برمجة أصلا. تستطيع تشغيله بسطر الأوامر وحدك، لكنك حينئذ ستكتب وصف المخطط بيدك، وهو ما تختصره الأداة أصلا.

كيف تبدأ: ثلاث خطوات

الخطوة الأولى: التثبيت

Archify يثبت بوصفه «مهارة» (skill)، وهي ببساطة مجلد فيه ملف تعليمات وبعض الملفات، يقرؤه مساعد البرمجة ويتبعه حين يقع على مهمة تناسبه. أي أنك لا تشغل برنامجا منفصلا؛ أنت تضيف قدرة جديدة إلى المساعد الذي تستعمله أصلا.

والتثبيت أمر واحد:

npx skills add tt-a1i/archify -g

ويعمل هذا داخل Claude Code وCursor وCodex CLI وopencode. ولمن أراد التجربة قبل التثبيت، أو تثبيتا صريحا في Cursor:

npx skills use tt-a1i/archify@archify --agent codex
npx -y skills add tt-a1i/archify --skill archify --agent cursor --global --copy --yes

أما في Claude.ai فترفع ملف ZIP في إعدادات المهارات، وفي منصة Raven (بيئة وكيل من EverMind) تفك الملف نفسه في مجلد مهاراتها. والمتطلب الوحيد على جهازك هو Node.js بإصدار 18 فأعلى.

الخطوة الثانية: اطلب المخطط بالكلام

ولا يشترط أن يكون لديك مستودع كود أصلا. إن أردت مخططا من وصف في رأسك، اكتب الوصف مباشرة:

Use Archify to draw: Browser -> API -> Redis cache -> PostgreSQL fallback.

وإن كان بين يديك مستودع كود مفتوح في محررك وأردت مخططا مبنيا عليه، فالطلب الأفضل يحدد النطاق وعدد المكونات صراحة، لأن ترك النطاق مفتوحا هو ما ينتج المخططات المزدحمة:

Analyze this repository, then use archify to create a high-level runtime architecture diagram.
Show 8-12 core components, one primary path, external dependencies, and trust boundaries.
Put supporting detail in cards instead of adding more edges.

الخطوة الثالثة: عدل بالكلام حتى يعجبك

بعد أن يخرج المخطط الأول، تكمل بطلبات قصيرة:

add Redis
move auth to the left
highlight the rollback path

فيعدل المساعد الوصف ويعيد الفحص. وهذه هي طريقة تحريك العناصر في أداة لا محرر فيها بالفأرة: تطلب النقل بالكلام، ويرفض الفاحص النتيجة إن أفسدت التخطيط. والمهم أن التعديل موضعي — يتغير ما طلبته وحده، وتبقى بقية المخطط على حالها بدل أن يعاد ترتيبه كله.

أنواع المخططات الخمسة

المخطط المعماري نوع واحد مما تصنعه الأداة، ولها خمسة أنواع لكل منها محرك عرض مستقل:

وإن التبس عليك أيها تختار، فثمة أمر في سطر الأوامر يجيبك مباشرة دون أن يفتح مستودعا ولا يستدعي نموذجا:

node bin/archify.mjs guide "Show an API request with Redis cache miss"

لماذا لا يخرج مخطط رديء؟

سؤال مشروع: إن كان الذي يرسم هو نموذج لغوي، فما الذي يمنع أن يخرج المخطط متداخلا أو ناقصا؟ الجواب أن النموذج لا يسلم المخطط مباشرة، بل يمر ما ينتجه على فاحص آلي قبل أن يصل إليك.

والفحص ليس تأكدا من صحة الصيغة فحسب. فمستوى الجودة showcase يجري تسعة فحوص على الملف الناتج ولا يقبل خطأ واحدا ولا تحذيرا. وتشمل هذه الفحوص: سلامة بنية الوصف، وقواعد التخطيط، وصحة الـ HTML والـ SVG الناتجين، ومسارات الأسهم، وخلو الكلمات من الأسهم — أي أن تكون المسافة بين أي تسمية وأي سهم يمر قربها كافية لتقرأ. وفي showcase ترفض المسافة الأقل من أربعة بكسلات، أما مستوى standard فيكتفي بتسجيل تحذير حين تنزل تحت بكسلين. يستعمل standard أثناء الاستكشاف، وshowcase للمخرج النهائي.

وحين يفشل الفحص، لا يتلقى المساعد رسالة خطأ غامضة يخمن بعدها. يتلقى تقريرا يحدد العنصر المخالف بعينه، والقياس المرصود فعليا، وقائمة بالإصلاحات المتاحة لتلك الحالة — على هيئة «هذه التسمية تبعد 1.8 بكسل عن هذا السهم، والإصلاحات الممكنة كذا». فيصلح النقطة المحددة بدل أن يعيد المحاولة عشوائيا. ولئلا يدور في حلقة لا تنتهي، تقيده تعليمات المهارة بجولتي تصحيح فقط: فإن لم تتحسن حصيلة الأخطاء في جولتين متتاليتين، وجب عليه أن يتوقف ويخبرك بالمشكلات الباقية كما هي.

وهذه الصرامة ملموسة في التجربة العملية. ففي اختبار مستقل نشره أحد المطورين، استغرق توليد مخطط من أحد عشر مكونا نحو 222 ثانية، رفض خلالها الناتج أربع مرات متتالية، لأسباب منها: تسميات متداخلة، ونص بارتفاع 4.2 بكسل لا يقرأ، ولوحة تزيد 49 بكسلا عن ارتفاع الشاشة عند دقة 1440×900. وهذه أخطاء يمررها أي نموذج يراجع عمله بنفسه، ببساطة لأنه لا يقيس البكسلات.

ويمتد الحرص إلى لحظة الكتابة على القرص. فالمخطط الجديد لا يحل محل القديم إلا بعد نجاح كل الفحوص؛ وإن فشل شيء، بقي ملفك السابق كما هو بايتا ببايت. أي أنك لا تجد نفسك أمام ملف نصف مرسوم أتلف مخططا سليما كان يعمل.

ما الذي يجري خلف الكواليس؟

الفكرة المركزية أن المساعد لا يكتب HTML ولا SVG ولا لغة رسم خاصة. يكتب ملف JSON بقواعد صارمة يصف فيه المخطط: ما مكوناته، وكيف تتصل، وأين تقع. ثم يأخذ برنامج عادي — لا علاقة له بالذكاء الاصطناعي — هذا الملف ويحوله إلى الصفحة النهائية.

ويسمي المشروع هذا الملف تمثيلا وسيطا منمطا (typed JSON IR). و«الوسيط» لأنه يقع بين ما كتبه الإنسان وما يعرض فعلا، فيحمل المعنى مجردا من شكل العرض. و«المنمط» لأن لكل حقل فيه نوعا محددا وقيما مسموحة، وأي حقل غير معروف يرفض بدل أن يتجاهل بصمت. وهذه عينة مختصرة تكفي لرؤية شكله:

{
  "schema_version": 1,
  "diagram_type": "architecture",
  "meta": { "title": "Sample Web App", "quality_profile": "showcase" },
  "components": [
    { "id": "api", "type": "backend", "label": "API Server",
      "sublabel": "FastAPI :8000", "pos": [670, 300], "size": [130, 60] },
    { "id": "cache", "type": "database", "label": "Redis",
      "sublabel": "cache :6379", "pos": [670, 150], "size": [130, 60] },
    { "id": "db", "type": "database", "label": "PostgreSQL",
      "sublabel": "primary :5432", "pos": [880, 300], "size": [130, 60] }
  ],
  "connections": [
    { "id": "cache-read-through", "from": "api", "to": "cache",
      "label": "read-through", "fromSide": "top", "toSide": "bottom" },
    { "id": "api-sql", "from": "api", "to": "db", "label": "SQL" }
  ]
}

كل مكون يحمل معرفا ثابتا (id)، ونوعا من قائمة مغلقة هي frontend وbackend وdatabase وcloud وsecurity وmessagebus وexternal، ثم اسما ووصفا فرعيا وموضعا وحجما. والوصلات (connections) تربط بين معرفين وتحمل تسمية تشرح العلاقة. والنوع ليس لونا فحسب: هو ما تبني عليه وظيفة L مقارنتها بين الأدوار.

ولماذا كل هذا التعقيد بدل أن يرسم النموذج الصورة مباشرة؟ لسببين. الأول أن البرنامج الذي يحول الملف إلى صفحة حتمي (deterministic)، أي يعطي من المدخل نفسه المخرج نفسه بالبايت في كل مرة بلا عشوائية — فالنتيجة قابلة للتكرار والمراجعة. والثاني أن الملف المنظم يمكن فحصه آليا قبل الرسم، وهو ما يستحيل مع صورة يولدها نموذج دفعة واحدة. باختصار: النموذج يقرر ماذا يقول المخطط، والبرنامج يقرر كيف يرسم.

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

وظيفتان تحتاجهما الفرق

الوظيفتان التاليتان تخدمان العمل الجماعي أكثر من الرسم الفردي.

مقارنة المخطط قبل التغيير وبعده

حين يغير أحدهم معمارية النظام في طلب دمج (pull request)، يصعب على المراجع أن يرى أثر التغيير في الصورة الكبيرة. ولهذا أمر يقارن نسختين:

node bin/archify.mjs compare architecture base.json head.json delta.html --json

فيخرج لك صفحة من ثلاث حالات: قبل، والفرق، وبعد. المكونات المحذوفة تبقى في مواضعها الأصلية، والمنقول يترك خيالا في موضعه القديم يحمل علامة MOVE FROM، والوصلة التي تغيرت أطرافها تعرض بمسارها القديم والجديد معا. والتمييز يعتمد على الرموز + و~ و− و↔ وعلى أنماط الخطوط لا على اللون وحده، فيبقى مفهوما لمن لا يميز الألوان ولمن يطبع الصفحة بالأبيض والأسود.

وتتوقف المقارنة بدل أن تخمن في الحالات الملتبسة — إن اختلف المستودع بين النسختين، أو لم تشتركا في أي معرف واحد. وهي لا تدعي شيئا عن المخاطر: لا نطاق تأثير، ولا تقييم أمان، ولا حكما بأن التغيير آمن للدمج. تعرض الفروق كما هي، ويبقى الحكم لمن يراجع.

ربط المخطط بالكود الحقيقي

يبقى السؤال الأصعب في مخططات المعمارية: كيف تثق بأن المخطط يصف الكود لا تخيلا عنه؟ ولـ Archify جواب جزئي صريح الحدود.

فحين تريد ربط المكونات بملفاتها الفعلية، تصرح في الوصف برابط مستودع عام، وببصمة إيداع كاملة (commit SHA)، وبمسار ملف واحد إلى ثلاثة ملفات لكل مكون، ثم تمرر موضع نسخة المستودع المحلية:

node bin/archify.mjs deliver architecture diagram.json out.html --repo-root /path/to/repo --quality showcase

وقبل أن ينشر أي رابط، يتحقق Archify محليا من أن المستودع البعيد هو المذكور فعلا، وأن الإيداع قائم بتلك البصمة، وأن الملفات موجودة فيه تحديدا، وأن نطاقات الأسطر — إن ذكرت — صحيحة. فإن اختل شرط، فشل التسليم. وتظهر العقدة الموثقة بعلامة هادئة SRC n تدل على عدد مصادرها، وتفتح روابطها من بطاقتها. وتبقى هذه الروابط خارج الصور المصدرة، فلا تحمل الصورة المنشورة مسارات داخلية.

وحدود الميزة معلنة: المستودعات الخاصة خارج النطاق، والفروع غير المرفوعة كذلك، لأن التثبيت على إيداع عام بعينه هو أساس التحقق. وقد نشر المشروع حالة مطبقة على مستودع عام حقيقي هو mco-org/mco عند الإيداع 9f1a1cf، بدل الاكتفاء بمثال مصنوع للعرض.

Archify أم Mermaid؟

Mermaid هو المقياس الطبيعي للمقارنة، وهو لغة رسم نصية تعرضها GitHub أصلا داخل ملفات Markdown. والمقارنة بينهما ليست في «أيهما أفضل» بل في اختلاف ما ينتجانه.

مصدر Mermaid سطور قليلة تقرأ في فرق النسخ (diff) بوضوح، وتعرض على GitHub بلا أدوات، ولا تكلف شيئا في حجم المستودع. فلمخطط من ثماني عقد في ملف README، يبقى Mermaid الخيار الأفضل بلا منافسة، وأي بوابة تحقق لا تعوض بساطة سطر يقرأ في المراجعة.

أما Archify فيصلح حين يكون المخطط مادة يتعامل معها القارئ لا صورة ينظر إليها: خريطة يبحث فيها المراجع عن مكون باسمه، ويتتبع طريقا بعينه، ويقارنها بنسختها قبل التغيير. وهو الخيار كذلك حين يقدم المخطط في عرض أو ينشر صورة لائقة، لأن Mermaid لا يعطيك سيطرة على التخطيط ولا وضع عرض ولا تصديرا منضبطا.

ويقبل Archify مدخلا بصيغة Mermaid، لكن ليس بالمعنى الذي قد يتوقع: لا يوجد محول آلي. يقرأ المساعد نص Mermaid ليفهم البنية والمعنى، ثم يؤلف وصفا جديدا بصيغة Archify من الصفر. ولا ينقل تنسيق Mermaid كما هو.

الترخيص والمتطلبات والخصوصية

Archify مجاني بالكامل برخصة MIT، فلا حساب ولا اشتراك ولا مفتاح واجهة برمجية للأداة نفسها. لكن المساعد الذي يشغلها — Claude Code أو Cursor أو غيرهما — له تكلفته المستقلة؛ فمجانية Archify لا تعني مجانية سير العمل كله. ومن كتب الوصف بيده وشغل سطر الأوامر مباشرة لا يحتاج نموذجا لغويا أصلا.

ومتطلبه الوحيد Node.js بإصدار 18 فأعلى، بلا أي اعتمادية تشغيل: فحزم التطوير مثل ajv تستعمل في توليد الفاحصات مسبقا لا في تشغيلها، والمخطط الناتج يعتمد خارجيا على خط واحد هو JetBrains Mono مع بديل محلي يعمل دون اتصال.

والمشروع مبني على مشروع سابق هو Cocoon-AI/architecture-diagram-generator المرخص بـ MIT كذلك، وهو ما يفسر جزءا من نضج الأداة رغم حداثة ظهورها. وقد أطلق في 15 أبريل 2026، وبلغ 52,157 نجمة و3,409 نسخة متفرعة في 7 سبتمبر 2026، وآخر إصدار مستقر منه v2.16.0 بتاريخ 30 أغسطس 2026.

أما من ناحية الشبكة، فالمهارة المحزومة قد تجري طلبا واحدا على عنوان ثابت لتنبهك بوجود إصدار جديد لا أكثر: لا تنزّل تحديثا ولا تثبته ولا تنفذه. والفحص الناجح ينتظر نحو 72 ساعة قبل تكراره، والخادم لا يرى إلا بيانات الاتصال المعتادة — لا رقم الإصدار ولا اسم المساعد ولا شيئا من بيانات مشروعك ولا مما تكتبه. ويوقفه متغير البيئة ARCHIFY_UPDATE_CHECK_DISABLED=1 تماما.

القيود وما هو خارج نطاقه عمدا

بعض ما لا يفعله Archify مذكور في توثيقه ضمن «خارج النطاق»، وهي حدود متعمدة لا نواقص: ليس محرر رسم عاما، فلا سحب صناديق بالفأرة ولا تحرير مرئي مباشر؛ ولا يوفر استضافة للمشاركة، فالملف يبقى عندك؛ ولا يستورد Mermaid آليا؛ ولا يقدم ترتيبا تلقائيا عاما.

وحجم المخرج قيد حقيقي أيضا. فقد قاس اختبار مستقل أحد الملفات فوجده 519,709 بايت، أي نحو نصف ميغابايت لكل مخطط — وهو رقم ثقيل إن أردت وضع عشرة مخططات في مستودع واحد. والسبب أن محرك العرض كله مدمج داخل الملف، وهو نفسه ما يجعله يعمل بلا خادم ولا اتصال. ولا علاقة للحجم بالبطء: زمن الرسم في الاختبار نفسه لم يتجاوز 73 ميلي ثانية.

ويحمل متتبع المشكلات المفتوح بلاغات تستحق الذكر بصدق. فمنها بلاغ بأن حجم الخط في المخططات المعمارية صغير يتعب العين، وآخر بأن ثلاثة من خمسة أمثلة مرفقة بالحزمة ترسب في فحص الاحتواء الخاص بـ Archify نفسه، وثالث بانهيار وضع المعاينة على مسارات Windows المختصرة. وGitHub Copilot ليس ضمن الأسطح المدعومة رسميا.

الخاتمة

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

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

وأصدق دليل على جدية هذا الفحص أن بلاغا مفتوحا في المشروع يقول إن ثلاثة من الأمثلة المرفقة به ترسب فيه. فالفحص الذي يوقع مؤلفه فحص يقيس شيئا حقيقيا، لا ختم يمنحه المشروع لنفسه.

ولمن أراد أن يرى مخرجات Archify الحقيقية قبل تثبيتها، معمل البراهين يفتح النماذج المتحقق منها في المتصفح مباشرة: