استخدام وكيل برمجي لكتابة صفحات الامتثال
الحقائق التي تحتاجها هذه الصفحات موجودة أصلًا في مستودعك. ما الذي يستطيع الوكيل استنتاجه فعلًا، وما الذي يجب أن يسألك عنه، والحدود التي تستحق أن تتمسك بها قبل أن تسمح لأي وكيل بالاقتراب من هذا.
الوكيل البرمجي القادر على قراءة مستودعك يملك أصلًا الحقائق التي تحتاجها هذه الصفحات: اسم التطبيق، ومعرّف الحزمة، وروابط المتجر، وكل حزمة SDK في البنية. وبالأدوات المناسبة يصوغ الصفحات من هذه الأدلة ويسلّمك رابطًا للمراجعة: تتحقق منها ثم تنشر.
أنجز هذا في دقائق بدلًا من ذلك
تستضيف AppFoyer الصفحات التي يتناولها هذا الدليل — سياسة الخصوصية والشروط والدعم وحذف الحساب وapp-ads.txt — على نطاق فرعي خاص بها، دون نطاق أو خادم خاص بك. تطبيق واحد مجاني، ولا شيء يشترطه المتجر يكون خلف جدار دفع أبدًا.
تمت المراجعة في 25 سبتمبر 2026. تتغير سياسات المتاجر، أحيانًا دون إشعار. كل ما يلي يربط بالتوثيق الرسمي، وتلك الصفحة — لا هذه — هي المرجع. إذا تعارضتا، فالمتجر هو المحق. هذا الدليل مترجم من الإنجليزية؛ والاقتباسات من توثيق المتاجر محفوظة بالإنجليزية الأصلية.
كتابة سياسة الخصوصية في معظمها عملية نقل. الجزء الصعب، أي معرفة ما يجمعه تطبيقك فعلًا، تجيب عنه ملفات موجودة أصلًا في مستودعك، وهذا بالضبط نوع العمل الذي يُتقنه وكيل يملك وصولًا إلى نظام الملفات.
ما الذي يستطيع الوكيل استنتاجه فعلًا
من ملفات البناء وحدها، دون أن يسألك عن أي شيء:
| الحقيقة | من أين تأتي |
|---|---|
| اسم التطبيق | strings.xml app_name، وCFBundleDisplayName، وpubspec.yaml، وapp.json |
| معرّف التطبيق / الحزمة | applicationId في Gradle، وPRODUCT_BUNDLE_IDENTIFIER في مشروع Xcode |
| المنصة | أيّ هذه الملفات موجود |
| جمع البيانات | كل حزمة SDK تابعة لجهة خارجية في build.gradle وPodfile وPackage.swift وpubspec.yaml وpackage.json |
| الأذونات ونصوص الاستخدام | AndroidManifest.xml، وInfo.plist |
| معرّف الناشر الإعلاني | معرّف تطبيق AdMob في ملف manifest أو plist |
| رابط Play مقترح | يُبنى من معرّف التطبيق: اقتراح لا حقيقة، فقد لا يكون التطبيق منشورًا في المتجر |
هذا الجدول هو جوهر سياسة الخصوصية. وهو أيضًا الجواب عن سؤال “ماذا يجمع تطبيقي”، وهو السؤال الذي يخطئ فيه معظم المطورين حين يعتمدون على الذاكرة، ويصيبون فيه حين يقرؤون الملفات.
ما لا يستطيع معرفته ويجب أن يسأل عنه
الوكيل الذي يخترع هذه المعلومات أسوأ من عدم وجود وكيل:
- اسم كيانك القانوني والولاية القضائية التي تحددها شروطك.
- عنوان الدعم الذي تقرؤه فعلًا. يجب ألا يخمّنه أبدًا من إعدادات git أو من حساب مطوّر Apple موجود في ملف fastlane.
- معرّفك الحقيقي في App Store، ما لم يكن في إعدادات fastlane، فالمعرّف الرقمي لا يمكن استنتاجه.
- هل التطبيق منشور، وتحت أي صفحة في المتجر.
- الحقائق التجارية: هل تبيع اشتراكات، وهل الأطفال جمهور مستهدف، وهل تشارك البيانات مع شريك لا يترك أثرًا في قائمة التبعيات.
- أي شيء يخص الخادم الخلفي. لا شيء في المستودع يقول كم من الوقت تحتفظ بالبيانات.
النتيجة الجيدة تبدو هكذا: كل ما يمكن استنتاجه مستنتَج مع الملف والسطر اللذين جاء منهما، وما تبقى قائمة قصيرة من الأسئلة التي لا يستطيع أحد غيرك الإجابة عنها.
حدود تستحق أن تتمسك بها
قبل أن تسمح لأي وكيل بالاقتراب من هذا، احسم هذه الأمور، فهي الفرق بين أداة مفيدة وعبء عليك:
- لا يُنشر شيء دون نقرة من إنسان. صفحة قانونية مولَّدة تُنشر دون مراجعة هي الخطر كله في جملة واحدة.
- كل حقيقة مستنتجة يمكن نسبتها إلى مصدرها. عبارة “وجدت
firebase-crashlyticsفيapp/build.gradle:47” يمكن التحقق منها؛ أما “تطبيقك يجمع بيانات تشخيصية” فلا. - لا يُجري commit ولا push. اقتراح diff مساعدة؛ أما إعادة كتابة مستودعك فليست كذلك.
- يرسل الحد الأدنى خارج جهازك. استنتاج الحقائق محليًا وإرسال الاستنتاجات أمر مختلف تمامًا عن رفع الكود المصدري.
- يصرّح بما لا يعرفه. الوكيل الذي يملأ نصًا مؤقتًا بجملة معقولة الظاهر قد أنتج وثيقة امتثال تحتوي تخمينًا.
اطرح هذه الأسئلة الخمسة على أي أداة في هذه الفئة، بما فيها أداتنا.
أين يبقى الإنسان في الحلقة
الوكيل يصوغ، وأنت تقرر. وتحديدًا، أنت من:
- يؤكد الأسئلة التي لم يستطع الوكيل استنتاجها؛
- يقرأ قسم الجهات الخارجية، وهو الجزء الذي يقارنه المراجِع بنموذج Data safety لديك؛
- يحدد مدد الاحتفاظ، لأنك وحدك تعرف خادمك الخلفي؛
- ينقر على النشر؛
- يملأ حقول وحدة تحكم المتجر، فلا ينبغي لأي وكيل أن يكون داخل Play Console الخاص بك.
إذا كان تطبيقك يتعامل مع المال أو البيانات الصحية أو الأطفال، فساعة من وقت محامٍ لا تزال مكانها في هذه القائمة. القالب المصاغ من الأدلة نقطة انطلاق أفضل من صفحة فارغة؛ لكنه ليس استشارة.
ما الذي تفعله AppFoyer هنا
هناك إضافة (plugin) لـClaude Code. تثبّتها، وتقول “make this app store-ready” (أي «اجعل هذا التطبيق
جاهزًا للمتجر»)، فتقرأ المهارة (skill) ملفات البناء لديك، وتستنتج الجدول أعلاه مع الملف والسطر لكل
حقيقة، ولا تسأل إلا عمّا لم تجده، وتصوغ الصفحات الخمس كلها إضافة إلى app-ads.txt. ثم تسلّمك رابطًا
للمراجعة في لوحة التحكم.
الحدود المذكورة أعلاه مفروضة لا موعودة. بيانات اعتماد الوكيل تصل إلى مجموعة ثابتة من الأدوات: عرض
التطبيقات وقراءتها، وإنشاؤها (تطبيق لكل flavor)، وتحديث الإعدادات، وصياغة الصفحات، وapp-ads.txt،
وقائمة التحقق، وأيقونة التطبيق، وعنوان مخصص، والنشر ليس من بينها: الأداة request_publish تمنحك
رابطًا، لا صفحة منشورة. الأيقونة والعنوان هما الشيئان الوحيدان اللذان لا توجد لهما خطوة مسودة، لذا يخبرك
الوكيل حين يضبطهما، ولن يستبدل عنوانًا تستخدمه أصلًا دون أن يسألك. لا يستطيع الوكيل النشر، ولا إلغاء
النشر، ولا حذف تطبيق، ولا تغيير قنوات الإشعارات، ولا المساس بصندوق طلبات الحذف لديك؛ تلك إجراءات خاصة
بالجلسة تتخذها أنت بنفسك. القائمة الكاملة للأدوات وأمثلة عملية موجودة في صفحة وثائق الوكيل.
لا تُجري المهارة commit ولا push أبدًا، ولا تقترح diff إلا حين تطلب منها ربط الروابط النهائية بالتطبيق.
إن لم يكن وكيلك Claude Code، بل Cursor أو Codex أو مساعد محادثة، ففي صفحة الخصوصية مسار بديل بالنسخ واللصق: يمنحك المحرر prompt مملوءًا مسبقًا ببيانات تطبيقك، تشغّله أينما شئت وتلصق الرد. الـprompt وسبب صياغته بهذه الطريقة موجودان في كتابة سياسة الخصوصية بمساعد ذكاء اصطناعي.
إن لم يكن لديك وكيل، فالشيء نفسه متاح في صورة نموذج قصير. مسار الوكيل أسرع لأن الإجابات موجودة أصلًا في مستودعك، وليس منتجًا مختلفًا.
المصادر الرسمية
- Provide information for Google Play’s Data safety section — مساعدة Google Play Console، عن كون بيانات حزم SDK مسؤوليتك في الإعلان عنها
- App privacy details on the App Store — Apple
- Privacy and security in Firebase — مثال على الإفصاح الخاص بكل SDK الذي يقرؤه الوكيل