AiHummer
Français
ConnexionCompte
v1.1.x
{ }Swagger

Politique et liste de contrôle des avis du marché

v1.1.x · mis à jour 2026-07-19

Chaque plugin communautaire soumis via le cabinet personnel est examiné avant de pouvoir être publié. Cette page est la liste de contrôle publique — les mêmes critères que ceux utilisés par l’examen — afin que vous puissiez satisfaire à toutes les exigences avant tu soumets.

La révision comporte deux étapes : une vérification automatisée contre cette liste de contrôle, puis un modérateur humain qui prend la décision finale. Rien n’est publié sans l’approbation du modérateur, et l’automatisation n’approuve jamais seule.

Comment un verdict est rendu

  • Chaque critère est noté réussir / avertir / échouer avec une brève raison (et, pour le modérateur, la preuve exacte).
  • A échec de sécurité définitif (tout article de la section A) ⇒ rejet automatique. Vous obtenir les raisons et pouvoir corriger et soumettre à nouveau.
  • Avertissements ou problèmes mineurs ⇒ la soumission est signalé pour un humain, qui les pèse et décide.
  • Passe-tout ⇒ ça va toujours à un humain, qui effectue la publication finale décision.

[!IMPORTANT] La révision automatisée jamais publie un plugin. Un modérateur humain fait toujours l’appel final, et rien n’atteint le catalogue sans lui.

A. Sécurité — un échec ici entraîne un rejet automatique

Ce sont des exigences strictes. Tout échec rejette automatiquement la soumission.

  • A1 — Pas de secrets codés en dur. Aucune clé API, jeton, mot de passe ou clé privée n’importe où dans l’artéfact ou les métadonnées. Déclarer les identifiants par nom dans le manifeste de capacité; Le client fournit des valeurs lors de l’installation.
  • A2 — Aucun code malveillant. Pas de shells inversés, d’évaluation de code à distance, de mineurs, rançongiciel ou modèles similaires.
  • A3 — Aucune exfiltration de données. Ne pas envoyer de données utilisateur, d’identifiants ou de mémoire à hôtes non déclarés. Chaque hôte que le plugin contacte doit être listé dans le manifeste network.
  • A4 — Aucune opération au-delà des capacités déclarées. Aucun accès au système de fichiers à l’extérieur le propre répertoire du plugin, aucun processus ne sera lancé sauf exec est déclaré, non élévation de privilèges, sans lecture des secrets de l’hôte (env, clés ssh, fichiers système).
  • A5 — Pas d’obfuscation. Pas de code empaqueté, minimisé pour être caché ou autrement obfusqué qui dissimule le comportement.
  • A6 — Nettoyer les dépendances. Aucun paquet connu comme malveillant ou vulnérable ; dépendances figées.
  • A7 — Les capacités déclarées correspondent au code. Le manifeste de capacité doit refléter ce que le code fait réellement — pas de réseau non déclaré, de système de fichiers, d’exécution, utilisation du canal ou des informations d’identification. Il s’agit de la vérification de correctitude la plus importante.
  • A8 — Manipulation sécurisée de sa propre surface. Pas d’injection de commandes, d’injection SQL ou traversée de chemin dans le code du plugin lui-même.

B. Exactitude

  • B1 — Manifeste valide. manifest.json a les champs requis, un identifiant valide, un semver version et un point d’entrée fonctionnel.
  • B2 — Ça charge. Le plugin s’initialise correctement.
  • B3 — Bien formé, capacités minimales. Le manifeste de capacités analyse et déclare le au moins il a besoin — de rien de plus.
  • B4 — Nouvelle version ou version mise à jour. Le version est plus élevée que toute précédente version soumise.
  • B5 — Pas de collision de limace. Le slug ne collide pas avec un réservé ou nom de la première partie.

C. Exhaustivité — parité des pages du magasin

  • C1 — Noms et descriptions en RU + EN. Nom, description courte et complète dans les deux langues, toutes significatives (pas d’espaces réservés).
  • C2 — Catégorie. Une catégorie de l’ensemble autorisé.
  • C3 — Icône + au moins une capture d’écran. Images valides.
  • C4 — Version + journal des modifications. Une version et des notes de journal des modifications lisibles par l’homme.
  • C5 — Identité de l’auteur. Un soumetteur résolvable.
  • C6 — Licence. Une licence provenant de l’ensemble autorisé.
  • C7 — Liens valides. Page d’accueil/dépôt, si fourni, est valide https:// URL. A lien de donation, si fourni, doit être valide https:// lien vers un connue hôte de donation (par exemple Boosty, Patreon, PayPal, YooMoney) — arbitraire ou Les hôtes de phishing sont rejetés.
  • C8 — Autorisations lisibles par l’homme. Le manifeste de capacité description explique, en langage clair, ce dont le plugin a besoin et pourquoi.

D. Politique, juridique et contenu

  • D1 — Aucun contenu interdit. Rien d’illégal, de nuisible ou contraire à la plateforme politique.
  • D2 — Pas d’usurpation d’identité. Aucun abus de marque ni prétendre être une autre marque ou l’équipe AiHummer.
  • D3 — Pas de déclarations trompeuses. Le plugin fait ce qu’il dit.
  • D4 — Paramètre régional cohérent. Le texte en russe et en anglais est réel et cohérent, pas une soupe de machine.
  • D5 — Pas de spam. Pas vide, doublon ou spam.

Ce que le système rejette automatiquement vs ce qu’un humain décide

Résultat Déclencheur
Rejet automatique N’importe section A échec critique de sécurité.
Signalé → humain Avertissements ou problèmes mineurs en B/C/D (description faible, catégorie limite, petite contestation manifeste).
L’humain décide Toute soumission qui passe l’automatisation nécessite encore une approbation explicite d’un modérateur pour être publiée.

La liste blanche des hôtes de donation

Un lien de don est optionnel et toujours externe — le marché ne manipule jamais d’argent. Si vous en ajoutez un, il doit pointer vers un plateforme de dons reconnue au-dessus https:// (par exemple Boosty, Patreon, PayPal ou YooMoney). Les liens vers des hébergeurs inconnus, des réducteurs d’URL ou tout ce qui ressemble à du phishing sont rejetés. Les plugins communautaires sont gratuit; le lien de don est simplement un moyen pour les utilisateurs reconnaissants de vous soutenir.

Où ensuite