يمكن لـ AI-DLC 2.11.0 إيقاف سير عمل Codex CLI قبل توليد الكود، كي يقرأ المطوّر الخطة المقترحة ويوافق عليها. يتبع هذا الدليل إصدار v2.11.0 الصادر في 8 أكتوبر 2026 وتعليماته الخاصة بذلك الإصدار لكل من Codex CLI، وملف تعريف سير العمل، و Plan Approval. راجعت BIG CHANGE هذه الوثائق ومرجع الأوامر المرتبط بالوسم. لم نثبّت AI-DLC ولم نشغّله؛ وجميع الخطوات أدناه مستندة إلى الوثائق فقط.
القارئ المقصود هو مطوّر لديه مشروع Git ويريد فحص خطة الكود قبل أن يولّد مساعد برمجة بالذكاء الاصطناعي الملفات. النتيجة المتوقعة هي سؤال Plan Approval يحدد الخطة، ويتيح للمطوّر طلب تغييرات، ويُبقي البناء منتظرًا حتى يجيب المطوّر. توجد في AI-DLC فحوص لاحقة أيضًا؛ وهذه البوابة تتعلق تحديدًا بخطة الكود.
قبل البدء
يتطلب دليل Codex المرتبط بالوسم استخدام Codex CLI 0.145.0 أو أحدث، ومستودع Git لخطّافات المشروع، ومزوّد نماذج مُعدّ. لا يتطلب إصدار AI-DLC الأصلي Bun أو Node.js. استخدم مشروعًا تملك صلاحية إرسال كوده وخطته إلى مزوّد النماذج الذي أعددته. راجع شروط معالجة البيانات والفوترة لدى المزوّد بصورة منفصلة؛ فمستودع AI-DLC لا يحدد سعرًا موحدًا لاستخدام مزوّد لهذا المسار.
جهّز مهمة تطوير محددة لتكون المدخل. يختار هذا الشرح ملف تعريف Feature لأن وثائق v2.11.0 تنص على تفعيل Plan Approval في Feature. يبدأ كل من Express و Proof of concept مع تعطيل Plan Approval، وإن كان بإمكان الشخص طلب مراجعة خطة بعينها. ملف التعريف أهم من التوقع العام بأن كل تشغيل لـ AI-DLC سيتوقف.
1. تثبيت الإصدار المحدد والتحقق منه
في macOS أو Linux أو WSL، يقدّم إصدار v2.11.0 أمر التثبيت التالي الخاص بهذا الإصدار:
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.sh | sh -s -- --version 2.11.0يوفّر الإصدار أيضًا برنامج تثبيت Windows خاصًا بالإصدار لـ PowerShell. افحص برنامج التثبيت واختر المسار الملائم لجهازك قبل تشغيله. ثم افحص الإصدار المثبّت والبيئة من داخل مشروعك:
aidlc --version
aidlc doctor
codex --versionيُفترض أن يعرض aidlc --version الإصدار 2.11.0. ويبلّغ aidlc doctor عن مشكلات الإعداد وبيئة التشغيل، بينما يتيح codex --version التحقق من الحد الأدنى لإصدار Codex CLI. إذا اختلف الإصدار المثبّت، فتوقف هنا واتبع تعليمات التثبيت أو التحديث في إصدار v2.11.0؛ فالخطوات أدناه مرتبطة بذلك الإصدار.
2. إعداد Codex ومنح الثقة لخطّافات المشروع
من جذر مشروع Git، استخدم مسار إعداد Codex المرتبط بالوسم:
aidlc config --harness codex
aidlc doctor
codexيسأل Codex عمّا إذا كنت تثق بخطّافات المشروع. راجع المشروع والخطّافات المولّدة قبل اختيار Trust all and continue (الوثوق بالجميع والمتابعة). يوضح الدليل المرتبط بالوسم أنه يمكن إعادة فتح مربع حوار سبق إغلاقه باستخدام /hooks، ثم t وEsc. بعد منح الثقة، شغّل $aidlc --doctor في Codex. إذا لم تكن الخطّافات تعمل، فاتبع استعادة الثقة في دليل بيئة التكامل؛ فنجاح برنامج التثبيت وحده لا يثبت أن خطّافات المشروع نشطة. يُضبط مزوّد النماذج وبيانات اعتماده في إعدادات Codex على مستوى المستخدم، ولا يوفّرهما AI-DLC.
3. بدء سير عمل Feature وفحص إعداداته
شغّل أولًا $aidlc --status في Codex وتحقق من عدم وجود سير عمل نشط. يذكر مرجع الأوامر المرتبط بالوسم أن أمر النطاق المجرّد يواصل العمل القائم إذا كان هناك سير عمل نشط. استخدم مشروعًا بلا سير عمل نشط في هذا الشرح.
في مشروع Codex الذي أعددته، اكتب $aidlc feature وأجب عن طلب وصف المهمة التي تريد بناءها. ينبغي أن يصف المدخل الميزة وقيودها؛ فالخطة النهائية تُولّد انطلاقًا من ذلك العمل. قبل بناء خطة الكود، افحص الضوابط الفعلية باستخدام مرجع أوامر v2.11.0:
$aidlc --status
$aidlc config get plan-approval
$aidlc config get guard-policyابحث عن حالة Plan Approval on (مفعّل) والمصدر المبيّن لها. إذا كان معطّلًا لهذا القصد، فإن $aidlc --plan-approval on يفعّل السؤال للخطة التالية. يمكن لمفتاح على مستوى الجهاز فرض تعطيله، ويمكن لقاعدة في ذاكرة الفريق فرض تفعيله؛ ويحدد سطر الحالة القيمة الفعلية. في هذا الشرح، اضبط Guard Policy على strict باستخدام $aidlc --guard-policy strict إذا أردت أيضًا أن تتطلب الخطة المعدّلة التي سبق اعتمادها، أو تعليمات اختبارها، موافقة أخرى. تفعيل Plan Approval يتحكم في السؤال الأول؛ أما Guard Policy فيتحكم فيما يحدث بعد تغيّر خطة معتمدة.
4. مراجعة خطة الكود عند البوابة
واصل سير العمل حتى تصبح خطة Code Generation جاهزة. عند تفعيل Plan Approval، يعرض محرك v2.11.0 ملخص الخطة ومسارها، مع خيارات تشمل Approve Plan (الموافقة على الخطة)، و Request Changes (طلب تغييرات)، أو I'll edit the files (سأعدّل الملفات). افتح ملف code-generation-plan.md المحدد، واقرأ الملفات المقترحة وتسلسلها وتعليمات الاختبار. راجع أي أوامر ووصول إلى بيانات المشروع وإجراءات قد تغيّر المستودع قبل الموافقة.
اختر Request Changes (طلب تغييرات) إذا احتاجت الخطة إلى تنفيذ مختلف أو اختبار مختلف. إذا عدّلت الملفات بنفسك، فاستخدم مسار المحرك I'll edit the files (سأعدّل الملفات) بدل اعتبار التعديل موافقة. إجابتك وحدها تخوّل الخطة؛ ولا يستطيع نموذج الموافقة نيابة عنك. عندما تكون البوابة مفعّلة، ينتظر توليد الكود تلك الإجابة. تنص ملاحظات الإصدار على إمكان متابعة مراجعة أو إعداد أو عملية commit أو طلب آخر مسموح به بينما ينتظر البناء.
5. الموافقة وفحص السجل والتعامل مع خطة معدّلة
عندما تكون الخطة مقبولة، أجب باختيار Approve Plan (الموافقة على الخطة) في السؤال المفتوح. يسجّل المحرك الموافقة على تلك الخطة ويستأنف البناء عبر مسار next المعتاد. وفقًا لملاحظات الإصدار، تبقى الخطة المعتمدة غير المتغيّرة محفوظة عبر ضغط سياق المحادثة أو تعليق الجلسة. يوثّق مرجع الأوامر المرتبط بالوسم الأمر المقتصر على القراءة aidlc engine audit history لفحص التسلسل الزمني المسجّل، ويعرض $aidlc --status موضع سير العمل. هذه السجلات، إلى جانب ظهور البوابة بوضوح قبل توليد الكود، هي ما يُستخدم للتحقق من النجاح.
إذا تغيّرت الخطة أو تعليمات اختبارها قبل البناء، تطلب Guard Policy في وضع strict الموافقة من جديد. في وضع relaxed أو off، يُبلّغ عن التغيير ويُسجّل، لكن يمكن لسير العمل المتابعة دون موافقة جديدة إلزامية. تميّز الوثائق المرتبطة بالوسم أيضًا تغيّر ملفات مصدر غير مرتبطة بعد الموافقة: يُبلّغ عن ذلك التغيّر، فيما تبقى موافقة الخطة متعلقة بالخطة وتعليمات الاختبار. يمكن للشخص أن يقول «عُد إلى الخطة المعتمدة» لاستعادة الخطة السابقة قبل البناء. ولا ينبغي أن تستدعي الخطة غير المتغيّرة سؤالًا ثانيًا لمجرد ضغط سياق المحادثة.
إذا لم يظهر التوقف
اقرأ أولًا $aidlc --status و $aidlc config get plan-approval. افحص النطاق المختار والإعداد الفعلي ومصدره. يكون Express وProof of concept معطّلين افتراضيًا؛ فعّل Plan Approval لذلك القصد، أو ابدأ سير عمل Feature إذا كانت دورة حياته الكاملة ملائمة للمهمة. إذا بدا أن الإعداد أو الخطّافات معطلة، فشغّل aidlc doctor واتبع استعادة بيئة تكامل Codex. تحقق من عدم تطابق الإصدارات قبل تغيير بيئة تشغيل مشروع نشط. لا تفترض أن غياب السؤال يثبت تسجيل الموافقة: عندما يكون الإعداد معطّلًا، يكتب AI-DLC صفًا من نوع PLAN_APPROVAL_SKIPPED تميّزه الوثائق المرتبطة بالوسم صراحةً عن موافقة شخص.
التغيير الكبير
- يضع AI-DLC 2.11.0 سؤال الخطة داخل محركه، الذي يسجّل القرار ويحتفظ بالخطة المعتمدة غير المتغيّرة عبر جلسة معلّقة أو مضغوط سياقها.
- في تشغيل Feature ضمن Codex CLI، يستطيع المطوّر فحص إعداد Plan Approval الفعلي، وقراءة الخطة قبل توليد الكود، وطلب تغييرات عند البوابة.
- تعتمد إعادة الموافقة بعد تعديل الخطة على Guard Policy. ويمكن للمطوّر اختيار strict لفرض توقف جديد عند تغيّر الخطة أو تعليمات الاختبار.
المصادر وقراءات إضافية
- إصدار AI-DLC 2.11.0 — إصدار مؤرّخ، وبرامج تثبيت محددة الإصدار، والسلوك المعلن لـ Plan Approval. تصف ملاحظات الإصدار الميزة؛ ولا تثبت أن BIG CHANGE نفّذ هذا الدليل.
- دليل Codex CLI في v2.11.0 — متطلبات إصدار Codex وGit والمزوّد، وإعداد المشروع، والثقة بالخطّافات، والاستدعاء.
- ملفات تعريف سير العمل في v2.11.0 — الإعدادات الافتراضية للملفات والفرق بين Feature وExpress/Proof of concept.
- Plan Approval وGuard Policy في v2.11.0 — بوابة الموافقة الأولى، وسجلات التخطي، والسلوك عند تغيّر خطة معتمدة.
- مرجع الأوامر في v2.11.0 — أوامر الحالة والإعداد وسجل التدقيق.



