إدارة استثناءات الشحن: سجل بناء Shipment Exception Commander

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

Shipment Exception Commander هو تطبيق مرجعي مفتوح المصدر مبني على Claude Managed Agents لمعالجة نقطة القرار هذه. يفحص حالة استثناء اصطناعية واحدة، ويحسب درجات جميع خيارات المعالجة آلياً، ويفوّض مراجعة مستقلة للمخاطر، ثم يعرض الإجراء المحدد على شخص للموافقة. وبعد الموافقة المدمجة، لا يسمح إلا بعملية تغيير واحدة داخل البيئة المعزولة، من دون تكرار أثرها.

إدارة استثناءات الشحن تبدأ بتقييم حتمي قبل حكم النموذج

لا يبتكر المنسق أسعاراً، ولا يحوّل النصوص الوصفية إلى سياسة. تتيح أداة shipment_intelligence للقراءة فقط، وتعمل من جهة الخادم، ثلاث حالات اصطناعية وتحسب درجة كل خيار وفق معادلة ثابتة: 50 نقطة للوفاء بالموعد الموعود، و20 لتغطية المخزون، و20 لكفاءة التكلفة قياساً إلى السقف المطلق، و10 للثقة. ويحمل كل خيار إصدار عرض السعر، ووقت انتهاء صلاحيته، وموعد الوصول المتوقع، وعدد الوحدات المحمية، والتكلفة الإضافية بالدولار الأمريكي.

قارنت حالة الإثبات الرئيسية، SCX-2026-071، بين ثلاثة أنماط فعلية للقرار: معالجة منخفضة التكلفة بالشحن البحري لكنها تفوّت الموعد، وشحن جوي كامل يتجاوز سقف الإنفاق المطلق، وتسريع جوي مجزأ يحمي جميع الوحدات الملتزم بها، وعددها 240 وحدة، مقابل $4,200. حصل الخيار المجزأ على 91 نقطة وظل ضمن حد المشغّل البالغ $5,000. تجعل الدرجة التوصية قابلة لإعادة الإنتاج؛ أما مهمة Claude فهي جمع الأدلة، واختبار الافتراضات، وشرح المفاضلة.

الأدلة غير الموثوقة لا تمنح صلاحية التنفيذ

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

ولا يملك المنسق ذاكرة قابلة للكتابة عبر الجلسات، أو خزنة، أو تكاملاً مع MCP، أو اتصالاً صادراً بالشبكة. تمثل read وglob وgrep الاستثناءات المحدودة التي تحظى بالموافقة التلقائية. أما Bash وكتابة المخرجات المطلوبة فمضبوطان على always_ask، بينما يظل التحرير وجلب الويب والبحث فيه معطلاً. ولا يحدث تغيير الحالة المرجعي الوحيد إلا عبر أمر execute في المهايئ.

مدقّق مستقل يختبر التوصية

قبل طلب تنفيذ أي إجراء، يكلّف منسق Opus مدقّق Haiku محدود الصلاحيات بمراجعة خيار المعالجة المقترح. وفي تشغيل الإثبات، أعاد المدقّق النتيجة NEEDS_CHANGES لأنه لم يستطع الجزم بأن عرض السعر Q-071-v4 لا يزال سارياً، أو بأن السعة والرسوم الإضافية نهائية. لم يتجاهل المنسق هذا الاعتراض؛ بل استدعى مدقّق المقترح الحتمي، الذي أعاد فحص الساعة الاصطناعية، وانتهاء صلاحية عرض السعر، وإصدار السياسة، ومستوى الإنفاق، وإصدار الحالة المتوقع. وحدها النتيجة المرجعية ready_for_human_approval نقلت الحالة الصافية إلى الجاهزية.

بعد ذلك، عرض موجز الموافقة معرّفي الحالة والخيار، والإنفاق الدقيق البالغ $4,200، وموعدي الوصول القديم والجديد، والأثر في الموعد الموعود للعميل، و240 وحدة محمية، ووقت انتهاء عرض السعر، وإصداري السياسة والحالة، والدرجة، وسجل المدقّق، والبدائل المرفوضة، ومفتاحاً ثابتاً لمنع تكرار الأثر، وحقول الإيصال المتوقعة، وسلوك النظام عند الرفض أو الفشل.

الرفض يعني عدم تغيير الحالة

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

وبناءً على طلب صريح من المشغّل، عُرض الإجراء المرجعي نفسه مرة أخرى، وهذه المرة جرت الموافقة عليه. عند حدود التغيير، أعاد المهايئ التحقق من إصدار الحالة 3، وسريان عرض السعر، والسياسة، ومستوى الموافقة، والسقف المطلق البالغ $10,000. نفّذ الإجراء مرة واحدة فقط، ونقل الحالة من detected بالإصدار 3 إلى resolved بالإصدار 4، ثم أعاد الإيصال rcpt_37105a2da411aee0391c مع مرجع الحجز SBX-56DFC3291972.

تنفيذ آمن من التكرار بنطاق معلن بوضوح

يحتفظ المهايئ الاصطناعي بالمفتاح الثابت SCX-2026-071:OPT-071-B:v3، وقفل على مستوى نظام التشغيل، وآلية لفحص الحالة المرجعية، وسجل للإيصالات. تعيد الاستدعاءات المكررة ذات القصد نفسه الإيصال الموجود؛ ويفشل أي قصد متعارض يستخدم المفتاح ذاته؛ أما الإصدارات القديمة، والتنفيذ المتزامن، واحتمال الكتابة الجزئية، فتتطلب الفحص بدلاً من إعادة المحاولة عشوائياً.

