OmniRoute/docs/i18n/ur/docs/frameworks/RADAR.md

Radar Free-Model Catalog (اردو)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

مستند ماخذ: src/lib/radar/، src/lib/db/radar.ts، src/app/api/radar/ آخری بار اپ ڈیٹ کیا گیا: 2026-09-01 — v3.8.51 ہوسٹ کردہ سروس کے شواہد کی حد: یہاں بیان کردہ سرور سائیڈ قواعد کی 2026-09-01 کو دانستہ طور پر نجی رکھے گئے Radar سرور کی عین ریویژن main@dce70f004364912f3f144cdb69f4cbcde16093ed کے برخلاف تصدیق کی گئی تھی۔ وہ نفاذ اس OSS ریپوزٹری میں تقسیم نہیں کیا جاتا؛ ہوسٹ کردہ دستیابی ایک الگ عملی حالت ہے۔

Radar ایک اختیاری ایڈ آن ہے جو ریلیز کی بنیادی فہرست (FREE_MODEL_BUDGETS در open-sse/config/freeModelCatalog.data.ts) کے اوپر ایک دستخط شدہ، تازہ طور پر مرتب کردہ مفت ماڈلز کی فہرست کی تہہ چڑھاتا ہے۔ اس کے وجود کی وجہ یہ ہے کہ مفت درجے کا منظرنامہ ریلیز کی رفتار سے زیادہ تیزی سے بدلتا ہے — فراہم کنندگان ریلیزوں کے درمیان مفت کوٹے شامل، کم، یا ختم کرتے ہیں، جبکہ بنیادی فہرست کو صرف نیا ورژن جاری ہونے پر تازہ کیا جا سکتا ہے۔

جو کچھ آج مفت ہے وہ ریموٹ فیڈ کی وجہ سے مفت ہونا بند نہیں ہوتا۔ Radar کبھی بھی بنیادی اندراج کو پے وال کے پیچھے نہیں ڈالتا؛ یہ صرف پڑھنے کے وقت حدود/حالت کے فیلڈز تازہ کرتا ہے اور ریلیزوں کے درمیان نئے دریافت شدہ مفت ماڈلز کی تہہ شامل کر سکتا ہے۔ آپریٹر اب بھی کسی ماڈل کو مقامی طور پر چھپا سکتا ہے، اور اسی ڈیش بورڈ سے اسے بحال کر سکتا ہے۔ بنیادی فہرست کو خود کبھی بھی ڈسک پر تبدیل نہیں کیا جاتا — ذیل میں پڑھنے کے وقت اوورلے کے انضمام کے قواعد دیکھیں۔

---

v3.8.51 میں فراہمی کی حالت

درج ذیل حالت یہ واضح کرتی ہے کہ یہ OSS ریلیز بعد کے Radar ورک اسٹریمز کے مقابلے میں کیا نافذ کرتی ہے۔ یہ کوڈ کی سطح کی حالت ہے، نہ کہ اس بات کا وعدہ کہ کوئی مخصوص ہوسٹ کردہ تعیناتی یا بیرونی انضمام فی الحال دستیاب ہے۔

شعبہ	اس ریلیز میں حالت
دستخط شدہ کیٹلاگ کلائنٹ	RADAR_ENABLED کے پیچھے نافذ ہے، جس میں علیحدہ آپٹ اِن، Ed25519 توثیق، مقامی انکرپٹ شدہ ترتیبات/کیش، مستقل ڈسپلے/فعال اوور رائیڈز، قابلِ واپسی ٹومب اسٹونز، شیڈیولر، اور ڈیش بورڈ شامل ہیں۔
معاون کی فعالیت	ڈیش بورڈ سرور پر ہوسٹ کردہ GitHub کلیم فلو سے لنک کرتا ہے اور موجودہ omr_… کلید قبول کرتا ہے۔ معاون کی اہلیت کا تعین نجی سروس کرتی ہے؛ OSS کلائنٹ میں کوئی GitHub ٹوکن یا اجرا کی منطق موجود نہیں۔
سپورٹر کلید کی فعالیت	نافذ ہے۔ خام کلید کی توثیق کی جاتی ہے، اسے محفوظ حالت میں انکرپٹ کیا جاتا ہے، پڑھنے پر ماسک کیا جاتا ہے، اور صرف سرور سائیڈ سنک کے ذریعے بھیجا جاتا ہے۔ کلید تبدیل یا صاف کرنے سے استحقاق سے متعلق چاروں فیڈ کیشز کالعدم ہو جاتے ہیں۔
ریفرل لنکس	علیحدہ طور پر دستخط شدہ، ہر گھنٹے تازہ ہونے والی فیڈ کے طور پر نافذ ہیں۔ مستقل لنکس کمیونٹی درجے کے لیے فوراً دستیاب ہیں؛ محدود مہمات بدستور لائیو درجے کا ڈیٹا رہتی ہیں۔
سپورٹر پیشکشیں	علیحدہ دستخط شدہ، صرف لائیو فیڈ اور ڈیش بورڈ صفحے کے طور پر نافذ ہیں۔ کلائنٹ بند بینیفٹ اسکیما کی دوبارہ توثیق کرتا ہے، آخری درست کیش محفوظ رکھتا ہے، میعاد ختم شدہ اندراجات فلٹر کرتا ہے، اور شراکت داروں کی پیشکشوں پر واضح لیبل لگاتا ہے۔
انٹیلی جنس اور سپورٹر کی شناخت	Radar کی ملکیت والے ELO، فہرست کی حقائق پر مبنی تازگی/رجحان، تصدیق شدہ مقامی سپورٹر بیج، ڈیش بورڈ صفحے، اور صرف مقامی CLI حالت/سنک کمانڈز کے ساتھ ایک سخت دستخط شدہ صرف لائیو فیڈ کے طور پر نافذ ہے۔
ادائیگیاں اور لین دین کی ای میل	OSS کلائنٹ میں نافذ نہیں ہیں۔ خریداری، عطیہ، رسید کا جائزہ، بازیابی، اور میل کی ترسیل نجی سروس کے دائرۂ کار میں آتے ہیں؛ ہوسٹ کردہ دستیابی اب بھی اس کی زیرِ نگرانی تعیناتی اور فراہم کنندہ کی تشکیل پر منحصر ہے۔
ریسرچ ایجنٹ ورک اسٹریم	اس کلائنٹ ریلیز کا حصہ نہیں ہے۔ مرتب کردہ فیڈ کا مواد بدستور سرور سائیڈ ڈیٹا رہتا ہے؛ OmniRoute کی تنصیب میں کوئی خود مختار ریسرچ ایجنٹ نہیں چلتا۔

---

عوامی اعلانات پڑھنے والا

عمومی اعلانات پڑھنے والا Radar فیچر فلیگ سے الگ ہے۔ ڈیش بورڈ کا Home اور Changelog ویور ایک سادہ GET کے ذریعے ریپوزٹری کی عوامی news.json فائل NEWS_JSON_URL (src/shared/utils/releaseNotes.ts) سے حاصل کرتے ہیں۔ وہ Radar کی کوئی ترتیب، پرامپٹ، فراہم کنندہ کی کنفیگریشن، استعمال کا ریکارڈ، یا مقامی طور پر برخاست کرنے کی حالت نہیں بھیجتے۔

news.json، parseNewsPayload() میں نافذ کردہ بند v2 اسکیما استعمال کرتی ہے:

• schemaVersion: 2 اور محدود items[] مجموعہ؛
• اعلان کے مستحکم اور منفرد id اقدار؛
• واضح active اور ISO publishedAt فیلڈز؛
• لازمی انگریزی متن، اختیاری مقامی زبان کے متن کے ساتھ؛
• اختیاری، اسناد سے پاک HTTPS لنکس اور اجازت یافتہ فہرست میں شامل آئیکن؛
• جدید ترین فعال اعلان کا پہلے انتخاب، لوکیل کے لیے انگریزی پر واپسی، اور ہر ID کے لحاظ سے مقامی برخاستگی۔

پارسر عارضی طور پر سابقہ واحد { active, title, message, ... } ساخت کو قبول کرتا ہے تاکہ پرانے فورکس خراب Changelog منظر کے بغیر منتقل ہو سکیں۔ غیر موزوں فیڈز غیر فعال رہتی ہیں۔ Radar لانچ اندراج active: false کے ساتھ فراہم کیا جاتا ہے؛ اسے true میں تبدیل کرنا مرج اور ڈیپلائمنٹ کے بعد ریلیز کی ایک الگ کارروائی ہے اور اس سے RADAR_ENABLED یا فیڈ سنک کی آزاد رضامندی تبدیل نہیں ہوتی۔

---

فلیگ: RADAR_ENABLED (بطور ڈیفالٹ بند)

Radar کو ابتدا سے انتہا تک RADAR_ENABLED فیچر فلیگ کے ذریعے محدود کیا گیا ہے (src/shared/constants/featureFlagDefinitions.ts، زمرہ policies، defaultValue: "false")۔

جب فلیگ بند ہو تو یہ سطح موجود ہی نہیں ہوتی:

