პლაგინის გამოქვეყნება პირადი კაბინეტიდან

Community-მარკეტფლეისი ნებისმიერ დარეგისტრირებულ მომხმარებელს აძლევს საშუალებას გამოაქვეყნოს პლაგინი, რომ ის ყველამ დააინსტალიროს — ისევე, როგორც თქვენ აქვეყნებთ აპლიკაციას აპლიკაციების მაღაზიაში. თქვენ ავსებთ ბარათის მეტამონაცემებს, აცხადებთ, რა უფლებები სჭირდება პლაგინს, ტვირთავთ ბილდს და აგზავნით შესამოწმებლად. ეს გვერდი მთელ პროცესს ნაბიჯ-ნაბიჯ გაგაცნობთ.

[!NOTE] ეს ნაკადი community (მესამე მხარის) პლაგინებისთვისაა, რომლებიც იგზავნება თქვენი პირადი კაბინეტიდან my.aihummer.ru-ზე. თავად AiHummer-ის პლაგინები საკუთარი კონვეიერით ვრცელდება. Community-პლაგინები უფასოა; შეგიძლიათ დაამატოთ დონატის არასავალდებულო ბმული.

სანამ დაიწყებთ

დარეგისტრირებული პირადი კაბინეტის ანგარიში — დარეგისტრირდით და დაადასტურეთ ის (იხ. რეგისტრაცია). გამოგზავნა ნებისმიერ მომხმარებელს შეუძლია.
აწყობილი პლაგინი — ხელმოწერილი სარელიზო tarball, აწყობილი Plugin SDK-ით (aihummer plugin package). თუ ჯერ არ აგიწყვიათ, ჯერ იქიდან დაიწყეთ.
ხატულა და მინიმუმ ერთი სქრინშოტი, ასევე მზა აღწერები რუსულ და ინგლისურ ენებზე.

როგორ მუშაობს გამოქვეყნება (საერთო სურათი)

თქვენი განაცხადი გადის ფიქსირებულ კონვეიერს. ყოველ ნაბიჯზე მის სტატუსს კაბინეტში ხედავთ.

ეტაპი	რა ხდება	ვინ მოქმედებს
მონახაზი	თქვენ ქმნით ჩანაწერს და ავსებთ მეტამონაცემებს; ჯერ არაფერია საჯარო.	თქვენ
გაგზავნილი	თქვენ აგზავნით შესამოწმებლად.	თქვენ
AI-შემოწმება	ავტომატური აგენტი ამოწმებს პლაგინს შემოწმების პოლიტიკის მიხედვით — უსაფრთხოება, მანიფესტის სისწორე, სისრულე, კონტენტი.	ავტომატიკა
მოდერაცია	მოდერატორი-ადამიანი კითხულობს AI-ის ანგარიშს, ასევე თქვენს არტეფაქტსა და მეტამონაცემებს და იღებს გადაწყვეტილებას.	AiHummer-ის გუნდი
გამოქვეყნებული	დამტკიცების შემდეგ არტეფაქტი ხელმოიწერება და ემატება community-კატალოგსა და საჯარო მარკეტფლეისის ლენტს.	AiHummer-ის გუნდი
უარყოფილი	თუ რაიმე ვერ გაიარა, თქვენ იღებთ მიზეზებს; ასწორებთ და თავიდან აგზავნით.	თქვენ → ისევ მონახაზში

[!IMPORTANT] AI არასდროს აქვეყნებს პლაგინს დამოუკიდებლად. საბოლოო გადაწყვეტილებას ყოველთვის ადამიანი იღებს, და არაფერი ხვდება კატალოგში მისი დამტკიცების გარეშე.

ნაბიჯი 1 — გახსენით «ჩემი პლაგინები»

შედით my.aihummer.ru-ზე, გახსენით განყოფილება «ჩემი პლაგინები» და დააჭირეთ «გამოქვეყნება»-ს (ან «ახალი პლაგინი»-ს). ასე იქმნება მონახაზი, რომლის თავისუფლად რედაქტირებაც შეგიძლიათ, სანამ არ გააგზავნით.

ნაბიჯი 2 — შეავსეთ მაღაზიის მეტამონაცემები

შეავსეთ ყველა ველი. არასრული მეტამონაცემები ერთ-ერთი ყველაზე გავრცელებული მიზეზია, რის გამოც განაცხადს უკან აბრუნებენ.

