Beans والمهام

TR

في هذه الصفحة
  1. أمران يشتركان في كلمة واحدة
  2. دورة حياة bean الوكيل
  3. لا يُحذف الـ bean أبدًا
  4. عمليات المحرك ليست استدعاءات لواجهة سطر الأوامر (CLI)
  5. مهام البشر (Todos) — لم تُبنَ بعد
  6. ما تحتويه خطة العمل في الوقت الحالي

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

✎ Edit TR

الـ Beans مخصصة للوكلاء. والمهام (todos) مخصصة للبشر. فهما تشتركان في كلمة واحدة في الحديث العادي ولا شيء غير ذلك، والخلط بينهما هو ما يجعل خطة العمل تحوي نوعين من الأشياء التي تتطلب معالجة مختلفة.

إن الـ bean هي حالة عملية (process state) يحتفظ بها الوكيل أثناء أداء العمل: تُحجز قبل البدء حتى تتجنبها أي جلسة موازية (sibling session)، وتُحدَّث باستمرار مع تقدم العمل، وتُغلق مع سجل يوضح ما تم تغييره. والمخزن هو beans/، مودع في Git (committed)، بحيث ينجو من استرداد الحاويات (reclaimed container) ويكون مرئيًا لكل جلسة أخرى.

أما المهمة (todo) فهي تذكير خاص بالشخص — ما يعتزم الاطلاع عليه لاحقًا. إنها ملك له لإنشائها وإعادة ترتيبها والتخلص منها وفق جدول زمني لا يحدده سواه، ولا ينبغي لأي شيء في عملية الوكيل أن يقرر متى تكتمل.

تصف هذه الصفحة الأول بالتفصيل. أما الثاني فهو لم يُبنَ بعد ويذكر ذلك صراحة.

أمران يشتركان في كلمة واحدة

✎ Edit TR

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

BeanTodo
المالكجلسة وكيلشخص
الغرضحالة عملية لعمل قيد التنفيذتذكير بالنية
المخزنbeans/، مودع في Git ومشاركلم يُحدد بعد
المنشئوكيل، بعد فحص تطابق العنوان بدقةالشخص، متى شاء
المغلقالوكيل الذي أدى العمل، مع ملخصالشخص، وفق تقديره الخاص
المرئيةلكل جلسة موازية (sibling session)للشخص، في المقام الأول
نمط الإخفاقمكرر، أو مغلق بواسطة الجلسة الخاطئةمنسي

أنماط الإخفاق هي ما يجعل الحفاظ على هذا الفصل أمرًا يستحق العناء. فالـ bean المكرر يحرم خطة العمل من الإشارة والتوجيه — ففي أحد الـ folios، أنتجت إعادة تشغيل غير محمية 14,688 تكرارًا، أي 92 % من كل bean مفتوح في المستودع. بينما المهمة المنسية تسبب إزعاجًا لشخص واحد فقط. والآليات المصممة للأول تُعد تعقيدًا وإجراءات شكلية زائدة على الثاني، والآليات المصممة للثاني ليست كافية على الإطلاق للأول.

دورة حياة bean الوكيل

✎ Edit TR

مخطط مسارات BPMN مع مسارين. في مسار الوكيل: يتم تحديد العمل الدائم، ويجري الوكيل بحثًا عن العنوان بدقة قبل إنشاء أي شيء، ثم تسأل بوابة عما إذا كان الـ bean موجودًا بالفعل. إذا لم يكن كذلك، يقوم بإنشائه؛ وإذا كان موجودًا، تسأل بوابة ثانية عن مالكه. الـ bean المملوك لشخص آخر يُوجَّه إلى المسار السفلي — جلسة موازية أو إنسان — حيث يكون الإجراء الوحيد هو تركه والتنسيق، منتهيًا هناك. أما الـ bean الخاص بالوكيل نفسه أو غير المحجوز فيُحجز كـ in-progress، ويُعمل عليه مع إبقاء المتن محدثًا، ثم يصل إلى بوابة نتائج ذات ثلاثة فروع: done يؤدي إلى complete، وnot wanted يؤدي إلى scrap مع بيان الأسباب وعدم الحذف أبدًا، وblocked يؤدي إلى تسجيل مانع التقدم وإعادته. وتلتقي الفروع الثلاثة عند حدث نهاية واحد، مع تسجيل الحالة.

