وكلاء مختلفون لا يتشاركون نفس الشجرة

معضلة الوكلاء المتوازين

s09–s11 تتيح تشغيل teammates متعددة في آنٍ واحد، لكن ثمة مشكلة خفية: جميعها تعمل في نفس دليل العمل. alice تُعدّل auth.py وbob يُعدّلها أيضاً في الوقت ذاته — تعارضات git، فوضى في الملفات، اختبارات تتلوث ببعضها.

حل s12 هو git worktree: نفس المستودع، لكن عبر git worktree add يمكن checkout فروع مختلفة في أدلة مختلفة. كل وكيل يحصل على worktree خاص، يعمل في دليله المستقل، بلا أي تداخل.

my-repo/                           # 主工作区（lead 用）
.worktrees/
  alice-auth/                      # alice 的隔离目录
    (branch: wt/alice-auth)
  bob-api/                         # bob 的隔离目录
    (branch: wt/bob-api)
  index.json                       # worktree 注册表
  events.jsonl                     # 生命周期事件日志

تقسيم المسؤوليات بين مستويين

s12 يُقسّم النظام صراحةً إلى مستويين:

• مستوى التحكم (control plane): ملفات JSON في .tasks/. المهمة وحدة مجردة لـ «ماذا نفعل»، لها تبعيات ومالك وحالة.
• مستوى التنفيذ (execution plane): أدلة في .worktrees/. الـ worktree حاوية مادية لـ «أين ننفذ»، دليل + فرع.

يرتبطان عبر task.worktree وworktree.task_id ثنائياً.

هذا الفصل يتيح: إعادة استخدام آلية إدارة المهام مع تغيير بيئة التنفيذ (مثلاً حاويات Docker بدلاً من git worktree). أو تغيير آلية المهام مع إبقاء worktree (مثلاً قاعدة بيانات بدلاً من ملفات JSON).

عرض دورة الحياة

سنسير خطوة بخطوة: create task → create worktree → تشغيل أوامر → keep أو remove. كل خطوة مُسجّلة في سجل الأحداث (events.jsonl)، وهو الأساس للمراقبة في بيئة الإنتاج.

keep مقابل remove

حين تنتهي مهمة worktree ثمة مصيران:

• remove: git worktree remove --force، يُحذف الدليل. عادةً يُنظّف الفرع أيضاً. يعني «هذا الاستكشاف لا نريده».
• keep: فقط تحديث .worktrees/index.json بـ status: kept، والدليل المادي يبقى. يعني «نريد هذه النتيجة، ننتظر الدمج».

النمط الشائع: subagent ينفّذ إعادة بنية تجريبية → النتيجة جيدة → keep → مراجعة بشرية → دمج في الفرع الرئيسي → حذف يدوي. النتيجة سيئة؟ remove مباشرة.