ثمانية اختبارات تُجريها بنفسك، على تثبيتك الخاص.

1السيادة: البيانات المحمية لا تغادر المحيط أبداً

الادعاء قيد الاختبار. أي طلب يرسل بيانات مصنّفة سيادية إلى نموذج سحابي يُرفض داخل المحيط بـ403 SOVEREIGNTY_BLOCK… قبل أن تغادر أي حزمة الشبكة.

الإعداد

1. Admin → Workspaces → أنشئ pov-sovereign بتصنيف بيانات Sovereign.
2. Admin → AI Gateway → تأكد من وجود مستوى سحابي واحد على الأقل (أي مزوّد) ومستوى محلي واحد.
3. ارفع إلى معرفة مساحة العمل هذه مستنداً يحوي سلسلة سرية يسهل تمييزها (مثلاً POV-SECRET-4711).
4. ابدأ التقاط حركة الخروج عند المحيط، مرشَّحةً إلى مضيفي المزوّد السحابي.

الخطوات

1. في الدردشة، داخل مساحة العمل pov-sovereign، اختر المستوى Cloud Reasoning واسأل: «ما السر الموجود في المستند المرفوع؟»
2. كرّر عبر واجهة البرمجة لترى الرمز الدقيق:

   curl -s -H "Cookie: $COOKIE" -H 'content-type: application/json' \
     -d '{"workspaceId":"pov-sovereign","modelTier":"cloud-reasoning","dataClassification":"sovereign","message":"What is the secret?"}' \
     $GW/chat/message -o /dev/null -w '%{http_code}\n'

3. انتقل إلى المستوى المحلي واطرح السؤال نفسه.
4. Admin → Governance → سجل التدقيق: رشّح حسب الإجراء sovereignty.data_classification.

الملحوظات

• الخطوة 1: ترفض الواجهة برسالة السيادة؛ ولا تُنتَج أي إجابة.
• الخطوة 2: HTTP 403، والمتن code: SOVEREIGNTY_BLOCK_DATA_CLASSIFICATION.
• الخطوة 3: يجيب المستوى المحلي بالسر مع استشهاد بالمستند.
• الخطوة 4: صف تدقيق واحد لكل رفض يحمل مساحة العمل والمستخدم والقاعدة sovereign-data-cloud-tier.
• التقاط المحيط: صفر اتصالات بالمزوّد السحابي أثناء الخطوتين 1 و2. هذه هي الملحوظة التي تهم؛ فالرمز 403 وحده يثبت وجود البوابة، أما الالتقاط فيثبت أنها تقع قبل الخروج.

النجاح: الملحوظات الخمس كلها. لا يُثبت: أن كل مسار في الكود محمي؛ وهذا ما يتراكم عبر صف التدقيق والالتقاط في اختباراتك الأخرى (2، 5).

النسخة B (فصل شبكي)

ثبّت حزمة الفصل الشبكي بـAANCER_OFFLINE_INSTALL=1 على مضيف يمنع جدار حمايته كل الحركة الصادرة. شغّل، سجّل الدخول، وأجرِ الاختبار 5. المتوقع: المنصّة قابلة للاستخدام بالكامل بالنماذج المحلية، والترخيص يُفعَّل من الرمز غير المتصل، وسجل جدار الحماية لا يُظهر أي محاولة صادرة من مضيفي المنصّة (لا يوجد اتصال بالمزوّد).

2أمان الوكلاء: الإجراء غير المصرَّح به يُرفض تقنياً، لا يُنهى عنه فحسب

الادعاء قيد الاختبار. أدوات الوكيل مقيَّدة بجواز سفره الموقَّع (النطاق، سقف التصنيف، الميزانية) وبالمقعد. أي استدعاء أداة خارج الغلاف ترفضه المنصّة بنتيجة PolicyDenied لا يستطيع النموذج التحايل عليها بالكلام، ويُسجَّل الرفض في التدقيق.

الإعداد

1. Agents → Design → أنشئ pov-agent بأداتين: أداة قراءة (مثل البحث في المعرفة) وأداة إجراء (مثل الإلحاق بمجموعة بيانات، أو أي كتابة عبر موصّل لديك).
2. اعتمده (Agent Administration → الشهادات → إصدار) بسقف تصنيف internal ونطاق مقصور على أداة القراءة وحدها.
3. أنشئ مجموعة بيانات pov_actions في مساحة عمل داخلية وأخرى في مساحة العمل pov-sovereign من الاختبار 1.

الخطوات

