المعاملات والعمليات

المعاملات هي الوحدة الذرية للتغيير في Asset Core. تحتوي كل معاملة على سلسلة من العمليات التي يتم تنفيذها معًا أو لا يتم تنفيذها على الإطلاق. هذا هو العقد الأساسي الذي يجعل Asset Core حتميًا وقابلًا للتدقيق.

المشكلة التي يحلها هذا المفهوم

تتطلب تغييرات الحالة المعقدة غالبًا تحديثات منسقة متعددة. بدون الذرية، تنحرف الأنظمة لأن التغييرات الجزئية تُعتمد ولم تعد تتطابق مع الحالة المقصودة.

إنشاء حاوية وملؤها
نقل الأصول بين المواقع
إضافة مثيل ووضعه

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

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

الأفكار الأساسية

هيكل الالتزام

طلب الالتزام يحتوي على قائمة من العمليات. الغلاف موحد عمداً حتى يمكن التحقق منه وإعادة تشغيله وتدقيقه بطريقة متسقة عبر جميع المجالات.

{
  "actor_id": "lab-operator-17",
  "operations": [
    { "op": "CreateContainer", "args": { ... } },
    { "op": "AddFungible", "args": { ... } }
  ],
  "idempotency_key": "optional-unique-key",
  "metadata": { "experiment": "phase-1" }
}

تتم تنفيذ العمليات بالترتيب داخل المعاملة. إذا فشلت أي عملية، يتم التراجع عن الالتزام بالكامل.

عملية الظرف

كل عملية لها نفس هيكل الظرف:

{
  "op": "OperationName",
  "args": { ... }
}

op: معرف العملية (على سبيل المثال، CreateContainer)
args: معلمات محددة للعملية

هذا الهيكل الموحد يجعل العمليات سهلة التركيب والمعالجة برمجياً.

العمليات الـ 24

تعرف Asset Core بالضبط 24 عملية عبر 5 مجالات. هذه المفردات الصغيرة المغلقة هي ما يجعل تنفيذ السياسات الآلي والتدقيق ممكنًا.

المجال	العمليات
الحاوية	CreateContainer, RemoveContainer
الرصيد	AddFungible, RemoveFungible, MoveFungible, TransferFungible, TransferMany, Distribute, MoveMany, MergeStacks, ConsolidateStacks
النسخة	AddInstance, MoveInstance, RemoveInstance, BurnInstance, Attach, Detach
الفتحة	PlaceInSlot, RemoveFromSlot, SwapSlots
المخطط	RegisterClass, RegisterClassShape, RegisterClassContinuousShape1d, RegisterClassContinuousShape2d

لماذا بالضبط 24؟ لأن هذه هي المجموعة الأدنى التي تغطي مساحة العمليات لأنظمة الحالة المكانية دون فقدان التعبيرية.

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

تعتبر هذه المفردات المغلقة أيضًا حاسمة للحكم. تعني واجهة برمجة التطبيقات غير المحدودة (SQL تعسفي، برمجة نصية عامة) أن المتصلين يمكنهم إجراء عمليات لم تتوقعها ولا يمكنك تدقيقها. تعني مجموعة العمليات الثابتة أنه يمكنك:

القائمة البيضاء حسب النطاق: “يمكن لهذا الوكيل تعديل الأرصدة فقط، وليس الحالات”
قائمة العمليات المدمرة المحظورة: “يمكن لهذا العميل التحرك ولكن لا يمكنه الاحتراق”
تدقيق شامل: “أرني كل عملية قام بها هذا الفاعل”

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

تقدم هذه المجموعة الثابتة:

قابلية التدقيق: كل تغيير محتمل في الحالة معروف
السلامة: لا طفرات تعسفية
الاتساق: نفس العمليات تعمل عبر جميع البيئات

نظام العلامات

تُصنَّف العمليات عبر أربعة أبعاد. هذه التصنيف ليست بيانات وصفية للوثائق - إنها الأساس للحوكمة.

لماذا يوجد هذا: عندما تمنح متصلًا إذنًا للتلاعب بحالة AssetCore، تحتاج إلى تحكم دقيق. “يمكن تعديل أي شيء” واسع جدًا. القوائم الطويلة هشة وصعبة الصيانة. يوفر لك نظام العلامات تصفية دلالية: “يمكن إنشاء وتحريك الحالات، ولكن لا يمكن تدميرها” أو “يمكن فقط تعديل الأرصدة، وليس الحاويات.”

الأبعاد الأربعة:

النطاق: ما نوع الكيان المتأثر

container, balance, instance, slot, schema

الإجراء: ما نوع التغيير

create, destroy, move, link, consolidate

النطاق: عدد الكيانات

single, multi

الرجعية: هل يمكن التراجع عنها

قابل للعكس، تدميري، محايد

كيف يساعدك هذا:

أذونات الوكيل: القائمة البيضاء حسب النطاق + الإجراء. “يمكن لهذا الوكيل نقل الحالات ولكن لا يمكنه حرقها” = domain:instance, action:move, reversibility:reversible.
استعلامات التدقيق: “أرني جميع العمليات المدمرة في آخر 24 ساعة” = تصفية سجل الأحداث بواسطة reversibility:destructive.
توليد الأدوات: يتضمن بيان العمليات (ملف JSON) علامات. يمكنك إنشاء تعريفات أدوات الوكلاء برمجياً: “إنشاء أداة لكل عملية ذات نطاق فردي وقابلة للعكس.”

مثال: يستخدم كتالوج أدوات MCP هذه العلامات لتجميع العمليات في أسطح أدوات آمنة. يحصل الوكلاء على assetcore_move_instance (قابل للعكس، نطاق فردي) ولكن ليس assetcore_burn_instance (تدميري) ما لم يتم منحه صراحة.

