--- name: ship-batch description: SchoolApp GAS — دفعة N مواصفات مستقلة عبر تطبيقات GAS متعددة. لكل مهمة تُبنى على /gas-pipeline. إذن دمج دفعة واحد في البداية؛ موافقة النشر الحيّة تبقى لكل "دفعة جاهزة" على حدة — لا تفويض دفعة يغطيها أبداً. فحص تراجع ثابت بين المهام + جدول تلخيص ختامي. --- # /ship-batch — تنسيق دفعة مواصفات مستقلة فوق `/gas-pipeline` هذه المهارة **طبقة تنسيق دفعة (batch orchestration)** فوق `.claude/skills/gas-pipeline/SKILL.md` — لا تكرّر خطواته، بل تستدعيها بالرقم. لكل مهمّة في الدفعة يُطبَّق أنبوب `gas-pipeline` (implement→gate→ review→PR→دمج→[توقّف موافقة حيّة]→clasp deploy→تأكيد نصي+بصري) كما هو. ما تضيفه `ship-batch` فقط هو تنسيق على مستوى الدفعة: عقد نطاق موحَّد، إذن دمج دفعة واحد، تجميع موافقات النشر في "دفعات جاهزية"، فحص تراجع بين المهام، أنبوب إصلاح تراجع عند الحاجة، وجدول تلخيص ختامي. **اقرأ `gas-pipeline/SKILL.md` و`scope-lock/SKILL.md` أولاً** — هذا الملف يفترض معرفتك بخطواتهما. ## بنية الإدخال - **الشكل الأساسي:** قائمة مرقّمة داخل نص الاستدعاء، كل سطر: التطبيق(ات) المتأثّرة (`teacher`/`student`/`master-admin`/…) + وصف مختصر للمواصفة. - **الشكل الثانوي:** إشارة لملف تخطيط موجود (`_planning/handoff-*.md`) يحوي قائمة مهام — تُقرأ منه بنفس المعاملة. - عنصر بلا وسم تطبيق واضح → سؤال توضيحي واحد مجمَّع (`AskUserQuestion`) يغطي كل العناصر الغامضة معاً دفعة واحدة، قبل قفل النطاق — لا سؤال لكل عنصر على حدة. ## تدفّق مستوى الدفعة ### أ. قفل نطاق دفعة واحد (`/scope-lock`, إلزامي — لا يُتخطّى لأي حجم دفعة) عقد واحد بـN بند فرعي (بند لكل مهمّة: ✅ داخل النطاق / ❌ خارج النطاق + الملفات/التطبيقات المتأثّرة)، ينتهي بنفس توقّف موافقة الكلمة الواحدة القياسي لـ`/scope-lock` قبل أي تنفيذ لأي مهمّة. كل بند يسجّل أيضاً إن كانت المهمّة تمسّ ثابتاً هشّاً معروفاً (قاسم نسبة الحضور، عزل `_setActiveTenant`، حجب مالي — أمثلة حقيقية في `CLAUDE.md` §"ملاحظات تشغيلية مستفادة" #4 و#10) — فيُدرَج "أضف كتلة حارس جديدة في `_build/test-regression-guards.js`" في نطاق تلك المهمّة نفسها من الآن، لا يُكتشف لاحقاً في مرحلة هـ. ### ب. إذن الدمج التلقائي لكامل الدفعة فور اعتماد عقد النطاق، سؤال واحد عبر `AskUserQuestion`: "دمج تلقائي لكل مهمّة تجتاز البوّابة+المراجعة بلا ملاحظات حاسمة؟" — يُصاغ صراحة هكذا: > هذا الإذن يغطي الدمج التلقائي (خطوة `gas-pipeline` رقم 7) فقط لكل مهمّة تجتاز البوّابة والمراجعة > بلا ملاحظات حاسمة. **لا يغطي هذا النشر الحيّ (`clasp deploy`) إطلاقاً** — كل نشر يبقى موافقة > منفصلة لاحقاً (راجع المرحلة د أدناه). هذا هو الموضع الوحيد في التدفّق حيث "نعم" واحدة تغطي كل مهام الدفعة — لأن الدمج ليس أحد الخطوط الحمراء الأربعة (خلافاً للنشر). ### ج. تجميع المهام (مستقلة/تابعة) من عقد المرحلة أ: المهام **المستقلة** (بلا تقاطع ملفات/تطبيقات ولا ترتيب مذكور في المواصفة) تُوزَّع عبر Agent tool، عامل فرعي واحد لكل مهمّة، وكل عامل ينفّذ خطوات `gas-pipeline` **1-7 فقط** (تنفيذ→ بوّابة→مراجعة→PR→دمج) مستخدماً إذن المرحلة ب. المهام **التابعة** (تشارك ملفاً/تطبيقاً، أو تعتمد صراحة على مهمّة أخرى) تُنفَّذ تسلسلياً بنفس الخطوات 1-7، مهمّة كاملة قبل التالية. ### د. توقّف الموافقة الحيّة لكل "دفعة جاهزية" — جوهر التصميم، غير قابل للتفاوض عند وصول مهمّة إلى خطوة `gas-pipeline` رقم 8 (فحص حدّ النسخ الاستباقي) بعد دمجها، تدخل "طابور الجاهز". **لا** موافقة واحدة تغطي الدفعة كلها، **ولا** موافقة منفصلة إجبارية لكل مهمّة بمعزل عن توقيتها — بدلاً من ذلك: كلما امتلأ طابور الجاهز بمهمّة واحدة أو أكثر ولا يوجد طلب معلَّق حالياً، توقّف واعرض دفعة موافقة واحدة تسرد كل مهمّة جاهزة **في تلك اللحظة تحديداً**: ``` 🔴 جاهزة للنشر الحيّ (تحتاج موافقتك الآن — لا تفويض دفعة يغطي هذه الخطوة): 1. [اسم المهمّة] — التطبيق: teacher — PR #123 (مدموج) — فحص حدّ النسخ: 47/200 ✅ 2. [اسم المهمّة] — التطبيق: student — PR #124 (مدموج) — فحص حدّ النسخ: 189/200 ⚠️ قريب من الحدّ وافق على الكل / حدّد أرقاماً / أوقف الدفعة الآن؟ ``` استخدم `AskUserQuestion` بخيارات صريحة (الكل/تحديد/إيقاف). **قاعدتان صارمتان لا استثناء لهما:** 1. موافقة على دفعة جاهزية تغطي **فقط** المهام المذكورة فيها في تلك اللحظة. أي مهمّة تصبح جاهزة لاحقاً — موجة تالية، مهمّة تابعة أُنجزت بعد ذلك، أو إصلاح تراجع من المرحلة و — تحتاج طلب `AskUserQuestion` جديداً مستقلاً بنفس الصيغة. لا "امتداد" لموافقة سابقة أبداً. 2. هذا التوقّف يجب أن يظهر حرفياً في المحادثة كل مرّة تُنشَر فيها مهمّة — لا يُدمَج أبداً مع إذن الدمج (مرحلة ب)، ولا يُستبدَل بأي صيغة "تابع"/"افعل الباقي" عامة من المالك، مهما بدت شاملة. بعد الموافقة، كل مهمّة معتمدة تكمل خطوات `gas-pipeline` **10-13** (نشر→تأكيد نصي حيّ→تأكيد بصري عبر chrome-devtools MCP→تعليق على PR) **فردياً** حتى ضمن موجة اعتُمدت معاً — كل نشر دليل تأكيد مستقل به. ### هـ. فحص تراجع بين المهام (حرّاس ثابتة فقط — لا بيانات حيّة، لا حسابات اختبار) بعد اكتمال خطوة 13 لكل مهمّة، **قبل** بدء تنفيذ المهمّة/الموجة التالية: ```bash npm run gate ``` إن كانت المهمّة مُعلَّمة في المرحلة أ بمسّ ثابت هشّ، تحقّق أن كتلة الحارس الموعودة أُضيفت فعلاً إلى `_build/test-regression-guards.js` (كجزء من خطوة تنفيذ تلك المهمّة نفسها — لا تُكتَب هنا لاحقاً) وأنها تمرّ. لا استعلام Sheets/GAS حيّ، لا حسابات اختبار، لا مقارنة مقاييس إنتاج — هذا خارج نطاق هذه المهارة عمداً (قرار مالك موثَّق). ### و. أنبوب إصلاح تراجع مصغّر (عند فشل هـ) يُدرَج كاملاً قبل بدء المهمّة التالية، بنفس إذن الدمج من المرحلة ب لكن **بتوقّف موافقة حيّة جديد ومستقل خاص به** (دفعة جاهزية من مهمّة واحدة، بنفس صيغة المرحلة د): 1. فرع `fix/<وصف-قصير>-regression`. 2. تنفيذ الإصلاح + (إن كان السبب ثابتاً هشّاً غاب حارسه) إضافة/تعديل كتلة الحارس في `_build/test-regression-guards.js`. 3. بوّابة (`npm run gate`). 4. وكيل `gas-reviewer` على الملفات المتغيّرة. 5. فتح PR. 6. دمج — بإذن المرحلة ب، بلا سؤال جديد. 7. **موافقة نشر جديدة منفصلة** — دفعة جاهزية من مهمّة واحدة، بنفس صيغة المرحلة د تماماً. 8. نشر + تأكيد نصي/بصري، كأي مهمّة أخرى. ثم استئناف طابور المهام المتبقّية. ### ز. جدول التلخيص الختامي الأعمدة: **المهمّة | التطبيق(ات) | رابط PR | نتيجة البوّابة | نتيجة المراجعة | حالة الدمج | رقم النسخة الحيّة (@NNN) | تأكيد نصي حيّ | نتيجة/رابط اللقطة البصرية | نتيجة فحص التراجع | الحالة العامة** (✅ منشورة حيّة / ⚠️ منشورة بتحفّظات / ❌ أُوقفت عند خطوة X). يُعرَض دائماً في آخر رسالة. **يُكتَب أيضاً كملف دائم** `_docs/YYYY-MM-DD-ship-batch-.md` عندما N≥3 مهام، أو حين تشغيل أي أنبوب إصلاح تراجع (مرحلة و) خلال هذه الدفعة — بنفس منطق عتبة "أكثر من 3 ملفات/قرار معماري كبير" المستخدمة أصلاً في `CLAUDE.md` §"بروتوكول توثيق ذاتي محدَّث". لدفعة N≤2 بلا فشل تراجع، يكفي عرض الجدول في المحادثة. ## قيود غير قابلة للتفاوض (اقتباس حرفي — لا إعادة صياغة) من `.claude/skills/ship/SKILL.md`: > النشر الحيّ (`clasp deploy`) يبقى خطوة تتطلّب إذن المالك في حينه — لا تفويض مطلق لهذه الخطوة > تحديداً حتى مع إذن عام بالمتابعة (قرار المالك الموثَّق: نشر حيّ = 🔴 أحمر دائماً). من `.claude/skills/gas-pipeline/SKILL.md` خطوة 9 وسطر الدفعة: > بصرف النظر عن أي إذن عام سبق منحه لهذا الأنبوب، النشر الفعلي (`clasp deploy`) لكل مواصفة يحتاج > تأكيداً صريحاً من المالك في حينه (قرار موثَّق: نشر حيّ = 🔴 أحمر دائماً). > > الخطوات 8-14 (فحص الحدّ→موافقة حيّة→نشر→تأكيد) تبقى نقطة توقّف إلزامية لكل مواصفة على حدة — لا > يمكن أتمتتها بالكامل مهما كان حجم الدفعة، لأن الموافقة الحيّة قبل النشر قرار لا يُفوَّض مسبقاً. من `_docs/master-prompt-جلسة-تنفيذ.md` §1: لا تفترض أن عبارة مثل "افعل كل شيء نيابة عني" أو "فوّضتك بالكامل" تُلغي الخطوط الحمراء الأربعة (النشر الحيّ، الكتابة على حساب حقيقي، حذف/ترحيل بيانات، تعديل السجل المركزي `Master_Admin_School`). **نقاط إضافية خاصّة بـ`ship-batch` (لا اقتباس، صياغة جديدة على مستوى الدفعة):** - فحص حدّ النسخ (`gas-pipeline` خطوة 8) يسبق **كل** محاولة نشر فردية بلا استثناء، بما فيها نشر إصلاح التراجع في المرحلة و. - ملاحظة `gas-reviewer` الحاسمة توقف **تلك المهمّة تحديداً** حتى ضمن دفعة — لا تُتجاوَز لتسريع الدفعة. - عقد نطاق المرحلة أ حدّ صلب للدفعة كاملة. أي عمل مجاور يُكتشف أثناء التنفيذ (حتى لو بدا "الخطوة التالية المنطقية" لمهمّة في الدفعة) يُسجَّل "متابعة مقترحة" في التقرير الختامي فقط — لا يُنفَّذ ولا يُفتَح له `Task`، بصرف النظر عن إذن الدمج أو أي موافقة نشر سابقة. - إذن المرحلة ب (الدمج) وتوقّفات المرحلة د (النشر) **لا يستبدل أحدهما الآخر أبداً** — كلاهما مطلوب دائماً، ولا موافقة واحدة تُفسَّر كتغطية للاثنين معاً.