1. بصفتك Platform Admin، تحدّث مع pov-agent في مساحة العمل الداخلية: «ألحق صفاً {note:'hello'} بمجموعة البيانات pov_actions.» (أداة الكتابة مرتبطة بالوكيل لكنها خارج نطاق الجواز.)
2. ثم: «ابحث في المعرفة عن POV-SECRET.» (ضمن النطاق).
3. أعد إصدار الجواز مع إدراج أداة الكتابة في النطاق؛ وكرّر الخطوة 1.
4. الآن تحدّث مع الوكيل نفسه من مساحة العمل pov-sovereign واطلب منه البحث في المعرفة.
5. بمقعد Knowledge Worker (بلا agent.execute_code)، اطلب من أي وكيل يملك أداة تشغيل الكود أن «يحسب 2**64 بدقة».
6. Admin → Governance → سجل التدقيق: رشّح agent.tool.call.

الملحوظات

• الخطوة 1: يُبلغ الوكيل أنه لا يستطيع تنفيذ الإجراء؛ ويُظهر تتبّع التشغيل استدعاء الأداة بالنتيجة PolicyDenied / envelope.out_of_scope؛ ولم يُكتب أي صف (تحقق من مجموعة البيانات).
• الخطوة 2: تنجح، ويُعرض الاستشهاد.
• الخطوة 3: يُكتب الصف؛ ويُظهر التتبّع allowed.
• الخطوة 4: PolicyDenied / sovereignty.classification_ceiling؛ فمساحة العمل السيادية أعلى من سقف internal في الجواز؛ ولم يُسترجع شيء.
• الخطوة 5: تُرفض أداة الكود للمقعد (صلاحية)، ويجيب الوكيل دونها.
• الخطوة 6: صف تدقيق واحد لكل استدعاء أداة يحمل outcome: denied وقاعدة القرار المذكورة أعلاه؛ ولا تحمل الصفوف المرفوضة أي وسائط للأدوات سوى أسمائها.

النجاح: الملحوظات الست كلها. لا يُثبت: حُكم النموذج؛ بل يُثبت أن المنصّة لا تعتمد عليه.

3الإبطال: الجواز المُبطَل يتوقف خلال 30 ثانية

الادعاء قيد الاختبار. إبطال شهادة الوكيل يوقف أي تنفيذ لاحق للأدوات خلال 30 ثانية (تحتفظ المنصّة بنتائج فحص الإبطال في الذاكرة المؤقتة 30 ثانية على الأكثر)؛ ويفشل الفحص مغلقاً إذا تعذّر الوصول إلى مخزن الإبطال.

الإعداد

pov-agent من الاختبار 2، معتمَداً، مع سير عمل أو تعليمة تجعله يستدعي أداةً بشكل متكرر (مثلاً «ابحث في المعرفة عن كل مصطلح من هذه المصطلحات الأربعين، استدعاء لكل مصطلح»).

الخطوات

1. ابدأ المحادثة الطويلة وسجّل الوقت (T0).
2. أثناء تشغيلها: Agent Administration → الشهادات → شهادة الوكيل → إبطال (أو POST $GW/admin/agent/certs/<lid>/revoke). سجّل T1.
3. راقب تتبّع التشغيل؛ وسجّل الطابع الزمني لآخر استدعاء أداة مسموح (T2) وأول PolicyDenied / revoked (T3).
4. ابدأ محادثة جديدة مع الوكيل المُبطَل.
5. فحص اختياري للفشل المغلق (Docker): docker stop <postgres> لمدة 20 ثانية أثناء التشغيل.

الملحوظات

• T3 − T1 ≤ 30 s؛ كل استدعاء أداة بعد T3 يُرفض؛ وينتهي التشغيل بخطأ صريح لا بتعليق.
• الخطوة 4: يُرفض فوراً: «Invalid or revoked agent token».
• الخطوة 5: تُرفض استدعاءات الأدوات ما دام المخزن غير متاح (لا تُسمح افتراضياً أبداً)، وتُستأنف عند عودته.
• التدقيق: agent.cert.revoked واستدعاءات الأدوات المرفوضة.

النجاح: T3 − T1 ≤ 30 s وسلوك الفشل المغلق. لا يُثبت: مقاطعة استدعاء أداة واحد قيد التنفيذ بالفعل (استدعاء موصّل جارٍ يكتمل أو ينتهي وقته بميزانيته الخاصة، perCallBudget.maxWallMs).

4عمق الموصّلات: عملية حقيقية من البداية إلى النهاية، لا شعار على صفحة

الادعاء قيد الاختبار. الموصّلات التي تحتاجها تدعم العمليات الفعلية والمصادقة ومعالجة الأخطاء التي تتطلبها عمليتك.

