إطار العمل الوكيل

في هذه الصفحة

حالات التفاعل
1. حالة الخمول (Idle state)
2. حالة سير العمل (Workflow state)
دورة حياة الجلسة
تصنيف الطلبات
1. قاعدة اكتشاف طلبات الميزات
سير عمل المحتوى
المعالجة الحتمية والوكيلة
تنفيذ BPMN: مهارة واحدة، ومحركان
سير عمل طلبات الميزات (CRDM)
المحتوى والمصادر المقدمة من المستخدم
1. لـ CRDM على وجه التحديد
انضباط المسائل وBeans
1. المسائل مقابل Beans
2. قواعد للوكلاء
مراجع المهارات المجمعة
ما لم يُبنَ بعد

تم توليد هذه الصفحة من content/docs/agentic-harness/ — يرتبط كل قسم أدناه بمصدره الخاص.

إن إطار العمل الوكيل (agentic harness) هو نموذج التفاعل الذي يعمل عليه folio-assistant — القواعد، والحالات، وسير العمل التي تحكم كيفية تعاون الوكيل والمستخدم داخل هذه المنصة. وقد وُصف الكثير من هذا السلوك بالفعل عبر مهارات ووثائق إرشادية فردية؛ وتجمع هذه الصفحة كل ذلك في مرجع واحد حتى يتمكن الوكيل الذي يدخل في جلسة من البحث عن السلوك المتوقع بدلاً من إعادة تركيبه من قواعد متفرقة.

لا يتعلق هذا بالهندسة المعمارية الداخلية للوكيل. بل يتعلق بـ العقد الملموس (observable contract) بين الوكيل والمستخدم: ما هي الحالات التي يمكن أن يكون فيها التفاعل، وكيف تُصنَّف الطلبات، وما هو سير العمل الذي يدخله الوكيل لكل فئة، وما يجب أن يتوقعه المستخدم في كل مرحلة.

حالات التفاعل

✎ Edit TR

يكون التفاعل بين المستخدم والوكيل دائمًا في إحدى حالتين بالضبط:

حالة الخمول (Idle state)

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

حالة سير العمل (Workflow state)

يقوم الوكيل بتنفيذ سير عمل مسمى — يتم تمثيل كل منها بمخطط عملية BPMN مع وضع الوكيل والمستخدم في مسارات سباحة (swimlanes) منفصلة. ويحدد سير العمل النشط ما سيفعله الوكيل بعد ذلك وما يتوقعه من المستخدم.

مسارات العمل النشطة في هذه المنصة:

سير العمل	مصدر BPMN	يُدخل إليه عندما
التأليف (paper)	`authoring-a-paper.bpmn`	يطلب المستخدم تأليف محتوى في folio من نوع paper
التأليف (document)	`authoring-a-document.bpmn`	يطلب المستخدم تأليف محتوى في folio من نوع document
دورة حياة المحتوى	`content-lifecycle.bpmn`	ينتقل المحتوى عبر التحقق → التصيير → النشر
استيعاب المستندات	`document-ingestion.bpmn`	يُسقط المستخدم ملفًا في `uploads/`
من المسودة إلى النشر	`draft-to-publication.bpmn`	ينتقل المحتوى من مسودة إلى منشور
متطلبات CRDM	`crdm-requirements.bpmn`	يكتشف الوكيل طلب ميزة
استرجاع الأدلة	`evidence-retrieval.bpmn`	يبحث الوكيل عن أدلة لدعم ادعاء

انتقالات الحالة: يمكن تعليق (suspend) سير العمل عندما يطلب المستخدم تبديل السياق. يسجل الوكيل أين كان (نشاط BPMN الحالي) ويمكنه الاستئناف لاحقًا. ويكون هناك سير عمل واحد فقط نشطًا في المرة الواحدة، ولكن تشكل مسارات العمل المعلقة مكدسًا (stack) — حيث يُستأنف الأحدث منها أولاً.

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

دورة حياة الجلسة

✎ Edit TR

تتبع كل جلسة وكيل دورة الحياة ذاتها:

