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

هذا إجراء يستند إلى الوثائق. لم تصل BIG CHANGE إلى مشروع Jira، ولم تشغّل Claude Code، ولم تعدّل مستودعًا أو تقس زمن تسليم ميزة. تعتمد أنواع المسائل والحقول والانتقالات والأوامر والتكاليف الدقيقة على مشروعك وحسابك.

التغيير الكبير

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

قبل البدء

اختر ميزة لها وصف اعتمده المسؤول، ومستودع يجوز لك تعديله، وفحص قبول أصلي يمكنك تشغيله. يجب أن يستدعي العمل الفعلي مسألة أصل واحدة بمستوى ملحمة، وقصصها المعتمدة، ومهمة فرعية واحدة مفيدة على الأقل تحت قصة في مشروع Jira Cloud المختار. إذا لم توجد مهمة فرعية حقيقية، تبقى هذه النتيجة الشاملة تحديدًا غير مكتملة؛ فإضافة مسألة شكلية تزيّف الخطة. سجّل مقدم الطلب، وصاحب سلطة الاعتماد، ومراجعة المصدر، والبيانات المسموح بها، والتثبيت الأولي في Git، ومسار العزل أو التراجع، ومن يحق له مراجعة الشيفرة وتغيير حالة Jira.

تحقق من إصدار Claude Code والمصادقة والأذونات في بيئتك المثبتة. تأكد من أن ملف CLAUDE.md في المستودع يوفر إرشادات للمشروع ولا يمنح إذنًا للتعديل أو تشغيل الأوامر أو إرسال البيانات. حدد المتطلبات والشيفرة التي يجوز أن يتلقاها Claude، والأوامر المسموح له بتشغيلها، وحد الاستخدام لهذه الميزة. قد يستهلك استخدام Claude Code حصة اشتراك أو يترتب عليه رسم من المزوّد؛ دليل التكاليف من Anthropic لا يحدد فاتورتك مسبقًا.

في Jira، احصل على إذن لاستعراض أنواع المسائل المعنية وإنشائها، ثم التعليق أو نقل الحالات بصفتك المستخدم المصرح له. يمكن لبرنامج نصي خاص استخدام طريقة البريد الإلكتروني ورمز API التي توثقها Atlassian؛ وقد يحتاج التكامل إلى OAuth. احتفظ ببيانات الاعتماد في مخزن أسرار خاص. لا تدرجها في المطالبات أو نصوص المسائل أو CLAUDE.md أو السجلات أو نظام التحكم بالإصدارات. اتفق على نطاق ظهور المسائل قبل إرسال المتطلبات إلى Jira.

احتفظ بسبعة سجلات خاصة أثناء العمل: docs/feature-prd.md، ticket-plan.json، ويومية لكتابة المسائل تسمح بالإضافة فقط، ticket-map.json، وإثبات تنفيذ لكل قصة، ويومية تحديثات Jira، وقرار مراجعة ختامية. هذه سجلات لميزتك، وليست ملفات قدمتها BIG CHANGE أو شغلتها.

1. اعتمد نسخة دقيقة من PRD

أعط Claude Code الوصف المعتمد فعليًا للميزة، واطلب تحديد الأسئلة غير المحسومة قبل صياغة docs/feature-prd.md. تحتاج الوثيقة إلى مقدم الطلب والمسؤول المعتمد، ومراجعة المدخلات، والمشكلة والمستخدم المقصود، والنطاق والاستثناءات، ومعرّفات متطلبات مرقمة، وفحوص القبول ومصادر أدلتها، والقيود غير الوظيفية، ومشروع Jira، والأسئلة المفتوحة. ليقارن شخص مسؤول المسودة بالوصف الأصلي ويعتمد مراجعة محتوى دقيقة واحدة وبصمتها. احسم الأسئلة الجوهرية قبل إنشاء المسائل أو تعديل الشيفرة.

تمنح البصمة السجلات اللاحقة مصدرًا دقيقًا. إذا تغير PRD، فراجع مجددًا خطة المسائل والفحوص المتأثرة؛ ففشل التنفيذ ليس مبررًا لإعادة كتابة معايير القبول كي تبدو ناجحة.

2. اكتشف تسلسل Jira وحقول هذا المشروع

