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

Radar Free-Model Catalog (Kiswahili)

🌐 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 · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

Chanzo cha ukweli: src/lib/radar/, src/lib/db/radar.ts, src/app/api/radar/ Ilisasishwa mwisho: 2026-09-01 — v3.8.51 Mpaka wa ushahidi wa huduma inayopangishwa: kanuni za upande wa seva zilizoelezwa hapa zilithibitishwa mnamo 2026-09-01 dhidi ya seva ya Radar iliyowekwa kuwa ya faragha kimakusudi katika sahihisho kamili main@dce70f004364912f3f144cdb69f4cbcde16093ed. Utekelezaji huo hausambazwi katika hazina hii ya OSS; upatikanaji wa huduma inayopangishwa unasalia kuwa hali tofauti ya kiutendaji.

Radar ni nyongeza ya hiari inayoweka juu ya msingi wa toleo (FREE_MODEL_BUDGETS katika open-sse/config/freeModelCatalog.data.ts) katalogi iliyotiwa saini na iliyohakikiwa hivi karibuni ya modeli zisizolipishwa. Ipo kwa sababu mazingira ya kiwango kisicholipishwa hubadilika haraka kuliko mzunguko wa matoleo — watoa huduma huongeza, hupunguza, au hukomesha viwango vya matumizi visivyolipishwa kati ya matoleo, na katalogi ya msingi inaweza kusasishwa tu toleo jipya linapotolewa.

Hakuna chochote ambacho ni cha bure leo kinachoacha kuwa cha bure kwa sababu ya mlisho wa mbali. Radar kamwe haiweki ingizo la msingi nyuma ya kizuizi cha malipo; husasisha tu sehemu za vikomo/hali wakati wa usomaji na inaweza kuongeza modeli mpya zisizolipishwa zilizogunduliwa kati ya matoleo. Mwendeshaji bado anaweza kuficha modeli ndani ya mfumo, na anaweza kuirejesha kutoka kwenye dashibodi hiyo hiyo. Katalogi ya msingi yenyewe haibadilishwi kamwe kwenye diski — tazama Kanuni za kuunganisha tabaka wakati wa usomaji hapa chini.

---

Hali ya uwasilishaji katika v3.8.51

Hali ifuatayo inatofautisha kile ambacho toleo hili la OSS linatekeleza na mikondo ya baadaye ya kazi ya Radar. Hii ni hali ya kiwango cha msimbo, si ahadi kwamba upelekaji fulani unaopangishwa au muunganisho wa nje unapatikana kwa sasa.

Eneo	Hali katika toleo hili
Kiteja cha katalogi iliyotiwa saini	Kimetekelezwa nyuma ya RADAR_ENABLED, kikiwa na ridhaa tofauti ya kujiunga, uthibitishaji wa Ed25519, mipangilio/akiba ya ndani iliyosimbwa kwa njia fiche, ubatilishaji endelevu wa uonyeshaji/uwezeshaji, alama za ufutaji zinazoweza kutenduliwa, kipanga ratiba, na dashibodi.
Uwezeshaji wa wachangiaji	Dashibodi inaunganisha kwenye mtiririko wa kudai wa GitHub unaopangishwa na seva na inakubali ufunguo uliopo wa omr_…. Ustahiki wa mchangiaji huamuliwa na huduma ya faragha; kiteja cha OSS hakina tokeni ya GitHub wala mantiki ya utoaji.
Uwezeshaji wa ufunguo wa mfadhili	Umetekelezwa. Ufunguo ghafi huthibitishwa, husimbwa kwa njia fiche unapohifadhiwa, hufichwa kwa sehemu unaposomwa, na hutumwa tu na ulandanishi wa upande wa seva. Kubadilisha au kufuta ufunguo hubatilisha akiba zote nne za milisho zinazotegemea haki za ufikiaji.
Viungo vya rufaa	Vimetekelezwa kama mlisho uliotiwa saini tofauti na kusasishwa kila saa. Viungo vya kudumu vinapatikana mara moja kwa kiwango cha jumuiya; kampeni zenye kikomo zinasalia kuwa data ya kiwango cha moja kwa moja.
Ofa za wafadhili	Zimetekelezwa kama mlisho tofauti uliotiwa saini, wa moja kwa moja pekee, pamoja na ukurasa wa dashibodi. Kiteja huthibitisha upya skima funge ya manufaa, huhifadhi akiba nzuri ya mwisho, huchuja maingizo yaliyoisha muda, na huweka lebo wazi kwenye ofa za washirika.
Taarifa za uchanganuzi na utambuzi wa wafadhili	Zimetekelezwa kama mlisho madhubuti uliotiwa saini, wa moja kwa moja pekee, wenye ELO inayomilikiwa na Radar, taarifa za kweli kuhusu usasishaji/mwelekeo wa katalogi, beji ya ndani ya mfadhili iliyothibitishwa, ukurasa wa dashibodi, na amri za hali/ulandanishi za CLI zinazotumika ndani ya mfumo pekee.
Malipo na barua pepe za miamala	Hayajatekelezwa katika kiteja cha OSS. Ununuzi, mchango, ukaguzi wa risiti, urejeshaji, na uwasilishaji wa barua ni majukumu ya huduma ya faragha; upatikanaji wa huduma inayopangishwa bado unategemea upelekaji wake unaosimamiwa na usanidi wa mtoa huduma.
Mkondo wa kazi wa ajenti wa utafiti	Si sehemu ya toleo hili la kiteja. Maudhui ya mlisho yaliyohakikiwa yanasalia kuwa data ya upande wa seva; hakuna ajenti huru ya utafiti inayoendeshwa katika usakinishaji wa OmniRoute.

---

Kisomaji cha matangazo ya umma

Kisomaji cha kawaida cha matangazo kimetenganishwa na alama ya kipengele cha Radar. Ukurasa wa Mwanzo wa dashibodi na kitazamaji cha Kumbukumbu ya Mabadiliko huchukua news.json ya umma ya hazina kupitia GET ya kawaida kwenda NEWS_JSON_URL (src/shared/utils/releaseNotes.ts). Hazitumi mpangilio wowote wa Radar, kidokezo, usanidi wa mtoa huduma, rekodi ya matumizi, wala hali ya ndani ya kupuuza tangazo.

news.json hutumia skima ya v2 iliyofungwa iliyotekelezwa na parseNewsPayload():

• schemaVersion: 2 na mkusanyiko wa items[] wenye kikomo;
• thamani za id za matangazo ambazo ni thabiti na za kipekee;
• sehemu bayana za active na publishedAt za ISO;
• maandishi ya Kiingereza yanayohitajika pamoja na maandishi ya hiari yaliyotafsiriwa;
• viungo vya hiari vya HTTPS visivyohitaji kitambulisho na ikoni iliyo kwenye orodha ya kuruhusiwa;
• uteuzi wa tangazo jipya zaidi lililo hai kwanza, kurejea Kiingereza ikiwa lugha haipatikani, na kupuuza ndani kwa kila ID.

Kichanganuzi kinakubali kwa muda muundo wa awali wa kipengee kimoja { active, title, message, ... } ili matawi ya zamani yaweze kuhamia bila kuvuruga mwonekano wa Kumbukumbu ya Mabadiliko. Milisho batili haifanyi chochote. Ingizo la uzinduzi wa Radar hutolewa likiwa na active: false; kulibadilisha kuwa true ni hatua tofauti ya uchapishaji baada ya kuunganisha na baada ya kupeleka na hakubadilishi RADAR_ENABLED wala idhini huru ya ulandanishi wa mlisho.

---

Alama: RADAR_ENABLED (imezimwa kwa chaguo-msingi)

Radar inadhibitiwa mwanzo hadi mwisho na alama ya kipengele ya RADAR_ENABLED (src/shared/constants/featureFlagDefinitions.ts, kategoria policies, defaultValue: "false").

Wakati alama imezimwa, sehemu hii haipo:

• Ncha zote za /api/radar/*, ikiwa ni pamoja na usomaji na uandishi wa hali ya modeli ya ndani, hurejesha 404 kabla ya kufikia moduli yoyote ya Radar.
• Skrini za dashibodi (/dashboard/radar, /dashboard/radar/setup, /dashboard/radar/combos, /dashboard/radar/offers, /dashboard/radar/intel) hutekeleza notFound().
• getRadarCatalog() (src/lib/radar/index.ts) hurejesha msingi ambao haujaguswa — idadi ileile ya maingizo, thamani zilezile, kila ingizo likiwa na lebo origin: "baseline" — na kamwe haisomi akiba ya mlisho.
• Hakuna ombi la mtandao la Radar linalowahi kufanywa; kila moduli ya ulandanishi hurejesha { status: "disabled" } kabla ya kufikia fetch.

Hiki ni kizuizi kamili kinachojumuisha masharti mengine: kuwasha alama hufungua skrini pekee, bila kitu kingine chochote. Hakipakii data, hakianzishi ulandanishi wa chinichini, wala hakibadilishi uelekezaji au uteuzi wa modeli — tazama idhini tofauti hapa chini.

---

Ulandanishi wa data ni idhini TOFAUTI — ahadi ya faragha

Kuwasha RADAR_ENABLED hufungua UI pekee. Kulandanisha mlisho kunahitaji idhini ya pili, iliyo huru, iliyohifadhiwa katika radar_settings.opt_in (src/lib/db/radar.ts, uhamishaji 136_radar_cache_settings.sql). syncRadar() hukagua alama na idhini kabla ya kufanya ombi lolote la mtandao:

Alama imezimwa  → { status: "disabled" }   — hakuna ombi la mtandao
Idhini ni false → { status: "opt_out" }    — hakuna ombi la mtandao

Wakati zote mbili zimewashwa, njia ya ulandanishi ni:

1. GET <feed base URL>/v1/catalog/latest yenye x-omniroute-radar-schema: 2 na kichwa cha hiari cha Authorization: Bearer <supporter key> (tazama hapa chini). Kwa chaguo-msingi, seva hutumia rasilimali ya mpito ya v1 iliyotiwa sahihi kando wakati kichwa cha skima hakipo, ili wateja wa zamani waliosakinishwa waendelee kupokea masasisho.
2. Huu ni mtiririko wa programu wa kupakua pekee, lakini bado ni ombi la HTTPS. Miundombinu inayopangishwa hupokea metadata ya kawaida ya muunganisho kama vile IP ya chanzo. Wakati ufunguo wa msaidizi umesanidiwa, ulandanishi pia hutuma ufunguo huo katika kichwa cha Bearer ili huduma iweze kubaini haki ya ufikiaji. Katika sahihisho mahususi la seva binafsi lililotambuliwa katika mpaka wa ushahidi hapo juu, uhasibu wa maombi ya mlisho hutumia heshi za funguo, matumizi ya jumla, na HMAC iliyofupishwa inayobadilishwa kila siku ya IP kwa ajili ya ukaguzi wa matumizi mabaya unaofanywa na binadamu; majedwali hayo hayahifadhi ufunguo wala IP katika muundo ghafi. Kumbukumbu za ufikiaji wa miundombinu na kisanduku toezi cha uwasilishaji kilichosimbwa kwa njia fiche ni mipaka tofauti ya uendeshaji.
3. OmniRoute haitumi kamwe vidokezo, majibu, mazungumzo, vitambulisho vya watoa huduma, trafiki ya modeli, muda wa upatikanaji, ukawiaji, wala usanidi wa ndani wa mtoa huduma kwenda kwenye huduma ya Radar.
4. Jibu huthibitishwa, huhakikiwa, na kuhifadhiwa ndani kwenye akiba (tazama Muundo wa usalama). Radar ina njia nne kamili za mtandao upande wa seva: syncRadar() kwa katalogi, syncRadarReferrals() kwa rufaa, na syncRadarOffers() / syncRadarIntel() kwa ofa na Intel za wafuasi pekee.

Ufunguo wa msaidizi ni tokeni ya hiari ya Bearer (radar_settings.supporter_key) inayoruhusu huduma ya mlisho kuamua kiwango kitakachotolewa (tazama Viwango). Ufunguo huu:

• Huhifadhiwa ukiwa umesimbwa kwa njia fiche wakati umepumzika kwa kutumia visaidizi vilevile vya AES-256-GCM vya encrypt()/decrypt() (src/lib/db/encryption.ts) vinavyotumika kwa vitambulisho vya watoa huduma.
• Huwekwa kupitia POST /api/radar/settings ({ supporterKey: "omr_" + 40 hex chars }) na hauonyeshwi tena kamwe — jibu hurejesha muundo uliofichwa (omr_****abcd).
• Kuubadilisha au kuufuta hubatilisha kwa pamoja akiba za katalogi, rufaa, ofa na Intel. Ulandanishi/usomaji unaofuata hubaini haki mpya ya ufikiaji upande wa seva; kuhifadhi ufunguo hakufanyi ombi la mtandao wala kutumia ufunguo wa uwezeshaji wa matumizi moja.
• Hutumwa kwenda kwenye huduma ya mlisho kama tokeni ya Bearer katika ombi la GET la ulandanishi — hakuna kitu kingine kuhusu ufunguo kinachowahi kuondoka kwenye kiteja.

---

Kanuni za ufikiaji na usalama zinazoonyeshwa kabla ya kujijumuisha

Dashibodi isiyotumika huonyesha kanuni hizi kutoka src/app/(dashboard)/dashboard/radar/RadarAccessExplainer.tsx kabla ya hatua yoyote ya kuwezesha. Kiwango rasmi cha ufikiaji ni:

Kiwango	Ustahiki	Ufikiaji	Kanuni ya kurudia/kuisha muda
Jumuiya	Mtu yeyote; hakuna ufunguo	Katalogi kamili hucheleweshwa kwa takribani siku 30	Inapatikana kila wakati; hakuna utoaji
Nyota + kufuata	GitHub OAuth huthibitisha nyota kwenye hifadhi na pia kumfuata mmiliki	Usomaji mmoja wa katalogi ya moja kwa moja, kisha Jumuiya	Utoaji mmoja kwa kila kuingia; hautolewi tena
Mchangiaji Top 10	Nafasi 1–10 katika orodha ya hivi karibuni iliyokamilika ya kila wiki	Siku 365 za ufikiaji wa moja kwa moja	Hudaiwa inapohitajika; kuondoka kwenye orodha hakupunguzi kipindi kilichotolewa
Mchangiaji Top 100	Nafasi 11–100 katika orodha hiyo	Siku 90 za ufikiaji wa moja kwa moja	Kanuni ileile ya kudai inapohitajika/isiyobadilisha matokeo ikirudiwa
Ununuzi wa msaidizi	Ununuzi wa mara moja wa miezi 6, mwaka 1, au maisha yote	Katalogi ya moja kwa moja, ofa zilizotiwa saini za moja kwa moja, na Intel	Hakuna usasishaji wa kiotomatiki
Mchango/ruzuku ya mwenyewe	Mchango uliokaguliwa na mmiliki au ruzuku ya mmiliki ya idadi maalumu ya siku/maisha yote	Haki ileile ya moja kwa moja kwa kipindi kilichotolewa	Ruzuku iliyokaguliwa, isiyobadilisha matokeo ikirudiwa

PR zilizounganishwa, commits, na mistari iliyobadilishwa ni vigezo vya kupanga nafasi pekee. Kuingia ukiwa nje ya Top 100 hakutoi ruzuku yoyote ya mchangiaji bila kujali idadi ya PR. Ununuzi wa muda maalumu, michango, vipindi vya wachangiaji, na ruzuku za mwenyewe huongezwa kuanzia tarehe ya sasa ya kuisha; ufikiaji wa maisha yote hutawala. Mabadiliko ya nafasi kamwe hayabatilishi kwa kurudi nyuma wala kupunguza muda ambao tayari umetolewa.

Leseni inayohudumiwa ni ya mtu binafsi na kanuni inayoonekana kwa mtumiaji ni usakinishaji mmoja unaotumika kwa wakati mmoja. Toleo hili halidai kufunga leseni kwa maunzi: usawazishaji wa OSS hautengenezi alama ya kipekee ya maunzi wala kudumisha ukodishaji wa kifaa unaolindwa kwa kriptografia. Katika marekebisho yaliyothibitishwa ya seva binafsi hapo juu, utekelezaji uliowekwa ni uthibitishaji wa haki pamoja na ishara ya ukaguzi wa mwenyewe pale ufunguo uleule unaotumika unapoonekana kutoka kwenye IP ya nne tofauti ndani ya saa 24. Ishara hiyo haizuii wala kubatilisha ufunguo kiotomatiki. Urejeshaji hubatilisha na kubadilisha ufunguo uliopotea huku ukihifadhi muda uliopo wa kuisha; hauanzishi upya kipindi kilichonunuliwa au kutolewa.

Ofa za moja kwa moja huratibiwa kwa mkono na zinaweza kubadilika au kuisha. Skrini ya kujijumuisha pia hutaja mpaka kamili wa faragha: metadata ya katalogi/uelekezaji iliyotiwa saini hupakuliwa; ufunguo halali pia hufungua ofa zilizotiwa saini na Intel; ufunguo wa Bearer na metadata ya kawaida ya muunganisho hufikia huduma inayohudumiwa; vidokezo, majibu, mazungumzo, vitambulisho vya mtoa huduma, trafiki ya modeli, muda wa upatikanaji, ukawiaji, na usanidi wa mtoa huduma wa ndani havifiki.

---

Kupata ufunguo wa msaidizi

Skrini ya uanzishaji (/dashboard/radar) ina viungo vya michakato miwili ya kupata ufunguo wa msaidizi. Repo ya OSS yenyewe haitoi ufunguo, haiendeshi kamwe msimbo wa malipo, na haitaji kamwe bei — bei huamuliwa na kuonyeshwa kikamilifu kwenye kurasa lengwa, si katika repo hii (uamuzi wa vipimo D14).

• "Mimi ni mchangiaji" — hufungua RADAR_CONTRIBUTOR_CLAIM_URL (chaguo-msingi https://radar.omniroute.online/auth/github), mchakato wa kudai kupitia GitHub OAuth unaopangishwa kwenye seva binafsi ya Radar. Hukagua upangaji wa hivi karibuni wa wiki uliokamilika: Walio 10 Bora hupokea siku 365 na nafasi za 11–100 hupokea siku 90. Nje ya 100 Bora, idadi ya PR haitoi kamwe ufikiaji; badala yake, mchakato hukagua kiwango tofauti cha matumizi mara moja cha kuweka nyota + kufuata.
• "Saidia mradi" — hufungua RADAR_SUPPORTER_PLANS_URL (chaguo-msingi https://radar.omniroute.online/planos), ukurasa unaopangishwa wa chaguo za mara moja za miezi 6, mwaka 1, na maisha yote. Ukurasa wa OSS bado hauonyeshi thamani yoyote ya kifedha.

URL zote mbili hutatuliwa upande wa seva (src/lib/radar/links.ts, kwa kutumia muundo uleule wa kubatilisha kupitia mazingira kama RADAR_FEED_URL) na kupelekwa kwenye dashibodi kupitia jibu lililopo la GET /api/radar/settings (contributorClaimUrl, supporterPlansUrl) — kijenzi cha mteja hakisomi kamwe process.env moja kwa moja.

Kigezo	Madhumuni
RADAR_CONTRIBUTOR_CLAIM_URL	Hubatilisha URL ya kudai kama mchangiaji (chaguo-msingi https://radar.omniroute.online/auth/github).
RADAR_SUPPORTER_PLANS_URL	Hubatilisha URL ya mipango ya wasaidizi (chaguo-msingi https://radar.omniroute.online/planos).

Kurejesha ufunguo wa msaidizi uliopotea

Sehemu ya kuanzia ya urejeshaji ya huduma inayopangishwa ni https://radar.omniroute.online/recover; pia imeunganishwa kutoka kwenye ukurasa wa mipango. Urejeshaji hubaki nje kabisa ya mteja wa OSS kwa sababu usakinishaji wa ndani haupokei barua pepe ya mnunuzi/mchangiaji na hauwezi kuunda upya ufunguo halisi kutoka kwenye mipangilio yake iliyosimbwa kwa njia fiche.

1. Wasilisha barua pepe inayohusishwa na ufunguo. Huduma hurudisha ukurasa uleule wa kukubaliwa iwe leseni inayoweza kurejeshwa ipo au la, kwa hivyo fomu haiorodheshi akaunti.
2. Ikiwa inastahiki, worker wa uwasilishaji hutuma kiungo cha matumizi mara moja chenye muda mfupi wa kuishi. Kukifungua huhamisha tokeni mara moja hadi kwenye kidakuzi cha muda mfupi kilichosimbwa kwa njia fiche cha HttpOnly/Secure na kuelekeza kwenye URL safi ya /recover; ukurasa hauna tokeni, barua pepe, ufunguo wa zamani, wala ufunguo mbadala.
3. Thibitisha ubatilishaji. Huduma binafsi hubatilisha ufunguo wa awali, huunda ufunguo mbadala wenye mpango/tarehe ya mwisho ileile, na kuuweka kwenye foleni ya kutumwa kwa barua pepe katika muamala mmoja. Ufunguo mbadala haurudishwi kamwe kwenye kivinjari.
4. Bandika ufunguo mbadala kwenye /dashboard/radar. Ufunguo wa zamani lazima sasa ushuke hadhi hadi community; ufunguo mbadala lazima utoe ulandanishaji wa live uliothibitishwa. Kufungua tena kiungo kilekile cha urejeshaji lazima kushindwe kwa jibu la jumla la kutokuwa halali/kuisha muda.

Njia ya urejeshaji inayopangishwa na worker wa barua zinaweza kuwepo katika msimbo huku zikiwa bado hazipatikani katika upelekaji fulani. Usitaje mchakato huu kuwa tayari kwa uzalishaji hadi seva iwe imepelekwa, mtoa huduma wa uwasilishaji awe amesanidiwa kwa mpokeaji anayedhibitiwa, na kiungo kamili cha matumizi mara moja kiwe kimejaribiwa.

Mara tu mgeni anapokuwa na ufunguo (omr_ + herufi 40 za heksadesimali), skrini ya uanzishaji (src/app/(dashboard)/dashboard/radar/page.tsx) huwa na sehemu ya kubandika ufunguo kama njia kuu: kubandika ufunguo na kuwasilisha hutuma POST /api/radar/settings ({ optIn: true, supporterKey }) kwa ombi moja — kubandika ufunguo huuweka na pia hujiunga, na hivyo kufungua skrini. Umbizo (omr_ + herufi 40 za heksadesimali) hukaguliwa kwanza upande wa mteja kwa kutumia kisaidizi cha pamoja cha isValidSupporterKeyFormat() (src/lib/radar/supporterKey.ts) kama uboreshaji wa UX; hata hivyo, schema ya Zod ya seva ndiyo ukaguzi wenye mamlaka. Mara tu ufunguo unapowekwa, skrini ya uanzishaji huonyesha umbizo lililofichwa (supporterKeyMasked kutoka GET /api/radar/settings) badala ya sehemu tupu ya kuingiza, pamoja na kidhibiti cha "badilisha ufunguo" ili kubandika mpya — ufunguo halisi hauonyeshwi tena kamwe. Vitufe viwili vya kudai/mipango vilivyo hapo juu hubaki kuwa njia ya kupata ufunguo hapo mwanzo; sehemu hii ya kuingiza ndiyo mahali ambapo mwendeshaji ambaye tayari anao huuwasha.

Uanzishaji wa mwanzo hadi mwisho na usanidi unaoongozwa

Huduma binafsi ya mlisho na mteja huyu wa OSS zina mpaka finyu uliowekwa kimakusudi: huduma hutoa na kuthibitisha ufunguo wa msaidizi, huku usakinishaji wa ndani wa OmniRoute ukisimba ufunguo kwa njia fiche, ukilandanisha vielelezo vilivyotiwa sahihi upande wa seva, na kuongoza usanidi wa mtoa huduma. Mpangilio wa uthibitishaji unaosaidiwa ni:

1. Pata ufunguo mpya uliotolewa au uliorejeshwa kutoka kwenye dai la mchangiaji, plans/checkout, mchakato wa urejeshaji, au mwendeshaji aliyeidhinishwa wa seva binafsi. Usibandike ufunguo halisi kwenye kumbukumbu, picha za skrini, maoni ya hoja, au hoja za mstari wa amri.
2. Washa alama ya kipengele RADAR_ENABLED kwenye usakinishaji wa ndani wa OmniRoute. Hii hufanya UI ipatikane, lakini hubaki bila shughuli za mtandao hadi idhini tofauti ihifadhiwe.
3. Fungua /dashboard/radar, bandika ufunguo, kisha uwashe. Kivinjari hutuma ombi moja la ndani la POST /api/radar/settings lenye { optIn: true, supporterKey }; ufunguo husimbwa kwa njia fiche ndani ya mfumo na jibu huwa na omr_****<last4> pekee.
4. Ruhusu skrini ya uanzishaji iendeshe ulandanishaji wa katalogi, au uchague Landanisha sasa. Thibitisha kwamba ukurasa unaonyesha live, toleo la mlisho, na muda wa uletaji. Kwa uchunguzi wa ndani uliothibitishwa, GET /api/radar/status huripoti idhini/uwepo wa ufunguo na hali nne za akiba bila kurudisha ufunguo. POST /api/radar/sync-all inaweza kuonyesha upya katalogi, marejeleo, ofa, na Intel moja kwa moja.
5. Fungua /dashboard/radar/setup?provider=<provider>. Fuata URL ya kitambulisho inayomilikiwa na mtoa huduma, chagua Ongeza ufunguo wa API, hifadhi kupitia fomu halisi ya mtoa huduma, rudi kwenye mwongozo, kisha uendeshe Jaribu muunganisho. Mwongozo hutumia njia za kawaida za /api/providers na /api/providers/<connection-id>/test; hauundi kitambulisho sambamba cha Radar.
6. Fungua /dashboard/radar/combos baada ya angalau miunganisho miwili ya watoa huduma inayooana kuwashwa. Kagua familia iliyopendekezwa na uunde mchanganyiko kupitia API iliyopo ya mchanganyiko. Ofa na Intel hubaki kuwa akiba tofauti zilizotiwa saini zinazopatikana wakati wa moja kwa moja pekee, na zinaweza kukaguliwa kwenye kurasa zao maalum za Radar.
7. Pakia upya /dashboard/radar na ukurasa wa usanidi. Idhini, hali ya ufunguo uliofichwa sehemu, akiba iliyothibitishwa, muunganisho wa mtoa huduma uliohifadhiwa, na kitendo cha majaribio lazima viendelee kuwepo baada ya kupakia upya. Nasa ushahidi tu baada ya ufunguo halisi na kitambulisho cha mtoa huduma kutoonekana tena.

Kuhifadhi ufunguo pekee si uthibitisho wa haki ya ufikiaji wa moja kwa moja. Uthibitisho ni muunganisho wa matokeo ya GET /v1/license/check ya huduma binafsi, kiwango cha live kinachotolewa na katalogi ya OSS, akiba iliyotiwa saini na kuthibitishwa, pamoja na mtiririko halisi wa muunganisho/majaribio ya mtoa huduma. Ufunguo batili, uliokwisha muda, au uliofutwa haki hushusha katalogi kwa usalama hadi community; haupaswi kuripotiwa kama uthibitishaji uliofanikiwa wa ufunguo wa moja kwa moja.

Kiungo cha paneli binafsi ya usimamizi

RADAR_ADMIN_URL huongeza kwa hiari Usimamizi wa Radar ↗ mara tu baada ya kipengee cha Radar kinachoonekana kwa mtumiaji katika sehemu ya Gharama ya utepe wa pembeni. Kwa makusudi, haina thamani chaguomsingi: kigezo kisipowekwa au kikiwa batili, utepe tuli wa pembeni, paleti ya amri, na skrini ya ugeuzaji kukufaa wa utepe wa pembeni hazitakuwa na kipengee cha usimamizi wala URL binafsi.

Thamani hutatuliwa upande wa seva na kuwasilishwa kupitia jibu la GET /api/settings lililothibitishwa kwa usimamizi kwa kipindi cha dashibodi kilichothibitishwa pekee, au kwa mmiliki anayeaminika wa loopback wakati wa uanzishaji wa ndani usiohitaji kuingia. Uthibitishaji wa CLI, huduma za ndani, na ufunguo wa API wenye wigo wa usimamizi haupokei thamani hiyo. Kivinjari huthibitisha jibu tena kabla ya kuunda kiungo cha nje, ambacho hufunguliwa kwa noopener noreferrer.

Tumia URL ya HTTPS tunnel/tailnet isiyo na vitambulisho. HTTP isiyo salama inakubaliwa tu kwa uelekezaji wa SSH wa loopback kama vile http://127.0.0.1:9351; miundo mingine, vitambulisho vilivyopachikwa, URL zenye hitilafu, na maeneo lengwa ya mbali ya HTTP hukataliwa kwa usalama na kuacha urambazaji bila kufanya kazi.

---

Muundo wa usalama

Sahihi ya Ed25519 kwenye baiti halisi

Data ya mpasho hutiwa sahihi kwa Ed25519. verifyFeedBytes() (src/lib/radar/verify.ts) huthibitisha sahihi kwenye baiti halisi za jibu zilizopokewa kupitia mtandao — data hiyo haisasishwi kamwe kabla ya uthibitishaji, kwa hivyo usimbaji upya wa baiti kwa baiti hauwezi kubatilisha au kukwepa kimyakimya ukaguzi wa sahihi. Kushindwa kwa uthibitishaji (invalid_signature) husitisha ulandanishaji kabla data hiyo haijachanganuliwa au kuhifadhiwa kwenye akiba.

Ufunguo wa umma uliobandikwa + ubadilishaji

Ufunguo wa umma wa uthibitishaji umebandikwa kwenye src/lib/radar/pinnedKeys.ts (PINNED_FEED_PUBLIC_KEYS), ambayo ni safu ili ufunguo mpya uweze kuongezwa mwanzoni kabla ya ubadilishaji huku mipasho ya zamani iliyohifadhiwa kwenye akiba na kutiwa sahihi kwa ufunguo wa awali ikiendelea kuwa halali hadi ilandanishwe upya.

Ubatilishaji kwa env unaofaa kwa fork

Vigeu viwili vya env huruhusu fork na wanaojiendeshea huduma waelekeze mteja kwenye mpasho wao wenyewe badala ya huduma chaguomsingi ya OmniRoute — tazama Jinsi ya kujiendeshea mpasho hapa chini:

Kigeu	Kusudi
RADAR_FEED_URL	Hubatilisha URL msingi ya mpasho (chaguomsingi https://radar.omniroute.online).
RADAR_FEED_PUBKEY	Hubatilisha ufunguo wa umma uliobandikwa (base64-DER SPKI au PEM), na kubadilisha safu iliyojengewa ndani kwa ufunguo huu mmoja.

Kikomo cha chini cha toleo

syncRadar() hukataa mpasho uliopakuliwa ambao version yake si mpya kabisa kuliko toleo lililohifadhiwa sasa kwenye akiba (ulinganishaji wa compareVersions(), wenye nukta wa YYYY.MM.DD.n) — { status: "stale" }. Hii huzuia kituo cha mwisho cha mpasho kilichodukuliwa au kusanidiwa vibaya kumrudisha mteja kwenye data ya zamani, iliyotiwa sahihi kwa njia tofauti.

Tarehe mbili, na kwa nini zote mbili huhifadhiwa

Mpasho uliohifadhiwa kwenye akiba huwa na tarehe mbili tofauti, na uwezekano wa kuzichanganya ndiyo sababu kuu ya kuhifadhi zote mbili:

Sehemu	Hutoka kwa	Hujibu
generatedAt	mwili wa mpasho uliotiwa sahihi	data ina umri gani
fetchedAt	saa ya usakinishaji huu	usakinishaji huu uliipakua lini

Mpasho uliopakuliwa dakika chache zilizopita unaweza kuwa na takwimu za wiki kadhaa zilizopita, kwa hivyo fetchedAt pekee haiwezi kumwambia mwendeshaji ikiwa tabaka la juu ni jipya kuliko data msingi iliyo chini yake. Zote mbili hudumishwa katika radar_feed_cache, hurejeshwa na getRadarCatalog().meta, na huripotiwa kando na GET /api/radar/status. Safu mlalo iliyohifadhiwa kwenye akiba kabla safu wima ya generated_at kuwepo (uhamishaji 163) husomwa tena kama null — kisichojulikana hubaki kisichojulikana badala ya kutumia muda wa upakuaji. radar_referrals_cache imehifadhi generated_at yake yenyewe tangu uhamishaji 142.

Kikomo cha chini cha toleo hapo juu hulinganisha version, si mojawapo ya tarehe hizo.

Mapengo mawili yamesalia, yote kwa makusudi: dashibodi bado huonyesha tu Mara ya mwisho kupakuliwa, kwa hivyo kusoma tarehe ya uundaji hapo kunahitaji lebo mpya (na maingizo yake 41 ya lugha); na akiba za ofa na taarifa hazihifadhi kabisa tarehe ya uundaji, ingawa miundo ya mipasho yake ina tarehe hiyo — GET /api/radar/status kwa hivyo huacha sehemu hiyo kwa hizo mbili badala ya kuripoti null ambayo ingesomeka kama "haijulikani".

Uthibitishaji wa skima

Baiti zilizopakuliwa huchanganuliwa na kuthibitishwa dhidi ya RadarFeedSchema (src/lib/radar/feedSchema.ts, skima ya Zod) baada ya uthibitishaji wa sahihi. Kutolingana kwa skima hurejesha { status: "invalid_schema" } na akiba huachwa bila kuguswa. Data iliyohifadhiwa kwenye akiba huthibitishwa tena kwa tahadhari kila inaposomwa (getRadarCatalog()) — safu mlalo ya akiba iliyoharibika au kuhaririwa kwa mkono hurudi kutumia data msingi badala ya kutolewa.

Kikomo cha ukubwa wa jibu (10 MB)

syncRadar() hutekeleza kikomo kamili cha 10 MB kwenye mwili wa jibu la mpasho — mpasho uliotiwa sahihi ni hati ya JSON yenye ukubwa wa KB, kwa hivyo chochote kinachozidi hiki huashiria RADAR_FEED_URL iliyosanidiwa vibaya au hasidi (au chanzo cha juu kinachotoa data taka), si katalogi halali. Utekelezaji una tabaka mbili:

1. Ukaguzi wa awali wa Content-Length huruka kabisa usomaji wa mwili wakati kichwa tayari kinatangaza thamani inayozidi kikomo.
2. Ukaguzi wa jumla inayoendelea wakati wa kusoma mwili hutekeleza kikomo hata wakati Content-Length haipo au inaonyesha ukubwa mdogo kuliko ukubwa halisi — kichwa hakiaminiwi kamwe peke yake. Kuunganisha vipande vilivyokusanywa huhifadhi baiti halisi zinazohitajika baadaye kwa ukaguzi wa sahihi ya Ed25519.

Kuzidi kikomo hurejesha { status: "too_large" } na huacha akiba bila kuguswa, kwa kufuata utaratibu uleule usioharibu kama kila hitilafu nyingine ya ulandanishaji (invalid_signature, invalid_schema, stale).

---

Viwango: community na live

Muundo wa mlisho una sehemu ya tier: "community" | "live", inayoamuliwa upande wa seva na huduma ya mlisho kulingana na ombi (uwepo na uhalali wa ufunguo wa mfuasi) — kiteja hakiamui kamwe kiwango chake chenyewe.

• community — katalogi isiyolipishwa iliyocheleweshwa kwa takribani siku 30 nyuma ya data mpya zaidi. Hiki ndicho kinachopokelewa na ombi lisilothibitishwa au lenye ufunguo batili.
• live — katalogi mpya zaidi, inayotolewa kwa maombi yaliyo na ufunguo halali wa mfuasi.

Ufunguo batili au uliokwisha muda wa mfuasi hushushwa hadi community — huwa si hitilafu kamwe. Njia ya ulandanishi hutofautisha tu kushindwa kwa sahihi/muundo/toleo (vyote vinaweza kurekebishwa, na vyote si hatari kwa hali iliyohifadhiwa kwenye kache) na { status: "updated", version, tier } iliyofanikiwa. Hakuna njia ya hitilafu inayohusiana na kiwango ambayo kiteja kinahitaji kushughulikia.

Kiwango kinachotolewa hutoka kwenye kichwa cha jibu, si mwili uliotiwa sahihi

Sehemu ya tier ya mwili wa mlisho uliotiwa sahihi daima ni "live" — huduma ya mlisho hutoa vizalia viwili vilivyotiwa sahihi kwa kila toleo: live inajumuisha kampeni za sasa na community inaziondoa. Kila kizalia hutiwa sahihi juu ya baiti zake halisi. Mwili bado hautumiki kama uamuzi wa haki ya ufikiaji; kiwango kilichochaguliwa kwa ombi hubebwa kwenye kichwa cha jibu cha x-omniroute-feed-tier, kinachoamuliwa upande wa seva kutokana na ufunguo wa Authorization wa ombi.

syncRadar() (src/lib/radar/sync.ts::parseServedTierHeader()) ndilo eneo pekee linalobainisha kiwango ambacho kiteja kinapaswa kukiamini:

1. Changanua x-omniroute-feed-tier kwa kutumia RadarTierSchema (Zod) — kichwa kisichopo, au thamani ambayo si "community" au "live" hasa, huchukuliwa kuwa haipo (haiaminiki kamwe na kuingizwa kwenye kache/UI kama ilivyo; hili pia linajumuisha seva za zamani za mlisho zilizokuwepo kabla ya kichwa hiki).
2. Tumia sehemu ya tier ya mwili uliotiwa sahihi (daima "live") kama chaguo mbadala pale tu ambapo hatua ya 1 haijatoa chochote.
3. Kiwango kilichobainishwa ndicho kinachohifadhiwa kwenye kache na kurudishwa kama { status: "updated", version, tier } — hii ndiyo thamani inayoonyeshwa na dashibodi, kamwe si sehemu ghafi ya mwili.

---

Kanuni za kuunganisha tabaka wakati wa kusoma

applyFeed() (src/lib/radar/applyFeed.ts) huunganisha mlisho uliohifadhiwa kwenye kache juu ya msingi tuli wakati wa kusoma, ndani ya getRadarCatalog(). Safu ya msingi (FREE_MODEL_BUDGETS) haibadilishwi kamwe — MergedEntry[] huhesabiwa upya katika kila mwito.

Kanuni nne, kwa mpangilio wa kipaumbele:

1. Mlisho hauandiki kamwe juu ya ubatilishaji wa ndani. Kwa kila sehemu: ikiwa opereta amebinafsisha sehemu kwenye ingizo (localOverrides map, yenye ufunguo provider:modelId), thamani ya mlisho kwa sehemu hiyo mahususi hurukwa — thamani ya opereta hushinda.
2. enabled: false huzima ingizo, huku chanzo chake kikihifadhiwa. Ingizo la mlisho linalozima ingizo huweka enabled: false na disabledBy: "radar" kwenye matokeo yaliyounganishwa, ili UI iweze kueleza kwa nini ingizo lilibadilika kutoka kupatikana hadi kuzimwa.
3. Ingizo lililoongezwa na mtumiaji ambalo halipo kwenye mlisho hubaki bila kubadilishwa. Maingizo ambayo yapo tu kwenye msingi (au yaliongezwa ndani) na hayana ingizo linalolingana kwenye mlisho hupitishwa bila kubadilishwa.
4. Ingizo lililowekewa alama ya kufutwa halifufuliwi kamwe. Ikiwa opereta alifuta kwa uwazi ingizo (tombstones set), mlisho unapoongeza tena provider:modelId hiyo katika toleo la baadaye haulirejeshi.

Sehemu zinazoweza kuhaririwa na alama za kufutwa huhifadhiwa kwa kudumu kwenye radar_local_model_state (uhamishaji 153_radar_local_model_state.sql). Adapta ya DB ya umma (src/lib/db/radar.ts) hubadilisha safu hizo kuwa localOverrides map na tombstones set zinazotumiwa na applyFeed(); katika uzalishaji, getRadarCatalog() hupakia hali hiyo baada ya vizuizi vya bendera, kache na muundo kupita. Ni displayName na enabled pekee zinazoweza kuhaririwa na opereta. Utambulisho wa mtoa huduma/modeli, chanzo cha mlisho, mgawo, uwezo, ToS, na data ya usanidi haviwezi kuandikwa kupitia kiolesura hiki.

Dashibodi hutoa vitendo vinne vya ndani:

• Hariri hubadilisha jina la kuonyesha la ndani na hali ya kuwashwa.
• Weka upya mabadiliko ya ndani huondoa sehemu zote mbili zinazoweza kuhaririwa bila kubadilisha alama ya kufutwa.
• Ficha huunda alama ya kufutwa, ili masasisho ya baadaye ya mlisho yasiweze kuunda upya safu hiyo.
• Rejesha huondoa alama ya kufutwa; ubatilishaji wowote uliohifadhiwa kando hubaki kutumika.

enabled: false ya mlisho hubaki kuwa hali ya kipekee ya usalama: hushinda enabled: true ya ndani iliyopitwa na wakati, huweka ingizo lililounganishwa likiwa limezimwa, na hurekodi disabledBy: "radar".

Machapisho ya katalogi hutumia schemaVersion: 2. contextWindow na kila moja ya tools, vision, na thinking hujitegemea kama number | null / boolean | null: null humaanisha haijulikani, huku false ikimaanisha chanzo rasmi cha mtoa huduma kilichothibitishwa na D16 kinasema kwa uwazi kuwa uwezo huo haupo. Bendera za ndani za sajili/vibainisho vya modeli za OmniRoute hazipandishwi kamwe moja kwa moja kuwa taarifa za mlisho. Kiteja bado kinakubali vijipicha vya v1; kwa sababu kiundaji cha zamani kilitumia false kama kishikilia nafasi cha kutokuwepo, false ya v1 husawazishwa kuwa haijulikani huku true ya v1 ikibaki kuwa taarifa halisi. Matoleo ya muundo yasiyojulikana hukataliwa kwa usalama na kache halali ya mwisho hubaki kupatikana. Kila modeli ya v2 yenye muktadha/uwezo usio null lazima iwe na metadataEvidenceUrls[] ya HTTPS isiyohitaji kitambulisho; vinginevyo uthibitishaji wa muundo hushindwa na kache haibadilishwi. Jedwali la katalogi huonyesha hali zote tatu kama ✓, ✕, na ?.

Michanganyiko elekezi na ufikiaji wa MCP

Thamani za familyId zilizothibitishwa hubaki baada ya tabaka kuunganishwa wakati wa kusoma na huendesha moduli halisi ya buildRadarComboSuggestions() (src/lib/radar/comboSuggestions.ts). Familia hupendekezwa tu wakati angalau watoa huduma wawili tofauti wana miunganisho inayotumika na wanatoa kitambulisho halisi cha modeli kilichoratibiwa. Modeli zilizozimwa, watoa huduma wasiotumika, vitambulisho vya modeli vinavyokosekana, familia zenye mtoa huduma mmoja, na ulinganishaji tata wa lakabu/kiambishi awali hukataliwa kwa usalama. Mapendekezo hutumia mkakati uliopo wa priority, yakipanga bajeti kubwa zaidi inayojirudia kila mwezi kwanza; UI huyaunda tu kupitia POST /api/combos.

UI elekezi inapatikana kwenye /dashboard/radar/combos. Inasoma tu sehemu za mwisho za ndani za GET /api/radar/catalog na GET /api/combos/builder/options. Kamwe haianzishi usawazishaji wa Radar, haisomi vitambulisho vya uthibitishaji vya mtoa huduma, wala haiandiki moja kwa moja kwenye hifadhidata ya combo.

Wateja wa MCP wanaweza kusoma makadirio hayohayo ya ndani kwa kutumia omniroute_radar_catalog (read:radar). Vichujio vya hiari vya provider, familyId, na enabledOnly hutathminiwa baada ya usomaji mmoja wa ndani wa GET /api/radar/catalog. Tokeo lake funge linajumuisha metadata ya katalogi pamoja na mtoa huduma/muundo, jina la kuonyesha, familyId, mgao, uwezo, hali ya kuwezeshwa, chanzo, na disabledBy; URL za usanidi, hatua, miunganisho, anwani za barua pepe, funguo, na data ya marejeleo hazirejeshwi kamwe. Zana hii ni ya kusoma pekee na kamwe haiiti /api/radar/sync.

Viashirio vya asili

Kila ingizo lililounganishwa lina uga wa origin ambao UI huonyesha kama beji:

• "baseline" — halijabadilishwa kutoka kwenye katalogi tuli ya toleo.
• "radar" — uga mmoja au zaidi ulisasishwa na mlisho.
• "local" — mwendeshaji ana angalau ubatilishaji mmoja wa ndani kwenye ingizo hili (ubatirishaji wa ndani daima hushinda mlisho kulingana na kanuni ya 1, bila kujali mlisho unasema nini).

---

Nyuso za ndani — kamwe si proksi ya mlisho

Familia za njia za ndani za Radar zilizo hapa chini zinaendesha UI iliyo chini ya src/app/api/radar/:

Njia	Mbinu	Kusudi
/api/radar/catalog	GET	Hurejesha katalogi iliyounganishwa (getRadarCatalog()) kutoka kwenye akiba ya ndani.
/api/radar/sync	POST	Huanzisha syncRadar() upande wa seva; hurejesha hali inayotokana.
/api/radar/settings	GET	Hurejesha { optIn, hasSupporterKey, supporterKeyMasked } — kamwe si ufunguo halisi.
/api/radar/settings	POST	Huweka ridhaa ya kushiriki na/au ufunguo wa msaidizi (uliosimbwa kwa njia fiche).
/api/radar/referrals	GET	Hurejesha { fixed, campaigns, tier } kutoka kwenye akiba ya ndani — tazama Viungo vya rufaa hapa chini.
/api/radar/offers	GET	Hurejesha ofa zinazotumika kutoka kwenye akiba hai ya ndani iliyothibitishwa; kamwe hairejeshi ufunguo wa msaidizi.
/api/radar/offers/sync	POST	Huanzisha mchakato wa syncRadarOffers() wa upande wa seva, unaotumia ufunguo hai pekee.
/api/radar/intel	GET	Hurejesha Intel hai ya ndani iliyothibitishwa pamoja na thamani ya boolean ya utambuzi wa msaidizi; kamwe si utambulisho au ufunguo.
/api/radar/intel/sync	POST	Huanzisha mchakato wa syncRadarIntel() wa upande wa seva, unaotumia ufunguo hai pekee.
/api/radar/status	GET	Hurejesha hali ya mipangilio/akiba ya ndani ya kusoma pekee kwa katalogi, rufaa, ofa na Intel, bila siri.
/api/radar/sync-all	POST	Huendesha moduli zote nne za ulandanishi upande wa seva na hurejesha hali tofauti kwa kila mlisho.
/api/radar/local-model-state	GET	Huorodhesha ubatilishaji na tombstone zilizohifadhiwa kwa vidhibiti vya kuhariri/kurejesha.
/api/radar/local-model-state	PATCH	Huweka au huondoa sehemu za ubatilishaji zilizothibitishwa za displayName/enabled.
/api/radar/local-model-state	PUT	Huunda au huondoa tombstone kwa kutumia { provider, modelId, tombstoned }.
/api/radar/local-model-state	DELETE	Huondoa sehemu za ubatilishaji zinazoweza kuhaririwa huku ikihifadhi tombstone yoyote.

Kanuni kali: njia hizi kamwe hazitumiki kama proksi ya huduma ya mlisho. Kivinjari huwasiliana tu na seva ya ndani ya OmniRoute. Moduli nne zinazowasiliana na huduma ya Radar ni src/lib/radar/sync.ts (katalogi), src/lib/radar/referralsSync.ts (rufaa), na src/lib/radar/offersSync.ts (ofa) pamoja na src/lib/radar/intelSync.ts (Intel); zote huendeshwa upande wa seva, kamwe si upande wa mteja. Hii huweka URL ya mlisho na ufunguo wowote wa msaidizi nje kabisa ya trafiki ya mtandao inayoonekana kwa mteja.

Endpoint zote za Radar hurejesha 404 wakati RADAR_ENABLED imezimwa (tazama Alama hapo juu), na hupitisha majibu ya hitilafu kupitia buildErrorBody()/sanitizeErrorMessage() kulingana na kanuni ya usafishaji wa hitilafu ya repo nzima (docs/security/ERROR_SANITIZATION.md).

Uthibitishaji

Endpoint zote za Radar zinahitaji uthibitishaji kupitia isAuthenticated() (src/shared/utils/apiAuth.ts) — kuki ya kipindi cha dashibodi au ufunguo wa API wenye upeo wa usimamizi, ambalo ni lango lilelile linalolinda sehemu nyingine za /api/settings/*. Ukaguzi wa 404 wakati alama imezimwa daima hufanyika kabla ya ukaguzi wa uthibitishaji, kwa hivyo usakinishaji ambao RADAR_ENABLED imezimwa hubaki sawa kabisa kwa kiwango cha baiti (hakuna ombi la uthibitishaji ili tu kujua kwamba uso huo haupo); mara tu alama inapowashwa, ombi lisilothibitishwa hupata 401 kabla ya usomaji au uandikaji wowote wa DB. GET /api/radar/settings kamwe hairejeshi ufunguo halisi wa msaidizi bila kujali hali ya uthibitishaji — hurejesha tu umbo lililofichwa na thamani ya boolean ya hasSupporterKey.

---

Ofa za waungaji mkono

Ofa hutumia artefakti yao wenyewe iliyotiwa saini, GET /v1/offers/latest, na kamwe hazishiriki kache ya katalogi au ya marejeleo. Endpoint ya seva inahitaji ufunguo halali wa Bearer wa moja kwa moja wa mwungaji mkono; hakuna mbadala wa jumuiya. Kwa hivyo, syncRadarOffers() husimama kabla ya kufikia mtandao ikiwa alama ya kipengele imezimwa, mwendeshaji hajachagua kushiriki, au hakuna ufunguo wa mwungaji mkono uliosanidiwa.

Baada ya GET kufanikiwa, kiteja huthibitisha saini ya Ed25519 juu ya baiti halisi za jibu, huhalalisha RadarOffersFeedSchema, huhitaji mwili uliotiwa saini na kichwa cha x-omniroute-feed-tier vyote viwe na thamani live, hutekeleza sharti la toleo lenye vitone kuwa jipya zaidi kabisa, na kisha tu hubadilisha radar_offers_cache kiatomiki (uhamishaji 144_radar_offers_cache.sql). Kikomo kilekile cha MB 10 cha kichwa pamoja na mtiririko kinachotumiwa na milisho mingine kinatumika. Hitilafu za saini, schema, daraja, urudiaji, ukubwa, HTTP na mtandao zote huhifadhi kache ya mwisho iliyothibitishwa.

Muundo funge wa ofa unakubali aina tatu za manufaa zinazoweza kulinganishwa: asilimia katika pointi za msingi, salio katika vipashio vidogo vya sarafu, au siku za kipindi cha majaribio. Ofa ya mshirika lazima ijumuishe kiwango cha msingi cha umma cha aina sawa na manufaa yake lazima yawe makubwa zaidi kabisa; ofa rasmi hazina kiwango cha msingi cha mshirika. URL lazima ziwe za HTTPS na zisiwe na vitambulisho vya uthibitishaji. getRadarOffers() kwa tahadhari huhalalisha upya data iliyohifadhiwa kwenye kache na huchuja vipengee vilivyokwisha muda wake katika kila usomaji wa ndani; /dashboard/radar/offers huchuja tena muda wa kuisha kabla ya kuonyesha, hutumia maandishi ya Kireno yanapopatikana na Kiingereza kama mbadala, na huweka lebo wazi kwenye ofa za washirika.

Kivinjari huita njia za ndani pekee: husoma muhtasari wa mipangilio uliofichwa sehemu, huomba POST /api/radar/offers/sync ili kuonyesha upya upande wa seva, kisha husoma GET /api/radar/offers. Bila ufunguo, huonyesha viungo vilivyopo vya wachangiaji/usaidizi badala ya kujaribu ombi la mlisho. Viungo vya nje vya ofa hufunguka katika kichupo kipya kwa kutumia noopener noreferrer. Hakuna zana ya MCP ya radar_offers inayotolewa katika toleo hili.

---

Taarifa za Radar, beji ya mwungaji mkono, na CLI

Taarifa ni artefakti iliyotiwa saini inayopatikana katika GET /v1/intel/latest. RadarIntelFeedSchema funge hukubali tu viwango vya ELO vinavyomilikiwa na Radar, vilivyotolewa na msimamizi binafsi kutokana na ulinganisho uliothibitishwa, pamoja na tofauti za kweli za umri/idadi ya katalogi zilizotolewa kutokana na mihtasari ya katalogi iliyotiwa saini. Mbinu imewekwa kuwa ukadiriaji wa awali wa 1000 na K=32. Mpangilio tupu wa viwango ni halali wakati hakuna ulinganisho uliothibitishwa; kiteja kamwe hakibuni mmoja.

syncRadarIntel() hutumia Bearer ileile ya upande wa seva, muda wa mwisho wa sekunde 30, kikomo cha mtiririko cha MiB 10, uthibitishaji wa Ed25519 wa baiti halisi, schema kali, sharti la live katika mwili/kichwa, kiwango cha chini cha toleo, na uhifadhi wa kache ya mwisho iliyo sahihi kama ilivyo kwa ofa. Baada ya muhtasari uliothibitishwa wa moja kwa moja kuhifadhiwa, kiteja hutengeneza radar:<sha256(supporter key)>, huhifadhi tu utambulisho huo wa mwelekeo mmoja, na hutoa tukio maalumu la utambuzi la radar_supporter. Beji yake ya radar-supporter ni idempotenti na hutoa XP sifuri; kamwe haisasishi bao za wanaoongoza wala kutumia tena token_share. /dashboard/radar/intel huonyesha beji kutokana tu na metadata iliyothibitishwa ya kache ya ndani.

CLI hutoa omniroute radar status na omniroute radar sync. Zote huwasiliana na API ya ndani ya OmniRoute pekee. status hutekeleza GET /api/radar/status ya kusoma pekee; sync hutuma POST /api/radar/sync-all moja na kuchapisha matokeo kwa kila mlisho. Hakuna amri inayosoma, kukubali, au kuchapisha ufunguo wa mwungaji mkono, na hakuna inayowasiliana moja kwa moja na huduma ya Radar.

---

Viungo vya rufaa (krediti za bure)

Viungo vya rufaa hutolewa kutoka kwenye mpasho huru, uliosasishwa kila wakati — GET /v1/referrals/latest — tofauti na mpasho wa katalogi. Hili limekusudiwa: mpasho wa katalogi kwenye kiwango cha jumuiya ni taswira ambayo inaweza kuwa ya hadi siku 30 zilizopita, kwa hivyo kiungo cha rufaa kilichotolewa humo kilikuwa kikichelewa kwa muda sawa na orodha halisi ya viungo ya seva (rufaa iliyoongezwa hivi karibuni isingemfikia mtumiaji wa bure/jumuiya kwa hadi mwezi mmoja). Mpasho wa rufaa huondoa ucheleweshaji huo kwa kusawazisha kwa ratiba yake yenyewe, ambayo ni fupi zaidi.

// Mwili wa jibu la GET /v1/referrals/latest (umesainiwa kwa Ed25519, ufunguo uleule uliobandikwa kama
// mpasho wa katalogi):
{
  feed: "omniroute-radar-referrals",
  schemaVersion: 1,
  generatedAt: string,           // ISO — thabiti: max(updatedAt) kwenye viungo vyote vya
                                  // rufaa, ili maombi mawili yanayofanana yatokeze baiti/sahihi
                                  // zilezile kabisa
  referrals: {
    fixed: RadarReferral[],      // ipo katika KILA kiwango, ikiwemo bila uthibitishaji/jumuiya
    campaigns: RadarReferral[],  // hujazwa tu kwa ufunguo halali wa moja kwa moja wa Bearer (mfuasi);
                                  // maombi yasiyo na uthibitishaji/yenye ufunguo ulioisha muda hupata []
  },
}
// RadarReferral = { provider, url, kind: "fixo" | "campanha", validUntil,
//                    requiredAction, isDefault }

Tofauti na mpasho wa katalogi, mwili huu hauna uga wa tier kabisa — seva huamua cha kujumuisha kwa kila ombi kulingana na ufunguo wa Authorization, kwa hivyo kichwa cha jibu cha x-omniroute-feed-tier ndicho chanzo PEKEE cha kiwango kilichotolewa (referralsSync.ts::syncRadarReferrals); kichwa kisichokuwepo/kisichotambulika hushushwa hadi "community", dhana yenye mapendeleo machache zaidi. RadarReferralsFeedSchema (src/lib/radar/referralsFeedSchema.ts) huthibitisha mwili wote, ikitumia tena RadarReferralSchema ileile ya kila rufaa iliyohamishwa kutoka feedSchema.ts, ili mipasho yote miwili ithibitishe rufaa binafsi kwa namna inayofanana. Kila RadarReferral.url lazima iwe https:// — url ya http:// hushindwa uthibitishaji wa skima.

Uga wa ZAMANI wa referrals uliopachikwa kwenye katalogi katika RadarFeedSchema (feedSchema.ts) umehifadhiwa kwa ajili ya uoanifu wa nyuma na mipasho ya katalogi ambayo tayari imehifadhiwa kwenye akiba, lakini getRadarReferrals() haisomi tena — tazama Kifikiaji hapa chini.

Usawazishaji

syncRadarReferrals() (src/lib/radar/referralsSync.ts) ndilo moduli PEKEE linalowasiliana na mtandao kwa ajili ya rufaa, likiakisi mkataba wa syncRadar() kikamilifu: alama imezimwa → disabled; chaguo la kushiriki ni false → opt_out; hupakua ${RADAR_FEED_URL}/v1/referrals/latest (mabadiliko yaleyale ya fork ya RADAR_FEED_URL/RADAR_FEED_PUBKEY kama katalogi), huthibitisha sahihi ya Ed25519 kwenye baiti halisi za jibu (verifyFeedBytes), huthibitisha dhidi ya RadarReferralsFeedSchema, na kuhifadhi kwenye akiba katika jedwali la radar_referrals_cache (uhamishaji 142_radar_referrals_cache.sql) — jedwali tofauti kabisa na radar_feed_cache ya katalogi. Kikomo cha jibu cha MB 10 na kiwango cha chini cha generatedAt hukataa mpasho unaoingia ambao ni wa zamani kuliko ule uliohifadhiwa kwenye akiba, hivyo kulinda dhidi ya urudiaji wa kizalia cha zamani kilichosainiwa. Muhuri wa muda unaolingana unakubaliwa: seva kwa makusudi huzipa lahaja za rufaa za jumuiya na za moja kwa moja generatedAt ileile thabiti, ili mzigo uliosainiwa na kiwango kinachotolewa viweze kubadilika baada ya mabadiliko ya ufunguo wa mfuasi bila seti ya msingi ya viungo kubadilika. Haitupi kamwe — daima hurudisha kitu cha hali; hitilafu kamwe hazibebi ufuatiliaji wa staka katika reason.

Vichochezi viwili huifanya akiba ya rufaa ibaki tayari, vyote vikiwa huru dhidi ya ratiba ya katalogi yenyewe ya saa 24:

• Usawazishaji wakati wa kusoma — GET /api/radar/referrals yenyewe huita syncRadarReferrals() moja kwa moja wakati wowote akiba haipo au ni ya zamani kuliko REFERRALS_STALE_MS (saa 1, shouldSyncReferralsOnRead()), kabla ya kutoa jibu. Hiki ndicho kinachofanya viungo visivyobadilika viwe "vimesasishwa kila wakati" kwa upakiaji unaofuata kabisa wa dashibodi, bila kusubiri kipima muda chochote cha chinichini.
• Usawazishaji wa pembeni wa kipanga ratiba — radarSchedulerTick() (scheduler.ts) hutathmini kwa kujitegemea uchakavu wa rufaa kwenye mpigo uleule wa kila saa unaotumiwa kwa katalogi, na kuita syncRadarReferrals() inapofaa. Hili hutekelezwa bila kujali kama katalogi yenyewe ilistahili kusawazishwa kwenye mpigo huo, na kamwe haliathiri muundo wa RadarTickResult (ni athari ya pembeni ya juhudi bora pekee, inayopuuzwa hitilafu ikitokea).

Kifikiaji

src/lib/radar/index.ts huhamisha vifikiaji viwili vya kusoma pekee, vyote havitupi kamwe (mkataba uleule wa kujilinda kama getRadarCatalog() — alama imezimwa, hakuna akiba, au mzigo ulioharibika uliohifadhiwa kwenye akiba, vyote hutoa muundo tupu badala ya hitilafu):

• getRadarReferrals() → { fixed: RadarReferral[], campaigns: RadarReferral[] }, ikisoma kutoka radar_referrals_cache (kupitia getRadarReferralsCache()) na kuthibitisha kupitia RadarReferralsFeedSchema — si akiba ya katalogi.
• getDefaultReferralFor(provider) → rufaa ya fixed yenye isDefault: true kwa mtoa huduma huyo, au null. Huangalia fixed pekee — kampeni haitumiki kamwe kama kiungo "chaguo-msingi" cha mtoa huduma.

Kanuni halisi ya "rufaa ipi ni chaguo-msingi kwa mtoa huduma" ipo katika findDefaultReferral() (src/lib/radar/referrals.ts), kitendakazi kidogo safi kisicho na uingizaji wa DB — ni salama kukiingiza katika kijenzi cha "use client". getRadarReferrals/ getDefaultReferralFor (katika index.ts) huingiza @/lib/db/radar na kwa hiyo hubaki upande wa seva pekee; dashibodi ya watoa huduma huingiza referrals.ts moja kwa moja badala ya index.ts (tazama hapa chini) ili kuepuka kujumuisha better-sqlite3 kwenye kifurushi cha kivinjari.

GET /api/radar/referrals

Hufuata mpangilio uleule kamili wa vizuizi kama kila njia nyingine ya Radar: RADAR_ENABLED ikiwa imezimwa → 404 (hukaguliwa kwanza, hali yake ikiwa sawa kabisa kwa kila baiti); bila uthibitishaji → 401; vinginevyo huanzisha ulandanishaji wakati wa kusoma (tazama hapo juu) ikiwa data imepitwa na wakati, kisha 200 ikiwa na { fixed, campaigns, tier } — tier hutoka moja kwa moja kwenye safu ya akiba (ambayo huenda ndiyo kwanza imeonyeshwa upya) na ni ya kutoa taarifa tu (huendesha ujumbe wa ushawishi usio mkali wa UI ulio hapa chini). Kamwe haipitishi ombi moja kwa moja kwa seva ya mipasho — msimbo wa chanzo wa njia yenyewe hauna mwito wa fetch(; mtandao hutumika tu ndani ya syncRadarReferrals(), kwa kanuni ileile ya kutumia akiba ya ndani pekee kama /api/radar/catalog.

UI ya dashibodi — kichupo cha "Salio la bure" kwenye /dashboard/radar

Hutumia tena ukurasa uliopo wa Radar (src/app/(dashboard)/dashboard/radar/page.tsx) kama kichupo cha pili badala ya njia mpya — hupunguza eneo la uelekezaji/i18n kwa kipengele ambacho ni tofauti ya data ambayo ukurasa tayari huleta. Baada ya kujijumuisha, upau wa vichupo hutoa Katalogi (jedwali lililopo) na Salio la bure:

• Viungo vya kudumu hupangwa kwa mtoa huduma, huku kila kimoja kikionyesha requiredAction (ikiwa ipo) na kitufe cha target="_blank" rel="noopener noreferrer" kinachoelekea kwenye URL ya rufaa.
• Kampeni huonyesha vivyo hivyo, pamoja na validUntil ikiwa ipo.
• Wakati campaigns haina kitu na kiwango kinachotolewa ni community, UI huonyesha ujumbe mfupi wa ushawishi ("kampeni za muda mfupi ni nyongeza kwa waungaji mkono") — hili kamwe halifichi wala kuzuia orodha ya viungo vya kudumu, ambayo husalia imejazwa kikamilifu kwa kila kiwango. Ushawishi huo ni ujumbe usio mkali tu, wala si kizuizi.

Kiungo cha rufaa kwenye jina la mtoa huduma (dashibodi ya watoa huduma)

ProviderPageHeader (src/app/(dashboard)/dashboard/providers/[id]/components/) tayari iliunganisha jina la mtoa huduma na providerInfo.website ikiwa ipo, ikiwa na mfano mmoja wa awali wa kiungo chenye uchumaji wa mapato: dokezo la kiungo cha mshirika wa Kimi (Moonshot AI) (ufunguo wa i18n wa providers.kimiPartnerLinkNote). D28 hutumia tena muundo huohuo kamili wa dokezo lisilo dhahiri kwa rufaa chaguomsingi za Radar badala ya kuanzisha ufunguo mpya.

Muunganisho hafifu, kwa makusudi:

• resolveProviderHeaderLink() (src/app/(dashboard)/dashboard/providers/providerPageUtils.ts) ni kitendakazi safi — (staticWebsite, referralUrl) => { website, isReferralLink } — kisicho na utegemezi kwa @/lib/radar au @/lib/db/*. providerPageUtils.ts kwa ujumla husalia bila uingizaji huo (imethibitishwa na tests/unit/provider-header-referral-link.test.ts).
• ProviderDetailPageClient.tsx (kijenzi cha "use client") ndicho sehemu pekee inayoruhusiwa kuleta data ya Radar — kupitia fetch("/api/radar/referrals"), muundo uleule wa njia ya ndani unaotumiwa na ukurasa wa dashibodi ya Radar wenyewe — na hukokotoa rufaa chaguomsingi upande wa mteja kwa kutumia findDefaultReferral() kutoka src/lib/radar/referrals.ts isiyotegemea DB.
• RADAR_ENABLED ikiwa imezimwa, ombi la fetch hupokea 404, referralUrl hubaki null, na resolveProviderHeaderLink() hurejesha website tuli ya katalogi bila mabadiliko — ukurasa wa mtoa huduma huwa sawa kabisa kwa kila baiti na ulivyokuwa kabla ya kipengele hiki kuwepo. Matokeo ni yaleyale wakati bado hakuna akiba au hakuna rufaa chaguomsingi kwa mtoa huduma huyo mahususi.
• Rufaa chaguomsingi inapotumika, ProviderPageHeader hupokea isReferralLink na huonyesha dokezo/maelezo ibukizi yale yale yasiyo dhahiri kama kiungo cha mshirika wa Kimi (ikitumia tena ufunguo wa providers.kimiPartnerLinkNote) — kamwe si mwonekano mpya na tofauti.

---

Jinsi ya kujipangishia mpasho

Fork au anayejipangishia mwenyewe anayetaka udhibiti kamili wa katalogi anaweza kuendesha huduma yake mwenyewe ya mpasho bila kugusa msimbo wa mteja:

1. Toa endpoint ya GET /v1/catalog/latest inayorudisha mwili wa JSON unaokidhi RadarFeedSchema (src/lib/radar/feedSchema.ts) — katika kiwango cha juu feed: "omniroute-radar", schemaVersion: 2, version, tier, providers, models, quirks, na totals. Zingatia x-omniroute-radar-schema: 2; seva inayooana na kipindi cha mpito inapaswa kuelekeza kwa chaguo-msingi maombi yasiyo nayo kwenye artifact ya v1 iliyotiwa sahihi kivyake.
2. Tia sahihi baiti halisi za jibu kwa kutumia jozi ya funguo ya Ed25519 na urudishe sahihi ya base64 katika header ya jibu ya x-omniroute-feed-signature.
3. Weka RADAR_FEED_URL kuwa URL mpya ya msingi na RADAR_FEED_PUBKEY kuwa ufunguo wa umma unaolingana (base64-DER SPKI au PEM) — angalia marejeleo ya env var.
4. Washa RADAR_ENABLED na ukubali kushiriki kupitia POST /api/radar/settings ({ optIn: true }).

Hakuna mabadiliko mengine ya msimbo yanayohitajika — verifyFeedBytes() hutambua ubatilishaji huo kiotomatiki (getFeedPublicKeys() katika src/lib/radar/pinnedKeys.ts), na ulinganishaji wa matoleo, uthibitishaji wa schema, pamoja na kanuni za kuunganisha hutumika kwa namna ileile kwa mpasho unaojipangishia.

Viungo vya rufaa (angalia Viungo vya rufaa (salio la bure) hapo juu) ni artifact tofauti ya hiari: fork inayotoa /v1/catalog/latest pekee bado hufanya kazi kikamilifu — syncRadarReferrals() hushuka hadi { status: "error" } inapopata 404 kutoka /v1/referrals/latest na cache hubaki tupu tu, hivyo GET /api/radar/referrals huendelea kurudisha { fixed: [], campaigns: [], tier: null } badala ya kusababisha sehemu nyingine ya ukurasa ishindwe. Ili pia kutoa viungo vya rufaa, toa GET /v1/referrals/latest inayokidhi RadarReferralsFeedSchema (src/lib/radar/referralsFeedSchema.ts) na uitie sahihi kwa jozi ileile ya funguo ya Ed25519 kama mpasho wa katalogi.

Ofa za wafuasi ni artifact nyingine ya hiari. Ili kuzitoa, tekeleza GET /v1/offers/latest kwa kutumia RadarOffersFeedSchema iliyofungwa (src/lib/radar/offersFeedSchema.ts), hitaji haki halali ya ufikiaji, rudisha x-omniroute-feed-tier: live, na utie sahihi baiti halisi kwa ufunguo huohuo. Fork inayoacha endpoint hii hudumisha tabia ya katalogi/rufaa bila kubadilika; kuonyesha upya ofa hushindwa bila kuharibu data na cache ya mwisho ya ofa ya ndani iliyothibitishwa huendelea kupatikana.

Intel ni ya hiari kwa namna hiyohiyo. Anayejipangishia anaweza kutoa GET /v1/intel/latest kwa kutumia RadarIntelFeedSchema (src/lib/radar/intelFeedSchema.ts), kuhitaji haki halali ya ufikiaji, kurudisha x-omniroute-feed-tier: live, na kutia sahihi baiti halisi kwa ufunguo wa pamoja wa Ed25519. Kuacha endpoint hii hakuathiri katalogi, rufaa, na ofa; kuonyesha upya Intel huhifadhi snapshot yoyote ya mwisho ya ndani iliyothibitishwa.

---

Nyaraka zinazohusiana

• docs/security/ERROR_SANITIZATION.md — muundo wa majibu ya hitilafu unaofuatwa na route za /api/radar/*.
• docs/reference/ENVIRONMENT.md — marejeleo ya RADAR_FEED_URL / RADAR_FEED_PUBKEY.