رسم توضيحي أصلي للموضوع: رسم أصلي للموضوع من ChainView BTC866 · ChainView BTC866 Editorial · CC BY 4.0
اقرأ نطاق البرنامج
وجود برنامج مكافآت لا يعني أن كل العقود والواجهات فُحصت. تحقق من النطاق والعناوين والمستودعات والاستثناءات ومدة البرنامج. اعرف أنواع الأخطاء المقبولة والبيئات المشمولة. الحد الأقصى للمكافأة ليس مبلغاً مدفوعاً ولا مقياساً للأمان. قد يقتصر البرنامج على شبكة اختبار. افصل في الخبر بين وجود البرنامج وعدد المشكلات التي لم يُعلن عنها.
استخدم مسار الإفصاح الآمن
اتبع قناة البلاغ الرسمية وحدود الاختبار. البرنامج ليس ترخيصاً للمس بأموال الآخرين أو بياناتهم. أرسل أقل دليل لازم واتفق على توقيت الإفصاح المسؤول. لا تنشر مفتاحاً أو تفاصيل قابلة للاستغلال. عنوان دفع في رسالة شخصية ليس دليلاً على الجهة الرسمية. عند الكتابة، ركز على الأثر المؤكد وما يحتاجه المستخدم بدلاً من وصف هجومي كامل.
اربط الكود بالتشغيل
دمج التصحيح في المستودع لا يعني أنه وصل إلى الإصدار العامل أو العقد الإنتاجي. راجع رقم الالتزام والإصدار وعنوان التنفيذ ومعاملة الترقية. في العقود القابلة للترقية، افحص عنوان التنفيذ وصلاحيات الإدارة. تحديث البرنامج لا يلغي مفتاحاً مسرباً ولا يعيد أموالاً سُرقت. الإصلاح وسحب الصلاحيات وتعويض الضرر حالات مستقلة ينبغي عدم خلطها.
اعرض الجدول الزمني
سجّل الاستلام والتحقق والإصلاح والنشر والإعلان العام. افصل رواية الباحث عن تأكيد المشغّل. إن وُجد فحص مستقل، اذكر نسخته وحدوده. حالة «مقترح» ليست «منشوراً»، والنشر لا يحدّث أجهزة المستخدم كلها. اترك رابط المتابعة وما بقي مجهولاً. مسار يمكن التحقق منه أكثر فائدة من رقم مكافأة كبير في العنوان.
حالات الإصلاح في مثال
قد يقترح المطور تصحيحاً يبقى قيد المراجعة، ثم يدخل الإصدار دون أن تنشره بيئة التشغيل بعد. سجّل الاقتراح والدمج والنشر وتطبيق المستخدم منفصلة. هذا لا يقلل قيمة العمل التقني بل يوضح متى بدأت الحماية ولمن بقي إجراء مطلوب.