فتح مصدر BPMN

المخطط أعلاه يوضح الدورة بأكملها، وثلاث من حوافه هي التي تستحق القراءة مرتين.

الخطوة الأولى هي البحث، وليست الإنشاء. إن أمر beans create ليس عملية متماثلة التأثير (not idempotent): فهو يُنشئ معرفًا جديدًا في كل استدعاء ولا يلغي التكرار بناءً على أي شيء، لذا فإن إعادة تنفيذ خطوة تؤدي إلى مضاعفة الخطة بدلاً من عدم فعل شيء. والفحص الدقيق للعنوان (exact-title check) هو ما يحول بين تكرار خطوة سير العمل وبين وجود مجموعة هائلة من الـ beans شبه المتطابقة.

الملكية هي بوابة، وليست مجاملة. إن الـ bean الذي حجزته جلسة أخرى ليس ملكك لحله، أو إلغائه (scrap)، أو حذفه. والحجز هو الطريقة التي تتجنب بها جلستان التقاط العنصر نفسه؛ وإن إغلاق عمل شخص آخر هو ما يتسبب في فقدانه لعمل لم ينتهِ من الإبلاغ عنه بعد.

“المعطل” (Blocked) ليس “غير مرغوب فيه” (not wanted). يعود الـ bean المعطل إلى حالة todo مع تسجيل مانع التقدم وبيان ما يمكن أن يزيله. أما تركه في حالة in-progress فهو أسوأ من الحالتين: فعنصر لا يحرز فيه أحد تقدمًا يظهر، لكل جلسة أخرى، كعمل نشط.

لا يُحذف الـ bean أبدًا

✎ Edit TR

أمر beans delete موجود في واجهة سطر الأوامر (CLI). لا تستخدمه.

العمل الذي يتبيّن أنه غير مرغوب فيه يتم إلغاؤه (scrapped) — status: scrapped، مع قسم يوضح سبب ذلك. هذا هو معنى “التعطيل” هنا؛ فلا تحتوي واجهة سطر الأوامر على حالة معطّل (disabled)، ومفرداتها هي draft وtodo وin-progress و completed وscrapped.

والسبب ليس الترتيب والنظافة. فالـ bean الملغى (scrapped) يسجل أن أمرًا ما قد نوقش ورُفض، وعلى أي أساس تم ذلك — وهو أمر له نفس قيمة سجل العمل الذي تم إنجازه بالنسبة للوكيل التالي، لأنه ما يمنع الدخول في الطريق المسدود نفسه مرة أخرى. أما الـ bean المحذوف فيترك الجلسة الموازية عاجزة عن التمييز بين التخلي المتعمد والخطأ العرضي، ويترك الوكيل التالي حراً في البدء من جديد في الأمر الذي استبعدته بالفعل.

لقد كُتب هذا الحظر هنا، وفي وثائق المخطط نفسها، على وجه التحديد لأن الأداة توفر هذه العملية. فالقاعدة التي تعتمد على ألا يلاحظ أحدٌ أمرًا ما ليست قاعدة.

عمليات المحرك ليست استدعاءات لواجهة سطر الأوامر (CLI)

✎ Edit TR

هناك أمران مختلفان يمكنهما تعديل الـ bean، والخطوة التي تخلط بينهما ستعلن عن تأثير ليس لها.