ველი	რა უნდა შეიყვანოთ
სახელი (RU + EN)	პლაგინის საჩვენებელი სახელი ორივე ენაზე.
მოკლე აღწერა (RU + EN)	ერთი ხაზი კატალოგის ბარათისთვის.
სრული აღწერა (RU + EN)	რას აკეთებს პლაგინი, როგორ გამოვიყენოთ, რა სჭირდება. აზრიანი — და არა შემავსებელი.
კატეგორია	აირჩიეთ ერთი დაშვებული ნაკრებიდან (მაგ. არხები, პროდუქტიულობა, ინტეგრაციები, ხმა, უტილიტები).
ვერსია	semver სტრიქონი, მაგ. `1.0.0`. ყოველი ახალი განაცხადი უნდა ზრდიდეს მას.
ხატულა	ვალიდური კვადრატული სურათი.
სქრინშოტები	მინიმუმ ერთი; რომელიც პლაგინს მოქმედებაში აჩვენებს.
ლიცენზია	პლაგინის ლიცენზია (მაგ. MIT, Apache-2.0).
საიტი / რეპოზიტორია	არასავალდებულო `https://` ბმული თქვენს პროექტზე.
დონატის ბმული	არასავალდებულო. ვალიდური `https://` ბმული ცნობილ დონატ-ჰოსტზე — მაგალითად Boosty, Patreon, PayPal ან YooMoney. ფიშინგი ან თვითნებური ჰოსტები უარიყოფება.
ცვლილებების ჟურნალი (RU + EN)	რა შეიცვალა ამ ვერსიაში.

[!TIP] დაწერეთ აღწერები რეალური მომხმარებლისთვის, რომელსაც არასდროს უნახავს თქვენი პლაგინი. “სულელებისთვის” ზუსტად ის არის, რაც საჭიროა: თქვით, რას აკეთებს, როდის გამოვიყენოთ და რა სჭირდება.

ნაბიჯი 3 — გამოაცხადეთ capability-მანიფესტი

Capability-მანიფესტი უსაფრთხოების მოდელის გულია. ეს არის მოკლე, სტრუქტურირებული დეკლარაცია ყველა უფლების, რაც თქვენს პლაგინს სჭირდება — რომელ ჰოსტებს ესაუბრება, რომელ ფაილებს ეხება, უშვებს თუ არა გარე ბრძანებებს, რომელ არხებსა და წვდომებს იყენებს.

რატომ უნდა გამოვაცხადოთ

მომხმარებლები ხედავენ მოთხოვნილ უფლებებს ინსტალაციამდე და თანხმდებიან მათზე, ისევე როგორც მობილური აპლიკაციის უფლებების მოთხოვნაზე.
ინსტანსი მანიფესტს იყენებს პლაგინის შესაზღუდად იმით, რაც მან გამოაცხადა.
შემმოწმებლები ამოწმებენ, რომ თქვენი გამოცხადებული უფლებები ემთხვევა იმას, რასაც კოდი რეალურად აკეთებს. პლაგინი, რომელიც ისეთ უფლებას წვდება, რომელიც არ გამოუცხადებია, უარიყოფა.

მინიმალური უფლებების პრინციპი

გამოაცხადეთ მხოლოდ ის, რასაც თქვენი პლაგინი ნამდვილად იყენებს, და მეტი არაფერი. ნაკლები უფლება ნიშნავს უფრო სწრაფ შემოწმებას, უფრო მარტივ თანხმობას მომხმარებლისგან და მეტ ინსტალაციას. თუ ფაილურ სისტემას არ ეხებით, გამოაცხადეთ ცარიელი სია. თუ არასდროს უშვებთ პროცესს, დააყენეთ exec მნიშვნელობაზე false.

ფორმატი

Capability-მანიფესტი JSON-ობიექტია შემდეგი ველებით:

ველი	ტიპი	მნიშვნელობა
`network`	string[]	ჰოსტების სახელები, რომლებსაც პლაგინი უკავშირდება (მისი გამავალი მოთხოვნების allowlist).
`filesystem`	string[]	ბილიკები, რომლებსაც კითხულობს ან წერს, საკუთარი პლაგინის დირექტორიის მიმართ.
`exec`	boolean	უშვებს თუ არა გარე პროცესებს / ბრძანებებს.
`channels`	string[]	შეტყობინებების არხები, რომლებთანაც ინტეგრირდება (მაგ. `telegram`).
`credentials`	string[]	დასახელებული სეკრეტები/კონფიგურაციის გასაღებები, რომლებსაც იყენებს (არასდროს — სეკრეტების მნიშვნელობები).
`description`	string	მოკლე, ადამიანისთვის წასაკითხი აღწერა, რა და რატომ სჭირდება.

მაგალითი:

{
  "network": ["api.example.com", "cdn.example.com"],
  "filesystem": ["./cache"],
  "exec": false,
  "channels": ["telegram"],
  "credentials": ["api_token"],
  "description": "Calls the Example API to sync tasks and posts replies to Telegram. Caches responses under its own ./cache directory. No process spawning, no other hosts."
}

