مترجَم عن الأصل الصيني. وعند الاختلاف بينهما، يُعتد بالأصل.

Confer — خارطة طريق النسخة الأولى وما بقي من عمل

مقسَّمة إلى محطات؛ وكل محطة نسخة قابلة للتسليم والعرض.

v0.1 — Core proof of concept (4-6 أسابيع)

الهدف: أن تعمل على جهاز واحد سلسلةُ «المستخدم ← وكيله ← وكيل الطرف الآخر» من طرفها إلى طرفها.

النطاق (الواجب)

Out of scope:

Acceptance:

يشغّل مطوّران عند كل منهما نسخةً محلية من Confer، فيضيف كلٌّ الآخر، ويتحادثان، ويريان الاستشهادات.


v0.2 — النسخة الأولى من إضافة Claude Code (3-4 أسابيع)

الهدف: أن تُمكن استشارة وكيل قرين من داخل Claude Code، وأن يترسّب الجواب في المشروع.

Scope:

Acceptance:

ينصّب أحدهم claude mcp add confer، ويضبطه، فيستطيع من داخل Claude Code أن يسأل mock vendor؛ فيأتي الجواب باستشهاداته، ويُكتب في .claude/peers/mock-vendor/facts.md، ويُودَع في git، ثم يُحمَّل من تلقاء نفسه في الجلسة التالية.


v0.3 — المحادثات الجماعية ونسخة المؤسسة (4-5 أسابيع)

الهدف: دعم المحادثات الجماعية (بشر ووكلاء معًا)، والقدرة على نشر «نسخة مؤسسة» على جهاز واحد.

Scope:

Acceptance:

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


v0.4 — تعدّد اللغات والجواب في غياب صاحبه (3 أسابيع)

الهدف: أن ينفع المنتج في السياقات الدولية وفي التواصل شبه اللامتزامن.

Scope:

Acceptance:

يسأل مطوّر صيني بالصينية وكيلَ مورّد ألماني (وثائقه بالألمانية)، فيتلقّى جوابًا بالصينية مع استشهاد بالأصل الألماني. وبعد ضبط standing policy، يعالج الوكيل في غياب صاحبه ما يوافق القاعدة من الطلبات معالجةً صحيحة، ويعلّق ما التبس.


v1.0 — جاهزية الإنتاج (4-6 أسابيع)

الهدف: أن يصلح للاستعمال في بيئة الإنتاج، مع دعم تجاري.

Scope:

Acceptance:

مئة مستخدم مسجَّل على الأقل، وعشرة وكلاء أقران منشورين باستقلال، ونسخة تعمل باستقرار أكثر من ثلاثين يومًا.


v1.5+ — النموّ والمنظومة (مستمر)

Scope:


حجم المهامّ (لأجل Claude Code)

تُقسَّم كل محطة إلى 50–200 مهمّة صغيرة. وكل مهمّة:

  1. لها مدخلات ومخرجات واضحة
  2. لها معايير قبول قابلة للاختبار
  3. لا تتجاوز يوم عمل لمطوّر واحد

ومن أمثلة مهامّ النسخة v0.1:

هيكل الخادوم

طبقة قاعدة البيانات

الهوية والبروتوكول

تجريد النموذج

Agent runtime

البوابة والواجهة

العميل

محتوى العرض التوضيحي


المخاطر والقرارات المبكّرة اللازمة

الخطر التخفيف
ما زال SDK الخاص بـMCP يتطوّر، وقد تنكسر واجهته التزام النسخة المستقرّة، ومتابعة changelog، وبناء طبقة تكيّف
بروتوكول A2A (من Google) ومعيار NANDA ما زالا يتطوّران أيضًا البدء بأصغر مجموعة جزئية، مع ترك مكان لطبقة تكيّف البروتوكول
Tauri 2.0 على iOS وAndroid حديث نسبيًا، وقد تعترضك عقبات في طور النسخة الأولى: أنظمة سطح المكتب الثلاثة فقط، والهاتف في v0.3
خروج كلفة النماذج عن السيطرة حصّة افتراضية + BYO key صريح + لوحة استهلاك مبكرة
حزم تطوير مزوّدي النماذج الصينيين (DeepSeek/Qwen) غير مستقرّة اتّخاذ الواجهة المتوافقة مع OpenAI (وكلّهم يدعمونها) نقطةَ دخول موحّدة

إرشادات التنفيذ لأجل Claude Code

  1. الاختبارات الوحدوية قبل التكامل: يجب أن تجتاز كل خدمة اختباراتها وحدها، من غير أن تتوقّف على إقلاع غيرها
  2. ترحيل قاعدة البيانات يمرّ بأداة الترحيل، لا بـSQL مكتوب باليد
  3. تُشارَك الأنواع عبر حزمة @confer/shared، ينتفع بها الطرفان
  4. كل طلب دمج يحمل تعديل توثيقه (إن مسّ البروتوكول أو الواجهة)
  5. يُفضَّل في تنفيذ بروتوكول A2A مكتبةٌ جاهزة (كحزمة npm المسمّاة http-message-signatures) على إعادة اختراع العجلة
  6. ويُفضَّل لـDID:web استعمال did-resolver وdid-jwt، وهي من أدوات W3C
  7. ويُفضَّل لخادوم MCP استعمال SDK الرسمي (@modelcontextprotocol/sdk)
  8. اكتب عنوان الإيداع جملةً تقول ما يفعله التغيير، لا بادئةً اصطلاحية. وانتبه: .github/scripts/gen-release-notes.sh لا يعرف إلا البادئات من نوع feat: وfix:، فملاحظات الإصدار تُكتب باليد — ولن يولّدها من عناوين نثرية
← العودة إلى Confer A2A · DID:web · RFC 9421 · NANDA