Store tələbləri və minimum icazələr

1. Kurs kontekstində ChatGPT Store nədir

Gəlin ümumi mənzərədən başlayaq. ChatGPT Store — ChatGPT daxilində tətbiqlər kataloqudur; istifadəçi ora daxil olub sizin App‑i tapa, aktivləşdirə və adi dialoqlarda istifadə edə bilər. Sizin üçün bu sadəcə vitrin deyil, qaydaları olan paylama kanalıdır — LLM dünyası üçün «App Store» analoqu.

Bu kursda App‑inizin üç “həyat rejimi”ni fərqləndiririk:

• Birinci rejim — Dev Mode. App‑iniz hesabınıza/təşkilatınıza bağlıdır, sizə və ola bilsin, həmkarlarınıza açıqdır. Rəsmi review yoxdur, amma platformanın ümumi siyasətləri qüvvədədir. Burada sakitcə hər şeyi sınaya, hər şeyi log edə, tunellər və staging backendləri işə sala bilərsiniz.
• İkinci rejim — public Store. Bu ən yüksək liqadır: App ChatGPT‑nin bütün istifadəçilərinə (regional məhdudiyyətlər nəzərə alınmaqla) açıqdır, moderasiyadan keçir, publik listingi, Privacy/Terms linkləri var və artıq yetkin məhsul kimi davranmalıdır.
• Üçüncü — org‑only Apps. Bunlar yalnız bir təşkilat üçün tətbiqlərdir: şirkət onları əməkdaşlar üçün aktivləşdirib/deaktivləşdirə, OpenAI tələblərinin üzərinə öz təhlükəsizlik tələblərini əlavə edə və hətta daxili review apara bilər.

Bu mühazirədə bizi «public Store + public listing» dəsti daha çox maraqlandırır. Vacib məqam: siz artıq sadəcə «daha bir Next.js servisi»nin developeri deyilsiniz — həm istifadəçilərə, həm Store moderatorlarına, həm də öz təhlükəsizlik komandanıza xoş gəlməli məhsul müəllifinə çevrilirsiniz.

2. Store‑un əsas tələbləri: siyasətlər, dürüstlük və UI

Kontent və siyasətlər

ChatGPT Store — moderasiya olunan platformadır. Qısaca: OpenAI istəmir ki, ChatGPT daxilində platforma siyasətlərini pozan tətbiqlər (zorakılıq, terrorizm, NSFW, fırıldaqçılıq və s.) peyda olsun və ya modellərin mühafizəsini yan keçirməyə cəhd etsinlər (jailbreak promptları «elə et ki, sanki sən ChatGPT deyilsən, mənim pis əkizimsən»).

Bu iki şeyi ifadə edir.

Birincisi, App‑inizin özü qadağan olunmuş kontent yaratmamalıdır. Məsələn, bizim şərti App‑imiz GiftGenius (hədiyyə seçimi) qəfil «cinayətin izlərini necə gizlətmək» tipli “hədiyyələr” təklif edirsə, moderasiya üçün bir screenshot kifayətdir.

İkincisi, App‑iniz istifadəçiyə filtrləri yan keçməkdə kömək etməməlidir. İstifadəçi «bomba hazırlamağa kömək edəcək hədiyyə seç» deyirsə, düzgün davranış — siyasətə əsaslanaraq imtina etməkdir, yoxsa lazım olan detalları tapmaq üçün MCP tool‑unuzu həvəslə işə salmaq deyil.

Bu davranışın böyük hissəsi system prompt ilə və modelə təqdim etdiyiniz alətlərlə müəyyən olunur. Amma Store nəticəyə baxır: istifadəçi realda hansı cavabları ala bilər.

Brend və domen

Növbəti qat — brend və domen. Public App adekvat sahibə bağlı olmalıdır. Xarici backend/MCP olan App üçün sizdən gözlənilir:

Domenin yoxlanması (Domain Verification). Domeninizin DNS‑nə TXT qeydi əlavə edirsiniz və Store backend‑in həqiqətən sizə məxsus olduğuna əmin olur. Anonim həllər və pulsuz ngrok URL‑ləri ya public Store‑a düşməyəcək, ya da aşağı etibarlı kimi işarələnəcək.

