إذا كان زر Publish أو Update يعرض "Your Cloud Balance is insufficient to publish" أو "Your Cloud Balance is insufficient to update," فهذا يعني أن محفظة Cloud لديك قد نفدت.

لإصلاح ذلك:

1. انتقل إلى Settings > Cloud & AI للتحقق من رصيدك الحالي.

2. حدد Top up now وأضف أموالاً إلى محفظة Cloud الخاصة بك.

3. ارجع إلى لوحة Publish وحاول مرة أخرى.

ملاحظة: محفظة Cloud الخاصة بك منفصلة عن رصيد اشتراكك. تموّل محفظة Cloud خدمات الاستضافة والنشر، بينما يُستخدم رصيد الاشتراك لمحادثات وكيل الذكاء الاصطناعي.

1. تحقق من عرض استخدام التخزين وحدد أكبر الدردشات والمشاريع والملفات.
2. نزّل أو انسخ احتياطيًا أي شيء قد تحتاج إليه لاحقًا.
3. احذف العناصر غير الضرورية فقط. إذا كان حذف الدردشة يعرض إزالة بيانات القرص المرتبطة، فحدد هذا الخيار فقط بعد التأكد من أن البيانات يمكن الاستغناء عنها بأمان.
4. حدّث الصفحة وتأكد من أن مساحة التخزين المتاحة قد زادت.
5. ارجع إلى Publish وأعد المحاولة مرة واحدة.

قد يكون الحذف دائمًا وقد يؤدي إلى تعطيل مشروع يشير إلى ملف تمت إزالته. إذا لم ينخفض الاستخدام، فاتصل بـ Support مع عرض التخزين، والباقـة، ورابط المشروع، ووقت فشل النشر.

انتظر حتى ينتهي فحص الأمان، ثم راجع كل عنصر تم وضع علامة عليه قبل النشر.

1. حدد Resolve All وافحص السلوك المتأثر. أصلح المشكلات التي تتضمن أسرارًا مكشوفة أو مصادقة أو أذونات أو بيانات مستخدم أو وصولًا خارجيًا غير آمن قبل الاستخدام في الإنتاج.
2. إذا كان من المحتمل أن يكون سر قد انكشف، فأزله من المشروع وقم بتدويره عبر المزوّد المعني قبل النشر.
3. شغّل الفحص مرة أخرى وتحقق من المسار المتأثر.
4. استخدم Publish Anyway فقط عندما يفهم مراجع مسؤول المخاطر المتبقية غير الحرجة ويقبلها. دوّن السبب وتجنب تجاوز خطر غير محلول على موقع إنتاج.

إذا لم تتمكن من تحديد تأثير نتيجة ما، فلا تنشرها. اتصل بـ Support أو بمالك الأمان لديك مع نص النتيجة والأدلة المنقحة.

1. اختبر عنوان URL الإنتاج الخاص بالمنصة والنطاق المخصص كلًّا على حدة. وقارن أيضًا الصفحة الرئيسية بالصفحة المحددة أو مسار API الذي يفشل.
2. سجّل رمز الحالة الدقيق، وعنوان URL الكامل، والوقت والمنطقة الزمنية، وما إذا كان الفشل ثابتًا أم متقطعًا.
3. تحقق من أحدث حالة نشر وما إذا كان تغيير حديث في تبعية أو متغير بيئة أو قاعدة بيانات أو خدمة خارجية يتطابق مع بداية الفشل.
4. التقط أخطاء Console وNetwork ذات الصلة.

إذا استمر الفشل، فاتصل بـ Support مع خطوات إعادة الإنتاج، والإصدار المتأثر، وبيانات التشخيص المنقحة. قبل إرسال HAR أو مخرجات الأوامر أو لقطة شاشة، أزل ملفات تعريف الارتباط، ورؤوس Authorization، وtokens، ومعلمات الاستعلام السرية، والبيانات الشخصية، ومعلومات الدفع.

إذا انتهت مهلة النشر أو كان الموقع المباشر غير متاح مؤقتًا:

1. تحقق مما إذا كان كل من النطاق الفرعي Prod الخاص بالمنصة وPreview غير متاحين، أو أحدهما فقط.

2. أبقِ صفحة الخطأ الحالية ظاهرة — لا تنقر فوق Publish بشكل متكرر.

3. تحقق مما إذا كنت قد عدّلت مؤخرًا التبعيات أو نقاط بدء التشغيل أو اتصالات قاعدة البيانات، لأن هذه التغييرات قد تؤثر في النشر.

إذا استمرت المشكلة، فاتصل بـ Support وضمّن:

- رابط المشروع وعنوان URL المباشر

- وقت الفشل ومنطقتك الزمنية

- رقم الإصدار ولقطة شاشة لصفحة الخطأ

- ما إذا كان Preview يعمل بشكل طبيعي

- ما إذا كنت قد عدّلت مؤخرًا التبعيات أو نقطة البدء أو اتصال قاعدة البيانات

إذا كانت لوحة Publish تعرض "latest" مع زر معطل، أو كانت عالقة على "Building":

1. لا تنقر فوق Publish بشكل متكرر — فهذا لن يسرّع الأمور وقد ينشئ مهام بناء مكررة.

2. انتظر بضع دقائق ثم حدّث الصفحة.

3. إذا لم تتغير الحالة بعد التحديث، فاتصل بـ Support.

ضمّن ما يلي عند الاتصال بـ Support:

- رابط الدردشة

- لقطة شاشة كاملة للوحة Publish (بما في ذلك عنوان URL للصفحة، ورقم الإصدار، وحالة الزر)

- وقت الحدوث ومنطقتك الزمنية

- رقم الإصدار المعروض حاليًا

- في أي خطوة بدأ يعرض "Building" أو أصبح الزر معطلاً

1. تحقق مما إذا كانت الصورة مفقودة في عارض التطبيقات أو على الموقع المنشور أو في كلا المكانين.
2. حدد Reload App Viewer مرة واحدة. إذا كانت المشكلة على الموقع المباشر فقط، فتأكد من نشر أحدث إصدار أو تحديثه.
3. أخبر Agent بالصفحة والصورة التي يجب أن تظهر ومن أين جاءت الصورة أصلًا. واطلب منه التحقق من أن المشروع الحالي لا يزال يستخدم اسم الصورة الصحيح وموقعها الصحيح.
4. إذا تمت إزالة الصورة الأصلية أو إعادة تسميتها، فقم بتحميل الصورة المقصودة أو تحديدها مرة أخرى، ثم أعد اختبار الصفحة.
5. إذا كانت الصورة تستخدم تخزين التطبيق أو خدمة متصلة أخرى، فتأكد من أن الخدمة المقصودة متصلة وأن الملف لا يزال موجودًا هناك.

إذا كانت الصورة لا تزال لا تُحمّل، فاتصل بـ Atoms Support مع Chat Link وعنوان URL للصفحة المتأثرة واسم الصورة أو مصدرها ولقطة شاشة. لا تضمّن روابط وصول خاصة أو كلمات مرور أو مفاتيح أو tokens.

إذا تم تنزيل حزمة الاستضافة الذاتية المصدّرة بنجاح لكنها فشلت في التشغيل:

1. تحقق من README المضمّن في حزمة التصدير لمعرفة متطلبات البيئة وخطوات الإعداد.

2. تحقق من أن بيئة التشغيل لديك تطابق المتطلبات (إصدار نظام التشغيل، وإصدار Docker، وإصدار Node.js).

3. شغّل أمر بدء التشغيل وراجع المخرجات الكاملة بحثًا عن رسائل الخطأ.

إذا استمرت المشكلة، فاتصل بـ Support وضمّن:

- إصدار التصدير ووقت التنزيل

- نظام التشغيل المستخدم وإصدار Docker

- الأمر الكامل الذي تم تنفيذه والمخرجات الكاملة

- السكربت أو مسار API الذي فشل

- طريقة النشر المتوقعة

