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