البدء — تشغيل مسح بدء الجلسة (beans prime، وbeans list، وscripts/session-start-coord-sweep.sh). يبرز هذا الإجراء خطة العمل الحالية، ومدى تقدم الفرع الافتراضي، ونشاط الفروع الشقيقة الأخير. راجع AGENTS.md § At session start.
التصنيف — يُصنف كل طلب للمستخدم (انظر القسم التالي) ويُوجه إلى سير العمل المناسب.
التنفيذ — يعمل الوكيل ضمن سير العمل النشط، متبعًا عملية BPMN الخاصة به. وتُبلغ كل جولة عن الـ bean الجاري العمل عليها وما سيأتي بعد ذلك.
التثبيت — تحصل كل وحدة عمل ذات مغزى على عملية تثبيت (commit) ودفع (push) خاصة بها. وتُفتح طلبات السحب (PRs) عند أول عملية تثبيت، وليس في النهاية. راجع AGENTS.md § Commit early, commit often, always PR.
التسليم — عندما تنتهي الجلسة (مغادرة المستخدم، حد السياق، استنفاد الرموز المميزة/tokens)، تكون الحالة الدائمة للوكيل متمثلة في:
- شفرة برمجية مثبتة ومرفوعة (committed and pushed)
- تحديث الـ beans بالحالة والملاحظات
- تعليقات على المسائل تتضمن ملخصات لما تم إنجازه
- المحادثة عابرة؛ وكل شيء آخر ينجو ويبقى

تصنيف الطلبات

✎ Edit TR

يُصنف كل طلب مستخدم إلى إحدى هذه الفئات. ويحدد هذا التصنيف سير العمل الذي يدخله الوكيل.

الفئة	الوصف	سير العمل الذي يتم دخوله
تأليف المحتوى	كتابة محتوى folio أو تعديله أو توسيعه (فصول، كتل، أقسام)	سير عمل التأليف (paper أو document)
مراجعة المحتوى	مراجعة المحتوى الحالي والتحقق منه وتقديم ملاحظات بشأنه	سير عمل دورة حياة المحتوى / تحرير تفاعل الإنسان والحاسوب (HCI)
استيعاب المحتوى	استيعاب مستند مصدر في الـ folio	سير عمل استيعاب المستندات
طلب ميزة	طلب قدرة جديدة للمنصة (انظر crdm-detect)	سير عمل متطلبات CRDM
طلب معلومات	الاستفسار عن المنصة أو المحتوى أو العملية	لا يوجد سير عمل — الإجابة مباشرة
استدعاء أداة	تشغيل أداة محددة (`content_validate`، و`qa_sweep`، إلخ)	لا يوجد سير عمل — التنفيذ والإبلاغ
إدارة خطة العمل	إنشاء الـ beans أو تحديثها أو الاستعلام عنها	لا يوجد سير عمل — التنفيذ والإبلاغ
تقرير خطأ	الإبلاغ عن سلوك معطوب في ميزات موجودة	الفرز: الإصلاح المباشر إن كان صغيرًا، أو CRDM إن استلزم الأمر إعادة تصميم

قاعدة اكتشاف طلبات الميزات

يقع الحد الفاصل الحرج للتصنيف بين تأليف المحتوى وطلب ميزة. وتوفر مهارة crdm-detect (skills/sdlc/crdm/crdm-detect.md) إشارات الاكتشاف التفصيلية. والقاعدة التلخيصية هي:

إذا كان تنفيذ الطلب يتطلب تغييرات في folio-assistant (مستودع المنصة) بدلاً من مستودع folio، فإن الطلب هو ميزة، ويجب على الوكيل الدخول في سير عمل CRDM.

عند عدم اليقين، يسأل الوكيل: “يبدو أن هذا قد يتطلب تغييرًا في المنصة — هل هذا صحيح، أم أنه شيء يمكنني فعله ضمن نموذج المحتوى الحالي؟”

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

✎ Edit TR

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