يقوم محرك سير العمل (workflow engine) بتنفيذ عمليات claim وnote وresolve على الـ bean الخاص بنسخة العملية نفسها عند اكتمال خطوة محددة بالوسم <cat-harness.processes:bean op="…"/>. يضبط claim الحالة على in-progress وهو متماثل التأثير (idempotent)؛ ويقوم note بالإضافة؛ بينما يُكمل resolve الـ bean فقط بمجرد اكتمال النسخة نفسها، لأن مسألة انتهاء العمل من عدمه هي حكم تقديري ولا يُغلق الـ bean بناءً على ادعاء طرف آخر.

يقوم الوكيل بكل ما عدا ذلك باستخدام واجهة سطر الأوامر beans: الإنشاء، والإلغاء (scrapping)، وإعادة التسمية، وتعيين الموانع. ولا يمتلك المحرك أي عملية لأي من هذه المهام.

هذا التمييز ليس افتراضيًا. فقد احتوى نشاط في مخطط CRDM على <cat-harness.processes:bean action="create"/> — حيث استخدم action بينما يقرأ المحرك op — لذا تم تحليله على أنه لا توجد عملية على الإطلاق. وأعلنت تلك الخطوة أن التوقيع والاعتماد يُنتج beans، ولكنها لم تنفذ أي شيء، وتم ذلك بصمت حتى قرأ أحدهم كود المحلل (parser).

عندما تضيف خطوة معلّمة بـ bean، استخدم إحدى العمليات الثلاث التي ينفذها المحرك، واذكر في توثيق الخطوة أي الأجزاء تمثل استدعاءات CLI الخاصة بالوكيل. سيكتشف أمر bun run cat check:workflow-refs أي مرجع مهارة لا يمكن حله؛ ولكنه لا يستطيع اكتشاف سمة تبدو معقولة ولكن المحرك لا يقرؤها أبدًا.

مهام البشر (Todos) — لم تُبنَ بعد

✎ Edit TR

لم تُبنَ بعد، وقد ذُكر ذلك صراحة هنا بدلاً من تركه كغياب يتعين على شخص ما ملاحظته.

تحتاج مهام الشخص إلى دورة خاصة بها، ولا يوجد أي جزء منها حاليًا:

  • متى تُعرض المهمة. إن إظهار كل عنصر مفتوح في كل دور (turn) يمثل تشويشًا؛ وعدم إظهار أي منها ينتج قائمة لا يقرؤها أحد. ومهما كانت القاعدة، فهي تختلف عن التهيئة المبدئية لخطة العمل (work-plan priming) التي يتلقاها الوكيل عند بدء الجلسة.
  • متى يمكن للشخص إنشاء مهمة، وعبر أي وسيلة — المحادثة، أو أمر، أو واجهة بدء الجلسة.
  • كيف يتم استبعاد المهمة وإحالتها للتقاعد. إن تخلي الشخص عن تذكير ما هو أمر عادي ولا يحتاج إلى قسم “أسباب الإلغاء”؛ فقواعد الـ bean لا تنطبق هنا.

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

ما تحتويه خطة العمل في الوقت الحالي

✎ Edit QA TR

توضح بقية هذه الصفحة ماهية الـ bean. أما هذا القسم فيبيّن ما يحتويه المخزن حاليًا — مقروءًا بشكل مباشر من /assets/beans/index.json، وهو الإسقاط (projection) الذي يكتبه gen-docs-pages.ts من beans/defs/ في كل بناء، إلى جانب فهرس المهام (todos) الذي نُشر منذ فترة أطول.

حتى تاريخ 2026-09-20 لم يكن هناك شيء يمكن وضعه هنا. كان لـ todos/ قارئ وفهرس منشور ولوحة تعرضه؛ بينما لم يكن لـ beans/ أي من الثلاثة، على الرغم من أنه المخزن الأكبر برتبتي مقدار. وخطة العمل التي لا يستطيع أحد الاطلاع عليها هي خطة لا يدققها أحد.