الإعداد

اختر عملية حقيقية واحدة تشمل نظامين من أنظمتك (مثلاً «مورّد جديد في SAP → موافقة → سجل في ServiceNow»، أو بريد M365 → استخراج → SharePoint). استخدم بيانات اعتماد اختبارية من جهتك.

الخطوات

1. Automations → تصميم سير عمل → ابنِ العملية بموصّلات المنصّة: مُشغِّل، قراءة، خطوة موافقة، كتابة. استخدم اختبار الخطوة عند كل خطوة.
2. شغّلها مرة من البداية إلى النهاية ببيانات صحيحة. وافق في Approvals.
3. شغّلها ببيانات غير صحيحة (حقل إلزامي مفقود عند الكتابة).
4. شغّلها مع إبطال بيانات اعتماد النظام الهدف من جهتك.
5. أعد الخطوة 2 بينما الهدف غير متاح مؤقتاً (احجبه في جدار الحماية دقيقة واحدة)، ثم أزل الحجب.
6. Activity & Results → افتح كل تشغيل.

الملحوظات

• الخطوة 2: تظهر الكتابة في النظام الهدف؛ ويعرض التشغيل مدخلات كل خطوة ومخرجاتها؛ وتعرض الموافقة مَن قرر ومتى.
• الخطوة 3: يفشل التشغيل عند خطوة الكتابة مع إظهار رسالة التحقق من الهدف (لا خطأ عام)؛ ولم يُكتب شيء جزئي.
• الخطوة 4: يفشل الموصّل بخطأ مصادقة؛ ولم تُعد المنصّة المحاولة بشكل أعمى؛ وتُعلَّم بيانات الاعتماد في Connectivity.
• الخطوة 5: تُعاد محاولة الخطوة وتكتمل بعد عودة الهدف؛ ويُظهر تفصيل التشغيل المحاولات.
• التدقيق: أحداث run.completed / run.failed؛ وصفوف connector.* تذكر المضيف لا الحمولة أبداً.

النجاح: الملحوظات الخمس كلها. لا يُثبت: دلالات المعاملات داخل نظامك الهدف؛ تحقق من منطق التعويض في تصميم عمليتك.

5المعرفة وRAG: الاستشهادات، الصلاحيات، المستندات الممسوحة ضوئياً

الادعاء قيد الاختبار. تستشهد الإجابات بالمقاطع التي جاءت منها؛ ولا يرى المستخدم إلا ما يُسمح لمقعده برؤيته؛ وملفات PDF الممسوحة ضوئياً قابلة للقراءة عند تكوين نموذج رؤية.

الإعداد

1. مساحتا عمل، pov-hr وpov-ops؛ ارفع 10 مستندات حقيقية إلى كل منهما، بينها ملفا PDF ممسوحان ضوئياً على الأقل ومستندان متناقضان (سياسة قديمة وأخرى جديدة).
2. مقعد Knowledge Worker عضو في pov-ops فقط.

الخطوات

1. بصفتك مسؤولاً في pov-hr: اطرح سؤالاً لا يجيب عنه إلا ملف PDF الممسوح ضوئياً.
2. اطرح سؤالاً يجيب عنه المستندان المتناقضان بشكل مختلف.
3. بصفتك Knowledge Worker، اطرح سؤال pov-hr من داخل pov-ops، وحاول فتح مجموعة معرفة pov-hr مباشرةً (/knowledge?workspace=pov-hr).
4. احذف مستنداً؛ واطرح سؤاله مجدداً.
5. Admin → Governance → سجلات أنشطة المعالجة (المادة 30) → تصدير.

الملحوظات

• الخطوة 1: إجابة مع استشهاد بالملف الممسوح والصفحة؛ ويفتح الاستشهاد المقطع. (إذا لم يكن نموذج رؤية مكوَّناً، يقول الرفع ذلك فوراً: «يبدو هذا مستنداً ممسوحاً ضوئياً. يحتاج استخراج نصه إلى نموذج رؤية…» بصراحة، بدلاً من فهرس فارغ بصمت.)
• الخطوة 2: تُظهر الإجابة المصدرين بتاريخيهما وتذكر أنهما مختلفان، أو تستشهد بالأحدث وتسمّي الأقدم؛ ولا تخلطهما في ادعاء واحد واثق.
• الخطوة 3: لا إجابة من محتوى pov-hr؛ ويُرفض العنوان المباشر (403 في واجهة البرمجة، وحالة فارغة صريحة في الواجهة).
• الخطوة 4: لم تعد الإجابة تستشهد بالمستند المحذوف؛ ويُظهر التدقيق knowledge.delete.
• الخطوة 5: يسرد التصدير مجموعات المعرفة بوصفها أنشطة معالجة مع فئات بياناتها.