باستخدام طلبات Jira REST API v3 المصرح بها، التي تكون للقراءة فقط، استعرض جميع صفحات GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes. ولكل نوع مقترح من المسائل، استعرض جميع صفحات GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId} لاكتشاف حقول الإنشاء المطلوبة والقيم المسموح بها. تصنّف Atlassian العملية الواسعة GET /issue/createmeta على أنها مهملة في مرجع API للمسائل لديها.

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

3. راجع خطة المسائل كاملة قبل الكتابة

اربط كل متطلب وفحص قبول في PRD داخل ticket-plan.json. سجّل planVersion الخاص به، وبصمة PRD، وموقع Jira ومفتاح المشروع، ومعرّف تشغيل محلي، ومعتمد الخطة ووقتها. ولكل مسألة مقترحة، سجّل معرّفًا محليًا فريدًا، ومعرّف الأصل المحلي المقصود، ومعرّف نوع المسألة المكتشف، وحقول المشروع المطلوبة، والملخص والوصف، ومعرّفات المتطلبات والقبول، والمسؤول ونطاق الظهور المسموح. يحدد العمل المعتمد عدد القصص والمهام الفرعية. يجب أن تنجز كل مهمة فرعية عملًا حقيقيًا تحت قصتها الفعلية.

يستخدم Jira REST v3 Atlassian Document Format (ADF)، وهي وثيقة JSON منظمة، لأوصاف المسائل والتعليقات متعددة الأسطر. جهز الوثائق من المحتوى المعتمد وافحص بيانات الحقول الوصفية التي يعيدها الموقع قبل بناء كل طلب. يوثق API للمسائل عملية الإنشاء، لكنه لا يقدم كائن حقول جاهزًا لمشروع مجهول. يجب أن يعتمد شخص البنية الكاملة وتغطية كل المتطلبات وعلاقات الأصل والوجهة الدقيقة للكتابة قبل أي POST.

4. أنشئ الأصول أولًا واقرأ كل مسألة مجددًا

أنشئ الأصل المعتمد عبر POST /rest/api/3/issue، ثم قصصه، ثم كل مهمة فرعية حقيقية. قبل كل طلب، أضف صفًا إلى اليومية الخاصة يتضمن معرّف التشغيل، ومعرّف المسألة المحلي، ومفتاح الأصل المؤكد عند الاقتضاء، والوجهة، وبصمة الطلب المعتمد الدقيق، ووقت المحاولة بتوقيت UTC، وحالة pending. لا تدرج رمزًا سريًا. عند HTTP 201، سجّل معرّف المسألة ومفتاحها اللذين أعادهما Jira، ثم نفّذ مباشرة GET /rest/api/3/issue/{issueIdOrKey}. قارن المشروع والنوع والملخص والوصف أو مرجع PRD والأصل بالخطة المعتمدة. لا تعلّم الصف بالحالة confirmed إلا بعد هذه القراءة. يتيح تأكيد الأصل إنشاء المسائل التابعة له.

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

اقرأ البنية المكتملة مباشرة وسجّلها في ticket-map.json: كل معرّف محلي، ومعرّف Jira ومفتاحه الفعليين، وعنوان URL الأساسي للمسألة، والمشروع والنوع ومفتاح الأصل، ومعرّفات PRD والقبول، ووقت القراءة ومرجع اليومية. قارن كل المسائل والمعايير المعتمدة مع PRD. أوقف الكتابات اللاحقة إذا غابت مسألة أو كانت تحت أصل خاطئ؛ استخدم إجراء التصحيح المراجع في المشروع.

5. نفّذ كل قصة معتمدة وراجعها بصورة مستقلة

أنجز القصص المعتمدة بحسب ترتيب اعتماد بعضها على بعض. لكل قصة، سجّل مفتاح Jira، وتثبيت Git الأولي والفرع أو شجرة العمل، وأمر القبول الأصلي، والمسارات والأوامر المسموح بها. اطلب من Claude Code استخدام Plan mode لربط معايير القصة بالمستودع. يفحص مطور الخطة ويصرح بتعديل محدود. تحافظ حدود القصة على قابلية مراجعة التغيير؛ ولا تحذف بقية القصص المعتمدة من الميزة.