التماثل

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

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

استخدم دائمًا مفاتيح الاستقلالية لأحمال الإنتاج.

كيف يتناسب مع النظام

تدفق التنفيذ

عميل يرسل طلب الالتزام
كتابة تحليل daemon والتحقق من صحته
يتم تنفيذ العمليات بالتسلسل (يحدث هنا التحقق من نوع الحاوية؛ انظر Containers and Assets)
يتم تسجيل الأحداث لكل عملية
يتم ختم الأحداث في دفعة
يتم إضافة الدفعة إلى سجل الالتزام الخلفي (انظر نموذج التشغيل)
يتلقى العميل استجابة ناجحة

التراجع عند الفشل

إذا فشلت أي عملية:

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

لا توجد التزامات جزئية مرئية للقراء.

توليد الأحداث

تولد كل عملية أحداثًا تتعلق بـ:

وصف تغيير الحالة
حمل حالة ما بعد لإعادة التشغيل
يتم تجميعها في دفعة المعاملة

الأحداث هي السجل المعتمد (تعتمد المتانة على الخلفية)؛ العمليات هي تنسيق الطلب.

المتغيرات الرئيسية والضمانات

الذرة

تنجح جميع العمليات في المعاملة أو تفشل معًا. هذه هي الضمانة التي تمنع فساد الحالة الجزئية.

بدون الذرية، فإن فشل في العملية 5 من 10 يترك العمليات 1-4 ملتزمة و6-10 غير منفذة. حالتك الآن غير متسقة داخليًا - حاوية تم إنشاؤها ولكن لم يتم ملؤها أبدًا، تحويل تم تنفيذه جزئيًا، مثيل تم نقله ولكن مرجع الوالد له قديم. يتطلب تصحيح الأخطاء إعادة بناء “ما كان يجب أن يحدث”، وهو ما يكون غالبًا مستحيلًا. يرى المستخدمون حالة فاسدة، وتفشل العمليات بشكل غير متوقع، ويتآكل الثقة.

يطبق AssetCore الذرية من خلال سجل التراجع (انظر نموذج التشغيل):

لا يوجد تنفيذ جزئي مرئي (الاستعلامات لا ترى أبداً الحالات الوسيطة)
استعادة التراجع تعيد الحالة السابقة بالضبط (إعادة تشغيل سجل التراجع بالعكس)
تستخدم استجابات الأخطاء تفاصيل المشكلة RFC 9457 مع رموز مستقرة (تخبرك بأي عملية فشلت ولماذا)

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

الحفاظ على الطلب

تُنفذ العمليات بالترتيب الذي تظهر به في المصفوفة. يبدو أن هذا واضح ولكن له تداعيات دقيقة على الصحة.

تظهر العمليات اللاحقة آثار العمليات السابقة ضمن نفس المعاملة. هذه هي الطريقة التي يمكنك من خلالها CreateContainer في العملية 1 و AddFungible إلى تلك الحاوية في العملية 2 - معرف الحاوية من نتيجة العملية 1 مرئي على الفور. بدون الحفاظ على ترتيب العمليات، ستحتاج إلى تقسيم هذه إلى معاملات منفصلة مع تنسيق يدوي.

يضمن AssetCore التنفيذ المتسلسل:

العمليات اللاحقة ترى آثار العمليات السابقة (تلبية الاعتماديات بالتسلسل)
يتم تلبية الاعتمادات بشكل متسلسل (لا يوجد تنفيذ متوازي ضمن معاملة)
لا إعادة ترتيب أو تحسين يغير المعاني (الوقت التشغيلي لا يعيد تنظيم الأداء)

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

الحتمية

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

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

يضمن AssetCore تنفيذًا حتميًا:

بالنظر إلى حالة وعمليات متطابقة (نفس حالة العالم، نفس مصفوفة العمليات)
ستكون الأحداث متطابقة بالبايت (نفس التسلسل، نفس الحمولة)
يمكّن من إعادة التشغيل والتحقق (إعادة بناء الحالة من السجل، إثبات ما حدث ومتى)

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

المفردات الثابتة

تعتبر العمليات الـ 24 هي المجموعة الكاملة. لا يمكنك تعريف عمليات مخصصة أو توسيع المفردات أثناء وقت التشغيل.

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

يطبق AssetCore مفردات ثابتة:

العمليات الـ 24 مكتملة (لا توجد عمليات مخصصة، لا تمديد وقت التشغيل)
التغييرات المعقدة تتكون من عمليات متعددة في معاملة واحدة (انظر الوصفات للأنماط الشائعة)
هذه القيود هي ميزة: تجعل الحوكمة ممكنة

ما تكسبه: مساحة تشغيل قابلة للتدقيق (اعرف كل نوع تغيير ممكن)، سلامة الوكيل (مفردات محدودة = لا مفاجآت)، دلالات متسقة عبر البيئات (نفس العمليات في كل مكان). ما تتخلى عنه: المرونة في تعريف العمليات الخاصة بالنطاق. إذا كان بعض السلوك لا يتطابق مباشرة، احتفظ بتلك المنطق خارج وقت التشغيل واستخدم Asset Core للانتقالات الحالة التي تتطابق. هذه هي نفس المقايضة مثل استخدام SQL (لغة استعلام ثابتة) مقابل الشيفرة التعسفية - القيد يمكّن الأدوات ويضمن.

انظر أيضًا

المعاملات - مرجع هيكل JSON
مرجع الإجراءات - تفاصيل العملية الكاملة
التحقق المسبق والالتزام العكسي - التحقق غير المتغير ودلالات التراجع
الوصفات - أنماط العمليات المتعددة الشائعة