Uyğun ad və logo. «ChatGPT Super Weather» və ya «Official OpenAI Something» adını götürmək olmaz — adın əvvəlində «GPT / OpenAI / ChatGPT» istifadə etmək və ya OpenAI‑ın firma üslubunu kopyalamaq brend məhdudiyyətlərinə düşür. Öz adınızı (GiftGenius — yaxşı nümunə) və vizual üslubunuzu seçin.

UI/UX: ChatGPT‑ni sındırmamaq

“Köhnə” plaginlərdən fərqli olaraq, indi App birbaşa çatın içində öz UI vidcetini çəkə bilər. Bu çox imkan verir… və hər şeyi korlamağın da çox yolu var.

Store‑un sadə ideyası var: vidcet ChatGPT‑yə qarşı «native» hiss edilməlidir. Şriftlər, boşluqlar, rənglər, dark/light mövzudakı davranış və mobil görünüş — hər şey səliqəli olmalı, elə təsir bağışlamamalıdır ki, sanki siz çata reklam banneri və ya ayrıca bir SPA yerləşdirmisiniz.

Store həmçinin çatı “ələ keçirən” UI‑ni sevmir: nəhəng tam ekran örtüklər, «dərhal abunə ol» tipli modal pəncərələr, avtomatik skroll və digər aqressiv patternlər. Sizin vidcet dialoq daxilində kart/sihirbaz/alət olmalıdır, ayrıca kainat yox.

Əslində, moderasiya üç şeyə baxır: kontent siyasətini pozursunuzmu, çaşdırırsınızmı (bununla bağlı ayrıca blok var — dərsin sonuna yaxın manifest və listing uyğunluğundan danışacağıq) və ChatGPT‑ni pis UX‑li reklam zibilliyinə çevirirsinizmi. «Dürüstlük» burada App‑in real bacarıqları ilə sizin təsvir və UI‑də iddia etdiklərinizin uyğunluğu deməkdir.

3. Store App‑inizin icazələrini necə görür

Ayrı böyük tələblər oxu — istifadəçidən və xarici sistemlərdən hansı hüquqları istədiyiniz. Burada Store yalnız təhlükəsizliyə deyil, həm də bu hüquqların tətbiqin vəd etdiyi dəyərə nə dərəcədə uyğun olduğuna baxır.

İndi isə mühəndis üçün ən maraqlısı: icazə modeli. Apps SDK və MCP kontekstində üç əsas giriş səviyyəniz var.

Anlaşıqlı olması üçün bunu belə təsvir etmək olar:

graph TD
    A[App manifest/konfiq] --> B[Model capabilities]
    A --> C[OAuth scopes]
    A --> D[MCP tools & ACP]
    D --> E[İstifadəçi təsdiqi səviyyəsi]

Model capabilities — ciddi mənada OAuth scopes və ya write tools kimi «icazələr» deyil, modelin daxili imkanlarıdır. Amma təhlükəsizlik layihələndirməsi üçün onları da minimallaşdırılmalı ilk giriş səviyyəsi kimi nəzərdən keçirmək rahatdır.

Səviyyə 1: model capabilities

Bu, modelin backend‑inizə müraciət etmədən «öz-özünə» edə bildikləridir: veb brauzing, DALL‑E ilə şəkil generasiyası və s.

Əgər həm brauzingi, həm də MCP tools aktiv etsəniz, model bəzən qərara gələ bilər ki, vəzifəni xüsusi alətinizlə deyil, veb axtarışla həll etmək daha asandır — xüsusən də tools təsvirləri bulanıqdırsa və ya promtda prioritetlər dəqiq verilməyibsə. Buna görə, App onsuz da MCP vasitəsilə sizin API‑nizə gedirsə, ya browsing‑i söndürməyi, ya da promtda MCP tools üçün prioriteti dəqiq sabitləşdirməyi düşünün.

Yəni bu səviyyədə də minimum icazə prinsipini tətbiq edirsiniz: App‑in real dəyəri üçün gərək olmayan hər şeyi söndürürsünüz.

Səviyyə 2: OAuth scopes

Əgər App‑iniz autentifikasiya istifadə edirsə (Modul 10), siz xarici provayderdən aşağıdakı kimi scope‑lar istəyirsiniz: openid, email, profile, orders.read, orders.write və s.

Burada minimalizm xüsusilə vacibdir:

• Əgər məqsədiniz sadəcə istifadəçiləri fərqləndirməkdirsə, çox vaxt openid (anonim identifikator) kifayətdir və email ümumiyyətlə lazım deyil.
• Email doğrudan da lazımdırsa, bu, UX‑də və icazə təsvirlərində şəffaf olmalıdır: «sizə qəbzləri və sifariş xatırlatmalarını göndərmək üçün lazımdır», «birdən lazım olar» yox.

Üstəlik, avtorizasiyanı «tələb əsasında» edirik: öncə istifadəçiyə login olmadan baza funksiyaları sınamağa imkan veririk, yalnız həqiqətən «hədiyyə seçimini sevimlilərə qeyd etmək» və ya «sifariş tarixçəsinə baxmaq» istəyəndə giriş istəyirik. Bu sürtünməni azaldır və konversiyanı artırır.

MCP tools üçün scope konfiqurasiyası nümunəsi (sadələşdirilmiş):

// server/mcp/config/auth.ts
export const OAUTH_SCOPES = {
  basic: ["openid"],
  orders: ["openid", "orders.read"],
  checkout: ["openid", "orders.read", "orders.write"]
};

Səviyyə 3: MCP tools və «consequential» əməliyyatlar

Üçüncü səviyyə — sizin MCP alətləriniz və ACP/Instant Checkout. MCP serverində hər bir alət aşağıdakı ola bilər:

• yalnız oxuma (read‑only): məzənnəni əldə etmək, hədiyyələri seçmək, kataloqa baxmaq;
• vəziyyəti dəyişən (consequential): sifariş yaratmaq, məktub göndərmək, vəsait çıxmaq.

İkinci tip alətlərdən Store daha sərt təsdiq modelini gözləyir. İdeya belədir: hər şeyi «sadəcə belə» çağırmaq olmaz. Platforma terminlərində bu, adətən consequential: true bayrağı və təsdiq siyasəti (always_allow əvəzinə ask_user) ilə ifadə olunur.

MCP alətinin qeydiyyatı nümunəsi — security‑schemes və bunun vəziyyəti dəyişən əməliyyat olduğunu göstərməklə:

// server/mcp/tools/createOrder.ts
server.registerTool(
  "create_order",
  {
    title: "Create order",
    description: "GiftGenius-də yeni sifariş yaradır.",
    inputSchema: {
      type: "object",
      properties: {
        productId: { type: "string" },
        quantity: { type: "integer", minimum: 1 }
      },
      required: ["productId", "quantity"]
    },
    _meta: {
      securitySchemes: [{ type: "oauth2", scopes: ["orders.write"] }]
    },
    // psevdosahə: bu əməliyyat vəziyyəti dəyişir
    consequential: true
  },
  async ({ input, security }) => {
    // ... sifarişin yaradılması məntiqi
  }
);

Scope və security‑schemes nümunəsi rəsmi MCP tools sənədlərindən götürülüb; alətlər ya avtorizasiyasız, ya da OAuth2 ilə qorunmuş ola bilər.

Store baxımından bu, istifadəçi üçün anlaşılan mətnə çevrilir: «Bu tətbiq GiftGenius mağazasında sifarişlər yarada və idarə edə bilər» və bəzən ayrıca təsdiq addımına.

4. İcazələrə istifadəçi və moderator gözü ilə baxış

Biz mühəndislər üçün App — manifest, MCP serveri və bir yığın TypeScript deməkdir. Store üçünsə bu, faktlar toplusudur: App istifadəçi məlumatları və xarici dünya ilə nə edə bilər.

Belə bir cədvəl təsəvvür etmək olar:

Açar fikir: hər texniki element insanın anlaya biləcəyi hərəkətə maplənməlidir. Modul planlarında bu birbaşa belə ifadə olunur: texniki MCP tool get_user_orders listingdə «mağazamızda sifariş siyahınıza baxış» mətninə çevrilir.

İcazəni bir‑iki cümlə ilə izah edə bilmirsinizsə — bu, narahatedicidir. Ola bilsin, artıq lazımi olandan çox şey istəyirsiniz və ya bir App daxilində bir neçə müxtəlif tapşırığı qarışdırmısınız.

5. Minimum zəruri icazələr prinsipi

Adi backend dünyasında PoLP (Principle of Least Privilege) tez‑tez «bəli, bazada rolları nə vaxtsa məhdudlaşdırarıq, sonra edərik» kimi qəbul olunur. ChatGPT Apps‑də bu «sonra» deyil — Store‑a düşməyin meyarı və istifadəçi konversiyasına təsir edən amildir.