مهم: أرفق مثال إعدادات منقحًا، لكن لا تضمّن كلمات مرور أو أسرارًا أو tokens.

يعرض عارض التطبيقات والموقع المنشور مرحلتين مختلفتين من مشروعك. حفظ تغيير مرئي لا يحدّث الموقع المباشر تلقائيًا.

1. في Design، حدد Save وانتظر حتى تنتهي مهمة Agent الحالية أو عملية البناء.
2. افتح Publish. يستخدم النشر أحدث إصدار من المشروع؛ ولا يوجد محدد إصدار في لوحة Publish.
3. حدد Publish للإصدار الأول أو Update لإصدار لاحق. انتظر حتى تعرض اللوحة Up to date.
4. افتح الموقع المباشر في علامة تبويب جديدة وأعد تحميله مرة واحدة.
5. إذا كان عنوان Atoms الافتراضي يعرض التغيير لكن النطاق المخصص لا يعرضه، فتحقق من اتصال النطاق بدلًا من نشر الإصدار نفسه بشكل متكرر.

إذا كان الموقع المباشر لا يزال يعرض الإصدار الخاطئ، فاتصل بـ Atoms Support مع Chat Link وعنوان URL المباشر والإصدار الذي كنت تنوي نشره والوقت والمنطقة الزمنية ولقطات شاشة من عارض التطبيقات والموقع المباشر.

1. احتوِ المخاطر الفورية. إذا كان الإصدار يكشف بيانات حساسة أو ينشئ سلوكًا غير آمن، فافتح App Status واستخدم Pause لتطبيق مؤهل من سحابة Atoms أو Unpublish لإزالة الوصول العام. إذا لم تكن هناك مخاطر نشطة، فتجنب التسبب في انقطاع غير ضروري.
2. سجّل النطاق المتأثر ووقت النشر والإصدار الحالي والإصدار المقصود والأثر التجاري.
3. بعد توقف مهمة الوكيل الحالية، افتح Versions، واختر آخر إصدار معروف بأنه جيد، وحدد Restore this version.
4. تحقق من الإصدار المستعاد في Preview، بما في ذلك تدفقات تسجيل الدخول والدفع والبيانات الحرجة، ثم قم بـ Publish أو Update له.

قد لا يؤدي استعادة إصدار مشروع إلى عكس تغييرات قاعدة بيانات الإنتاج أو الإجراءات الخارجية. لا تستبدل بيانات الإنتاج أو تحذفها لمحاكاة التراجع. اتصل بـ Support فورًا عندما تكون البيانات أو بيانات الاعتماد أو المدفوعات أو التغييرات المدمرة متضمنة.

1. أوقف مهمة الوكيل الحالية أو انتظرها؛ لا يمكن استعادة إصدار أثناء وجود عمل متعارض نشط.
2. افتح Versions، وحدد آخر إصدار معروف بأنه جيد، ثم حدد Restore this version.
3. راجع المشروع المستعاد في Preview واختبر التدفقات الحرجة التي تغيّرت.
4. قم بـ Publish أو Update فقط بعد أن تكون نتيجة Preview صحيحة.

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

Pause وUnpublish إجراءان مختلفان:

Pause (لمشاريع سحابة Atoms فقط):

- يصبح التطبيق غير متاح للزوار.

- تبقى موارد الخادم مخصصة وتستمر الفوترة.

- يمكنك استئناف التطبيق في أي وقت من App Status.

Unpublish (جميع المشاريع):

- يتوقف الموقع الإلكتروني بالكامل عن العمل. يفقد أي شخص يستخدم عنوان URL المنشور إمكانية الوصول.

- بالنسبة إلى مشاريع سحابة Atoms، يتم تحرير موارد الخادم.

- يمكنك نشر المشروع مرة أخرى لاحقًا، لكن لا يمكن للزوار الوصول إليه حتى تفعل ذلك.

استخدم Pause للإزالة المؤقتة مع إعادة تشغيل سريعة. واستخدم Unpublish لإزالة الموقع بالكامل.

