سجل المهام

سجل المهام — حلّ دائم للقصد

وُلد من حادثة حقيقية (2026-08-27). ردّ المستخدم بعبارة “كمّل التالي” أثناء تشغيل مسح لأسماء العلامات التجارية. كانت المحادثة قد قُطعت للتوّ إلى شذرة من 158 حرفًا بسبب توقف منتصف البث، فأصبح أعلى إشارة في السياق هي بيئة العمل المحيطة (“تغييرات غير مُ Commit…”) — ففسّر النموذج كلمة “التالي” على أنها git commit لإعدادات لا علاقة لها بالمهمة. ولم تظهر بطاقة موافقة لأن نافذة YOLO التي تضغط 4 ساعات كانت ما تزال فعّالة.

السجل يجعل هذا الصنف كله مستحيلًا بنيويًا: المتابعات القصيرة تُحلّ مقابل حالة المهام الدائمة، لا مقابل المحادثة؛ والمتابعة غير المحسومة لا تُنتج إلا سؤالًا؛ وتعديلات المستودع تمر بالبوابة دائمًا حتى مع YOLO.

ما هو

سجل نشط واحد لكل محادثة، مخزَّن في قاعدة SQLite مستقلة (kazma-data/task_ledgers.db بصيغة WAL) — خارج نص المحادثة تمامًا:

الحقل	المعنى
goal	المهمة في جملة واحدة (تُزرع من أول رسالة ≥40 حرفًا؛ ويحسّنها الوكيل عبر الأداة).
steps	الخطة المعلنة — كل خطوة بحالة pending / running / done / failed ونتيجة من سطر واحد.
next_action	الهدف المُلزِم: الخطوة التالية التي أعلنها الوكيل بنفسه.
findings	نتائج دائمة تستحق الحفظ (مثل قائمة الأسماء الخضراء).
open_questions	التفرعات غير المحسومة التي تستوجب سؤال المستخدم.

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

كيف يبقى محدَّثًا

كاتبان، دون استدعاء LLM إضافي:

1. استخراج حتمي — سياج ```plan في كل رد يصبح خطوات السجل، وسطر النية المعلن الختامي — “الآن مسح السوشيال لـ X، Y، Z”، “Next: …”، “التالي: …” — يصبح next_action (أنماط عربية وإنجليزية؛ آخر إعلان هو الملزم، لأن الوكيل يعيد الإعلان مع كل إعادة تخطيط).
2. أداة task_ledger_update — يدير الوكيل الهدف والخطوة التالية والنتائج وحالة الخطوات بشكل واعٍ. صيانة السجل هي طريقه لجعل كلمة “التالي” بلا غموض.

كيف يُحلّ القصد

عندما تكون رسالتك متابعة قصيرة (“كمّل”، “تابع”، “proceed”، “next”)، يستشير المُنسّق السجل قبل تشغيل الدورة:

• توجد خطوة تالية معلنة → ربط (BINDING). ينصّ سياق الدورة صراحةً على المقصود بـ”التالي” — “CONTINUATION BINDING: this means ‘the social sweep for potensfit, acerfit, voimfit’” — مع بند إفلات صريح تتجاوزه المهمة الجديدة فعًا.
• لا توجد خطوة معلنة → توضيح بنيوي (STRUCTURAL CLARIFY). تُقفل الدورة على سؤال توضيحي واحد وتُسحب كل الأدوات منها — يستحيل فيزيائيًا على الوكيل التصرف بناءً على تخمين. الخطأ في القراءة يكلّف سؤالًا، لا فعلًا. والرد القصير أثناء وجود توضيح معلّق يفتح الدورة: يتابع بالخيار الموصى به ولا يسأل مرتين أبدًا.
• تحوّل الموضوع → إحلال (SUPERSEDE). التحول المكتشف يعلّم السجل القديم كمُحلّى (يُحفظ في التاريخ) ويزرع سجل جديد تلقائيًا.

نطاق الضرر

حدّان صارمان حتى يبقى سوء الفهم الحقيقي رخيصًا:

• أوامر git الكتابية تمر بالبوابة دائمًا. git commit وpush وmerge وrebase وreset وcheckout -- وrestore وclean وrm وما شابه تتطلب بطاقة موافقة على كل مسار تنفيذ (عامل الأدوات في الرسم وسجل swarm/IDE) — لا يمكن لـ YOLO الموافقة عليها تلقائيًا. أما git القرائي (status وlog وdiff) فمعفى.
• نوافذ YOLO ساعة واحدة افتراضيًا (كانت 4). تجاوزها عبر KAZMA_YOLO_TTL_SECONDS (0/off = بلا انتهاء) إن احتجت فعًا لمدة أطول.

ملاحظات تشغيلية

• المخزن “بجدية محدودة” ولا يرفع استثناءات أبدًا — السجل المعطوب يتحلل إلى “لا سجل”، ولا تفشل دورة بسببه قط.
• السجلات لكل محادثة؛ ويُحتفظ بتاريخ السجلات المُحلّاة لكل thread.
• التوصيلات في kazma_core/agent/task_ledger.py والمُنسّق (graph_supervisor.py)؛ والاختبارات في tests/test_task_ledger.py.
• ذات صلة: طبقة الالتزام (البوابات الدلالية) والأمان والسلامة (مستويات HITL).