Marketplace review policy & checklist

Every community plugin submitted through the personal cabinet is reviewed before it can be published. This page is the public checklist — the same criteria the review uses — so you can meet every requirement before you submit.

Review has two stages: an automated check against this checklist, then a human moderator who makes the final decision. Nothing is published without the moderator’s approval, and the automation never approves on its own.

How a verdict is reached

Each criterion is scored pass / warn / fail with a short reason (and, for the moderator, the exact evidence).
A security hard-fail (any item in section A) ⇒ automatic rejection. You get the reasons and can fix and resubmit.
Warnings or minor issues ⇒ the submission is flagged for a human, who weighs them and decides.
All-pass ⇒ it still goes to a human, who makes the final publish decision.

[!IMPORTANT] The automated review never publishes a plugin. A human moderator always makes the final call, and nothing reaches the catalog without it.

A. Security — a fail here auto-rejects

These are hard requirements. Any failure rejects the submission automatically.

A1 — No hardcoded secrets. No API keys, tokens, passwords or private keys anywhere in the artifact or metadata. Declare credentials by name in the capability manifest; the customer supplies values at install time.
A2 — No malicious code. No reverse shells, remote-code evaluation, miners, ransomware or similar patterns.
A3 — No data exfiltration. No sending user data, credentials or memory to undeclared hosts. Every host the plugin contacts must be listed in the manifest’s network.
A4 — No operations beyond declared capabilities. No filesystem access outside the plugin’s own directory, no spawning processes unless exec is declared, no privilege escalation, no reading host secrets (env, ssh keys, system files).
A5 — No obfuscation. No packed, minified-to-hide or otherwise obfuscated code that conceals behavior.
A6 — Clean dependencies. No known-malicious or known-vulnerable packages; dependencies pinned.
A7 — Declared capabilities match the code. The capability manifest must reflect what the code actually does — no undeclared network, filesystem, exec, channel or credential use. This is the single most important correctness check.
A8 — Safe handling of its own surface. No command-injection, SQL-injection or path-traversal in the plugin’s own code.

B. Correctness

B1 — Valid manifest. manifest.json has the required fields, a valid slug, a semver version and a working entrypoint.
B2 — It loads. The plugin initializes cleanly.
B3 — Well-formed, minimal capabilities. The capability manifest parses and declares the least it needs — nothing extra.
B4 — New or incremented version. The version is higher than any previously submitted version.
B5 — No slug collision. The slug does not collide with a reserved or first-party name.

C. Completeness — store-page parity

C1 — Names & descriptions in RU + EN. Name, short and full description in both languages, all meaningful (no placeholders).
C2 — Category. One category from the allowed set.
C3 — Icon + at least one screenshot. Valid images.
C4 — Version + changelog. A version and human-readable changelog notes.
C5 — Author identity. A resolvable submitter.
C6 — License. A license from the allowed set.
C7 — Valid links. Homepage/repository, if given, is a valid https:// URL. A donation link, if given, must be a valid https:// link to a known donation host (for example Boosty, Patreon, PayPal, YooMoney) — arbitrary or phishing hosts are rejected.
C8 — Human-readable permissions. The capability manifest’s description explains, in plain language, what the plugin needs and why.

D. Policy, legal & content

D1 — No prohibited content. Nothing illegal, harmful or against platform policy.
D2 — No impersonation. No trademark abuse or pretending to be another brand or the AiHummer team.
D3 — No misleading claims. The plugin does what it says.
D4 — Coherent locale. RU and EN text is real and coherent, not machine soup.
D5 — Not spam. Not empty, duplicate or spam.

What auto-rejects vs what a human decides

Outcome	Trigger
Auto-reject	Any section A security hard-fail.
Flagged → human	Warnings or minor issues in B/C/D (weak description, borderline category, minor manifest quibble).
Human decides	Every submission that clears automation still needs an explicit moderator approval to publish.

The donation-host allowlist

A donation link is optional and always external — the marketplace never handles money. If you add one it must point to a recognized donation platform over https:// (for example Boosty, Patreon, PayPal or YooMoney). Links to unknown hosts, shorteners or anything resembling phishing are rejected. Community plugins are free; the donation link is purely a way for grateful users to support you.

Where next

Submit a plugin — the step-by-step submission walkthrough.
Plugin SDK — build the plugin and its manifest.json.
Marketplace overview & tiers — how the official and community catalogs differ.