إذا كان المتصفح يعرض "too many redirects" أو كانت الصفحة تستمر في إعادة التحميل دون عرض المحتوى:

1. جرّب النطاق الفرعي Prod الافتراضي للمنصة (وليس نطاقك المخصص) لتحديد ما إذا كانت حلقة إعادة التوجيه ناتجة عن إعداد النطاق أو عن التطبيق نفسه.
2. إذا كان النطاق الفرعي Prod الافتراضي يعمل، فتحقق من إعدادات DNS لنطاقك المخصص ومن مسجل النطاق لديك بحثًا عن قواعد إعادة توجيه قد تتعارض مع المنصة.
3. امسح ذاكرة التخزين المؤقت للمتصفح أو اختبر في نافذة التصفح الخفي لاستبعاد عمليات إعادة التوجيه المخزنة مؤقتًا.

إذا استمرت المشكلة، فاتصل بـ Support وضمّن:

- عنوان URL الكامل الذي يعرض حلقة إعادة التوجيه

- ما إذا كان النطاق الفرعي Prod الافتراضي يمكن الوصول إليه

- اسم النطاق وموفر DNS

- لقطة شاشة كاملة للخطأ

إذا كان تطبيقك يعمل في Preview لكنه يفشل في الإنتاج بسبب متغيرات بيئة مفقودة أو فارغة:

1. تحقق مما إذا كان متغير البيئة قد تم حفظه قبل آخر عملية نشر أو بعدها. إذا تم حفظه بعدها، فستحتاج إلى النشر مرة أخرى حتى يسري التغيير.
2. تحقق من أن المتغير مضبوط للبيئة الصحيحة (Development مقابل Production).
3. تحقق مما إذا كانت رسالة الخطأ من الخدمة التابعة تعطي دلالة — على سبيل المثال، غالبًا ما تعني "unauthorized" أن مفتاح API فارغ أو غير صحيح في تلك البيئة.

إذا استمرت المشكلة، فاتصل بـ Support وضمّن:

- رابط المشروع أو عنوان URL المباشر

- اسم المفتاح المتأثر وأي بيئة بها المشكلة

- الخطأ الكامل من الخدمة التابعة

- لقطة شاشة منقحة لصفحة الإعدادات

- ما إذا كان الإعداد قد تم حفظه قبل النشر أو بعده

مهم: قدّم أسماء المفاتيح فقط. لا ترسل القيم السرية أو كلمات المرور أو tokens.

قد تستخدم النتائج صياغة متشابهة مع الإشارة إلى مواقع مختلفة. ولا تعني الصياغة المتشابهة بالضرورة أن النتائج مكررة.

1. قارن اسم النتيجة والموقع المعروض لكل نتيجة.
2. راجع كل موقع فريد بدلًا من تجاهل الصياغة المتكررة.
3. إذا كانت عدة نتائج لها السبب الجذري نفسه، فأصلح ذلك السبب ثم تحقق من كل موقع مرة أخرى.
4. شغّل فحص الأمان مرة أخرى على الإصدار المحدّث.

إذا كانت النتيجة نفسها والموقع نفسه لا يزالان يظهران أكثر من مرة، فاتصل بـ Atoms Support مع Chat Link ووقت الفحص والمنطقة الزمنية وعدد النتائج ولقطة شاشة منقحة. أزل أي كلمات مرور أو مفاتيح أو tokens أو أي معلومات حساسة أخرى قد تظهر في نتيجة ما.

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

قبل النشر، اختبر الرحلات المهمة في تطبيقك، بما في ذلك تسجيل الدخول وأدوار المستخدمين والوصول إلى البيانات الخاصة والمدفوعات والخدمات المتصلة. استخدم حسابات اختبار منفصلة للأدوار المختلفة وتأكد من أن كل حساب يمكنه الوصول فقط إلى المعلومات والإجراءات المقصودة له.