وقد وُصفت هذه الضمانات عن قصد ضمن حدودها الفعلية: فالقفل والحالة وسجل الإيصالات ملفات محلية للجلسة داخل بيئة Managed Agents معزولة واحدة، ولا تشكل ضماناً إنتاجياً موزعاً. سيحتاج مهايئ حقيقي لناقل أو لنظام TMS إلى مخزن معاملات مشترك، وإلى حد لمنع تكرار الأثر لدى النظام التالي في السلسلة.

مقيّم النتائج راجع الأدلة

أنشأت الجلسة ثلاث مخرجات داخل /mnt/session/outputs/: حزمة معالجة مقروءة للبشر، وسجل تدقيق منظم، وإيصال التنفيذ الخام. وقارنت نتيجة مستقلة في Managed Agents هذه الملفات بالكتالوج، ومصدر المهايئ، والحالة المرجعية، وسجل الموافقات، وسجل الإيصالات. وطلبت تعديلات لإظهار انتهاء صلاحية عرض السعر، وتوضيح سلوك الفشل، وإضافة قائمة بالمخرجات، وبيان قيد النطاق المحلي للجلسة، قبل أن تعيد satisfied.

بعد ذلك، نُزّلت حزمة المعالجة عبر وسيط ملفات التطبيق. قيمة SHA-256 الخاصة بها هي 30c8ad1d0d13cf7ad4b7070e67370ea270562c5e4ef44dfa503e3124180bd40b. جلسة الإمكانات هي sesn_01CcQjCVoWvNQ7VJLFbuDJxh، والنتيجة هي outc_01GoD4rsLMh93iQNfAUw63KW.

كشف تشغيل النتيجة الحي أيضاً عن فجوة في واجهة المستخدم: يمكن للخيوط الفرعية التابعة للمقيّم طلب الموافقة بينما تظل الجلسة الأم في وضع الخمول. يعيد الإصدار الآن بناء بطاقات الموافقة المعلّقة من أحداث requires_action في الخيط الأم، ومن أحداث evaluated_permission: ask في الخيوط الفرعية. كما يسحبها عند ورود التأكيد أو النتيجة، ويمنع إعادة التشغيل من إحياء المطالبات المحسومة. ويرسل أيضاً session_thread_id الخاص بالمقيّم عبر قائمة سماح محدودة في المتصفح، ويتحقق الخادم من ذلك المسار بمقارنته مع حدث الأداة الأصلي نفسه قبل تمرير القرار.

اختبرت جلسة إثبات منفصلة ومهيأة باستخدام Sonnet، وهي sesn_01BvSf33BLBbN86w5oDb3BkQ، ذلك المسار المصحح. حملت أداة المقيّم المنشورة عبر الخيوط sevt_013VnmofY8ytk6QwgDtNSYoq الخيط sthr_018HMgpidoN86Qp4iGLZt1q3؛ وأنشأت واجهة المستخدم التأكيد sevt_016ZFv5TdBPKNyEPThzGT36Q بالمعرّفين نفسيهما للأداة والخيط، فقبله الخادم، واستأنف المقيّم عمله ليطلب فحصه التالي. بعد ذلك أُوقِف الإثبات المحدود عمداً لتجنب دفع تكلفة تكرارات إضافية غير ذات صلة؛ أما نتيجة الشحنة الرئيسية فظلت satisfied.

Opus للتشغيل الرئيسي وSonnet للتحقق وHaiku للتدقيق

يظل المنسق المجهّز هو claude-opus-5. ولخفض تكلفة التحقق المدفوع القابل للتكرار، تستطيع الجلسات المحلية أن تستبدل نموذج المنسق وحده صراحةً بـclaude-sonnet-5؛ وتفشل أي محاولة أخرى لتجاوز إعدادات وقت التشغيل بصورة مغلقة وآمنة. ويستخدم المدقّق المستقل claude-haiku-4-5. أما جلسة اختبار الدخان المدفوعة sesn_01RTs3wLV41odV9p92eWtrHV، فاستخدمت Sonnet وأعادت الاستجابة الدقيقة SMOKE OK.

تظل مجموعة اختبارات الإنتاج معزولة عمداً عن بيانات الاعتماد، حتى عندما يكون لدى المطوّر ملف .env.local مهيأ. وهي تثبت أن أي نشر جديد لا يعرض حقلاً لمفتاح المتصفح، ولا يرسل أي حركة مرور إلى Anthropic، ويبلغ عن configured: false، ويعيد 503 من مسارات الفوترة.

مرجع عام يفشل بصورة مغلقة وآمنة

لا يتضمن مرجع Vercel العام أي مفتاح لـAnthropic أو معرّفات موارد Managed Agents. تظل صفحة البداية و/api/agent/health متاحتين، بينما يفشل إنشاء الجلسات بصورة مغلقة وآمنة. يجهّز المستخدمون الوكيل وبيئته عبر حساباتهم الخاصة لدى Anthropic؛ ويجب حماية الوصول إلى أي نسخة مهيأة قبل إتاحتها لمستخدمين آخرين.

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

أدلة الإصدار

• المستودع: dvnc-labs/shipment-exception-commander
• الإصدار: v0.1.0
• التكامل المستمر: تشغيل إصدار ناجح
• الالتزام: 1db0329
• النشر: shipment-exception-commander.vercel.app
• السلامة: حالة الوكيل المغلقة والآمنة

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