سير عمل النشر — دورة حياة المحتوى من المسودة وحتى التحقق والتصيير والنشر. وتغطي الأدوار (المؤلف، المراجع، المحرر)، والعمليات الأساسية، والأنشطة والمهارات.
استيعاب المستندات — كيف يتحول الملف المُودَع إلى مصدر L1: استخراج الهيكل، واشتقاق المحتوى، وبناء الرسم البياني المعرفي لـ L1، وبوابة الاكتمال.
أدلة الكتابة:

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

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

✎ Edit QA TR

إن معالجة سير العمل هنا هي طيف وليست مفتاح تشغيل/إيقاف، ويقع إطار العمل بالفعل عند أربع نقاط مختلفة عليه دون أن يُسمي المحور صراحة على الإطلاق: حيث تحدد السمة cat-harness.processes:policy enforcement ما إذا كانت الخطوة غير الممكنة ستُرفض أم يُكتفى بتدوينها؛ وتحدد relaxable="false" ما إذا كان يجوز لحزمة ما التفاوض لإلغاء خطوة أساسية؛ وتحدد cat-harness.processes:decision ما إذا كان الفرع يُحسب من جدول بدلاً من اختياره؛ وترفض بوابة حد التثبيت (commit-boundary gate) الكتابة من قِبل أي جهة ليست الوكيل.

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

توضح البوابة الآن أيهما المعني. فـ <cat-harness.processes:decision> تعني أن جدولاً هو من يحسبها وأن النتيجة المقدمة يدويًا تُرفض؛ بينما تعني <cat-harness.processes:judgement reason="…"> أنها قرار تقديري لشخص ما، مع وجوب ذكر السبب. وقبل وضع هذه العلامة، كان التمييز مستحيلاً بين “لا يوجد جدول لأن هذا حكم تقديري” وبين “لا يوجد جدول لأنه لم يكتب أحد جدولاً” — ويقوم الأمر bun run cat check:workflow-refs الآن بطباعة التقسيم الثلاثي، بحيث يصبح للسؤال ما مقدار ما يقرره النموذج من هذا؟ إجابة محسوبة بالأرقام بدلاً من مجرد ادعائها.

الهدف من هذا الإحصاء هو البحث، وهو مسار مفتوح. ما هي نقاط الحكم التقديري التي تشكل مخاطر على السلامة، وما المقدار الذي يجب أن يكون حتميًا، وكيف تقارَن النماذج عبر مسارات العمل الفرعية في ظل طبقة محكومة من السياق والذكريات؛ هذه ثلاثة أسئلة يمكن لهذا المستودع طرحها الآن ولم يجب عليها بعد. وجدول الأعمال، مع تمييز كل ادعاء بأنه مقيس (measured) أو مقطوع به (decided) أو فرضية (hypothesis)، موجود في deterministic-and-agentic. اقرأه كجدول أعمال: ففيه من الفرضيات أكثر مما فيه من القياس، وهو يقر بذلك صراحة.

تنفيذ BPMN: مهارة واحدة، ومحركان

✎ Edit QA TR

المالك، 2026-09-23، مسميًا المهارة التي يدور حولها هذا الطيف:

مهارة تنفيذ BPMN: بالنظر إلى عملية (Process)، وسياق (Context)، وحالة (State)، ودور (Role)، يتم استخدام مهارة واحدة أو أكثر من أجل تنفيذ مهمة (Task).

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

	الطرف الحتمي	الطرف الوكيلي
الأداة	أي محرك BPMN 2.0 مفتوح المصدر	سرب وكيل (agentic swarm)
نطاق عمل الوكيل	مهمة واحدة في المرة الواحدة، يسندها المحرك إليه	معظم المهام أو كلها
الحالة	يحتفظ بها المحرك بشكل صارم	غير محكومة: يحتفظ بها السرب
مسارات السباحة	مفروضة: دور المسار فقط هو المخول بتنفيذ مهمته	مخففة: قد يتصرف الوكيل عبر المسارات
ما يضمن النزاهة	يرفض المحرك الخطوة قبل حدوثها	تكتشفها تقارير ضمان/مراقبة الجودة (QA/QC) الميكانيكية + الوكيلة بعد حدوثها

