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