Política de revisión del mercado y lista de verificación

Cada complemento comunitario enviado a través de gabinete personal es revisado antes de que pueda ser publicado. Esta página es la lista de verificación pública — los mismos criterios que utiliza la revisión — para que puedas cumplir con todos los requisitos antes tú te sometes.

La revisión tiene dos etapas: una verificación automatizada contra esta lista de verificación, entonces un moderador humano quién toma la decisión final. Nada se publica sin la aprobación del moderador, y la automatización nunca aprueba por sí sola.

Cómo se llega a un veredicto

Cada criterio se califica aprobar / advertir / reprobar con una razón breve (y, para el moderador, la evidencia exacta).
A fallo de seguridad crítico (cualquier artículo en la sección A) ⇒ rechazo automático. Usted obtén las razones y puedes corregir y volver a enviar.
Advertencias o problemas menores ⇒ la presentación es marcado para un humano, quien los pesa y decide.
Todo paso ⇒ todavía va a un humana, quien hace la publicación final decisión.

[!IMPORTANT] La revisión automatizada nunca publica un complemento. Un moderador humano siempre hace la llamada final, y nada llega al catálogo sin ella.

A. Seguridad: un fallo aquí rechaza automáticamente

Estos son requisitos estrictos. Cualquier fallo rechaza la presentación automáticamente.

A1 — Sin secretos codificados. No claves de API, tokens, contraseñas o llaves privadas en cualquier lugar del artefacto o los metadatos. Declarar credenciales por nombre en el manifiesto de capacidad; el cliente proporciona valores en el momento de la instalación.
A2 — Sin código malicioso. No reverse shells, evaluación de código remoto, mineros, ransomware o patrones similares.
A3 — No hay exfiltración de datos. No enviar datos de usuario, credenciales ni memoria a anfitriones no declarados. Cada anfitrión con el que el complemento se contacte debe estar listado en el manifiesto network.
A4 — No realizar operaciones más allá de las capacidades declaradas. Sin acceso al sistema de archivos fuera el propio directorio del complemento, sin generar procesos a menos que exec se declara, no escalamiento de privilegios, sin leer secretos del host (env, claves ssh, archivos del sistema).
A5 — Sin ofuscación. Código sin empaquetar, minificar para ocultar o de otro modo ofuscado que oculta el comportamiento.
A6 — Limpiar dependencias. No se conocen paquetes maliciosos ni paquetes con vulnerabilidades conocidas; dependencias fijadas.
A7 — Las capacidades declaradas coinciden con el código. El manifiesto de capacidad debe reflejar lo que el código realmente hace — sin red, sistema de archivos, exec no declarados, uso del canal o de las credenciales. Esta es la verificación de corrección más importante.
A8 — Manipulación segura de su propia superficie. Sin inyección de comandos, inyección SQL o recorrido de rutas en el propio código del complemento.

B. Exactitud

B1 — Manifiesto válido. manifest.json tiene los campos requeridos, un slug válido, un semver version y un punto de entrada funcional.
B2 — Carga. El complemento se inicializa correctamente.
B3 — Bien formado, capacidades mínimas. El manifiesto de capacidad analiza y declara el menos no necesita — nada extra.
B4 — Versión nueva o incrementada. la version es más alto que cualquier anterior versión enviada.
B5 — Sin colisión de identificadores. El identificador no colisiona con uno reservado o nombre de la primera parte.

C. Integridad — paridad de página de la tienda

C1 — Nombres y descripciones en RU + EN. Nombre, descripción corta y completa en ambos idiomas, todos significativos (sin marcadores de posición).
C2 — Categoría. Una categoría del conjunto permitido.
C3 — Icono + al menos una captura de pantalla. Imágenes válidas.
C4 — Versión + registro de cambios. Una versión y notas de cambios legibles para humanos.
C5 — Identidad del autor. Un remitente resoluble.
C6 — Licencia. Una licencia del conjunto permitido.
C7 — Enlaces válidos. La página de inicio/repositorio, si se proporciona, es válida https:// URL. A enlace de donación, si se proporciona, debe ser válido https:// enlace a un conocida anfitrión de donaciones (por ejemplo Boosty, Patreon, PayPal, YooMoney) — arbitrario o Los hosts de phishing son rechazados.
C8 — Permisos legibles por humanos. El manifiesto de capacidad description explica, en lenguaje sencillo, lo que el complemento necesita y por qué.

D. Política, legal y contenido

D1 — Sin contenido prohibido. Nada ilegal, dañino o en contra de la plataforma política.
D2 — Sin suplantación. No abusar de marcas registradas ni hacerse pasar por otra marca o el equipo AiHummer.
D3 — Sin afirmaciones engañosas. El complemento hace lo que dice.
D4 — Local coherente. El texto en ruso e inglés es real y coherente, no una mezcla artificial.
D5 — No es spam. No vacío, duplicado o spam.

Qué rechaza automáticamente vs lo que decide un humano

Resultado	Disparador
Rechazo automático	Cualquiera sección A fallo de seguridad crítico.
Marcado → humano	Advertencias o problemas menores en B/C/D (descripción débil, categoría límite, pequeña objeción manifiesta).
Humano decide	Cada envío que pasa la automatización aún necesita la aprobación explícita de un moderador para publicarse.

La lista de permitidos para anfitriones de donaciones

Un enlace de donación es opcional y siempre externa — el mercado nunca maneja dinero. Si agregas uno, debe apuntar a un plataforma de donaciones reconocida sobre https:// (por ejemplo Boosty, Patreon, PayPal o YooMoney). Se rechazan los enlaces a hosts desconocidos, acortadores o cualquier cosa que se asemeje a phishing. Los complementos de la comunidad son gratis; el enlace de donación es simplemente una forma para que los usuarios agradecidos te apoyen.

¿A dónde vamos después?

Enviar un complemento — el paso a paso guía de envío.
SDK de complementos — construir el complemento y su manifest.json.
Resumen del mercado y niveles — cómo el Los catálogos oficiales y comunitarios difieren.