Vacib məqamlar:

• App nə qədər az hüquq istəsə, istifadəçinin baza etibarı o qədər yüksək olar. ChatGPT daxilində dialoq — istifadəçinin müəyyən səviyyədə məxfilik gözlədiyi mühitdir. Qəfil bütün hesabına, ödənişlərə və kontaktlara giriş istəyən App şübhəli görünür.
• İcazələr nə qədər anlaşıqlı və dar olsa, review edən üçün bir o qədər rahatdır. Moderator App‑in nə etdiyini və bunun siyasətlərə və təhlükəsizlik üzrə ən yaxşı təcrübələrə nə dərəcədə uyğun olduğunu tez başa düşməlidir. Over‑permissioned App‑lər tipik olaraq «dəqiqləşdirmə istə» və bəzən rədd cavabı alır.
• Just‑in‑time və minimal giriş reallaşdırdıqca, UX daha yumşaq olur. Auth ekranı — ciddi sürtünmə nöqtəsidir. App avtorizasiyadan əvvəl də faydalı təcrübə verirsə (məsələn, istifadəçiyə bağlı olmadan top hədiyyələri göstərmək), istifadəçi daha sonra genişləndirilmiş imkanlara razı olur.

Buna görə Store‑da «minimum icazələr» təkcə təhlükəsizliklə bağlı deyil, həm də marketinq və böyümə ilə bağlıdır. Modul 18‑də ayrıca vurğulanır ki, minimal icazələr bürokratik formalıq deyil, rəqabət üstünlüyüdür.

6. Nümunələr: «pəhrizdən» əvvəl və sonra GiftGenius icazələri

Bunun abstrakt nəzəriyyədə qalmaması üçün şərti qəhrəmanımız GiftGenius‑u götürək. Tutaq ki, siz onu «maksimum»a görə layihələndirmisiniz və belə bir imkan siyahısı alınıb:

1. Məhsul kataloqunu oxumaq və hədiyyələri filtrləmək.
2. İstifadəçinin sifariş tarixçəsinə baxmaq.
3. Yeni sifarişlər yaratmaq və mövcudları ləğv etmək.
4. «Seçilmiş siyahıları» istifadəçi hesabında saxlamaq.
5. Endirimlərlə bağlı email bildirişləri göndərmək.

Konfiqurasiya səviyyəsində bu belə ifadə oluna bilər:

// server/mcp/config/permissions-naive.ts
export const PERMISSIONS_NAIVE = {
  capabilities: { webBrowsing: true, dalle: false },
  oauthScopes: ["openid", "email", "orders.read", "orders.write"],
  tools: {
    searchProducts: { consequential: false },
    getUserOrders: { consequential: false },
    createOrder: { consequential: true },
    cancelOrder: { consequential: true },
    saveFavoriteList: { consequential: true },
    sendDiscountEmail: { consequential: true }
  }
};

Kağız üzərində belə dəst məntiqli görünə bilər («gec‑tez hamısı lazım olacaq»), amma Store üçün ilk relizdə bu, artıqdır:

• Sifariş tarixçəsini dərhal oxumağa ehtiyac yoxdur. Bir dəfəlik seçim və platformanın öz nəzarətində olan təhlükəsiz ACP/Instant Checkout ilə kifayətlənmək olar.
• Email bildirişləri — ümumiyyətlə ayrıca mövzudur: onlar üçün həm email saxlamaq, həm Privacy Policy‑də izah, həm də unsubscribe emalı lazımdır. MVP üçün GiftGenius‑da bu, demək olar ki, həmişə artıqdır.

Minimallaşdırma prinsipini nəzərə alaraq minimal start dəstini belə qura bilərsiniz:

// server/mcp/config/permissions-v1.ts
export const PERMISSIONS_V1 = {
  capabilities: { webBrowsing: false, dalle: false },
  oauthScopes: [], // giriş (login) olmadan, anonim işləyirik
  tools: {
    searchProducts: { consequential: false },
    createOrder: { consequential: true }
  }
};

Bu versiyada:

• App istifadəçinin hesabına «girmir», tarixçəni oxumur, email göndərmir.
• Bütün həssas əməliyyatlar (sifarişin yaradılması) ACP/Instant Checkout vasitəsilə gedir; burada istifadəçi standart ödəniş axınını görür.