• مقامی ماڈل کی حالت پڑھنے اور لکھنے سمیت تمام /api/radar/* اینڈپوائنٹس، کسی Radar ماڈیول کو چھیڑنے سے پہلے 404 لوٹاتے ہیں۔
• ڈیش بورڈ اسکرینیں (/dashboard/radar، /dashboard/radar/setup، /dashboard/radar/combos، /dashboard/radar/offers، /dashboard/radar/intel) notFound() رینڈر کرتی ہیں۔
• getRadarCatalog() (src/lib/radar/index.ts) بغیر تبدیلی کے بنیادی کیٹلاگ لوٹاتا ہے — اندراجات کی وہی تعداد، وہی اقدار، ہر اندراج پر origin: "baseline" ٹیگ — اور کبھی فیڈ کیش نہیں پڑھتا۔
• Radar کی کوئی نیٹ ورک کال کبھی نہیں کی جاتی؛ ہر سنک ماڈیول fetch کو چھیڑنے سے پہلے { status: "disabled" } لوٹاتا ہے۔

یہ ایک سخت سپر سیٹ گیٹ ہے: فلیگ کو آن کرنے سے صرف اسکرینیں دستیاب ہوتی ہیں، اس سے زیادہ کچھ نہیں۔ یہ ڈیٹا اپ لوڈ نہیں کرتا، پس منظر میں سنک شروع نہیں کرتا، اور روٹنگ یا ماڈل کے انتخاب کو تبدیل نہیں کرتا — ذیل میں الگ رضامندی ملاحظہ کریں۔

---

ڈیٹا سنک ایک الگ رضامندی ہے — رازداری کا وعدہ

RADAR_ENABLED آن کرنے سے صرف UI دستیاب ہوتا ہے۔ فیڈ سنک کرنے کے لیے ایک دوسری، آزاد رضامندی درکار ہے جو radar_settings.opt_in (src/lib/db/radar.ts، مائیگریشن 136_radar_cache_settings.sql) میں محفوظ ہوتی ہے۔ syncRadar() کوئی بھی نیٹ ورک کال کرنے سے پہلے فلیگ اور رضامندی دونوں کو چیک کرتا ہے:

فلیگ بند        → { status: "disabled" }   — کوئی نیٹ ورک کال نہیں
رضامندی false   → { status: "opt_out" }    — کوئی نیٹ ورک کال نہیں

جب دونوں آن ہوں تو سنک کا راستہ یہ ہے:

1. GET <feed base URL>/v1/catalog/latest، x-omniroute-radar-schema: 2 اور ایک اختیاری Authorization: Bearer <supporter key> ہیڈر کے ساتھ (ذیل میں دیکھیں)۔ اسکیما ہیڈر موجود نہ ہونے پر سرور الگ سے دستخط شدہ v1 عبوری آرٹیفیکٹ کو بطور ڈیفالٹ استعمال کرتے ہیں، تاکہ پرانے انسٹال شدہ کلائنٹس کو اپ ڈیٹس ملتی رہیں۔
2. یہ صرف ڈاؤن لوڈ پر مشتمل ایپلیکیشن بہاؤ ہے، لیکن پھر بھی یہ ایک HTTPS درخواست ہے۔ ہوسٹ کردہ انفراسٹرکچر کو ماخذ IP جیسا معمول کا کنکشن میٹا ڈیٹا موصول ہوتا ہے۔ جب کوئی سپورٹر کلید کنفیگر کی گئی ہو تو سنک اس کلید کو Bearer ہیڈر میں بھی بھیجتا ہے تاکہ سروس استحقاق کا تعین کر سکے۔ اوپر شواہد کی حد میں شناخت کردہ نجی سرور کی عین ریویژن پر، فیڈ درخواستوں کا حساب کتاب کلیدوں کے ہیش، مجموعی استعمال، اور دستی طور پر غلط استعمال کے جائزے کے لیے IP کے روزانہ تبدیل ہونے والے مختصر HMAC کا استعمال کرتا ہے؛ ان جدولوں میں نہ کلید اور نہ ہی IP خام صورت میں محفوظ رہتا ہے۔ انفراسٹرکچر ایکسیس لاگز اور خفیہ کردہ ڈیلیوری آؤٹ باکس الگ عملیاتی حدود ہیں۔
3. OmniRoute کبھی بھی پرامپٹس، جوابات، گفتگوئیں، فراہم کنندہ کی اسناد، ماڈل ٹریفک، اپ ٹائم، لیٹنسی، یا مقامی فراہم کنندہ کی کنفیگریشن Radar سروس کو نہیں بھیجتا۔
4. جواب کی تصدیق اور توثیق کی جاتی ہے، پھر اسے مقامی طور پر کیش کیا جاتا ہے (دیکھیں سیکیورٹی ماڈل)۔ Radar کے پاس سرور سائیڈ نیٹ ورک کے عین چار راستے ہیں: کیٹلاگ کے لیے syncRadar()، ریفرلز کے لیے syncRadarReferrals()، اور صرف سپورٹرز کے لیے آفرز اور Intel کی خاطر syncRadarOffers() / syncRadarIntel()۔

سپورٹر کلید ایک اختیاری Bearer ٹوکن (radar_settings.supporter_key) ہے جو فیڈ سروس کو یہ فیصلہ کرنے دیتا ہے کہ کون سا ٹیئر فراہم کیا جائے (دیکھیں ٹیئرز)۔ یہ:

• فراہم کنندہ کی اسناد کے لیے استعمال ہونے والے انہی AES-256-GCM encrypt()/decrypt() معاون فنکشنز (src/lib/db/encryption.ts) کے ذریعے محفوظ حالت میں خفیہ کردہ ہوتی ہے۔
• POST /api/radar/settings ({ supporterKey: "omr_" + 40 hex chars }) کے ذریعے مقرر کی جاتی ہے اور کبھی واپس ظاہر نہیں کی جاتی — جواب ایک مخفی صورت (omr_****abcd) لوٹاتا ہے۔
• اسے تبدیل یا صاف کرنے سے کیٹلاگ، ریفرلز، آفرز اور Intel کیشز ایٹمی انداز میں غیر مؤثر ہو جاتے ہیں۔ اگلا سنک/مطالعہ نئے استحقاق کا سرور سائیڈ پر تعین کرتا ہے؛ کلید محفوظ کرنے سے بذاتِ خود کوئی نیٹ ورک درخواست نہیں ہوتی اور نہ ہی یک بار استعمال ہونے والی ایکٹیویشن کلید خرچ ہوتی ہے۔
• سنک GET پر Bearer ٹوکن کے طور پر فیڈ سروس کو بھیجی جاتی ہے — کلید کے بارے میں اس کے علاوہ کچھ بھی کلائنٹ سے باہر نہیں جاتا۔

---

آپٹ اِن سے پہلے دکھائے جانے والے رسائی اور تحفظ کے قواعد

غیر فعال ڈیش بورڈ، فعال کرنے کی کسی بھی کارروائی سے پہلے src/app/(dashboard)/dashboard/radar/RadarAccessExplainer.tsx سے یہ قواعد دکھاتا ہے۔ رسائی کا مستند پیمانہ یہ ہے:

سطح	اہلیت	رسائی	تکرار/میعاد ختم ہونے کا قاعدہ
کمیونٹی	کوئی بھی شخص؛ کلید درکار نہیں	مکمل کیٹلاگ تقریباً 30 دن کی تاخیر سے	ہمیشہ دستیاب؛ کوئی اجرا نہیں
اسٹار + فالو	GitHub OAuth، repository پر اسٹار اور مالک کو فالو کرنے، دونوں کی تصدیق کرتا ہے	لائیو کیٹلاگ کو ایک بار پڑھنے کی رسائی، پھر کمیونٹی	ہر لاگ اِن پر ایک اجرا؛ دوبارہ کبھی جاری نہیں کیا جاتا
شراکت کنندہ Top 10	تازہ ترین مکمل ہفتہ وار درجہ بندی میں پوزیشنیں 1–10	365 لائیو دن	حسبِ ضرورت کلیم؛ درجہ بندی سے نکلنے پر دی گئی مدت کم نہیں ہوتی
شراکت کنندہ Top 100	اس درجہ بندی میں پوزیشنیں 11–100	90 لائیو دن	حسبِ ضرورت/یکساں نتیجہ دینے والے کلیم کا وہی قاعدہ
معاون کی خریداری	6 ماہ، 1 سال، یا تاحیات کی ایک بار کی خریداری	لائیو کیٹلاگ، دستخط شدہ لائیو آفرز، اور Intel	خودکار تجدید نہیں
عطیہ/دستی گرانٹ	مالک کے زیرِ جائزہ عطیہ یا دنوں کی واضح تعداد/تاحیات کے لیے مالک کی جانب سے گرانٹ	دی گئی مدت کے لیے وہی لائیو استحقاق	آڈٹ شدہ، یکساں نتیجہ دینے والی گرانٹ

ضم شدہ PRs، commits، اور تبدیل شدہ لائنیں صرف درجہ بندی کے اِن پٹس ہیں۔ Top 100 سے باہر لاگ اِن کرنے والے کو PRs کی تعداد سے قطع نظر شراکت کنندہ گرانٹ نہیں ملتی۔ محدود مدت کی خریداریاں، عطیات، شراکت کنندہ کی مدتیں، اور دستی گرانٹس موجودہ تاریخِ تنسیخ کے بعد جمع ہوتی جاتی ہیں؛ تاحیات رسائی سب پر غالب رہتی ہے۔ درجہ بندی میں تبدیلی پہلے سے دی گئی مدت کو کبھی سابقہ اثر کے ساتھ منسوخ یا مختصر نہیں کرتی۔

میزبانی شدہ لائسنس ذاتی ہے اور صارف کو دکھایا جانے والا قاعدہ یہ ہے کہ ایک وقت میں صرف ایک فعال انسٹالیشن ہو سکتی ہے۔ یہ ریلیز ہارڈ ویئر لاک کا دعویٰ نہیں کرتی: OSS سنک نہ تو ہارڈ ویئر کا فنگر پرنٹ بناتا ہے اور نہ ہی cryptographic ڈیوائس لیز برقرار رکھتا ہے۔ اوپر دی گئی تصدیق شدہ پرائیویٹ سرور revision میں نافذ کردہ عمل درآمد، استحقاق کی توثیق کے ساتھ ایک دستی جائزے کا سگنل ہے، جو اس وقت پیدا ہوتا ہے جب ایک ہی لائیو کلید 24 گھنٹوں کے اندر چوتھے منفرد IP سے دیکھی جائے۔ یہ سگنل کبھی بھی خودکار طور پر کسی کلید کو بلاک یا منسوخ نہیں کرتا۔ بازیافت، موجودہ تاریخِ تنسیخ کو برقرار رکھتے ہوئے گم شدہ کلید کو منسوخ کرکے اس کی جگہ نئی کلید جاری کرتی ہے؛ یہ خریدی یا دی گئی مدت کو دوبارہ شروع نہیں کرتی۔

لائیو آفرز دستی طور پر مرتب کی جاتی ہیں اور تبدیل یا ختم ہو سکتی ہیں۔ آپٹ اِن اسکرین رازداری کی درست حد بھی بیان کرتی ہے: دستخط شدہ کیٹلاگ/ریفرل metadata ڈاؤن لوڈ کیا جاتا ہے؛ ایک درست کلید اضافی طور پر دستخط شدہ آفرز اور Intel کو اَن لاک کرتی ہے؛ Bearer کلید اور معمول کا کنکشن metadata میزبانی شدہ سروس تک پہنچتے ہیں؛ prompts، responses، conversations، provider credentials، model traffic، uptime، latency، اور مقامی provider configuration وہاں نہیں پہنچتے۔

---

سپورٹر کلید حاصل کرنا

ایکٹیویشن اسکرین (/dashboard/radar) سپورٹر کلید حاصل کرنے کے لیے دو طریقوں کے لنکس فراہم کرتی ہے۔ خود OSS ریپو کبھی کوئی کلید جاری نہیں کرتا، ادائیگی کا کوڈ کبھی نہیں چلاتا، اور کبھی کوئی قیمت بیان نہیں کرتا — قیمت کا تعین اور اس کی نمائش مکمل طور پر منزل کے صفحات پر ہوتی ہے، اس ریپو میں نہیں (خصوصی فیصلہ D14)۔

• "میں ایک کنٹریبیوٹر ہوں" — RADAR_CONTRIBUTOR_CLAIM_URL (ڈیفالٹ https://radar.omniroute.online/auth/github) کھولتا ہے، جو نجی Radar سرور پر ہوسٹ کیا گیا GitHub OAuth کلیم فلو ہے۔ یہ تازہ ترین مکمل ہفتہ وار درجہ بندی چیک کرتا ہے: سرفہرست 10 کو 365 دن اور 11–100 پوزیشنز کو 90 دن ملتے ہیں۔ سرفہرست 100 سے باہر، PR کی تعداد کبھی رسائی فراہم نہیں کرتی؛ اس کے بجائے یہ فلو علیحدہ star + follow سنگل یوز لیول چیک کرتا ہے۔
• "پروجیکٹ کو سپورٹ کریں" — RADAR_SUPPORTER_PLANS_URL (ڈیفالٹ https://radar.omniroute.online/planos) کھولتا ہے، جو ایک بار کی ادائیگی والے 6 ماہ، 1 سال، اور لائف ٹائم آپشنز کا ہوسٹ کردہ صفحہ ہے۔ OSS صفحہ پھر بھی کوئی مالی قدر نہیں دکھاتا۔

دونوں URLs کو سرور سائیڈ پر حل کیا جاتا ہے (src/lib/radar/links.ts، وہی env-override پیٹرن جو RADAR_FEED_URL کے لیے ہے) اور موجودہ GET /api/radar/settings رسپانس (contributorClaimUrl، supporterPlansUrl) کے ذریعے ڈیش بورڈ تک پہنچایا جاتا ہے — کلائنٹ کمپوننٹ خود کبھی process.env نہیں پڑھتا۔

Var	مقصد
RADAR_CONTRIBUTOR_CLAIM_URL	کنٹریبیوٹر کلیم URL کو اوور رائیڈ کرتا ہے (ڈیفالٹ https://radar.omniroute.online/auth/github)۔
RADAR_SUPPORTER_PLANS_URL	سپورٹر پلانز URL کو اوور رائیڈ کرتا ہے (ڈیفالٹ https://radar.omniroute.online/planos)۔

گم شدہ سپورٹر کلید کی بازیابی

ہوسٹ کردہ سروس کا ریکوری انٹری پوائنٹ https://radar.omniroute.online/recover ہے؛ اس کا لنک پلانز کے صفحے سے بھی دیا گیا ہے۔ ریکوری مکمل طور پر OSS کلائنٹ سے باہر رہتی ہے کیونکہ مقامی انسٹالیشن کو خریدار/کنٹریبیوٹر کا ای میل کبھی موصول نہیں ہوتا اور وہ اپنی انکرپٹ شدہ سیٹنگز سے اصل کلید دوبارہ تشکیل نہیں دے سکتی۔

1. کلید سے وابستہ ای میل جمع کریں۔ قابل بازیابی لائسنس موجود ہو یا نہ ہو، سروس وہی قبولیت کا صفحہ واپس کرتی ہے، لہٰذا فارم اکاؤنٹس کو ظاہر نہیں کرتا۔
2. اہل ہونے کی صورت میں، ڈیلیوری ورکر ایک مختصر مدت کے، یک بار استعمال ہونے والے لنک کو بھیجتا ہے۔ اسے کھولنے پر ٹوکن فوری طور پر ایک عارضی، انکرپٹ شدہ HttpOnly/Secure کوکی میں منتقل ہو جاتا ہے اور صاف /recover URL پر ری ڈائریکٹ کر دیتا ہے؛ صفحے میں کوئی ٹوکن، ای میل، پرانی کلید، یا متبادل کلید شامل نہیں ہوتی۔
3. منسوخی کی تصدیق کریں۔ نجی سروس پچھلی کلید کو منسوخ کرتی ہے، اسی پلان/میعاد کے ساتھ متبادل کلید بناتی ہے، اور ایک ہی ٹرانزیکشن میں اسے ای میل کے لیے قطار میں شامل کرتی ہے۔ متبادل کلید کبھی براؤزر کو واپس نہیں کی جاتی۔
4. متبادل کلید کو /dashboard/radar میں پیسٹ کریں۔ اب پرانی کلید کو لازماً community تک تنزل کرنا چاہیے؛ متبادل کلید کو تصدیق شدہ live سنک فراہم کرنا چاہیے۔ اسی ریکوری لنک کو دوبارہ کھولنے پر عمومی ناموزوں/میعاد ختم ہونے والا رسپانس ملنا چاہیے۔

ہوسٹ کردہ ریکوری روٹ اور میل ورکر کوڈ میں موجود ہو سکتے ہیں، جبکہ کسی مخصوص ڈیپلائمنٹ میں پھر بھی دستیاب نہ ہوں۔ جب تک سرور ڈیپلائے نہ ہو جائے، ڈیلیوری پرووائیڈر کو ایک کنٹرول شدہ وصول کنندہ کے ساتھ کنفیگر نہ کر دیا جائے، اور مکمل یک بار استعمال ہونے والے لنک کو ٹیسٹ نہ کر لیا جائے، اس فلو کو پروڈکشن کے لیے تیار قرار نہ دیں۔

جب کسی وزیٹر کے پاس کلید (omr_ + 40 hex حروف) آ جائے، تو ایکٹیویشن اسکرین (src/app/(dashboard)/dashboard/radar/page.tsx) بنیادی راستے کے طور پر کلید پیسٹ کرنے کا ان پٹ فراہم کرتی ہے: کلید پیسٹ کر کے جمع کرانے سے ایک ہی کال میں POST /api/radar/settings ({ optIn: true, supporterKey }) بھیجا جاتا ہے — کلید پیسٹ کرنے سے وہ سیٹ بھی ہوتی ہے اور آپٹ اِن بھی، جس سے اسکرین اَن لاک ہو جاتی ہے۔ فارمیٹ (omr_ + 40 hex حروف) کو UX کی سہولت کے لیے پہلے مشترکہ isValidSupporterKeyFormat() ہیلپر (src/lib/radar/supporterKey.ts) کے ذریعے کلائنٹ سائیڈ پر چیک کیا جاتا ہے؛ ہر صورت میں سرور کا Zod schema ہی حتمی جانچ ہے۔ ایک بار کلید سیٹ ہو جانے پر، ایکٹیویشن اسکرین خالی ان پٹ کے بجائے ماسک شدہ شکل (supporterKeyMasked از GET /api/radar/settings) دکھاتی ہے، اور نئی کلید پیسٹ کرنے کے لیے "کلید تبدیل کریں" کنٹرول فراہم کرتی ہے — اصل کلید دوبارہ کبھی نہیں دکھائی جاتی۔ اوپر موجود دونوں کلیم/پلانز بٹن پہلی بار کلید حاصل کرنے کا ذریعہ رہتے ہیں؛ یہ ان پٹ وہ جگہ ہے جہاں پہلے سے کلید رکھنے والا آپریٹر اسے فعال کرتا ہے۔

اینڈ ٹو اینڈ ایکٹیویشن اور رہنمائی پر مبنی سیٹ اپ

نجی فیڈ سروس اور اس OSS کلائنٹ کے درمیان دانستہ طور پر محدود حد ہے: سروس سپورٹر کلید جاری کرتی اور اس کی توثیق کرتی ہے، جبکہ مقامی OmniRoute انسٹالیشن کلید کو انکرپٹ کرتی ہے، دستخط شدہ آرٹیفیکٹس کو سرور سائیڈ پر سنک کرتی ہے، اور پرووائیڈر سیٹ اپ کی رہنمائی کرتی ہے۔ معاون توثیق کی ترتیب یہ ہے:

1. شراکت کنندہ کلیم، plans/checkout، ریکوری کے عمل، یا کسی مجاز نجی سرور آپریٹر سے نئی جاری کردہ یا بازیافت شدہ کلید حاصل کریں۔ خام کلید کو لاگز، اسکرین شاٹس، مسئلے کے تبصروں، یا کمانڈ لائن آرگیومنٹس میں پیسٹ نہ کریں۔
2. مقامی OmniRoute انسٹالیشن پر RADAR_ENABLED فیچر فلیگ فعال کریں۔ اس سے UI ظاہر ہو جاتا ہے، لیکن علیحدہ آپٹ اِن محفوظ کیے جانے تک یہ نیٹ ورک پر غیر فعال رہتا ہے۔
3. /dashboard/radar کھولیں، کلید پیسٹ کریں، اور فعال کریں۔ براؤزر مقامی طور پر ایک POST /api/radar/settings درخواست { optIn: true, supporterKey } کے ساتھ بھیجتا ہے؛ کلید مقامی طور پر انکرپٹ کی جاتی ہے اور جواب میں صرف omr_****<last4> شامل ہوتا ہے۔
4. ایکٹیویشن اسکرین کو کیٹلاگ سنک چلانے دیں، یا ابھی سنک کریں منتخب کریں۔ تصدیق کریں کہ صفحہ live، فیڈ ورژن، اور حاصل کرنے کا وقت دکھاتا ہے۔ تصدیق شدہ مقامی تشخیص کے لیے، GET /api/radar/status کلید واپس کیے بغیر آپٹ اِن/کلید کی موجودگی اور چاروں کیش حالتیں دکھاتا ہے۔ POST /api/radar/sync-all کیٹلاگ، ریفرلز، آفرز، اور Intel کو واضح طور پر ریفریش کر سکتا ہے۔
5. /dashboard/radar/setup?provider=<provider> کھولیں۔ پرووائیڈر کے زیرِ انتظام اسناد کے URL پر جائیں، API کلید شامل کریں منتخب کریں، اصل پرووائیڈر فارم کے ذریعے محفوظ کریں، گائیڈ پر واپس آئیں، اور کنکشن ٹیسٹ کریں چلائیں۔ گائیڈ معمول کے /api/providers اور /api/providers/<connection-id>/test روٹس استعمال کرتی ہے؛ یہ کوئی متوازی Radar سند تخلیق نہیں کرتی۔
6. کم از کم دو ہم آہنگ پرووائیڈر کنکشن فعال ہونے کے بعد /dashboard/radar/combos کھولیں۔ تجویز کردہ فیملی کا جائزہ لیں اور موجودہ کومبو API کے ذریعے کومبو تخلیق کریں۔ آفرز اور Intel علیحدہ، صرف لائیو، دستخط شدہ کیشز رہتے ہیں اور انہیں ان کے مخصوص Radar صفحات پر چیک کیا جا سکتا ہے۔
7. /dashboard/radar اور سیٹ اپ صفحہ دوبارہ لوڈ کریں۔ آپٹ اِن، ماسک شدہ کلید کی حالت، تصدیق شدہ کیش، محفوظ شدہ پرووائیڈر کنکشن، اور ٹیسٹ ایکشن کو دوبارہ لوڈ ہونے کے بعد بھی برقرار رہنا چاہیے۔ ثبوت صرف اس وقت حاصل کریں جب خام کلید اور پرووائیڈر کی سند مزید نظر نہ آ رہی ہوں۔

کلید محفوظ کرنا بذاتِ خود لائیو استحقاق کا ثبوت نہیں ہے۔ ثبوت نجی سروس کے GET /v1/license/check نتیجے، OSS کیٹلاگ کے فراہم کردہ live ٹیئر، تصدیق شدہ دستخطی کیش، اور اصل پرووائیڈر کنکشن/ٹیسٹ کے عمل کا مجموعہ ہے۔ غلط، زائد المیعاد، یا منسوخ شدہ کلید محفوظ طریقے سے کیٹلاگ کو community پر لے جاتی ہے؛ اسے کامیاب لائیو کلید کی توثیق کے طور پر رپورٹ نہیں کیا جانا چاہیے۔

نجی ایڈمن پینل لنک

RADAR_ADMIN_URL اختیاری طور پر Costs سائڈبار سیکشن میں صارف کو دکھائی دینے والے Radar آئٹم کے فوراً بعد Radar Admin ↗ شامل کرتا ہے۔ دانستہ طور پر اس کی کوئی ڈیفالٹ قدر نہیں ہے: جب ویری ایبل سیٹ نہ ہو یا غلط ہو، تو جامد سائڈبار، کمانڈ پیلیٹ، اور سائڈبار حسبِ ضرورت بنانے والی اسکرین میں کوئی ایڈمن آئٹم یا نجی URL شامل نہیں ہوتا۔

قدر کا تعین سرور پر کیا جاتا ہے اور مینجمنٹ سے تصدیق شدہ GET /api/settings جواب کے ذریعے صرف تصدیق شدہ ڈیش بورڈ سیشن تک، یا مقامی بغیر لاگ اِن بوٹسٹریپ کے دوران قابلِ اعتماد لوپ بیک مالک تک پہنچایا جاتا ہے۔ CLI، اندرونی سروس، اور manage-scope API کلید کی توثیق کو یہ قدر موصول نہیں ہوتی۔ بیرونی لنک، جو noopener noreferrer کے ساتھ کھلتا ہے، بنانے سے پہلے براؤزر جواب کی دوبارہ توثیق کرتا ہے۔

اسناد سے پاک HTTPS ٹنل/tailnet URL استعمال کریں۔ سادہ HTTP صرف لوپ بیک SSH فارورڈ، جیسے http://127.0.0.1:9351، کے لیے قبول کیا جاتا ہے؛ دیگر اسکیمیں، شامل شدہ اسناد، ناقص URLs، اور ریموٹ HTTP منازل محفوظ طور پر ناکام ہو جاتی ہیں اور نیویگیشن کو غیر فعال چھوڑ دیتی ہیں۔

---

سیکیورٹی ماڈل

عین بائٹس پر Ed25519 دستخط

فیڈ پے لوڈ پر Ed25519 کے ذریعے دستخط کیے جاتے ہیں۔ verifyFeedBytes() (src/lib/radar/verify.ts) وائر کے ذریعے موصول ہونے والی عین ریسپانس بائٹس پر دستخط کی تصدیق کرتا ہے — تصدیق سے پہلے پے لوڈ کو کبھی دوبارہ سیریلائز نہیں کیا جاتا، اس لیے بائٹ بہ بائٹ دوبارہ انکوڈنگ خاموشی سے دستخط کی جانچ کو نہ غیر مؤثر بنا سکتی ہے، نہ اس سے بچ سکتی ہے۔ تصدیق میں ناکامی (invalid_signature) پے لوڈ کو پارس یا کیش کیے جانے سے پہلے ہی سنک روک دیتی ہے۔

پِن شدہ عوامی کلید + روٹیشن

تصدیقی عوامی کلید src/lib/radar/pinnedKeys.ts (PINNED_FEED_PUBLIC_KEYS) میں پِن کی گئی ہے؛ یہ ایک ارے ہے تاکہ روٹیشن سے پہلے نئی کلید کو شروع میں شامل کیا جا سکے، جبکہ پچھلی کلید سے دستخط شدہ پرانی کیش شدہ فیڈز دوبارہ سنک ہونے تک درست رہیں۔

فورک کے موافق env اوور رائیڈز

دو env vars فورکس اور خود میزبانی کرنے والوں کو ڈیفالٹ OmniRoute سروس کے بجائے کلائنٹ کو اپنی فیڈ کی طرف بھیجنے دیتے ہیں — ذیل میں فیڈ کو خود میزبانی کرنے کا طریقہ دیکھیں:

متغیر	مقصد
RADAR_FEED_URL	فیڈ کے بنیادی URL کو اوور رائیڈ کرتا ہے (ڈیفالٹ https://radar.omniroute.online)۔
RADAR_FEED_PUBKEY	پِن شدہ عوامی کلید (base64-DER SPKI یا PEM) کو اوور رائیڈ کرتے ہوئے بلٹ اِن ارے کو اس واحد کلید سے بدلتا ہے۔

ورژن کی کم از کم حد

syncRadar() ایسی ڈاؤن لوڈ شدہ فیڈ کو مسترد کرتا ہے جس کا version موجودہ کیش شدہ ورژن سے لازماً نیا نہ ہو (compareVersions()، نقطوں سے جدا YYYY.MM.DD.n موازنہ) — { status: "stale" }۔ یہ کسی متاثرہ یا غلط کنفیگر شدہ فیڈ اینڈ پوائنٹ کو کلائنٹ پرانا، مختلف دستخط شدہ پے لوڈ واپس دینے سے روکتا ہے۔

دو تاریخیں، اور دونوں کیوں رکھی جاتی ہیں

کیش شدہ فیڈ میں دو الگ تاریخیں ہوتی ہیں، اور انہیں ایک سمجھنے سے بچنا ہی دونوں کو رکھنے کی بنیادی وجہ ہے:

فیلڈ	ماخذ	کس سوال کا جواب دیتی ہے
generatedAt	دستخط شدہ فیڈ باڈی	ڈیٹا کتنا پرانا ہے
fetchedAt	اس انسٹال کی گھڑی	اس انسٹال نے اسے کب ڈاؤن لوڈ کیا

چند منٹ پہلے حاصل کی گئی فیڈ میں کئی ہفتے پرانے اعداد و شمار ہو سکتے ہیں، اس لیے صرف fetchedAt کسی آپریٹر کو یہ نہیں بتا سکتا کہ اوورلے اپنے بنیادی ڈیٹا سے زیادہ تازہ ہے یا نہیں۔ دونوں radar_feed_cache میں محفوظ کیے جاتے ہیں، getRadarCatalog().meta کے ذریعے واپس کیے جاتے ہیں، اور GET /api/radar/status کے ذریعے الگ الگ رپورٹ کیے جاتے ہیں۔ generated_at کالم کے وجود میں آنے سے پہلے کیش کی گئی قطار (مائیگریشن 163) واپس پڑھنے پر null دیتی ہے — نامعلوم قدر، فیچ کا وقت مستعار لینے کے بجائے نامعلوم ہی رہتی ہے۔ radar_referrals_cache نے مائیگریشن 142 سے اپنا generated_at برقرار رکھا ہوا ہے۔

مندرجہ بالا ورژن کی کم از کم حد version کا موازنہ کرتی ہے، دونوں تاریخوں میں سے کسی کا نہیں۔

دو خلا باقی ہیں، اور دونوں دانستہ ہیں: ڈیش بورڈ اب بھی صرف Last fetched دکھاتا ہے، اس لیے وہاں بلڈ کی تاریخ دکھانے کے لیے ایک نیا لیبل (اور اس کی 41 لوکیل اندراجات) درکار ہیں؛ نیز آفرز اور انٹیلیجنس کیشز بلڈ کی تاریخ بالکل محفوظ نہیں کرتے، اگرچہ ان کے فیڈ اسکیما میں یہ موجود ہے — لہٰذا GET /api/radar/status ان دونوں کے لیے null رپورٹ کرنے کے بجائے یہ فیلڈ شامل ہی نہیں کرتا، کیونکہ null کو "نامعلوم" سمجھا جائے گا۔

اسکیما کی توثیق

ڈاؤن لوڈ شدہ بائٹس کو دستخط کی تصدیق کے بعد RadarFeedSchema (src/lib/radar/feedSchema.ts، ایک Zod اسکیما) کے مطابق پارس اور توثیق کیا جاتا ہے۔ اسکیما میں عدم مطابقت کی صورت میں { status: "invalid_schema" } واپس آتا ہے اور کیش میں کوئی تبدیلی نہیں کی جاتی۔ ہر بار پڑھتے وقت کیش شدہ پے لوڈ کی دفاعی طور پر دوبارہ توثیق بھی کی جاتی ہے (getRadarCatalog()) — خراب یا دستی طور پر ترمیم شدہ کیش قطار پیش کیے جانے کے بجائے بنیادی ڈیٹا پر واپس چلی جاتی ہے۔

ریسپانس کے حجم کی حد (10 MB)

syncRadar() فیڈ کی ریسپانس باڈی پر 10 MB کی سخت حد نافذ کرتا ہے — دستخط شدہ فیڈ KB پیمانے کی JSON دستاویز ہے، اس لیے اس سے بڑا مواد کسی جائز کیٹلاگ کے بجائے غلط کنفیگر شدہ یا مخاصمانہ RADAR_FEED_URL (یا فضول مواد پیش کرنے والے اپ اسٹریم) کی نشاندہی کرتا ہے۔ نفاذ کی دو تہیں ہیں:

1. Content-Length کی پیشگی جانچ اس وقت باڈی کو مکمل طور پر پڑھنے سے گریز کرتی ہے جب ہیڈر پہلے ہی حد سے زیادہ قدر ظاہر کرے۔
2. باڈی پڑھتے وقت جاری مجموعے کی جانچ، Content-Length کی عدم موجودگی یا حقیقی حجم کو کم ظاہر کرنے کی صورت میں بھی حد نافذ کرتی ہے — صرف ہیڈر پر کبھی بھروسا نہیں کیا جاتا۔ جمع شدہ حصوں کو جوڑنے سے بعد میں Ed25519 دستخط کی جانچ کے لیے درکار عین بائٹس محفوظ رہتی ہیں۔

حد سے تجاوز کرنے پر { status: "too_large" } واپس آتا ہے اور کیش میں کوئی تبدیلی نہیں کی جاتی، بالکل اسی غیر تباہ کن طریقے کے مطابق جو سنک کی ہر دوسری ناکامی (invalid_signature، invalid_schema، stale) کے لیے اپنایا جاتا ہے۔

---

درجات: community اور live

فیڈ اسکیما میں tier: "community" | "live" فیلڈ شامل ہے، جس کا فیصلہ فیڈ سروس درخواست کی بنیاد پر سرور کی جانب سے کرتی ہے (سپورٹر کلید کی موجودگی اور درست ہونے کی بنیاد پر) — کلائنٹ کبھی اپنی درجہ بندی کا فیصلہ خود نہیں کرتا۔

• community — مفت کیٹلاگ، جو تازہ ترین ڈیٹا سے تقریباً 30 دن پیچھے ہوتا ہے۔ غیر مصدقہ یا غلط کلید والی درخواست کو یہی موصول ہوتا ہے۔
• live — تازہ ترین کیٹلاگ، جو درست سپورٹر کلید والی درخواستوں کو فراہم کیا جاتا ہے۔

غلط یا میعاد ختم شدہ سپورٹر کلید community میں تنزلی کا باعث بنتی ہے — یہ کبھی بھی خرابی نہیں ہوتی۔ سنک کا راستہ صرف دستخط/اسکیما/ورژن کی ناکامیوں (سب قابلِ بازیافت، اور سب کیش شدہ حالت کے لیے غیر مہلک) اور کامیاب { status: "updated", version, tier } کے درمیان فرق کرتا ہے۔ درجہ سے متعلق کوئی مخصوص خرابی کا راستہ نہیں جسے کلائنٹ کو سنبھالنے کی ضرورت ہو۔

فراہم کردہ درجہ دستخط شدہ باڈی سے نہیں، رسپانس ہیڈر سے آتا ہے

دستخط شدہ فیڈ باڈی کا tier فیلڈ ہمیشہ "live" ہوتا ہے — فیڈ سروس ہر ورژن کے لیے دو دستخط شدہ آرٹیفیکٹس فراہم کرتی ہے: live میں موجودہ مہمات شامل ہوتی ہیں جبکہ community انہیں شامل نہیں کرتا۔ ہر آرٹیفیکٹ پر اس کے اپنے عین بائٹس کے مطابق دستخط کیے جاتے ہیں۔ باڈی پھر بھی استحقاق کے فیصلے کا ذریعہ نہیں ہوتی؛ کسی درخواست کے لیے حقیقتاً منتخب کردہ درجہ x-omniroute-feed-tier رسپانس ہیڈر میں منتقل کیا جاتا ہے، جس کا فیصلہ درخواست کی Authorization کلید کی بنیاد پر سرور کی جانب سے ہوتا ہے۔

syncRadar() (src/lib/radar/sync.ts::parseServedTierHeader()) وہ واحد جگہ ہے جو اس درجہ کا تعین کرتی ہے جس پر کلائنٹ کو اعتماد کرنا چاہیے:

1. x-omniroute-feed-tier کو RadarTierSchema (Zod) کے ذریعے پارس کریں — غیر موجود ہیڈر، یا کوئی ایسی قدر جو عین "community" یا "live" نہ ہو، اسے غیر موجود سمجھا جاتا ہے (اس پر کبھی بھی جوں کا توں کیش/UI میں اعتماد نہیں کیا جاتا؛ اس میں وہ پرانے فیڈ سرورز بھی شامل ہیں جو اس ہیڈر سے پہلے کے ہیں)۔
2. صرف اس وقت دستخط شدہ باڈی کے tier فیلڈ (جو ہمیشہ "live" ہوتا ہے) پر واپس جائیں جب مرحلہ 1 سے کچھ حاصل نہ ہو۔
3. طے شدہ درجہ ہی کیش کیا جاتا اور { status: "updated", version, tier } کے طور پر واپس کیا جاتا ہے — ڈیش بورڈ یہی قدر دکھاتا ہے، خام باڈی فیلڈ کبھی نہیں۔

---

پڑھنے کے وقت اوورلے ضم کرنے کے قواعد

applyFeed() (src/lib/radar/applyFeed.ts) کیش شدہ فیڈ کو جامد بنیادی ڈیٹا کے اوپر getRadarCatalog() کے اندر، پڑھنے کے وقت ضم کرتا ہے۔ بنیادی ایرے (FREE_MODEL_BUDGETS) میں کبھی تبدیلی نہیں کی جاتی — ہر کال پر ایک نیا MergedEntry[] شمار کیا جاتا ہے۔

ترجیح کی ترتیب کے مطابق چار قواعد:

1. فیڈ کبھی بھی مقامی اوور رائیڈ کو نہیں مٹاتا۔ ہر فیلڈ کے لحاظ سے: اگر آپریٹر نے کسی اندراج کا کوئی فیلڈ حسبِ ضرورت تبدیل کیا ہو (localOverrides میپ، جس کی کلید provider:modelId ہے)، تو اس مخصوص فیلڈ کے لیے فیڈ کی قدر چھوڑ دی جاتی ہے — آپریٹر کی قدر غالب رہتی ہے۔
2. enabled: false اندراج کو ماخذ کی وضاحت کے ساتھ غیر فعال کرتا ہے۔ ایسا فیڈ اندراج جو کسی اندراج کو بند کرتا ہے، ضم شدہ نتیجے میں enabled: false اور disabledBy: "radar" مقرر کرتا ہے، تاکہ UI وضاحت کر سکے کہ کوئی اندراج دستیاب سے غیر فعال کیوں ہوا۔
3. صارف کا شامل کردہ ایسا اندراج جو فیڈ میں موجود نہ ہو، بغیر تبدیلی کے برقرار رہتا ہے۔ وہ اندراجات جو صرف بنیادی ڈیٹا میں موجود ہوں (یا مقامی طور پر شامل کیے گئے ہوں) اور جن کا کوئی متعلقہ فیڈ اندراج نہ ہو، بغیر تبدیلی کے گزر جاتے ہیں۔
4. ٹومب اسٹون کیا گیا اندراج کبھی بحال نہیں ہوتا۔ اگر آپریٹر نے واضح طور پر کسی اندراج کو حذف کیا ہو (tombstones سیٹ)، تو بعد کے ورژن میں فیڈ کی جانب سے اس provider:modelId کو دوبارہ شامل کرنا اسے واپس نہیں لاتا۔

قابلِ ترمیم فیلڈز اور ٹومب اسٹونز radar_local_model_state (مائیگریشن 153_radar_local_model_state.sql) میں مستقل طور پر محفوظ کیے جاتے ہیں۔ عوامی DB اڈاپٹر (src/lib/db/radar.ts) ان قطاروں کو applyFeed() کے زیرِ استعمال localOverrides میپ اور tombstones سیٹ میں تبدیل کرتا ہے؛ پروڈکشن getRadarCatalog()، فلیگ، کیش، اور اسکیما کی شرائط پوری ہونے کے بعد یہ حالت لوڈ کرتا ہے۔ صرف displayName اور enabled آپریٹر کے ذریعے قابلِ ترمیم ہیں۔ فراہم کنندہ/ماڈل کی شناخت، فیڈ کا ماخذ، کوٹا، صلاحیتیں، ToS، اور سیٹ اپ ڈیٹا کو اس سطح کے ذریعے نہیں لکھا جا سکتا۔

ڈیش بورڈ چار مقامی اعمال فراہم کرتا ہے:

• ترمیم مقامی نمائشی نام اور فعال حالت کو تبدیل کرتی ہے۔
• مقامی تبدیلیاں ری سیٹ کریں ٹومب اسٹون کو تبدیل کیے بغیر دونوں قابلِ ترمیم فیلڈز صاف کرتا ہے۔
• چھپائیں ایک ٹومب اسٹون بناتا ہے، تاکہ بعد کی فیڈ اپ ڈیٹس قطار کو دوبارہ تخلیق نہ کر سکیں۔
• بحال کریں ٹومب اسٹون ہٹا دیتا ہے؛ الگ سے محفوظ کیا گیا کوئی بھی اوور رائیڈ بدستور مؤثر رہتا ہے۔

فیڈ کا enabled: false حفاظتی استثنا برقرار رہتا ہے: یہ فرسودہ مقامی enabled: true پر غالب آتا ہے، ضم شدہ اندراج کو غیر فعال رکھتا ہے، اور disabledBy: "radar" ریکارڈ کرتا ہے۔

کیٹلاگ کی اشاعتیں schemaVersion: 2 استعمال کرتی ہیں۔ contextWindow اور tools، vision، اور thinking میں سے ہر ایک آزادانہ طور پر number | null / boolean | null ہوتا ہے: null کا مطلب نامعلوم ہے، جبکہ false کا مطلب ہے کہ D16 سے تصدیق شدہ فراہم کنندہ کا سرکاری ماخذ واضح طور پر بتاتا ہے کہ یہ صلاحیت موجود نہیں۔ اندرونی OmniRoute رجسٹری/ماڈل-اسپیک فلیگز کو کبھی براہِ راست فیڈ کے حقائق میں ترقی نہیں دی جاتی۔ کلائنٹ اب بھی v1 اسنیپ شاٹس قبول کرتا ہے؛ چونکہ پرانا بلڈر عدم موجودگی کے پلیس ہولڈر کے طور پر false استعمال کرتا تھا، اس لیے v1 کے false کو نامعلوم میں معمول پر لایا جاتا ہے جبکہ v1 کا true حقیقت پر مبنی رہتا ہے۔ نامعلوم اسکیما ورژنز محفوظ انداز میں ناکام ہوتے ہیں اور آخری درست کیش دستیاب رہتا ہے۔ ہر ایسے v2 ماڈل کے ساتھ، جس کا context/capability غیر null ہو، لازماً بلا اسناد HTTPS metadataEvidenceUrls[] ہونا چاہیے؛ بصورتِ دیگر اسکیما کی توثیق ناکام ہو جاتی ہے اور کیش تبدیل نہیں کیا جاتا۔ کیٹلاگ ٹیبل تینوں حالتوں کو بالترتیب ✓، ✕، اور ? کے طور پر دکھاتا ہے۔

رہنمائی شدہ کومبوز اور MCP رسائی

تصدیق شدہ familyId قدریں پڑھنے کے وقت اوورلے کے بعد برقرار رہتی ہیں اور خالص buildRadarComboSuggestions() ماڈیول (src/lib/radar/comboSuggestions.ts) کو چلاتی ہیں۔ کسی فیملی کی تجویز صرف تب دی جاتی ہے جب کم از کم دو مختلف فراہم کنندگان کے فعال کنکشن ہوں اور وہ عین منتخب کردہ ماڈل ID پیش کرتے ہوں۔ غیر فعال ماڈلز، غیر فعال فراہم کنندگان، غائب ماڈل IDs، صرف ایک رکن والی فیملیز، اور مبہم عرف/پریفکس مماثلتیں محفوظ انداز میں ناکام ہوتی ہیں۔ تجاویز موجودہ priority حکمتِ عملی استعمال کرتی ہیں، جس میں سب سے بڑے بار بار آنے والے ماہانہ بجٹ کو پہلے رکھا جاتا ہے؛ UI انہیں صرف POST /api/combos کے ذریعے تخلیق کرتا ہے۔

رہنمائی شدہ UI، /dashboard/radar/combos پر موجود ہے۔ یہ صرف مقامی GET /api/radar/catalog اور GET /api/combos/builder/options endpoints کو پڑھتا ہے۔ یہ کبھی Radar sync کو متحرک نہیں کرتا، provider credentials نہیں پڑھتا، اور combo database میں براہِ راست نہیں لکھتا۔

MCP clients اسی مقامی projection کو omniroute_radar_catalog (read:radar) کے ذریعے پڑھ سکتے ہیں۔ اختیاری provider، familyId، اور enabledOnly filters کا جائزہ ایک مقامی GET /api/radar/catalog read کے بعد لیا جاتا ہے۔ اس کے محدود output میں catalog metadata کے علاوہ provider/model، display name، familyId، quota، capabilities، enabled state، origin، اور disabledBy شامل ہوتے ہیں؛ setup URLs، steps، connections، e-mail addresses، keys، اور referral data کبھی واپس نہیں کیے جاتے۔ یہ tool read-only ہے اور کبھی /api/radar/sync کو invoke نہیں کرتا۔

ماخذ کے نشانات

ہر merged entry میں ایک origin field ہوتا ہے، جسے UI ایک badge کے طور پر دکھاتا ہے:

• "baseline" — static release catalog سے بغیر کسی تبدیلی کے۔
• "radar" — ایک یا زیادہ fields کو feed کے ذریعے refresh کیا گیا۔
• "local" — operator نے اس entry پر کم از کم ایک local override مقرر کیا ہے (قاعدہ 1 کے مطابق local overrides ہمیشہ feed پر فوقیت رکھتے ہیں، چاہے feed کچھ بھی کہے)۔

---

مقامی سطحیں — کبھی بھی فیڈ پراکسی نہیں

ذیل میں دیے گئے مقامی Radar روٹ خاندان src/app/api/radar/ کے تحت UI کو سہارا دیتے ہیں:

روٹ	طریقہ	مقصد
/api/radar/catalog	GET	مقامی کیش سے یکجا شدہ کیٹلاگ (getRadarCatalog()) واپس کرتا ہے۔
/api/radar/sync	POST	سرور کی جانب syncRadar() کو متحرک کرتا ہے؛ نتیجے کی حیثیت واپس کرتا ہے۔
/api/radar/settings	GET	{ optIn, hasSupporterKey, supporterKeyMasked } واپس کرتا ہے — خام کلید کبھی نہیں۔
/api/radar/settings	POST	آپٹ اِن اور/یا (انکرپٹ شدہ) سپورٹر کلید مقرر کرتا ہے۔
/api/radar/referrals	GET	مقامی کیش سے { fixed, campaigns, tier } واپس کرتا ہے — ذیل میں ریفرل لنکس دیکھیں۔
/api/radar/offers	GET	تصدیق شدہ مقامی لائیو کیش سے فعال آفرز واپس کرتا ہے؛ سپورٹر کلید کبھی واپس نہیں کرتا۔
/api/radar/offers/sync	POST	صرف لائیو کلید والی، سرور کی جانب چلنے والی syncRadarOffers() پائپ لائن کو متحرک کرتا ہے۔
/api/radar/intel	GET	تصدیق شدہ مقامی لائیو Intel کے ساتھ سپورٹر کی شناخت کا ایک بولین واپس کرتا ہے؛ کبھی کوئی شناخت یا کلید نہیں۔
/api/radar/intel/sync	POST	صرف لائیو کلید والی، سرور کی جانب چلنے والی syncRadarIntel() پائپ لائن کو متحرک کرتا ہے۔
/api/radar/status	GET	رازوں کے بغیر، کیٹلاگ، ریفرلز، آفرز، اور Intel کے لیے صرف پڑھنے کے قابل مقامی ترتیبات/کیش کی حیثیت واپس کرتا ہے۔
/api/radar/sync-all	POST	سرور کی جانب چاروں سنک ماڈیول چلاتا ہے اور ہر فیڈ کے لیے الگ حیثیت واپس کرتا ہے۔
/api/radar/local-model-state	GET	ترمیم/بحالی کنٹرولز کے لیے محفوظ کردہ اوور رائیڈز اور ٹومب اسٹونز کی فہرست دیتا ہے۔
/api/radar/local-model-state	PATCH	توثیق شدہ displayName/enabled اوور رائیڈ فیلڈز مقرر یا صاف کرتا ہے۔
/api/radar/local-model-state	PUT	{ provider, modelId, tombstoned } کے ساتھ ٹومب اسٹون بناتا یا ہٹاتا ہے۔
/api/radar/local-model-state	DELETE	کسی بھی ٹومب اسٹون کو برقرار رکھتے ہوئے قابلِ ترمیم اوور رائیڈ فیلڈز صاف کرتا ہے۔

سخت اصول: یہ روٹس کبھی بھی فیڈ سروس کی پراکسی نہیں بنتے۔ براؤزر ہمیشہ صرف مقامی OmniRoute سرور سے بات کرتا ہے۔ Radar سروس سے رابطہ کرنے والے چار ماڈیول src/lib/radar/sync.ts (کیٹلاگ)، src/lib/radar/referralsSync.ts (ریفرلز)، اور src/lib/radar/offersSync.ts (آفرز) کے علاوہ src/lib/radar/intelSync.ts (Intel) ہیں؛ سبھی سرور کی جانب چلتے ہیں، کبھی کلائنٹ کی جانب نہیں۔ اس طرح فیڈ URL اور کسی بھی سپورٹر کلید کو کلائنٹ کے سامنے آنے والی نیٹ ورک ٹریفک سے مکمل طور پر دور رکھا جاتا ہے۔

جب RADAR_ENABLED بند ہو تو تمام Radar اینڈ پوائنٹس 404 واپس کرتے ہیں (اوپر فلیگ دیکھیں)، اور پورے ریپو پر لاگو ایرر سینیٹائزیشن اصول (docs/security/ERROR_SANITIZATION.md) کے مطابق روٹ کی خرابی کے جوابات کو buildErrorBody()/sanitizeErrorMessage() کے ذریعے گزارا جاتا ہے۔

توثیق

تمام Radar اینڈ پوائنٹس کے لیے isAuthenticated() (src/shared/utils/apiAuth.ts) کے ذریعے توثیق درکار ہے — یعنی ڈیش بورڈ سیشن کوکی یا مینجمنٹ دائرۂ کار والی API کلید، وہی گیٹ جو باقی /api/settings/* کی حفاظت کرتا ہے۔ فلیگ بند ہونے کی 404 جانچ ہمیشہ توثیق کی جانچ سے پہلے چلتی ہے، اس لیے RADAR_ENABLED بند رکھنے والی انسٹالیشن بائٹ بہ بائٹ یکساں رہتی ہے (صرف یہ جاننے کے لیے کوئی توثیقی پرامپٹ نہیں آتا کہ یہ سطح موجود نہیں ہے)؛ فلیگ آن ہونے کے بعد، غیر توثیق شدہ درخواست کو کسی بھی DB ریڈ یا رائٹ سے پہلے 401 ملتا ہے۔ GET /api/radar/settings توثیق کی حالت سے قطع نظر کبھی بھی خام سپورٹر کلید واپس نہیں کرتا — صرف ماسک شدہ شکل اور ایک hasSupporterKey بولین واپس کرتا ہے۔

---

معاونین کی پیشکشیں

پیشکشیں اپنا الگ دستخط شدہ آرٹیفیکٹ، GET /v1/offers/latest، استعمال کرتی ہیں اور کبھی بھی کیٹلاگ یا ریفرلز کیش کا اشتراک نہیں کرتیں۔ سرور اینڈپوائنٹ کے لیے ایک درست فعال معاون Bearer کلید درکار ہے؛ کمیونٹی فال بیک دستیاب نہیں ہے۔ لہٰذا syncRadarOffers() نیٹ ورک تک پہنچنے سے پہلے ہی رک جاتا ہے اگر فیچر فلیگ بند ہو، آپریٹر نے شرکت کی رضامندی نہ دی ہو، یا کوئی معاون کلید کنفیگر نہ کی گئی ہو۔

کامیاب GET کے بعد، کلائنٹ عین جوابی بائٹس پر Ed25519 دستخط کی تصدیق کرتا ہے، RadarOffersFeedSchema کی توثیق کرتا ہے، تقاضا کرتا ہے کہ دستخط شدہ باڈی اور x-omniroute-feed-tier ہیڈر دونوں live ظاہر کریں، نقطوں والی صرف سختی سے نئی ورژن کو قبول کرتا ہے، اور صرف تب radar_offers_cache (مائیگریشن 144_radar_offers_cache.sql) کو ایٹمی انداز میں تبدیل کرتا ہے۔ دیگر فیڈز میں استعمال ہونے والی وہی 10 MB ہیڈر-بشمول-اسٹریم حد یہاں بھی لاگو ہوتی ہے۔ دستخط، اسکیما، ٹیئر، ری پلے، سائز، HTTP، اور نیٹ ورک کی تمام ناکامیوں کی صورت میں آخری تصدیق شدہ کیش محفوظ رہتا ہے۔

بند پیشکش کی ساخت تین قابلِ موازنہ فائدے کی اقسام کو سپورٹ کرتی ہے: بیسس پوائنٹس میں فیصد، کرنسی کی ذیلی اکائیوں میں کریڈٹ، یا آزمائشی دن۔ شراکت دار کی پیشکش میں اسی نوعیت کی عوامی بیس لائن شامل ہونا ضروری ہے اور اس کا فائدہ اس سے لازماً زیادہ ہونا چاہیے؛ سرکاری پیشکشوں کے لیے شراکت دار کی بیس لائن نہیں ہوتی۔ URLs اسناد سے پاک HTTPS ہونے چاہییں۔ getRadarOffers() احتیاطاً ہر مقامی ریڈ پر کیش شدہ پے لوڈ کی دوبارہ توثیق کرتا اور میعاد ختم شدہ اندراجات فلٹر کرتا ہے؛ /dashboard/radar/offers رینڈرنگ سے پہلے میعاد کو دوبارہ فلٹر کرتا ہے، دستیاب ہونے پر پرتگالی متن اور بصورتِ دیگر انگریزی فال بیک استعمال کرتا ہے، اور شراکت دار کی پیشکشوں کو واضح طور پر لیبل کرتا ہے۔

براؤزر صرف مقامی روٹس کو کال کرتا ہے: یہ ماسک شدہ سیٹنگز اسنیپ شاٹ پڑھتا ہے، سرور کی جانب ریفریش کرنے کے لیے POST /api/radar/offers/sync سے درخواست کرتا ہے، پھر GET /api/radar/offers پڑھتا ہے۔ کلید کے بغیر، یہ فیڈ کی درخواست کرنے کے بجائے موجودہ معاونت کنندہ/سپورٹ لنکس دکھاتا ہے۔ بیرونی پیشکش کے لنکس noopener noreferrer کے ساتھ نئے ٹیب میں کھلتے ہیں۔ اس ریلیز میں کوئی radar_offers MCP ٹول دستیاب نہیں کیا گیا۔

---

Radar Intel، معاون بیج، اور CLI

Intel ایک دستخط شدہ آرٹیفیکٹ ہے جو GET /v1/intel/latest پر دستیاب ہے۔ بند RadarIntelFeedSchema صرف Radar کی ملکیتی ELO درجہ بندیوں کو قبول کرتا ہے، جو نجی کیوریٹر تصدیق شدہ موازنوں سے اخذ کرتا ہے، نیز دستخط شدہ کیٹلاگ اسنیپ شاٹس سے اخذ کردہ کیٹلاگ کی عمر/تعداد کے حقائق پر مبنی فرق قبول کرتا ہے۔ طریقۂ کار ابتدائی ریٹنگ 1000 اور K=32 پر مقرر ہے۔ جب کسی موازنے کی تصدیق نہ ہوئی ہو تو خالی درجہ بندی درست ہے؛ کلائنٹ کبھی خود سے کوئی درجہ بندی تخلیق نہیں کرتا۔

syncRadarIntel() پیشکشوں کی طرح وہی سرور سائیڈ Bearer، 30 سیکنڈ ٹائم آؤٹ، 10 MiB اسٹریم شدہ حد، عین بائٹس پر Ed25519 تصدیق، سخت اسکیما، باڈی/ہیڈر کے لیے live کا تقاضا، ورژن فلور، اور آخری درست کیش کے تحفظ کا اطلاق کرتا ہے۔ تصدیق شدہ لائیو اسنیپ شاٹ محفوظ ہونے کے بعد، کلائنٹ radar:<sha256(supporter key)> اخذ کرتا ہے، صرف اسی یک طرفہ شناخت کو محفوظ کرتا ہے، اور مخصوص radar_supporter شناختی ایونٹ خارج کرتا ہے۔ اس کا radar-supporter بیج آئڈیم پوٹنٹ ہے اور صفر XP دیتا ہے؛ یہ کبھی لیڈر بورڈز کو اپ ڈیٹ نہیں کرتا اور نہ ہی token_share دوبارہ استعمال کرتا ہے۔ /dashboard/radar/intel بیج کو صرف تصدیق شدہ مقامی کیش میٹا ڈیٹا سے رینڈر کرتا ہے۔

CLI میں omniroute radar status اور omniroute radar sync دستیاب ہیں۔ دونوں صرف مقامی OmniRoute API سے رابطہ کرتے ہیں۔ status صرف پڑھنے کے لیے GET /api/radar/status انجام دیتا ہے؛ sync ایک POST /api/radar/sync-all بھیجتا ہے اور ہر فیڈ کا نتیجہ پرنٹ کرتا ہے۔ دونوں میں سے کوئی کمانڈ معاون کلید کو نہ پڑھتی، نہ قبول کرتی، نہ پرنٹ کرتی ہے، اور نہ ہی Radar سروس سے براہِ راست رابطہ کرتی ہے۔

---

ریفرل لنکس (مفت کریڈٹس)

ریفرل لنکس ایک علیحدہ، ہمیشہ تازہ ترین فیڈ سے فراہم کیے جاتے ہیں — GET /v1/referrals/latest — جو کیٹلاگ فیڈ سے الگ ہے۔ یہ دانستہ ہے: کمیونٹی ٹیئر پر کیٹلاگ فیڈ ایک اسنیپ شاٹ ہے جو 30 دن تک پرانا ہو سکتا ہے، لہٰذا اس سے اخذ کردہ ریفرل لنک بھی سرور کی اصل لنکس فہرست سے اتنی ہی مدت پیچھے رہتا تھا (نیا شامل کیا گیا ریفرل کسی مفت/کمیونٹی صارف تک ایک ماہ تک نہیں پہنچتا تھا)۔ ریفرلز فیڈ اپنی الگ، کہیں مختصر وقفے والی ہم وقت سازی کے ذریعے یہ تاخیر ختم کرتی ہے۔

// GET /v1/referrals/latest کا رسپانس باڈی (Ed25519 سے دستخط شدہ، وہی پن شدہ کلید جو
// کیٹلاگ فیڈ میں ہے):
{
  feed: "omniroute-radar-referrals",
  schemaVersion: 1,
  generatedAt: string,           // ISO — تعینی: تمام ریفرل لنکس میں سے max(updatedAt)،
                                  // تاکہ دو یکساں درخواستیں بالکل وہی دستخط شدہ
                                  // بائٹس/دستخط پیدا کریں
  referrals: {
    fixed: RadarReferral[],      // ہر ٹیئر میں موجود، بشمول بغیر تصدیق/کمیونٹی
    campaigns: RadarReferral[],  // صرف ایک درست فعال (سپورٹر) Bearer کلید کے لیے پُر؛
                                  // بغیر تصدیق/میعاد ختم شدہ کلید کی درخواستوں کو [] ملتا ہے
  },
}
// RadarReferral = { provider, url, kind: "fixo" | "campanha", validUntil,
//                    requiredAction, isDefault }

کیٹلاگ فیڈ کے برعکس، اس باڈی میں tier فیلڈ بالکل نہیں ہے — سرور Authorization کلید کی بنیاد پر ہر درخواست کے لیے فیصلہ کرتا ہے کہ کیا شامل کرنا ہے، لہٰذا x-omniroute-feed-tier رسپانس ہیڈر ہی فراہم کردہ ٹیئر کا واحد ماخذ ہے (referralsSync.ts::syncRadarReferrals)؛ غیر موجود/غیر شناخت شدہ ہیڈر کو "community" میں تنزل کر دیا جاتا ہے، جو کم ترین مراعات والا مفروضہ ہے۔ RadarReferralsFeedSchema (src/lib/radar/referralsFeedSchema.ts) مکمل باڈی کی توثیق کرتا ہے اور feedSchema.ts سے ایکسپورٹ کردہ وہی فی ریفرل RadarReferralSchema دوبارہ استعمال کرتا ہے، تاکہ دونوں فیڈز انفرادی ریفرلز کی یکساں طور پر توثیق کریں۔ ہر RadarReferral.url لازماً https:// ہونا چاہیے — ایک http:// url اسکیما کی توثیق میں ناکام ہو جاتا ہے۔

RadarFeedSchema (feedSchema.ts) پر کیٹلاگ میں شامل پرانا referrals فیلڈ پہلے سے کیش شدہ کیٹلاگ فیڈز کے ساتھ پسماندہ مطابقت کے لیے برقرار رکھا گیا ہے، لیکن getRadarReferrals() اب اسے نہیں پڑھتا — ذیل میں ایکسیسر دیکھیں۔

ہم وقت سازی

syncRadarReferrals() (src/lib/radar/referralsSync.ts) وہ واحد ماڈیول ہے جو ریفرلز کے لیے نیٹ ورک تک رسائی کرتا ہے اور syncRadar() کے معاہدے کی بالکل عکاسی کرتا ہے: فلیگ بند → disabled؛ رضامندی false → opt_out؛ ${RADAR_FEED_URL}/v1/referrals/latest ڈاؤن لوڈ کرتا ہے (کیٹلاگ جیسے ہی RADAR_FEED_URL/RADAR_FEED_PUBKEY فورک اوور رائیڈز)، بالکل درست رسپانس بائٹس پر Ed25519 دستخط کی توثیق کرتا ہے (verifyFeedBytes)، RadarReferralsFeedSchema کے مطابق توثیق کرتا ہے، اور radar_referrals_cache ٹیبل میں کیش کرتا ہے (مائیگریشن 142_radar_referrals_cache.sql) — یہ ٹیبل کیٹلاگ کے radar_feed_cache سے مکمل طور پر الگ ہے۔ 10 MB رسپانس حد اور generatedAt کی کم از کم حد، کیش شدہ فیڈ سے پرانی آنے والی فیڈ کو مسترد کرتی ہیں، جس سے کسی پرانے دستخط شدہ آرٹیفیکٹ کے دوبارہ چلائے جانے سے تحفظ ملتا ہے۔ مساوی ٹائم اسٹیمپ قبول کیا جاتا ہے: سرور دانستہ طور پر کمیونٹی اور فعال ریفرل ویریئنٹس کو یکساں تعینی generatedAt دیتا ہے، تاکہ بنیادی لنکس سیٹ تبدیل ہوئے بغیر سپورٹر کلید کی تبدیلی کے بعد دستخط شدہ پے لوڈ اور فراہم کردہ ٹیئر تبدیل ہو سکیں۔ یہ کبھی exception نہیں پھینکتا — ہمیشہ ایک اسٹیٹس آبجیکٹ واپس کرتا ہے؛ reason میں errors کبھی stack trace نہیں رکھتے۔

دو ٹریگرز ریفرلز کیش کو تازہ رکھتے ہیں، اور دونوں کیٹلاگ کے اپنے 24h وقفے سے آزاد ہیں:

• پڑھنے پر ہم وقت سازی — جب بھی کیش غیر موجود یا REFERRALS_STALE_MS سے پرانا ہو (1h، shouldSyncReferralsOnRead())، GET /api/radar/referrals خود رسپانس فراہم کرنے سے پہلے وہیں syncRadarReferrals() کو کال کرتا ہے۔ یہی مقررہ لنکس کو اگلی ہی ڈیش بورڈ لوڈنگ کے لیے "ہمیشہ تازہ ترین" بناتا ہے، کسی پس منظر ٹائمر کا انتظار کیے بغیر۔
• شیڈیولر کی ضمنی ہم وقت سازی — radarSchedulerTick() (scheduler.ts) کیٹلاگ کے لیے استعمال ہونے والے اسی فی گھنٹہ ٹِک پر ریفرلز کی تازگی کا آزادانہ جائزہ لیتا ہے اور وقت آنے پر syncRadarReferrals() کو کال کرتا ہے۔ یہ اس بات سے قطع نظر چلتا ہے کہ اس ٹِک پر خود کیٹلاگ کی باری تھی یا نہیں، اور RadarTickResult کی ساخت کو کبھی متاثر نہیں کرتا (صرف بہترین کوشش پر مبنی ضمنی اثر، error آنے پر نظر انداز کر دیا جاتا ہے)۔

ایکسیسر

src/lib/radar/index.ts صرف پڑھنے کے لیے دو ایکسیسرز ایکسپورٹ کرتا ہے، اور دونوں کبھی exception نہیں پھینکتے (getRadarCatalog() جیسا ہی دفاعی معاہدہ — فلیگ بند، کیش نہ ہونا، یا خراب کیش شدہ پے لوڈ، سبھی error کے بجائے خالی ساخت میں تبدیل ہو جاتے ہیں):

• getRadarReferrals() → { fixed: RadarReferral[], campaigns: RadarReferral[] }، radar_referrals_cache سے پڑھتا ہے (getRadarReferralsCache() کے ذریعے) اور RadarReferralsFeedSchema کے ذریعے توثیق کرتا ہے — کیٹلاگ کیش سے نہیں۔
• getDefaultReferralFor(provider) → اس provider کے لیے وہ fixed ریفرل جس میں isDefault: true ہو، یا null۔ یہ صرف fixed کو دیکھتا ہے — کسی campaign کو کبھی provider کے "ڈیفالٹ" لنک کے طور پر استعمال نہیں کیا جاتا۔

"کسی provider کے لیے کون سا ریفرل ڈیفالٹ ہے" کا اصل اصول findDefaultReferral() (src/lib/radar/referrals.ts) میں موجود ہے، جو بغیر کسی DB import کے ایک چھوٹا خالص فنکشن ہے — اسے "use client" کمپوننٹ میں import کرنا محفوظ ہے۔ getRadarReferrals/getDefaultReferralFor (index.ts میں) @/lib/db/radar کو شامل کرتے ہیں اور اس لیے صرف سرور تک محدود رہتے ہیں؛ providers ڈیش بورڈ index.ts کے بجائے براہ راست referrals.ts import کرتا ہے (ذیل میں دیکھیں)، تاکہ better-sqlite3 کو براؤزر بنڈل میں شامل ہونے سے روکا جا سکے۔

GET /api/radar/referrals

ہر دوسرے Radar روٹ کی طرح بالکل اسی گیٹ ترتیب کی پیروی کرتا ہے: RADAR_ENABLED بند → 404 (سب سے پہلے جانچا جاتا ہے، بائٹ بہ بائٹ یکساں عدم فعالیت)؛ غیر توثیق شدہ → 401؛ بصورتِ دیگر پرانا ہونے پر sync-on-read (اوپر دیکھیں) متحرک کرتا ہے، پھر { fixed, campaigns, tier } کے ساتھ 200 — tier براہِ راست (ممکنہ طور پر ابھی تازہ کی گئی) کیش قطار سے آتا ہے اور خالصتاً معلوماتی ہے (ذیل میں UI کے نرم upsell متن کو چلاتا ہے)۔ فیڈ سرور کو کبھی براہِ راست پراکسی نہیں کرتا — روٹ کے اپنے سورس میں کوئی fetch( کال نہیں ہے؛ نیٹ ورک صرف syncRadarReferrals() کے اندر ہی استعمال ہوتا ہے، یعنی /api/radar/catalog جیسا صرف مقامی کیش والا اصول۔

ڈیش بورڈ UI — /dashboard/radar پر "مفت کریڈٹس" ٹیب

نیا روٹ بنانے کے بجائے موجودہ Radar صفحے (src/app/(dashboard)/dashboard/radar/page.tsx) کو دوسرے ٹیب کے طور پر دوبارہ استعمال کرتا ہے — ایسی خصوصیت کے لیے کم routing/i18n دائرہ جو پہلے سے حاصل کیے جانے والے صفحے کے ڈیٹا ہی کی ایک قسم ہے۔ شمولیت اختیار کرنے کے بعد، ٹیب بار کیٹلاگ (موجودہ جدول) اور مفت کریڈٹس پیش کرتا ہے:

• مستقل لنکس فراہم کنندہ کے لحاظ سے گروپ کیے جاتے ہیں، اور ہر ایک requiredAction (جب موجود ہو) اور ریفرل URL کے لیے target="_blank" rel="noopener noreferrer" بٹن دکھاتا ہے۔
• مہمات بھی یہی چیزیں، اور موجود ہونے پر validUntil بھی دکھاتی ہیں۔
• جب campaigns خالی ہو اور فراہم کردہ درجہ community ہو، تو UI ایک مختصر upsell نوٹ ("محدود مدت کی مہمات معاونین کے لیے ایک اضافی سہولت ہیں") دکھاتا ہے — یہ مستقل لنکس کی فہرست کو کبھی نہیں چھپاتا یا مقید کرتا، جو ہر درجے کے لیے مکمل طور پر پُر رہتی ہے۔ upsell صرف نرم پیغام رسانی ہے، کبھی رکاوٹ نہیں۔

فراہم کنندہ کے نام پر ریفرل لنک (فراہم کنندگان کا ڈیش بورڈ)

ProviderPageHeader (src/app/(dashboard)/dashboard/providers/[id]/components/) پہلے ہی، موجود ہونے پر، فراہم کنندہ کے نام کو providerInfo.website سے منسلک کرتا تھا، اور آمدنی والے لنک کی ایک نظیر موجود ہے: Kimi (Moonshot AI) پارٹنر لنک نوٹ (providers.kimiPartnerLinkNote i18n کلید)۔ D28 نئی کلید متعارف کرانے کے بجائے Radar کے ڈیفالٹ ریفرلز کے لیے عین اسی محتاط نوٹ کے نمونے کو دوبارہ استعمال کرتا ہے۔

ڈیزائن کے مطابق ڈھیلا ربط:

• resolveProviderHeaderLink() (src/app/(dashboard)/dashboard/providers/providerPageUtils.ts) ایک خالص فنکشن ہے — (staticWebsite, referralUrl) => { website, isReferralLink } — جس کا @/lib/radar یا @/lib/db/* پر کوئی انحصار نہیں۔ مجموعی طور پر providerPageUtils.ts ان imports سے پاک رہتا ہے (جس کی توثیق tests/unit/provider-header-referral-link.test.ts کرتا ہے)۔
• ProviderDetailPageClient.tsx (ایک "use client" جزو) وہ واحد جگہ ہے جسے Radar ڈیٹا حاصل کرنے کی اجازت ہے — fetch("/api/radar/referrals") کے ذریعے، یعنی وہی مقامی روٹ کا نمونہ جو Radar ڈیش بورڈ صفحہ خود استعمال کرتا ہے — اور یہ DB سے آزاد src/lib/radar/referrals.ts کے findDefaultReferral() کے ذریعے کلائنٹ سائیڈ پر ڈیفالٹ ریفرل کا حساب لگاتا ہے۔
• RADAR_ENABLED بند ہونے پر، fetch کو 404 ملتا ہے، referralUrl کی قدر null رہتی ہے، اور resolveProviderHeaderLink() جامد کیٹلاگ website کو بغیر تبدیلی کے واپس کرتا ہے — فراہم کنندہ کا صفحہ اس خصوصیت کے وجود سے پہلے کی حالت سے بائٹ بہ بائٹ یکساں رہتا ہے۔ یہی نتیجہ اس وقت بھی ہوتا ہے جب ابھی کوئی کیش موجود نہ ہو یا اس مخصوص فراہم کنندہ کے لیے کوئی ڈیفالٹ ریفرل نہ ہو۔
• جب کوئی ڈیفالٹ ریفرل لاگو ہوتا ہے، تو ProviderPageHeader کو isReferralLink موصول ہوتا ہے اور وہ Kimi پارٹنر لنک جیسا ہی محتاط نوٹ/ٹول ٹِپ دکھاتا ہے (providers.kimiPartnerLinkNote کلید کو دوبارہ استعمال کرتے ہوئے) — کبھی کوئی نیا، الگ بصری انداز نہیں۔

---

فیڈ کو خود ہوسٹ کرنے کا طریقہ

کوئی فورک یا سیلف ہوسٹر، جو کیٹلاگ پر مکمل کنٹرول چاہتا ہو، کلائنٹ کوڈ میں تبدیلی کیے بغیر اپنی فیڈ سروس چلا سکتا ہے:

1. ایک GET /v1/catalog/latest اینڈ پوائنٹ فراہم کریں جو ایسی JSON باڈی واپس کرے جو RadarFeedSchema (src/lib/radar/feedSchema.ts) کی شرائط پوری کرتی ہو — اعلیٰ سطح پر feed: "omniroute-radar"، schemaVersion: 2، version، tier، providers، models، quirks، اور totals۔ x-omniroute-radar-schema: 2 کی تعمیل کریں؛ منتقلی سے مطابقت رکھنے والے سرور کو اس کے بغیر آنے والی درخواستوں کے لیے بطور ڈیفالٹ الگ سے دستخط شدہ v1 آرٹی فیکٹ استعمال کرنا چاہیے۔
2. عین جوابی بائٹس پر Ed25519 کلیدی جوڑے سے دستخط کریں اور base64 دستخط کو x-omniroute-feed-signature رسپانس ہیڈر میں واپس کریں۔
3. RADAR_FEED_URL کو نئے بنیادی URL پر اور RADAR_FEED_PUBKEY کو متعلقہ عوامی کلید (base64-DER SPKI یا PEM) پر سیٹ کریں — ماحولیاتی متغیرات کا حوالہ دیکھیں۔
4. RADAR_ENABLED فعال کریں اور POST /api/radar/settings کے ذریعے شمولیت اختیار کریں ({ optIn: true })۔

کوڈ میں کسی اور تبدیلی کی ضرورت نہیں — verifyFeedBytes() خودکار طور پر اوور رائیڈ استعمال کر لیتا ہے (src/lib/radar/pinnedKeys.ts میں getFeedPublicKeys())، جبکہ ورژن کا موازنہ، اسکیما کی توثیق، اور انضمام کے اصول سیلف ہوسٹڈ فیڈ پر بھی یکساں طور پر لاگو ہوتے ہیں۔

ریفرل لنکس (اوپر ریفرل لنکس (مفت کریڈٹس) دیکھیں) ایک الگ، اختیاری آرٹی فیکٹ ہیں: جو فورک صرف /v1/catalog/latest فراہم کرتا ہے وہ بھی مکمل طور پر کام کرتا ہے — /v1/referrals/latest سے 404 ملنے پر syncRadarReferrals() کی حالت گھٹ کر { status: "error" } ہو جاتی ہے اور کیش محض خالی رہتا ہے، لہٰذا باقی صفحہ ناکام ہونے کے بجائے GET /api/radar/referrals بدستور { fixed: [], campaigns: [], tier: null } واپس کرتا ہے۔ ریفرل لنکس بھی فراہم کرنے کے لیے، ایسا GET /v1/referrals/latest فراہم کریں جو RadarReferralsFeedSchema (src/lib/radar/referralsFeedSchema.ts) کی شرائط پوری کرے اور اس پر کیٹلاگ فیڈ والے اسی Ed25519 کلیدی جوڑے سے دستخط کریں۔

سپورٹر آفرز ایک اور اختیاری آرٹی فیکٹ ہیں۔ انہیں فراہم کرنے کے لیے، بند RadarOffersFeedSchema (src/lib/radar/offersFeedSchema.ts) کے ساتھ GET /v1/offers/latest نافذ کریں، فعال استحقاق لازم قرار دیں، x-omniroute-feed-tier: live واپس کریں، اور عین بائٹس پر اسی کلید سے دستخط کریں۔ ایسا فورک جو یہ اینڈ پوائنٹ شامل نہ کرے، کیٹلاگ/ریفرلز کے رویے کو بدستور برقرار رکھتا ہے؛ آفر ریفریش کسی موجودہ ڈیٹا کو نقصان پہنچائے بغیر ناکام ہو جاتا ہے اور آخری توثیق شدہ مقامی آفر کیش دستیاب رہتا ہے۔

Intel بھی اسی طرح اختیاری ہے۔ کوئی سیلف ہوسٹر RadarIntelFeedSchema (src/lib/radar/intelFeedSchema.ts) استعمال کرتے ہوئے GET /v1/intel/latest فراہم کر سکتا ہے، فعال استحقاق لازم قرار دے سکتا ہے، x-omniroute-feed-tier: live واپس کر سکتا ہے، اور عین بائٹس پر مشترکہ Ed25519 کلید سے دستخط کر سکتا ہے۔ اینڈ پوائنٹ شامل نہ کرنے سے کیٹلاگ، ریفرلز، اور آفرز میں کوئی تبدیلی نہیں آتی؛ Intel ریفریش آخری توثیق شدہ مقامی اسنیپ شاٹ کو محفوظ رکھتا ہے۔

---

متعلقہ دستاویزات

• docs/security/ERROR_SANITIZATION.md — وہ ایرر رسپانس پیٹرن جس کی /api/radar/* روٹس پیروی کرتے ہیں۔
• docs/reference/ENVIRONMENT.md — RADAR_FEED_URL / RADAR_FEED_PUBKEY کا حوالہ۔