schoolos-deploy

Use for SchoolOS merge-and-deploy work (session 0601): admitting owner-approved PRs to the merge queue, batching, after-hours Railway deploys, verifying web/worker/beat after deploy, ejected or stuck

SKILL.md

GitHub

الدمج والنشر على الإنتاج — جلسة «0601 · النشر على الإنتاج والدمج»

الغرض: نقلُ ما اعتمده المالكُ من طابور الدمج إلى الإنتاج بلا مفاجأة — دفعةٌ مرتّبة، بعد الدوام، ثمّ تحقّقٌ يُثبت أنّ الـcommit المقصود حيٌّ وسليمٌ على الخدمات الثلاث، ثمّ تسليمٌ للخارطة والقياس.

متى تُستعمل ومتى لا

  • تُستعمل: طلبٌ «جاهزٌ للدمج» وصل من جلسةٍ منفِّذة؛ دفعةٌ تُجمع أو تُنشر؛ طلبٌ أُقصي من الطابور؛ الإنتاجُ خلف main؛ فشلُ نشرٍ أو كنار؛ قرارُ رجوع.
  • لا تُستعمل: كتابةُ الإصلاح نفسِه (يعود لصاحبه في 04)، والمعاينةُ والاعتماد (0501، مهارة schoolos-flow)، وأمانُ غيت في شجرتك (schoolos-git-safety)، وتحليلُ SQL هجرةٍ وأقفالها (schoolos-migration-guard).

الإجراء (دورةُ دفعة)

  1. اقرأ الحال قبل أيّ فعل: الوقتُ بالدوحة من الأداة؛ bash scripts/preview.sh status (main مقابل commit الإنتاج)؛ الطابورُ فارغٌ أو ما فيه؛ ولا نافذةَ عمليّةِ إنتاجٍ للمالك قائمة. عند الشكّ في قاعدةٍ: git show origin/main:CLAUDE.md لا نسخةَ سياقك.
  2. لكلّ طلب: python .claude/skills/schoolos-deploy/scripts/pr_gate.py <N> ثمّ اقرأ git diff origin/main...<رأسه> بنفسك. الشروطُ في 01-pre-merge-checks.md.
  3. رتّب الدفعة: المتراكبُ بعد أساسه، والطلبُ الذي يملك ملفّاً يرفضه حارسٌ جديدٌ قبل حاملِ الحارس، والمتداخلان في ملفٍّ واحدٍ لا يدخلان معاً. حاكِ السلسلةَ دمجاً بأبٍ واحد (squash).
  4. أدخِل بأوامر صريحةٍ متتابعة gh pr merge <N> --auto بعد قراءةٍ حيّةٍ للحالة — لا بحلقةٍ تتحقّق وتدمج. راقب الطابور ≈15 دقيقة لكلّ مجموعة.
  5. بعد الدمج: bash scripts/preview.sh sync --now ودخانٌ على 8500، ثمّ النشر: أوامرُ الخدمات الثلاث للمالك في كتلٍ منفصلة (04-owner-only-commands.md)، وأنت تراقب قراءةً.
  6. تحقّق: verify_deploy.py <sha7> ثمّ الصفحاتُ المعنيّة وأثرُ الهجرة (02-post-deploy-verification.md). لا يدخل طلبٌ جديدٌ الطابورَ قبل اكتمال هذا.
  7. سلّم: «0701 · تحديث الخارطة» و«0702 · مراقبات الجودة» وأصحابُ الطلبات — كلٌّ باسمه في الشريط لا برقم منفذ.