النجاح: الملحوظات الخمس كلها. لا يُثبت: جودة الاسترجاع على مجموعتك على نطاق واسع؛ اختبرها على مجموعة تمثيلية من 1,000 مستند قبل أن تقرر.

6منصّة الإضافات: ابنِ حزمة قسم واحدة وخذها عبر دورة حياتها

الادعاء قيد الاختبار. تخصيص القسم حزمة بيانات موقَّعة: تُثبَّت، وتُفعَّل بمعاملات، وتُرقَّى، وتُرجَع، وتُسحب بنظافة، وتُرفض أي حزمة موقَّعة بمفتاح مجهول.

الإعداد

Node 20 على حاسوب محمول؛ أداة سطر الأوامر tools/aancer-pack من حزمة الإصدار؛ فصل تأليف الحزمة في دليل العميل. مساحة عمل pov-dept.

الخطوات

1. aancer-pack keygen --out dept.key. اكتب manifest.json يحوي مجموعة بيانات واحدة، ونموذج عمل واحداً، ولوحة معلومات واحدة بمؤشر أداء ومخطط يُصدر ترشيحاً متقاطعاً، وخطافاً واحداً على dataset.rows.published، وسمة واحدة (ألوانك)، وبطاقة رئيسية واحدة. وقّعه: aancer-pack sign manifest.json content/ -o dept-1.0.0.ancpack --key dept.key.
2. Platform Settings → Extensions → استيراد الحزمة قبل إضافة مفتاحك.
3. أضف dept.pub تحت Trust keys؛ استورد مجدداً؛ تكوين وتفعيل، مع ربط pov-dept.
4. استورد 50 صفاً إلى مجموعة البيانات عبر CSV؛ افتح لوحة المعلومات؛ انقر على شريط.
5. غيّر عنوان المخطط، ارفع الإصدار إلى 1.1.0، وقّع، استورد، فعّل. ثم أرجع إلى 1.0.0.
6. اسحب الحزمة.
7. عدّل بايتاً واحداً داخل .ancpack موقَّع (مثلاً عدّل content/theme.json داخل الملف المضغوط) واستورده.

الملحوظات

• الخطوة 2: يُرفض، PACK_SIGNER_UNKNOWN؛ ولا يُخزَّن شيء.
• الخطوة 3: «Bundle verified»، العناصر مسرودة مع أي تحذيرات تباين؛ وبعد التفعيل كل عنصر Active، وتظهر لوحة المعلومات في التنقل، وتُطبَّق السمة، وتظهر البطاقة الرئيسية، ويُظهر الخطاف managed by pack.
• الخطوة 4: تعرض لوحة المعلومات صفوفك؛ ويرشّح النقر مؤشر الأداء وتظهر شريحة؛ وتُظهر تسليمات الخطاف تسليماً واحداً لاستيراد CSV (إذا كان سير العمل المعالج منشوراً بمُشغِّل Event؛ وإلا يُظهر الخطاف handler paused، وهذا صحيح أيضاً).
• الخطوة 5: العنوان الجديد بعد الترقية؛ والعنوان القديم بعد الإرجاع؛ والإصداران مسرودان.
• الخطوة 6: تختفي لوحة المعلومات والبطاقة والسمة والخطاف؛ وتُحفظ صفوف مجموعات البيانات للتدقيق؛ وتعود العلامة الافتراضية.
• الخطوة 7: يُرفض بخطأ عدم تطابق التجزئة.
• التدقيق: extension.pack.imported|activated|rolled_back|retired، وإخفاقات التوقيع بوصفها رفضاً.

النجاح: الملحوظات السبع كلها. لا يُثبت: جودة حزم الأطراف الثالثة؛ بل يُثبت حدود المنصّة.

7الأعطال والتعافي: أوقف المكوّنات في منتصف التشغيل

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

الإعداد

تثبيت Docker (في Helm: استخدم kubectl delete pod بالمثل). سير عمل بثلاث خطوات وموافقة في المنتصف (يكفي سير الاختبار 4). خطاف من الاختبار 6.

الخطوات

