صمّم موافقة على إجراء محدد

حوّل الخطر إلى قاعدة موافقة

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

سياسة مدار التدريبية تسمح بقراءة الحالة للمستخدم المخول، وتجهيز مسودة بلا إرسال. إرسال عرض حتى 1000 يحتاج مشرف تشغيل، وأكثر من 1000 يحتاج المشرف ثم المدير المالي.

دي سياسة خيالية للتدريب، وليست قاعدة قانونية أو سعرًا حقيقيًا. في مشروع العميل تؤخذ الحدود من صاحب السياسة وتوثق نسختها.

قيمة 1000 تقع في مسار حتى 1000، أما 1000.01 في المسار الأعلى. اختبار الحد مهم لأنه يكشف خطأ أكبر من الفرق العددي الصغير.

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

مثال محلول
سياسة v1:عرض حتى 1000→مشرف؛ أكثر من 1000→مشرف ثم مدير مالي؛ المبلغ بالجنيه التدريبي.

الطلب
وجّه عرضين 1000 و 1000.01 وفق حد السياسة.

المخرج
1000→مشرف التشغيل.1000.01→مشرف التشغيل ثم المدير المالي. لا إرسال قبل استيفاء السلسلة.

لماذا؟
حد حتى يشمل 1000.
فوق 1000 يتطلب موافقتين متتابعتين.
السياسة معطاة للتدريب فقط.

اعرض بطاقة قرار تكشف الأثر

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

بطاقة العرض Q17 تحتوي العميل التدريبي C7 والمبلغ 900 ونسخة المحتوى 2 والفعل send_quote. نعرض نص العرض ومصدر المبلغ والجهة المستلمة قبل الزر.

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

أي حقل ناقص يؤثر في الوجهة أو القيمة يوقف الاعتماد التنفيذي. زر الموافقة لا يعالج نقصًا لم يره المراجع؛ النظام يفحصه أيضًا.

المثال ينتج بطاقة قابلة للمراجعة؛ لا يرسل العرض فعلًا. الإرسال اللاحق يحتاج موافقة سارية ومطابقة للمحتوى والوجهة ثم إيصالًا.

مثال محلول
Q17؛ C7؛ 900؛ revision2؛ action=send_quote؛ بريد العميل غير محدد.

الطلب
اكتب بطاقة قرار وحدد هل الاعتماد التنفيذي متاح.

المخرج
عرض Q17 للعميل C7 بقيمة 900، نسخة 2. الوجهة غير محددة؛ يمكن مراجعة الصياغة لكن الإرسال موقوف حتى تأكيد الوجهة وإعادة عرض البطاقة.

لماذا؟
الفعل محدد بوضوح.
الوجهة جزء من الأثر المعتمد.
مراجعة النص غير اعتماد الإرسال.

افرض الأدوار من هوية موثقة

الموافقة تحتاج شخصًا مخولًا، وليس اسمًا مكتوبًا داخل الطلب. الجلسة أو نظام الهوية يحدد من ضغط، والخادم يقارن دوره بالسياسة.

في السيناريو N1 جهز العرض، و S1 مشرف، و F1 مدير مالي. لو السياسة تفصل طالب الإجراء عن معتمده، N1 لا يوافق لنفسه حتى لو غير النص المرسل إلى role=supervisor.

الدور وحده قد لا يكفي؛ نطاق الفرع أو الشركة مهم أيضًا. مشرف T2 لا يعتمد عرض T1 إلا بتفويض موثق يسمح بذلك.

نسجل هوية صاحب القرار ودوره والسياسة ووقت القرار والنسخة المعتمدة. لا نعتمد على توقيع نصي يستطيع أي مستخدم تغييره.

الاختبار يتضمن مستخدمًا صحيحًا وآخر ينتحل دورًا في الجسم. المتوقع أن الخادم يرفض الادعاء ويستخدم الهوية الموثقة فقط.

مثال محلول
N1 طالب الإجراء؛ S1 مشرف T1؛ S2 مشرف T2. السياسة تمنع الموافقة الذاتية والخروج عن النطاق.

الطلب
حدد من يمكنه يعتمد Q17 ضمن T1.

