================================================================================
                    خطة ترحيل البيانات التشغيلية
        من: supehgku_Packagemaker → إلى: supehgku_fixed_v2
================================================================================

📅 تاريخ الإعداد: 2025-10-26
🔧 الأداة: Windsurf AI Migration Analyzer

================================================================================
1️⃣ التحليل الهيكلي (Schema Analysis)
================================================================================

🔷 قاعدة المصدر (supehgku_Packagemaker):
  ✓ allowed_users       → 358 مستخدم
  ✓ control_sessions    → 25 جلسة
  ✓ message_templates   → 8 قوالب
  ✓ steam_accounts      → 102 حساب
  ✓ steam_requests      → 3,411 طلب
  ✓ sub_bots            → 26 بوت

🔷 قاعدة الهدف (supehgku_fixed_v2):
  الجداول المشتركة (6) + 19 جدول جديد للنظام المتقدم

================================================================================
2️⃣ الفروقات الجوهرية
================================================================================

⚠️ تعارضات رئيسية:

1. نظام الحدود: المصدر يستخدم daily_attempts - الهدف له نظام limits متقدم
2. message_templates: المصدر 8 قوالب - الهدف 13 قالب متطور
3. Foreign Keys: متطابقة ومتوافقة ✅
4. Views: لا DEFINER - آمنة ✅
5. Triggers: ستعمل تلقائياً عند الإدراج ✅

================================================================================
3️⃣ البيانات المطلوب ترحيلها
================================================================================

🚫 المستثنى (لن يُرحّل):
  ❌ جميع جداول limits_* (سياسة المستخدم)
  ❌ message_templates (نبقي قيم fixed_v2)
  ❌ أعمدة attempts (معطلة في الهدف)

✅ الضروري للترحيل:
  1. sub_bots (26) - بدون daily_attempts
  2. steam_accounts (102) - بدون daily_attempts_override
  3. allowed_users (358) - كامل
  4. steam_requests (3411) - كامل
  5. control_sessions (25) - اختياري بـ --with-sessions

================================================================================
4️⃣ خطة التنفيذ
================================================================================

التسلسل:
  1. sub_bots (50/batch)
  2. steam_accounts (100/batch)
  3. allowed_users (500/batch)
  4. steam_requests (1000/batch)
  5. control_sessions (100/batch) - اختياري

آليات الأمان:
  ✓ INSERT...ON DUPLICATE KEY UPDATE (idempotent)
  ✓ حفظ حالة الاستئناف في .migrate_state.json
  ✓ Dry-run mode (--dry-run)
  ✓ Logging في migrate_execution.log
  ✓ ROLLBACK تلقائي عند الفشل

================================================================================
5️⃣ التحقق بعد الترحيل
================================================================================

✅ Row Count (يجب التطابق):
  المصدر → الهدف
  sub_bots: 26 → 26
  steam_accounts: 102 → 102
  allowed_users: 358 → 358
  steam_requests: 3411 → 3411

✅ Integrity Checks:
  - Foreign Keys صحيحة
  - Unique Keys لا تكرار
  - Triggers عملت (كل bot/account في المجموعة الافتراضية)

================================================================================
6️⃣ المخاطر المعروفة
================================================================================

⚠️ متوسطة:
  1. نظام الحدود: يحتاج ضبط limits_global يدوياً بعد الترحيل
  2. steam_requests كبير: قد يأخذ 30-60 ثانية

🛡️ منخفضة (تم معالجتها):
  ✅ FK متطابقة
  ✅ لا DEFINER
  ✅ COLLATION متطابق

================================================================================
7️⃣ خطة التراجع (Rollback)
================================================================================

في حالة الفشل:
  - السكريبت: ROLLBACK تلقائي + استئناف من آخر نقطة
  - يدوي: TRUNCATE الجداول المرحلة + إعادة التشغيل

نسخة احتياطية موصى بها:
  mysqldump -u user -p supehgku_fixed_v2 > backup_before_migration.sql

================================================================================
8️⃣ نافذة الصيانة
================================================================================

الوقت المقدر: 1-2 دقيقة للترحيل + 1 دقيقة للتحقق
النافذة المقترحة: 5-10 دقائق (مع وقت احتياطي)

أفضل وقت: ساعات الصيانة (أقل حركة مرور)

================================================================================
9️⃣ خطوات ما بعد الترحيل
================================================================================

1. ضبط limits_global:
   UPDATE limits_global SET mode='weekly', per_day=2, weekly_cap=6, ban_days=7 WHERE id=1;

2. اختبار بوت واحد:
   - سحب كود من حساب
   - التحقق من عمل نظام الحدود

3. مراقبة Logs:
   SELECT * FROM system_logs ORDER BY created_at DESC LIMIT 50;

4. التحقق النهائي من عدد السجلات

================================================================================
10️⃣ أوامر الاختبار
================================================================================

Dry-run (آمن):
  php migrate_core_no_templates.php --dry-run

ترحيل بدون control_sessions (موصى به):
  php migrate_core_no_templates.php

ترحيل مع control_sessions:
  php migrate_core_no_templates.php --with-sessions

استئناف بعد فشل:
  php migrate_core_no_templates.php
  (يستأنف تلقائياً من .migrate_state.json)

================================================================================
⚠️ تحذيرات مهمة
================================================================================

1. لا تشغل السكريبت أثناء استخدام النظام بكثافة
2. تأكد من نسخة احتياطية قبل التشغيل
3. اختبر بـ --dry-run أولاً
4. راقب الـ logs أثناء التنفيذ
5. لا تقاطع التنفيذ - دعه يكمل أو يفشل بأمان

================================================================================
نهاية الوثيقة - جاهز للتنفيذ
================================================================================