Listingdə dürüst şəkildə yazmaq olar: «GiftGenius mağazasında hədiyyələr seçir və sifarişlər yaradır. Tətbiq sizin çat tarixçənizi saxlamır və email bildirişləri göndərmir». Bu, həm istifadəçi, həm də reviewer üçün xoşdur.

Sonra, stabil trafik və etibar yarandıqda, əlavə icazələrlə (sifariş tarixçəsi, sevimlilər) yeniləmə buraxa və uyğun olaraq listing və Privacy Policy‑ni yeniləyə bilərsiniz.

7. İcazələri listingdə necə təsvir etmək

Manifest və konfiqurasiya — maşın dilidir. Moderator və istifadəçi tam başqa mətni oxuyur: ad, təsvir, «Bu tətbiq nə edə bilər» bloku və Privacy/Terms linkləri.

Modul 17 xəritələndirməni vurğulayır: texniki scope və alətlər → insan‑dili əməliyyatlar.

GiftGenius v1 üçün bunu belə tərtib edə bilərik.

Texniki:

• Browsing: off
• DALL‑E: off
• MCP tools: search_products (read‑only), create_order (consequential)

Listingdə:

• «Təsvirinizə və ya parametrlərə (cins, yaş, büdcə, maraqlar) görə hədiyyələr seçir.»
• «ChatGPT daxilində qorunan checkout vasitəsilə GiftGenius mağazasında sifarişlər yarada bilir.»
• «Sizin email və ya sifariş tarixçənizə giriş istəmir, bildirişlər göndərmir.»

Sonradan OAuth login və orders.read əlavə etsək, təsviri dürüst şəkildə yeniləyirik:

• «GiftGenius hesabını qoşduqda, keçmiş sifarişlərinizi görə və daha fərdiləşdirilmiş tövsiyələr verə bilər.»

Çox vacibdir: App‑in etmədiyi şeyi vəd etməyin və kritik əməliyyatları gizlətməyin. Modul 18 üçün toplanmış sənədlərdə birbaşa vurğulanır: listingdəki məlumat real davranışa tam uyğun olmalıdır — xüsusən ödənişlər və PII kimi həssas mövzularda.

8. Store tələblərinin arxitekturanızla əlaqəsi

Store tələblərinin vakuumda mövcud olmadığını görmək vacibdir. Bütün bu tələblər «marketinqdən gələn əlavə forma» deyil. Store əslində təhlükəsizlik və production modullarında artıq etdiklərinizi yoxlayır:

• Əgər OAuth qurdunuz, səliqəli .well-known end‑pointlər və token yoxlamaları etdinizsə, App qəfil geniş scope‑lar vasitəsilə istifadəçidən «yarım internet» istəsə, bu qəribə görünər. Belə App asanlıqla over‑permissioned kimi review‑da ilişər.
• Əgər retention siyasətini və PII‑scrub‑u vicdanla reallaşdırmısınızsa, dürüst Privacy Policy yazmaq və yoxlamadan keçmək asanlaşacaq. Store və istifadəçilər linkə keçib sizin vədlərinizi real proseslərlə tutuşdura bilərlər.
• Əgər MCP serverinin sabitliyini, log və metrikləri (observability və SLO modulları) yaxşı sazlamısınızsa, reviewer‑lərin performans və alət səhvləri ilə bağlı sualları az olacaq.

Minimal icazələr bu mənzərəni gözəl tamamlayır: siz təkcə təhlükəsiz və stabil deyilsiniz, həm də istifadəçi məlumatlarına «təvazökar» yanaşırsınız.

9. Dərs gedişində mini‑praktika

Yalnız nəzəriyyədə qalmasın deyə, indidən hazırkı App‑inizi (və ya GiftGenius‑u) addım‑addım təhlil edin.

Əvvəlcə App‑in real edə bildiyi bütün əməliyyatları yazın. Məsələn: «hədiyyə seçmək», «sifariş yaratmaq», «tarixçəni göstərmək», «sevimlilərə saxlamaq», «həmkarlara məktub göndərmək». Bunu adi mətnlə yazmaq daha yaxşıdır, hələ texniki detalları düşünməyin.