القواعد وأسبابها

  • لا دمجَ بلا سطر «اعتُمد من المالك على 8500 — <التاريخ>» أو اعتمادٍ مباشرٍ من المالك لك بعد معاينته؛ والخضرةُ لازمةٌ غيرُ كافية. السبب: دُمجت أربعةُ طلباتٍ بالفحص الفنّيّ وحدَه فاعترض المالك. المصدر: CLAUDE.md («الفلو» البند 7)، feedback_approval_line_hard_gate، D-39م.
  • الفرقُ الفعليّ لا الوصف: #715 وصفُه «لا أثرَ بصريّ» وفرقُه يُلغي إصلاحَ #709 المنشورَ مع اختباره. المصدر: feedback_verify_actual_diff_before_enqueue.
  • الدمجُ ممنوعٌ الأحد–الخميس 07:00–14:00 الدوحة إلّا بوسم «نشر-عاجل» وإذن المالك الصريح لتلك المرّة؛ الجمعةُ والسبتُ مسموحان. المصدر: scripts/deploy_window.py، feedback_deploy_batches_and_urgent، feedback_saturday_deploy_allowed.
  • النشرُ يدويٌّ يبني رأسَ main كلَّه (--from-source)، فلا استثناءَ لإيداعٍ مدموج: طلبٌ مشروطُ النشر يبقى خارج الطابور، ولا يدخل طلبٌ جديدٌ بين الإطلاق والتحقّق. المصدر: .github/workflows/deploy-railway.yml (الرأس)، feedback_gated_pr_stays_out_of_queue.
  • أوامرُ الإنتاج (نشر، ssh، متغيّرات، رجوعٌ من اللوحة) يحجبها المصنِّف عنك ولو أذن المالك في المحادثة؛ تُجهَّز له ولا يُلتفّ عليها. المصدر: feedback_auto_classifier_production_actions.
  • الإصلاحُ البنيويّ الصرف (ترتيبُ استيراد، إعادةُ إدخال) هنا؛ وما يمسّ منطقَ الميزة يعود لصاحبه. المصدر: feedback_publish_session_scope.
  • الحجزُ الصريحُ من المالك على طلبٍ لا يرفعه إلّا قولُه لك مباشرةً، لا «قال المالك» من جلسةٍ أخرى. المصدر: feedback_publish_session_merges_all.

فخاخ

  • خطأ: «الفحوص خضراء فأُدخله» ← الصواب: سطرُ الاعتماد والفرقُ الفعليّ أوّلاً؛ الخضرةُ ثالثُ الشروط.
  • خطأ: «خرج من الطابور = أُقصي» من قراءةٍ واحدة ← الصواب: قراءتان بينهما 20 ثانية ولا تقدّمَ لـmain؛ الإدخالُ يختفي قبل أن يرتفع merged بثوانٍ.
  • خطأ: فحوصُ الطلب خضراءُ فالإقصاءُ لغز ← الصواب: gh run list --event merge_group: تعارضٌ دلاليٌّ بلا تعارضٍ نصّيّ (حارسٌ جديدٌ يرفض ملفَّ طلبٍ سبقه).
  • خطأ: /health/ أخضرُ فالنشرُ سليم ← الصواب: /health/ يفحص الويب وحده؛ سجلّاتُ العامل وbeat قد تكون في حلقة ImproperlyConfigured.
  • خطأ: railway up أو railway run ← الصواب: النشرُ من GitHub (redeploy --from-source)، وأوامرُ القاعدة داخل الحاوية بـrailway ssh.
  • خطأ: «نشر-عاجل» لأنّ الطلب مهمّ ← الصواب: الوسمُ لإصلاحٍ لا يحتمل التأجيل وبإذن المالك نصّاً في كلّ مرّة.
  • خطأ: متابعةُ جوابٍ على سؤالٍ بقي معلّقاً ساعات ← الصواب: أعِد قراءةَ الحيّ (الوقت، الإنتاج، النوافذ) قبل أيّ أمر.

المراجع

الملفّ متى تقرؤه
references/00-batch-recipe.md قبل أوّل دفعةٍ في الجلسة، أو عند سؤال «متى وكيف ننشر» والاستعجال
references/01-pre-merge-checks.md قبل إدخال أيّ طلبٍ الطابور، وعند وجود هجرةٍ أو ملفّ بنية
references/02-post-deploy-verification.md بعد أن يشغّل المالكُ النشر، وعند فشل الكنار أو التحقّق
references/03-stuck-merge-and-rollback.md طلبٌ أُقصي أو UNMERGEABLE أو GH006، أو عطلٌ بعد النشر وقرارُ رجوع
references/04-owner-only-commands.md كلّما لزم أمرٌ يمسّ الإنتاج أو إعداداً دائماً
references/99-test-cases.md عند تعديل المهارة أو تقييم تفعيلها

الأدواتُ الخارجيّة (خارج المستودع، لجلسة النشر): ~/deploy_work/ — verify_deploy.py، simulate_chain.py، queue_watch.sh، deploy_watch.sh، ودخانا المعاينة preview_*_smoke.py.