فلسفة الكتالوج: معلومات صادقة فقط
لماذا لا تضع أرقام تحميلات ولا إصدارات غير مؤكدة في كتالوجنا؟ جولة داخل قواعد البيانات الموثوقة التي تحكم كل بطاقة في البوابة.
المشكلة التي نراها في كل مكان
معظم مواقع التطبيقات تتزاحم بأرقام تحميلات ضخمة وتقييمات ملفقة وروابط تنزيل ميتة، فيصبح المستخدم ضحية وعودٍ لا تُنفذ. جرّب يومًا أن تنزّل ملفًا من موقع لا تعرف مصدره لتكتشف أنه نسخة معدلة أو قديمة أو أسوأ من ذلك؛ هذه التجربة هي بالضبط ما أردنا أن لا يمر به مستخدمو تطبيقاتنا.
الشفافية ليست ترفًا تسويقيًا، بل قرار هندسي يؤثر في كل تفاصيل الموقع. حين تكون كل معلومة في الكتالوج قابلة للتحقق، ينخفض الضغط على الدعم، وتعبر الثقة من موقعنا إلى التطبيقات نفسها.
القواعد الثلاث التي تحكم البوابة
القاعدة الأولى: لا إصدارات غير مؤكدة. لا يُعرض رقم إصدار ولا تاريخ نشر في صفحة أي تطبيق إلا إذا كان معتمدًا فعليًا، ولذلك سترى عبارة «لم يُحدد بعد» في كثير من الصفحات — وهي ليست نقصًا بل صدق.
القاعدة الثانية: لا روابط غير موثوقة. لا يُضاف رابط تنزيل أو APK إلا بعد التحقق من ملكيته وسلامة الملف، والروابط كلها عبر HTTPS. القاعدة الثالثة: المصدر الوحيد للحقيقة هو ملف الكتالوج apps.json، وكل صفحة وواجهة برمجية تقرأ منه مباشرة دون أي تعديل يدوي.
كيف يتدفق التحديث إلى الموقع
عندما ينضج تطبيق ما — إصدار جديد، رابط تنزيل، ربط بمستودع — يُعدّل ملف الكتالوج عبر طلب سحب في GitHub، وبعد المراجعة ينشر التعديل تلقائيًا في كل مكان: البطاقات، صفحات التفاصيل، واجهة /api/apps، وخريطة الموقع. لا صفحات تُحدّث يدويًا ولا معلومات تعيش في مكانين.
بهذا الشكل تتحول مراجعة البيانات من عبء إداري إلى عملية هندسية قابلة للتتبع: كل تعديل له مؤلف وسبب وسجل كامل في مستودع عام يمكن لأي شخص الاطلاع عليه.
دعوتك
إن لاحظت معلومة في الكتالوج تبدو غير دقيقة، أو رابطًا لا يعمل، فبلاغك عبر صفحة الدعم أو فتح Issue في المستودع يعني لنا الكثير. نبني هذا المكان ليكون المرجع الصادق الوحيد لتطبيقات DRS، والصدق مسؤولية مشتركة بيننا وبينكم.