[!WARNING] ნუ ჩადებთ რეალურ სეკრეტებს, ტოკენებს ან გასაღებებს არსად — არც მანიფესტში, არც მეტამონაცემებში, არც არტეფაქტში. გამოაცხადეთ წვდომები მხოლოდ სახელით (მაგ. api_token); რეალურ მნიშვნელობას მომხმარებელი ინსტალაციისას შეიყვანს. ჩაშენებული (hardcoded) სეკრეტები ავტომატური უარყოფაა.

ნაბიჯი 4 — ატვირთეთ არტეფაქტი

ატვირთეთ თქვენი პლაგინის ბილდი:

ფორმატი: .tar.gz სარელიზო tarball, აწყობილი ბრძანებით aihummer plugin package.
ის უნდა შეიცავდეს პლაგინის manifest.json-ს (SDK-მანიფესტი — kind, ვერსია, entrypoint, გამოცხადებული capabilities, კონფიგურაციის ველები).
ნაბიჯ 3-ში შევსებული capability-მანიფესტი უნდა იყოს თანხმდებადი იმასთან, რასაც კოდი და manifest.json რეალურად აკეთებს.

ხატულასა და სქრინშოტებს აქვე ამაგრებთ, თუ ჯერ არ დაგირთავთ.

[!TIP] ატვირთვამდე ლოკალურად გაუშვით aihummer plugin validate. ვალიდაციის კონტრაქტი იგივეა, რასაც მარკეტფლეისი იყენებს, ამიტომ ლოკალურად გავლილი მანიფესტი აქაც მიიღება.

ნაბიჯი 5 — გააგზავნეთ შესამოწმებლად

როცა ყველა ველი შევსებულია და არტეფაქტი ატვირთული, დააჭირეთ «გაგზავნა შესამოწმებლად»-ს. კაბინეტი ჯერ ამოწმებს სისრულეს; თუ რაიმე აკლია — ზუსტად გეტყვით, რა. მიღების შემდეგ სტატუსი იცვლება გაგზავნილზე, შემდეგ AI-შემოწმებაზე — მეტი აღარაფრის გაკეთება არ გჭირდებათ.

ნაბიჯი 6 — თვალი ადევნეთ სტატუსს და წაიკითხეთ ვერდიქტი

გახსენით პლაგინი «ჩემს პლაგინებში», რომ თვალი ადევნოთ მის სტატუსს. შემოწმების დასრულებისას ერთ-ერთ შემდეგს დაინახავთ:

მოდერაციაზე — ავტომატურმა შემოწმებამ გაიარა ან მხოლოდ წვრილმანები მონიშნა; ახლა ადამიანი უყურებს. უბრალოდ დაელოდეთ.
უარყოფილი — რაიმე ვერ გაიარა. თქვენ დაინახავთ ვერდიქტს, მოკლე რეზიუმეს და კონკრეტულ ჩავარდნილ პუნქტებს (ყოველზე მიზეზით). ეს თქვენი გამოსასწორებელი სიაა.
გამოქვეყნებული — დამტკიცებული, ხელმოწერილი და პროდში. თქვენი პლაგინი ახლა ჩნდება AiHummer-ის მარკეტფლეისზე და ინსტალირდება ნებისმიერ ინსტანსში, სადაც community-კატალოგი ჩართულია.

როგორ წავიკითხოთ უარი და თავიდან გავაგზავნოთ

გახსენით პლაგინი; წაიკითხეთ ჩავარდნილი პუნქტები და მათი მიზეზები.
გაასწორეთ ისინი — უმეტესად ეს ერთ-ერთია: აკლია/სუსტი აღწერა, შეუთანხმებელი capability-მანიფესტი, ჩაშენებული სეკრეტი, ცუდი დონატის ბმული ან ვერსია, რომელიც არ გაზარდეთ.
დაარედაქტირეთ მეტამონაცემები და/ან ატვირთეთ ახალი არტეფაქტი გაზრდილი ვერსიით.
ისევ დააჭირეთ «გაგზავნა შესამოწმებლად»-ს. ის იმავე კონვეიერს გაივლის.

[!NOTE] უარი დასჯა კი არა, ჩეკ-ლისტია. შემოწმების პოლიტიკა სწორედ იმისთვისაა საჯარო, რომ ყველა მოთხოვნა გაგზავნამდე დააკმაყოფილოთ.

სად შემდეგ

შემოწმების პოლიტიკა და ჩეკ-ლისტი — ზუსტი კრიტერიუმები, რომლითაც თქვენს პლაგინს ამოწმებენ.
Plugin SDK — პლაგინისა და მისი manifest.json-ის აწყობა.
პლაგინის გამოქვეყნება — პრივატული side-load და გამოქვეყნების სხვა რეჟიმები.
ინსტალაცია და განახლებები — როგორ აინსტალირებენ მომხმარებლები და როგორ არის მოწყობილი ნდობის მოდელი.