1. ابدأ سير العمل؛ وأثناء تنفيذ الخطوة 1: docker restart <automation-runner>.
2. ابدأه مجدداً؛ وأثناء انتظاره الموافقة: docker restart <gateway>؛ ثم وافق.
3. استورد ملف CSV يُطلق الخطاف؛ وفوراً docker stop <postgres> لمدة 60 ثانية؛ ثم شغّله.
4. سلامة السجل: GET $GW/admin/compliance/audit-chain/verify → سجّل ok:true. ثم بصفتك المستخدم الأعلى لقاعدة البيانات، حاول UPDATE audit_events SET action='x' WHERE id=(SELECT id FROM audit_events LIMIT 1); وTRUNCATE audit_events;.
5. إذا كان لديك وصول مباشر إلى قاعدة البيانات وأردت رؤية كشف التلاعب نفسه: عطّل المُشغِّل، عدّل حمولة صف واحد، أعد تفعيله، واستدعِ نقطة التحقق مجدداً.
6. GET $GW/metrics (برمز المقاييس) و/health.

الملحوظات

• الخطوة 1: ينتهي التشغيل بحالة failed بخطأ صريح أو يكتمل بعد عودة المُنفِّذ، ولا يكون أبداً نصف تشغيل صامت؛ ويذكر تفصيل التشغيل أيهما حدث.
• الخطوة 2: تبقى الموافقة معلّقة بعد إعادة التشغيل؛ والموافقة تستأنف التشغيل فيكتمل بمعرّف التشغيل نفسه.
• الخطوة 3: تُعاد محاولة تسليم الخطاف بعد عودة قاعدة البيانات (تراجع 30 ثانية، 120 ثانية، 480 ثانية) ويُسلَّم مرة واحدة؛ ويرتفع aancer_event_outbox_pending في /metrics ثم يعود إلى 0؛ ولا تشغيل مكرر.
• الخطوة 4: ترفض قاعدة البيانات العبارتين («audit_events is append-only»)؛ ويظل verify يُبلغ ok:true.
• الخطوة 5: يُبلغ verify بـok:false, brokenAt:<row>؛ فالسلسلة تكشف التغيير.
• الخطوة 6: /health 200؛ و/metrics يسرد مقاييس البوابة وصندوق الصادر.

النجاح: الملحوظات الست كلها. لا يُثبت: التوافر العالي تحت حمل مستمر؛ فذلك تمرين تحجيم مع مكوّنات Enterprise الجانبية.

8الخروج: خذ كل شيء معك

الادعاء قيد الاختبار. يستطيع العميل المغادرة ببياناته وأتمتته وملكيته الفكرية للإضافات، ويستطيع إبقاء إصدار مثبَّت يعمل دون المورّد.

الخطوات

1. مجموعات البيانات: تصدير CSV لكل مجموعة (GET $GW/datasets/<id>/export.csv).
2. لوحات المعلومات: تصدير كحزمة لكل لوحة منشورة، وهو .ancpack موقَّع يحوي اللوحة والودجات والنماذج ومخططات مجموعات البيانات.
3. سير العمل: Designer → تصدير JSON لكل سير (واستيراد JSON على تثبيت ثانٍ لإثبات الذهاب والعودة).
4. الامتثال: Governance → تصدير سجل التدقيق وسجلات المادة 30 وتقرير DIFC Reg. 10 (/compliance-log/export، /compliance/gdpr-art30/export، /compliance/difc-reg10/export).
5. بيانات المستخدم الخاصة: Admin → Users → تصدير الوصول (المادة 15).
6. حزم الإضافات: احتفظ بملفات .ancpack الموقَّعة ومفتاحك الخاص؛ فالمنصّة لا تحتفظ بالمفتاح أبداً.
7. الإصدار المجمّد: على مضيف الفصل الشبكي من الاختبار 1B، افصله عن كل شيء أسبوعاً؛ وسجّل الدخول يومياً.

الملحوظات

• تُنتج الخطوات من 1 إلى 5 ملفات كاملة يمكنك فتحها خارج AANCER (CSV وJSON وملف مضغوط موقَّع)؛ ويستورد التثبيت الثاني سير العمل ويشغّله.
• الخطوة 7: يظل التثبيت يعمل؛ والترخيص، بوصفه رمزاً موقَّعاً غير متصل بلا اتصال بالمزوّد، لا ينتهي بالفصل (بل في تاريخ انتهائه الخاص، الذي يمكنك قراءته في Platform Settings → Licence).

النجاح: كل شيء. لا يُثبت، ونقولها بوضوح: لا يوجد اليوم زر واحد «لتصدير التثبيت بأكمله»؛ فالخروج هو مجموع عمليات التصدير لكل كائن أعلاه مضافاً إليها نسخة احتياطية من قاعدة البيانات، ومكوّن النسخ الاحتياطي الجانبي جزء من Enterprise. أما إيداع الكود المصدري فمسألة تعاقدية لا خاصية في المنتج.