أدوار الوكلاء

Coroid لا تستخدم وكيلًا واحدًا متعدد الاستخدامات. كل مرحلة من المسار من الوصف إلى pull request يتم التعامل معها بواسطة وكيل ذو مهمة محددة ومجموعة أدوات محدودة بشكل متعمد.

القيود هي الهدف من ذلك. الوكيل الذي لا يستطيع كتابة الكود لا يمكنه كتابة الكود عن طريق الخطأ.

الأدوار#

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

الأربعة الأوائل هم وكلاء التسليم الذين تراهم في كل مهمة. في الوضع القياسي، يتم تشغيلهم بالترتيب التالي:

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

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

دور واحد فقط – وهو دور المطور – يمكنه تغيير الملفات في مستودعك. جميع الوكلاء الآخرين يقرؤون أو ينفذون أو يبلغون أو يخلقون مهامًا تابعة.

طريقتان لتشغيل المهام#

تُشغل المهمة بإحدى الطريقتين. و AI profile ونشرك يحددان الطريقة المستخدمة.

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

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

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

المنسق#

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

ما يفعله المنسق#

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

ما لا يمكن للمنسق القيام به#

يوجه المنسق العملية؛ لكنه لا يقوم بالحكم. تفرض المنصة هذه القيود، لذا فهي لا تعتمد على قرار المنسق:

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

لذا، تنتهي أي مهمة يديرها منسق بإحدى الطرق الثلاث: طلب pull request لتتم الموافقة عليه؛ أو تأكيد وحدة الـ QA بأن الكود يقوم بالفعل بما تطلبه المهمة، وبالتالي لا يوجد ما يتطلب تغييرًا؛ أو مهمة فاشلة توضح سبب ذلك. ولا تنتهي المهمة بمجرد إعلان الوكيل المسؤول عنها اكتمالها.

المسارات التي يمكن لمنسق اتخاذها#

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

• المسار الكامل. التخطيط، البناء، التحقق، المراجعة، الإنهاء. هكذا تسير المهمة ما لم يكن لدى المنسق سبب لاتخاذ مسار آخر.
• إعادة إرسال العمل. عندما تفشل وحدة الـ QA في التحقق من العمل أو يطلب المراجع إجراء تغييرات، تُعاد الإصلاحات إلى المطور. ويجب على النسخة الجديدة اجتياز اختبارات الـ QA قبل أن تتمكن المهمة من الانتهاء. ولا ينتقل نجاح النسخة السابقة إلى النسخة الجديدة.
• تم إنجازه بالفعل. قد يقوم الكود بالفعل بما تطلبه المهمة. يمكن للمنسق حينئذٍ أن يطلب من وحدة الـ QA التحقق من الكود غير المتغير مقابل معايير القبول بدلاً من بناء أي شيء. وعندما تجتاز الـ QA الاختبارات ويوافق المراجع في حال تطلب الأمر مراجعة، تُنهى المهمة دون الحاجة إلى pull request، لعدم وجود ما يستدعي الدمج. ويكون التحقق من الـ QA هو النتيجة النهائية. ويُغلق هذا المسار بمجرد أن تنتج عملية التنفيذ تغييرًا خاصًا بها، لأن الـ QA ستقبل كودًا غير مطابق للنسخة التي سيتم شحنها.

هناك مساران أقصر اختياريان. ولا تستخدمهما Coroid بشكل افتراضي. فهما يغيران مسار المنسق، ولكن لا يغيّران نقاط التحقق:

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

عندما يكون المراجع مطلوبًا#

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

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

• إذا كان المراجع قد بدأ بالفعل العمل على المهمة، أو إذا كانت قواعد المراجعة في مشروعك أو مخطط الجودة في مؤسستك تستوجب وجود مراجع؛
• إذا كان التغيير يمس مصادقة المستخدمين، الجلسات، الصلاحيات، البيانات السرية أو التشفير، عمليات ترحيل قاعدة البيانات، إعدادات البناء والنشر، ملفات الاعتماد، أو الكود الذي يتواصل مع خدمات خارجية؛
• إذا كان التغيير كبيرًا (بشكل افتراضي، أكثر من 80 سطرًا متغيرًا)، أو يشمل ملفات ثنائية، روابط رمزية أو وحدات فرعية؛
• لا يمكن لـ Coroid قراءة السياسة أو التغيير نفسه؛ وعند الشك، يُلزم وجود مراجع.

التغيير الذي لا يحدث أي تغييرات لا يحتاج إلى مراجع. يتخذ الكود هذا القرار، وليس المنسق، ولا يمكن للمنسق التحايل عليه. وتنتهي وصفية pull request بسطر يوضح المسار المتبع والسبب؛ حيث يبدأ بعبارة «مراجع مطلوب» أو «مراجع غير مطلوب».

معماري#

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

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

مطور#

ينجز العمل: يقرأ الكود ذا الصلة، ويُجري التغيير، ويكتب أو يحدّث الاختبارات، ثم يشغّلها محليًا في بيئة العمل حتى تمر بنجاح.

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

التأكد من الجودة#

تقوم بعملية التحقق بشكل مستقل عن الوكيل الذي كتب الكود — مجموعة الاختبارات الخاصة بك، وبوابات الجودة المُعدة للمشروع، ومعايير القبول المذكورة في المواصفات.

تُصدر عملية التأكد من الجودة حكمًا. لا تقوم بإصلاح ما تجده؛ تُعاد الأخطاء إلى المطور كإعادة عمل. مطور كإعادة عمل.

مراجع#

يقرأ الاختلافات النهائية ويُنتج نتائج، مع تطبيق أي قواعد مراجعة قامت مؤسستك بإعدادها. تُوجه النتائج إما إلى المطور كإعادة عمل، أو تُرفق بـ pull request لتوافق عليها.

مختبر ويب#

يستخدم متصفحًا حقيقيًا لتشغيل معاينة لتطبيقك والتحقق من سلاسل العمليات الخاصة بالمستخدم من البداية إلى النهاية. يُستخدم عندما لا يمكن استنتاج أي تأكيد حول السلوك من الكود وحده.

مستكشف#

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

محلل التبعيات#

يفحص التبعيات وكيف تنتشر التغييرات عبر قاعدة الكود، بما في ذلك عبر المشاريع حيث تم إعداد تبعيات بين المشاريع.

لماذا يهم هذا التقسيم؟#

ينتج عن تقسيم العمل بهذه الطريقة أربع خصائص:

1. التحقق مستقل. الوكيل الذي يتحقق من العمل ليس هو الوكيل الذي كتبه، لذا ليس له مصلحة في النتيجة.
2. نطاق الضرر محدود. دور المطور فقط هو الذي يمتلك أدوات كتابة الكود، لذا فإن أي خلل في المراجعة أو التحليل لا يمكن أن يفسد مستودعك.
3. كل دور يستخدم نموذجًا مناسبًا له. التخطيط يستفيد من اتساع المعرفة العالمية؛ بينما كتابة الكود القابل للتجميع تحتاج إلى شيء آخر تمامًا. AI profile يحتوي على نموذج لكل دور لهذا السبب بالتحديد.
4. يتم تحديد الإنجاز بناءً على عمليات التحقق، وليس بواسطة الوكيل المسؤول. في وضع المنسق، لا يمكن للوكيل الذي يوجه المهمة إنهاؤها دون الحصول على قرارات من فريق ضمان الجودة والمراجع.

التالي#

العودة إلى كيف تتحول مهمة إلى pull request لمراحل تعيين هذه الأدوار عليها، أو ما هو Coroid للحصول على نظرة عامة مختصرة.