ما تعرضه لوحة المعلومات، ولماذا اتخذت كل لوحة شكلها الحالي. تُعد الأعداد بمثابة عنوان رئيسي، لذا فهي أرقام وليست رسمًا بيانيًا من أربعة أعمدة يقول الشيء نفسه. وتوزيع الملاحم (epic distribution) يمثل الحجم عبر هويات ذات أسماء طويلة، لذا فهو شريط أفقي. والنتائج (findings) عبارة عن ثلاثة أو أربعة صفوف، لذا فهي قائمة — مع أيقونة وتسمية في كل صف، لأن لون الحالة لا يحمل المعنى بمفرده أبدًا.

تُحسب النتائج من البيانات المودعة (committed) فقط، وأحدها غائب عن قصد. إن كاشف عناصر in-progress الراكدة سيتعين عليه قراءة الساعة، والإسقاط مشروط بالمحتوى الدقيق — فأي شيء يُحسب مقابل الساعة يغير الملف في كل عملية بناء ومن ثم تنطلق بوابة الركود (staleness gate) باستمرار إلى الأبد. لذا ينشر الإسقاط حقل updated_at لكل bean كحقيقة ثابتة، وتقوم الصفحة بحساب العمر عند فتحها. وبالتالي يتحرك العمر دون أن يتحرك الملف أو يتغير، وهو الترتيب السليم للأمور.

يوجد عرض أشمل، وهو قابل للتصفح. يحصل كل رسم بياني للحالة (state graph) مُعلَن على أداة تصور خاصة به عند المسار الذي تستخدمه هذه النسخة بالفعل لهذا الرسم — /beans/ و/todos/، وواحدة لكل من الرسوم الأخرى. هذا المسار ليس من اختراع هذه الصفحة: فالـ bean o7eq يحمل قرار المالك بأن الأصل المعروض (rendered asset) يتم عنونته بواسطة اسم نسخته مع جعل الرسم البياني المُعلَن كجزء من المسار (path segment)، وأن هذه النسخة تحذف اسمها الخاص لأن مجلد docs/ الخاص بها هو ما يخدمه الموقع، وتحدد مهارة harness-requirements عنوان URL المحدد هذا كالتزام — «من متطلباتها توفير أدوات تصور يمكن الوصول إليها عبر <base-url>/beans». ولا يوجد فهرس فوقها، لأن المسار / مخصص لموقع التوثيق، لذا تدرج كل صفحة نظيراتها.

الرسم البياني الذي لا يملك إسقاطًا يوضح ذلك صراحة. إن qa وhealth وissue-marks و uploads هي رسوم بيانية للحالة مُعلنة ولم ينشر أي شيء إسقاطًا لها حتى الآن. وتذكر لوحات معلوماتها ذلك تحديدًا وتشير إلى الـ bean 2krx، بدلاً من عرض أصفار لمخزن لم يقرأه أحد — فلوحة المعلومات التي تفتح على صفر لا يمكن تمييزها عن مخزن لا يحتوي على شيء، وهما حقيقتان متناقضتان.

كل معرّف في تلك الصفحات هو رابط. يوجّه معرّف الـ bean إلى ملف الـ bean نفسه، ورقم المسألة أو طلب السحب (pull-request) إلى منصة الكود (forge)، وتحمل كل نتيجة رمز قلم يوجّه إلى المكان الذي تتم فيه الكتابة فعليًا. أما المرجع الذي لا يمكن حله فيبقى كنص عادي، وهو الفرق المرئي بين «اتبع هذا الرابط» و«يشير هذا إلى مكان لم أتمكن من الوصول إليه».

ما ليس موجودًا هنا. موضع الـ bean داخل عملية BPMN، وهو النصف الآخر من الـ bean v49e. يحتاج هذا الربط إلى beans/workflows/، وهو رسم workflow-state البياني المُعلَن، وهو فارغ حاليًا — لذا فإن عرض الموضع سيُبلغ عن “لا مكان” لكل bean في المخزن. وهو بانتظار وجود حالة للنسخة.

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


folio-assistant — code under the Apache License 2.0, documentation under CC BY 3.0. Generated schema and API references are rebuilt from source on every push to main.

deployed b08c961 · 2026-10-23T23:11:09Z