يختلف الطرفان في توقيت فحص القاعدة، وليس في أيّ قاعدة تُفحص. فالعملية ذاتها، والأدوار ذاتها، والأذونات ذاتها تحكم كلاً منهما. يفحصها المحرك قبل بدء المهمة ويرفض؛ بينما يتصرف السرب ويفحصها تقرير ضمان/مراقبة الجودة (QA/QC) بعد ذلك، استنادًا إلى سجل ما تم إنجازه. ولا يعمل هذا إلا إذا كانت القواعد والسجل بيانات يمكن للتقرير قراءتها، وهو الحال مع W3C ODRL 2.2 كلغة للأذونات وW3C PROV-O كسجل للتنفيذ (المالك، 2026-09-23؛ والمخطط الذي يقتضيه هذا هو مقترح الجهات الفاعلة وODRL وPROV-O).

تقع معظم عمليات التشغيل الحقيقية بين الطرفين، ويكون ذلك على مستوى المهمة بدلاً من مستوى العملية ككل: فالقسم السابق يحصي بالفعل أي البوابات تُحسب حاسوبيًا وأيها قرارات تقديرية. ويمكن أن تكون خطوة التوقيع مفروضة من قِبل المحرك داخل عملية تشغيل وكيلة بخلاف ذلك، وتلك خاصية للمهمة ذاتها، وليست للمخطط بأكمله.