بعد التعديل، احتفظ بالفروق الدقيقة، وأمر الفحص الأصلي مع المخرجات الكاملة وحالة الخروج، والاختبارات الموجهة ذات الصلة، وحكم لكل معرّف متطلب. افحص الشيفرة والسجلات الفعلية. لا تثبت خطة مكتوبة أو ملفات مولدة أو عبارة Claude بأن الاختبارات نجحت أن التغيير يعمل. أوقف القصة عند فشل فحص، أو ظهور سر غير متوقع، أو تغيير تبعيات، أو كتابة خارجية، أو إعادة هيكلة واسعة؛ أصلح ضمن النطاق المعتمد وأعد الفحص الأصلي. يقرر مراجع شيفرة منفصل قبول التثبيت الناتج أو إبقاء الفروق معلقة. سجّل القرار لكل قصة. دليلنا السابق لتغيير واحد مراجع باستخدام Claude Code يغطي مرحلة مراجعة الشيفرة الأضيق؛ ويحدد PRD وبنية Jira الكاملة هنا حدود الميزة الأوسع.

6. تحقق من تحديثات Jira المصرح بها

لكل قصة مراجعة، اقرأ حالتها الحالية في Jira واطلب GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields. افحص الانتقال المتاح فعليًا لهذا المستخدم، ووجهته، والحقول المطلوبة والقيم المسموح بها. يمكن للمسؤول المصرح له بعدها إرسال الانتقال المختار عبر POST /rest/api/3/issue/{key}/transitions بقيم الحقول المحددة للمشروع. اقرأ المسألة مباشرة مجددًا وأكد حالتها الجديدة. اجتياز فحص الشيفرة لا يمنح وحده إذن Done أو الدمج أو النشر التشغيلي.

سجّل في يومية تحديثات Jira الحالة السابقة للكتابة والانتقال المقصود والمستخدم والطلب والاستجابة. انشر تعليق أدلة واقعيًا بصيغة ADF عبر POST /rest/api/3/issue/{key}/comment: التثبيت المقبول أو الفروق المعلقة، والفحص الأصلي والاختبارات الموجهة، والإخفاقات المتبقية وقرار المراجع. اقرأ معرّف التعليق المنشأ ومحتواه من API التعليقات في Jira. إذا كانت استجابة أي كتابة غير مؤكدة، افحص الحالة أو التعليقات مباشرة قبل التفكير في طلب آخر. قائمة انتقالات فارغة أو حقل مطلوب غير متاح يعني نقصًا في سير العمل أو الصلاحيات يجب حله مع مسؤول المشروع، وليس دعوة لاختلاق معرّف.

7. قرر ما إذا كان CLAUDE.md يحتاج إلى تغيير

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

الاكتمال والتعافي

لا تكتمل الميزة إلا عندما تطابق مراجعة PRD المعتمدة بنية الملحمة والقصص والمهام الفرعية المؤكدة مباشرة؛ وتكون كل قصة معتمدة موثقة بحالتها الأولية وفروقها المقبولة وأدلة الفحص الأصلي والاختبارات الموجهة ومراجعة مستقلة؛ وتوجد قراءة مباشرة لكل انتقال Jira وتعليق أدلة مصرح به؛ ويكون شخص قد قرر بشأن المراجعة الختامية. سجّل المرحلة المتبقية الدقيقة إذا نقص أي عنصر. اختيار أول مهمة بالذكاء الاصطناعي ينتهي في مرحلة أسبق، عند اختيار المهمة واقتراح الفحص؛ ولا يثبت نتيجة التنفيذ هذه.

يبقى إنشاء Jira غير المؤكد في حالة unknown حتى يطابق شخص هويته. يوقف الأصل الخاطئ إنشاء المسائل التابعة. تحتفظ الاختبارات الفاشلة بمعاييرها الأصلية. يترك الانتقال المفقود أو حد الاستخدام المستنفد سجلًا جزئيًا مؤرخًا للمسؤول. قلل المتطلبات وبيانات العملاء إلى الحد الأدنى المعتمد لـ Claude وJira، وافحص تكاليف الحساب وأذوناته الحالية، وخصص موارد للمراجعة البشرية للشيفرة. يوثق هذا الدليل مسارًا مشروطًا عبر الأدوات؛ ولا يبلغ عن ميزة أكملتها BIG CHANGE، أو كتابة في Jira، أو تشغيل نموذج، أو وفر مقاس، أو دمج، أو نشر تشغيلي.

المصادر وقراءات إضافية