مهام

المهمة هي وحدة عمل واحدة تنتهي بـ pull request واحد. هي ما يتم تنفيذه فعليًا — الخطط والسبرينتات ومسارات العمل هي طرق لتنظيم المهام.

العنوان#

تلخص مجموعة العلامات اللاصقة المهمة في نظرة واحدة: المشروع، و النوع، و AI profile الذي يقوم بتشغيلها، و فحوصات ضمان الجودة المطبقة — تظهر كاسم للسياسة ومصدرها ونسختها، على سبيل المثال Standard · From plan · Organisation policy · v6.

وجود قفل على AI profile يعني أنه ثابت ولا يمكن تغييره الآن. كما يتم تثبيت سياسة ضمان الجودة المحلولة عند بدء التنفيذ، لذا فإن تغيير سياسة التنظيم لاحقًا لا يؤثر بشكل رجعي على العمل الذي يتم تنفيذه بالفعل.

سير عمل الوكلاء#

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

معماري → مطور → ضمان جودة → مراجع

هذا هو الجواب الأوضح على سؤال "أين هذه المهمة؟". مهمة تظهر أن المطور أكمل عمله وضمان الجودة قيد الانتظار، فهي تنتظر التحقق وليست متوقفة.

في وضع المنسق، يقوم المنسق بتحديد الوكيل الذي سيتم تشغيله تاليًا، لذا يمكن أن يتكرر التسلسل كالتالي: مطور، فريق ضمان الجودة، ثم مطور آخر بعد حدوث خطأ، ثم فريق ضمان الجودة مجددًا. كما يمكن أن يكون التسلسل أقصر؛ فعندما ينجز الكود بالفعل ما تطلبه المهمة، يقوم فريق ضمان الجودة بالتحقق من الكود غير المتغير، دون الحاجة لتدخل المطور، وبالتالي تُنجَز المهمة دون الحاجة إلى pull request. اطلع على المزيد. أدوار الوكلاء.

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

انظر إلى أدوار الوكلاء لمعرفة ما يستطيع كل وكيل القيام به وما لا يستطيع.

معايير القبول#

المعايير المستمدة من "المواصفة" المواصفة، على هيئة قائمة تحقق مع حالة لكل بند — Verified OK عند تأكيد تحقيق أحد المعايير.

تتبع الحالات مرحلة سير العمل الحالية، لذا يتم التحقق من المعايير أثناء تقدم المهمة بدلاً من التحقق منها جميعًا في النهاية.

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

سجل التنفيذ#

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

DEV · Generating code · Completed
4m 41s / 608.9k tokens · 16.2 g Est. CO2e / deepseek-v4-flash-0731

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

عند توسيع عملية التنفيذ، يتم عرض المسار التفصيلي خطوة بخطوة: الملفات التي تم قراءتها، والأوامر التي تم تشغيلها، ومنطق الوكيل، وكل ملف تم تغييره مع عدد أسطره (+25 / −0). تعرض مدخلات الرموز كفاءة الذاكرة المؤقتة (9.1k used (90% cached)), والتي عادةً ما تكون الفرق بين عملية تشغيل مكلفة وأخرى رخيصة.

هذا هو العرض الذي يجب فتحه عندما ترغب في معرفة كيف تم إنجاز شيء ما كيف وليس فقط ما تغير.

الأقسام المتبقية#

الاستخدام والجدول الزمني يُبلغ عن المحاولات بالإضافة إلى التكلفة — 1 attempts يعني أن المهمة نجحت من المرة الأولى. وكلما زاد الرقم، دل ذلك على إعادة العمل، وهو أدق مؤشر على جودة المواصفة.

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

الأولوية#

تحمل المهام أولوية من P0 (الأعلى) إلى P3، مع اعتماد القيمة الافتراضية P2. تحدد الأولوية ترتيب الانتظار عندما تكون هناك مهام أكثر في الانتظار من الفراغ المتاح.

لكنها لا تزيد من السعة. إذا كانت كل المهام P0، فلن يتم تنفيذ أي منها — انظر إلى السعة ومواقع الوكلاء.

الحالات#

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

• PENDING ليست عالقة. إنها في قائمة الانتظار، تنتظر توفر فراغ.
• NEEDS_HUMAN_REVIEW ليست فشلاً. إنها استفسار. أجب عنه وستستمر المهمة.

التدخل#

أثناء تشغيل مهمة، يمكنك إيقافها مؤقتًا، أو إلغاؤها، أو إعادتها مع تعليقات للقيام بإعادة العمل. لمعرفة أي خيار يجب اختياره، انظر إلى عندما تتعثر مهمة أو تفشل.

ذات صلة#

• وصف ما تحتاجه
• خطط
• أدوار الوكلاء
• المنشأ