Sonra hər əməliyyat üçün cavab verin: «Bu, istifadəçi məlumatlarının hansını əhatə edir?» və «Xarici sistemdə vəziyyəti dəyişirmi?». Beləcə əməliyyatları read‑only və consequential olaraq avtomatik böləcəksiniz.

Bundan sonra əməliyyatları icazə səviyyələri ilə tutuşdurun: harada yalnız model capabilities kifayətdir, harada OAuth scope lazımdır, harada isə MCP tools üzərində consequential: true və bəlkə də istifadəçi təsdiqi gərəkdir.

Və indi «qayçı» oynayın: əsas dəyəri öldürmədən ilk relizdən nəyi çıxarmaq olar? Çox vaxt elə çıxır ki, tarixçə, sevimlilər və email bildirişləri olmadan da App öz əsas işini görür. Deməli, bu icazələri 1.1 və ya 2.0 versiyasına saxlamaq olar.

10. Store tələbləri və icazələrlə tipik səhvlər

Səhv №1: «Hər şeyi edən super App düzəldək, Store özü başa düşər».
Developer App‑i universal assistent kimi təsvir edir («maliyyə, tibb, hüquq və alış‑verişdə kömək edərəm»), onlarla MCP tools qoşur və maksimum hüquqlar istəyir. Belə App eyni anda həssas domenlərə (tibb/maliyyə/hüquq) girir, çoxlu məlumat istəyir və «one job per app» prinsipini pozur. Nəticə göz qabağındadır: moderasiya çox sual verəcək və ya sadəcə rədd edəcək. Daha yaxşısı, aydın icazələri olan bir neçə dar fokuslu App hazırlamaqdır.

Səhv №2: «Birdən lazım olar» deyə over‑permissioned auth.
Klassika: App email, profile, orders.read, orders.write, billing.read istəyir, halbuki faktiki olaraq «təsvirə görə hədiyyə seçmək» kifayətdir. İstifadəçi üçün bu, tamahkar məlumat toplayıcı kimi görünür; Store üçünsə riskli tətbiqdir. Apps təhlükəsizliyi üzrə sənədlərdə bu, pis təcrübə nümunəsi kimi birbaşa göstərilir.

Səhv №3: Manifestlə listingin uyğunsuzluğu.
Manifestdə sizdə create_order, cancel_order və ödəniş əməliyyatlarına giriş var, təsvirinizdə isə yalnız «hədiyyə tövsiyə edir» yazmısınız. Tez ya gec reviewer və ya istifadəçilər görəcək ki, App iddia ediləndən artıq şey bacarır. Bu, etibarı zədələyir və App‑in Store‑dan çıxarılmasına gətirə bilər.

Səhv №4: Həssas əməliyyatları «zərərsiz» UI arxasında gizlətmək.
Məsələn, vidcetdə «Seçimi saxla» düyməsi çəkirsiniz, amma bu əslində şöbədə hamıya məktub göndərir və ya kənar sistemdə tapşırıqlar yaradır; icazələrdə isə bunu izah etmirsiniz. Store sürprizləri sevmir. Developer bələdçilərində birbaşa deyilir: tətbiq məhz vəd etdiyi işi görməlidir, gizli davranış olmamalıdır.

Səhv №5: Login olmadan da mümkünkən «girişdə» login istəmək.
App işə düşür — və dərhal hesab qoşmağı, hər şeyə giriş verməyi tələb edir; guya «yoxsa işləmir», halbuki ssenarilərin yarısını anonim də reallaşdırmaq olar. Bu, konversiyanı azaldır və sanki dəyər vermək yox, məlumat toplamaq üçün tələsirsiniz təəssüratı yaradır. Daha yaxşısı əvvəlcə App‑in həqiqətən faydalı olduğunu göstərmək, sonra isə niyə əlavə hüquqlar lazım olduğunu izah etməkdir.

Səhv №6: Təşkilati konteksti görməzdən gəlmək.
Bəzən developer App‑i “hamı üçün” düzəldir, halbuki mahiyyətcə bu, daxili korporativ alətdir. Nəticədə Store‑a çox spesifik icazələr (daxili CRM, əməkdaşların məxfi məlumatları) daşıyır ki, bunları geniş istifadəçiyə adekvat izah etmək çətindir. Belə hallarda public Store‑a yox, org‑only rejiminə və daxili review‑a yönəlmək lazım idi.