المخرج
S1 مسموح وفق نطاقه. N1 مرفوض للموافقة الذاتية. S2 مرفوض لخروجه عن النطاق. الدور من الجلسة وليس body.

لماذا؟
فصل الأدوار مفروض بالسياسة.
النطاق جزء من التفويض.
حقل الدور الوارد غير موثوق.

تعامل مع الرفض والانتهاء والتعديل

الموافقة حالة لها دورة حياة:مطلوبة، مقبولة، مرفوضة، منتهية أو ملغاة بسبب تعديل. لا نحول الرفض إلى قبول بمجرد انتظار وقت أطول.

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

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

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

المثال يستخدم أوقاتًا صريحة بتوقيت UTC لتجنب التباس المناطق الزمنية. واجهة العرض ممكن تحولها للتوقيت المحلي مع الحفاظ على القيمة الأصلية.

مثال محلول
موافقة صدرت 2026-10-05T10:00Z؛ صلاحيتها 24 ساعة؛ محاولة تنفيذ 2026-10-06T10:01Z.

الطلب
حدد صلاحية الموافقة والإجراء التالي.

المخرج
انتهت في 2026-10-06T10:00Z. التنفيذ بعدها بدقيقة مرفوض؛ نطلب اعتمادًا جديدًا ونحتفظ بقرار السابق.

لماذا؟
الانتهاء محسوب من وقت الإصدار.
دقيقة واحدة بعد الحد تكفي للانتهاء.
القرار القديم لم يُحذف.

اربط الموافقات المتتابعة بمحتوى واحد

في سلسلة موافقات، كل شخص يجب أن يرى نفس النسخة التي سينفذها النظام. لو المشرف اعتمد 900 ثم تغيرت القيمة 1200، السلسلة القديمة لا تنطبق.

العرض Q18 بقيمة 1200 يمر بالمشرف ثم المدير المالي حسب السياسة. رفض الأول يوقف السلسلة، وقبول الثاني قبل الأول لا يحقق الترتيب المطلوب.

نربط القرارات برقم العرض ونسخة المحتوى وبصمته وبنسخة السياسة. عندما يتغير أي عنصر مؤثر نعيد حساب المطلوب بدل تجميع أختام قديمة.

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

الاختبار يسجل ترتيب القرار ونسخته. نجاح الواجهة في عرض علامتي صح لا يكفي إذا كانتا لنسختين مختلفتين.

مثال محلول
Q18v2 بقيمة 1200؛ المشرف وافق v2؛ المدير المالي وافق v1 القديمة.

الطلب
هل السلسلة مكتملة؟ حدد المطلوب.

المخرج
غير مكتملة؛ موافقة المدير المالي لنسخة 1 لا تغطي 2. يلزم قراره على v2 بعد موافقة المشرف عليها؛ لا إرسال.

لماذا؟
الأختام ليست مستقلة عن المحتوى.
الترتيب جزء من السياسة.
عدد الموافقات لا يكفي دون تطابق النسخة.

اختبر الموافقة كحاجز تنفيذي

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

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

الحالة الخامسة تسمح بالمحاولة، لكنها لا تثبت نجاح الإرسال. بعد السماح نحتاج إيصالًا من الموصل، ونحفظ unknown إذا انقطع الرد.

نسجل سبب الرفض بدقة كي يستطيع المسؤول إصلاحه دون توسيع الصلاحيات. كلمة ممنوع عامة قد تجعل الفريق يلغي الحماية بدل فهمها.

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

مثال محلول
خمس حالات:بلا اعتماد؛ منتهي؛ نسخة مختلفة؛ دور خاطئ؛ اعتماد مطابق ساري.

الطلب
حدد الأثر المسموح ودليل النجاح لكل حالة.

المخرج
الأربع الأولى:منع وصفر أثر. الخامسة:يسمح بمحاولة الإرسال؛ النجاح الفعلي يحتاج إيصالًا. إذا الرد مجهول→unknown واستعلام.

لماذا؟
الحاجز يمنع قبل الأثر.
السماح غير نتيجة التنفيذ.
المهلة تظل ملتبسة حتى بعد موافقة صحيحة.