إذا اكتشفت مشكلة في الإنتاج قد تكشف الحسابات أو البيانات الخاصة أو المدفوعات أو بيانات الاعتماد، فأوقف استخدام الميزة المتأثرة أو قيّد الوصول إليها أولًا. قم بتدوير أي بيانات اعتماد قد تكون انكشفت، ثم اتصل بـ Atoms Support مع Chat Link والإصدار المتأثر وخطوات إعادة إنتاج المشكلة والوقت والمنطقة الزمنية ولقطة شاشة منقحة. لا تشارك بيانات الاعتماد المكشوفة نفسها.

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

1. افتح النتيجة وحدد الإجراء أو الموقع الذي تسميه.
2. حدد الأدوار المسجلة الدخول التي يجب أن يُسمح لها باستخدام ذلك الإجراء.
3. اطلب من Agent التحقق من إذن المستخدم عند طلب الإجراء، وليس فقط عند عرض الزر.
4. اختبر الإجراء أثناء تسجيل الخروج، ومع حساب اختبار عادي، ومع حساب اختبار مشرف مصرح له.
5. أكد أن المحاولات المرفوضة لا تكشف أي بيانات خاصة ولا تُحدث أي تغييرات، ثم شغّل فحص الأمان مرة أخرى.

لا تنشر الميزة المتأثرة إذا كان لا يزال بإمكان حساب غير مصرح له استخدام الإجراء. اتصل بـ Atoms Support مع Chat Link ونص النتيجة والإصدار المتأثر ولقطة شاشة منقحة إذا لم تتمكن من حلها.

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

1. افتح النتيجة ولاحظ الموقع والعنوان الدقيقين اللذين يبلّغ عنهما.
2. اطلب من Agent استبدال ذلك الاتصال المحدد بالعنوان الآمن الذي يدعمه مزوّده، أو تصحيح إعداد النطاق ذي الصلة.
3. لا تتجاهل تحذيرات الشهادة ولا تغيّر عنوانًا بشكل أعمى إذا كانت الخدمة الخارجية لا توثق بديلاً آمنًا مكافئًا.
4. أعد اختبار رحلة المستخدم المتأثرة وتأكد من عدم إرسال أي كلمة مرور أو Token أو تفاصيل دفع أو معلومات خاصة عبر اتصال غير آمن.
5. شغّل فحص الأمان مرة أخرى على الإصدار المحدّث.

إذا كانت النتيجة تتعلق بنطاق مخصص أو شهادة لا يمكنك تصحيحها، فاتصل بـ Atoms Support مع Chat Link وعنوان URL المتأثر ونص النتيجة والوقت والمنطقة الزمنية ولقطة شاشة منقحة.

Row Level Security أو RLS هي ميزة في Supabase تتحكم في صفوف قاعدة البيانات التي يمكن لكل مستخدم قراءتها أو تغييرها. تكون هذه النتيجة ذات صلة فقط عندما يستخدم المشروع Supabase ويحدد الفحص جدولًا تحتاج قواعد الوصول الخاصة به إلى مراجعة.

1. افتح النتيجة وحدد الجدول الذي تسميه.
2. دوّن من يجب أن يكون قادرًا على عرض بيانات ذلك الجدول أو إضافتها أو تعديلها أو حذفها.
3. اطلب من Agent إنشاء أقل سياسات Supabase سماحًا التي تدعم رحلات المستخدم تلك.
4. اختبر أثناء تسجيل الخروج ومع حساب اختبار منفصل لكل دور. أكد أن كل حساب يمكنه الوصول فقط إلى الصفوف والإجراءات المقصودة.
5. شغّل فحص الأمان مرة أخرى بعد تطبيق السياسات.

لا تقم بتعطيل RLS أو السماح لكل مستخدم فقط لإزالة التحذير. قبل إجراء تغيير قد يؤثر في البيانات الحالية، أكد الخطة واحتفظ بنسخة احتياطية آمنة أو تصدير آمن عند الاقتضاء. لا تشارك أبدًا مفاتيح Supabase أو بيانات اعتماد قاعدة البيانات في Chat أو لقطات الشاشة.