مبني جزئيًا. لم يتم ربط أي محرك BPMN بعد. لكن تقرير ضمان/مراقبة الجودة الميكانيكي موجود الآن: حيث يكتب الأمر bun run cat prov:qaqc سجل تاريخ كل نسخة من سير العمل كسجل PROV-O ويعيد فحص كل خطوة مقابل سياسات ODRL، استشاريًا (المسألة رقم #1180، الخطوة 5؛ مهارة task-authorization). أما تقرير ضمان/مراقبة الجودة الوكيلي فغير موجود بعد. وتحدد بقية هذا القسم الهدف حتى يكون للمقترح شيء يُقاس عليه.

سير عمل طلبات الميزات (CRDM)

✎ Edit TR

عندما يُصنف طلب على أنه طلب ميزة، يدخل الوكيل في سير عمل متطلبات CRDM (التوثيق الكامل، وBPMN).

يعد سير عمل طلبات الميزات هو الموضع الذي تقدم فيه وثيقة إطار العمل هذه أكبر فائدة، لأنها تصف سلوكًا كان ضمنيًا في السابق. فبينما وُثقت مسارات عمل التأليف والمراجعة لعدة أشهر؛ لم يكن سير عمل المتطلبات موجودًا إلا في شكل محادثات ارتجالية.

كيف يدخل الوكيل في CRDM

يوجد منطق الاكتشاف في skills/sdlc/crdm/crdm-detect.md. ثلاثة سيناريوهات:

جلسة جديدة، والطلب الأول هو ميزة: ← تأكيد الاستلام، وشرح أنك ستساعد في العمل على المتطلبات أولاً، والدخول في المرحلة 1.

جلسة موجودة، وتعمل بالفعل في CRDM: ← دمج الطلب الجديد في وثيقة المتطلبات الحالية، والمتابعة.

جلسة موجودة، وتؤدي عملاً على المحتوى: ← استخلاص الحاجة إلى الميزة، وسؤال المستخدم عما إذا كان يفضل إيقاف عمل المحتوى مؤقتًا ومعالجتها الآن، أو تسجيلها كـ bean للاحقًا.

ما يراه المستخدم

لا يقول الوكيل “جارٍ الدخول في وضع CRDM” أو يستخدم مصطلحات منهجية متخصصة. بل يقول بدلاً من ذلك:

“يبدو هذا كتغيير في المنصة — شيء سنحتاج إلى إضافته إلى folio-assistant نفسه. قبل أن أقوم ببناء أي شيء، اسمح لي بمساعدتك في تحديد ما هو مطلوب بالضبط حتى نقوم بالأمر بالشكل الصحيح. سأوثق المتطلبات في المسألة حتى يتمكن الآخرون من إبداء آرائهم.”

كيف يخرج الوكيل من CRDM

ينتهي سير عمل CRDM عندما:

يتم حل جميع الـ beans الناتجة عن المتطلبات المعتمدة، أو
يؤجل المستخدم العمل المتبقي صراحة

عند الخروج، إذا كان سير عمل المحتوى قد تم تعليقه، يقوم الوكيل باستئنافه.

المحتوى والمصادر المقدمة من المستخدم

✎ Edit TR

يقدم المستخدمون المحتوى والمواد المصدرية عبر قنوات متعددة. وينبغي للوكيل قبولها جميعًا وتوجيهها إلى المسار الإجرائي المناسب:

القناة	مثال	تُوجَّه إلى
دليل `uploads/`	يُسقط المستخدم ملف Word، أو PDF، أو Excel	مسار استيعاب المستندات الإجرائي
مراجع `library/`	يشير المستخدم إلى مصدر L1 تم استيعابه بالفعل	اقتباس مباشر في المحتوى
تعديلات `content/`	يعدل المستخدم كتلة `.md` مباشرة	سير عمل تأليف المحتوى
مرفقات مسائل GitHub	يرفق المستخدم ملفًا بتعليق على المسألة	ينزل الوكيل الملف ويعالجه
الرفع عبر المحادثة	يرفع المستخدم ملفًا في واجهة محادثة LLM	يحفظ الوكيل الملف في `uploads/` أو يعالجه مباشرة
مرجع الرابط (URL)	يلصق المستخدم رابطًا لمستند	يجلب الوكيل المستند ويستوعبه إذا كان ذلك مناسبًا

لـ CRDM على وجه التحديد

أثناء جمع المتطلبات، يعتبر المحتوى الذي يقدمه المستخدم مدخلاً للمتطلبات، وليس محتوى لتأليفه. وينبغي للوكيل:

قراءة المادة المقدمة وفهمها
استخراج المعلومات ذات الصلة بالمتطلبات
صياغتها ودمجها في بيان الاحتياجات أو وثيقة المتطلبات
الإشارة إلى المصدر في التعليق على المسألة (برابط أو مرفق)

مثال: يقوم مستخدم برفع جدول بيانات Excel يتضمن ملاحظات استشارة عامة. لا يحاول الوكيل استيعاب الجدول كمحتوى folio؛ بل يقرأ بنود الملاحظات ويصيغها في شكل متطلبات لأداة فرز المراجعات.

انضباط المسائل وBeans

✎ Edit TR

يجب ربط العمل على الميزات بمسألة في GitHub. بينما يستخدم العمل على المحتوى الـ beans. وهما مرتبطان ولكنهما ليسا مترادفين.

المسائل مقابل Beans

	مسألة GitHub	Bean
النطاق	ميزة، أو مجموعة متطلبات، أو قصة مستخدم	وحدة عمل فردية بحجم طلب سحب (PR) واحد
الجمهور	أصحاب المصلحة، وطالب الميزة، ومحلل الأعمال (BA)	الوكيل، والمطور
دورة الحياة	مفتوحة ← متطلبات ← اعتماد ← تنفيذ ← إغلاق	مُنشأة ← قيد التنفيذ ← محلولة
العلاقة	المسألة الواحدة لها عدة beans	تشير كل bean إلى مسألتها الأصلية

قواعد للوكلاء

العمل على الميزات ← المسألة أولاً. قبل التنفيذ، تحقق من:
- هل توجد مسألة مفتوحة بالفعل؟ ابحث باستخدام الكلمات المفتاحية.
- إذا لم تجد تطابقًا بين المسائل المفتوحة، فتحقق من المسائل المغلقة مؤخرًا.
- إذا لم تجد أي تطابق على الإطلاق، فاطلب من المستخدم إنشاء مسألة. لا تنشئ مسألة دون إذن المستخدم.
دائمًا فرع ميزة + طلب سحب. لا استثناءات في العمل على الميزات. ويجب أن يشير اسم الفرع إلى رقم المسألة (مثل feat/197-word-import).
اسأل دائمًا قبل الدمج في main. يجب على المستخدم التأكيد صراحة. وهذا أكثر صرامة من القاعدة العامة في AGENTS.md الخاصة بالعمل على المحتوى، لأن التغييرات في الميزات تؤثر على المنصة ككل.
انشر ملخصات الجولات في المسألة. بعد كل جولة تنفيذ (حل bean واحدة أو أكثر)، انشر تعليقًا على المسألة المرتبطة يتضمن:
- ما تم إنجازه في هذه الجولة
- ما يتبقى لإنجازه (الـ beans المفتوحة)
- روابط إلى المحتوى المحدث للمراجعة (عناوين URL للبيئة التجريبية، وصفحات التوثيق)
- جدول مقارنة قبل/بعد للصفحات التي تم تغييرها
لا تغلق مسألة أبدًا دون تفويض صريح. يقوم محلل الأعمال (BA) أو صاحب المصلحة بإغلاقها. ولا يغلقها الوكيل إلا عندما يطلب منه محلل الأعمال ذلك صراحة. ويجب ألا يفترض الوكيل الاكتمال أبدًا.
قد تمتد المتطلبات عبر مسائل متعددة. ينبغي للوكيل الربط بجميع المسائل ذات الصلة وتدوين العلاقات بينها.
الـ Beans ليست مسائل. إن beans create مخصص لبنود خطة العمل. بينما المسائل مخصصة للمتطلبات الموجهة لأصحاب المصلحة. لا تخلط بينهما.

مراجع المهارات المجمعة

✎ Edit TR

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

السلوك	المهارة / الوثيقة المصدر	الموقع
مسح بدء الجلسة	`AGENTS.md § At session start`	`AGENTS.md`
بروتوكول Bean	`todo-manager.md`، و`bean-coordination.md`	`skills/folio-core/`
انضباط التثبيت وطلبات السحب	`AGENTS.md § Commit early, commit often`	`AGENTS.md`
اكتشاف طلبات الميزات	`crdm-detect.md`	`skills/sdlc/crdm/crdm-detect.md`
سير عمل متطلبات CRDM	`crdm-requirements-workflow.md`	`skills/sdlc/crdm/crdm-requirements-workflow.md`
تأليف المحتوى (paper)	مهارات authoring-math	`skill_list` → `authoring-math`
تأليف المحتوى (document)	مهارات folio-document-adapter	`skill_list` → `folio-document-adapter`
دورة حياة المحتوى	مهارات content-lifecycle	`skills/authoring/content-lifecycle/`
استيعاب المستندات	`docs-generation.md`	`skills/ui/ui-core/docs-generation.md`
الإرسال والتنسيق	`dispatch-agent.md`، و`coordinate.md`	`skills/folio-core/`
أنواع المحتوى والمحولات	`AGENTS.md § Content types`	`AGENTS.md`
تأليف مخططات BPMN	مهارة `bpmn-authoring`	`skills/folio-core/`

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

ما لم يُبنَ بعد

✎ Edit TR

استدامة حالة سير العمل — يصف إطار العمل تعليق سير العمل واستئنافه، ولكن لا توجد آلية للاحتفاظ بحالة سير عمل الوكيل واستدامتها عبر الجلسات. ويعتمد هذا اليوم على الـ beans وتعليقات المسائل كبدائل تمثيلية.
التصنيف الآلي للطلبات — يعد جدول التصنيف مرجعًا يقرأه الوكلاء؛ ولا توجد أداة مصنِّف توجه الطلبات تلقائيًا.
مخطط BPMN لدورة حياة beans — تملك خطة عمل beans دورة حياة (إنشاء ← حجز ← قيد التنفيذ ← حل) نوقشت في AGENTS.md ومهارة todo-manager ولكن لا يوجد لها مخطط BPMN.
مخطط BPMN لإطار العمل الوكيل نفسه — لم يتم بعد تأليف مخطط BPMN عالي المستوى يوضح آلة حالة الخمول/سير العمل وتوجيه التصنيف.
بروتوكول تسليم الجلسة — إن القواعد الخاصة بما يجب تثبيته قبل انتهاء الجلسة موجودة في AGENTS.md، ولكن لا يوجد نتاج تسليم مهيكل يمكن لجلسة جديدة قراءته للاستئناف من النقطة التي توقفت عندها الجلسة السابقة تمامًا.

يتم تتبعه في: #203