متطلبات مسبقة لتقييم Yudun VMP

قدّم أولاً نسخة مرشح للإطلاق قابلة للتحديد بشكل فريد

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

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

عند التعامل مع كود ملكي أو بيانات مستخدمين، قدّمها عبر سير عمل المشروع المتحكم به على منصة Yudun المركزية. توفر مواقع المواضيع العامة فقط الأساليب ونقاط الدخول؛ ولا تقبل الحسابات، أو ملفات التثبيت، أو الشهادات، أو أسرار المشروع.

تحديد الخسارة التجارية للكود الذي يتطلب الحماية

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

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

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

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

يجب أن تحدد مشاريع Android إصدارات Java وKotlin وNDK وGradle وإضافة Gradle لـAndroid، وminSdk، وtargetSdk، ومعالجات التعليمات (ABIs) المُصدَرة، واستخدام الانعكاس، والتسلسل، وتحميل الفئات الديناميكي، والإصلاحات السريعة، وهيكلة الإضافات، وWebView، والمكونات الأصلية، وهياكل العمليات المتعددة. أما مشاريع iOS فيجب أن تحدد إصدارات Swift وObjective-C، وأقل إصدار لنظام التشغيل، والملحقات، والمكتبات الديناميكية، وخصائص وقت التشغيل، وقدرات التوقيع.

بالنسبة لأطر العمل متعددة المنصات مثل Flutter أو React Native أو Unity أو Cocos أو غيرها، سجّل إصدار الإطار، وطريقة الجسر، والمحرك، ومكتبات الأعمال الأصلية. لا تكتفِ بذكر "متعدد المنصات"، لأن بنية القطع الأثرية، وسلوك بدء التشغيل، وتكاملات الطرف الثالث تختلف اختلافًا كبيرًا بين الإصدارات.

قد تعتمد خدمات تسجيل الدخول والدفع والإشعارات الفورية والخرائط والصوت/الفيديو والتحليلات والتحكم في المخاطر والإصلاحات السريعة وخدمات البائعين الأخرى على الانعكاس، أو التوقيعات، أو إدخالات ملف Manifest، أو مخططات URL، أو واجهة JNI، أو الموارد، أو فحوصات النزاهة الخاصة بها. إن سرد هذه العناصر بالكامل أثناء التقييم الأولي يوفر وقتًا أطول من تخمينها واحدة تلو الأخرى بعد حدوث الأعطال.

• اللغات، وأنظمة البناء، وإصدارات الإضافات الرئيسية
• أقل إصدار لنظام التشغيل والإصدار المستهدف، والأجهزة، ومعالجات التعليمات (ABIs)
• المكونات الأصلية، وواجهة JNI، والتحميل الديناميكي، وأطر العمل متعددة المنصات
• العمليات المتعددة، وWebView، والإصلاحات السريعة، وهيكلة الإضافات
• مجموعات تطوير البرمجيات (SDKs) الحرجة: تسجيل الدخول، الدفع، الإشعارات الفورية، الصوت/الفيديو، إلخ.

توضيح التوقيع والقنوات وخطط الترقية قبل إثبات المفهوم (PoC)

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

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

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

تحديد شروط النجاح والفشل والإيقاف لاختبار المفهوم مسبقًا

اختبار المفهوم ليس مجرد توليد حزمة محمية قابلة للتثبيت. حدّد مسبقًا نطاق الحماية للمراقبة، وسطح التعرض الثابت، وسلوك بدء التشغيل، وتدفقات الأعمال الحرجة، وميزانية الأداء، والأنظمة المستهدفة، وواجهات ثنائية التطبيق (ABIs)، ومجموعات تطوير البرمجيات التابعة لجهات خارجية، وعمليات التثبيت/الترقية، ومسارات الاستثناء البديلة. قد تختلف أوزان كل مشروع، لكن لا يجوز غياب أي تعريف منها.

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

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

project_stage: release-candidate
artifacts:
  baseline: identified
  protected_candidate: pending
assets:
  - entitlement-decision
  - protocol-core
stack:
  platform: Android
  min_os: project-defined
  abis: [arm64-v8a]
critical_journeys:
  - cold-launch
  - sign-in
  - protected-operation
acceptance:
  functional_parity: required
  performance_budget: project-defined
  compatibility_matrix: required
  rollback_rehearsal: required
boundaries:
  - no_unverified_attack_resistance_claim
  - uncovered_devices_remain_open

المخرجات المُشكَّلة بعد تقييم Yudun واكتمال تقديم البيانات

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

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

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

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