Reihantt6/sns-myagent

CLI de Wonda

Wonda CLI es un conjunto de herramientas de creación de contenido para agentes basados en terminal. Úsalo para generar imágenes, videos, música y audio; editar y componer medios; publicar en plataformas sociales; e investigar/automatizar en LinkedIn, Reddit y X/Twitter.

Instalación

Si wonda no se encuentra en el PATH, instálalo primero. Las instalaciones recomendadas son los instaladores de escritorio firmados (CLI + icono de bandeja + relay siempre activo, sin pasos adicionales): macOS brew install --cask degausai/tap/wonda-app (o el wonda-macos.pkg desde los lanzamientos), Windows winget/wonda-windows-setup.exe. Los canales solo CLI a continuación funcionan en todas partes y pueden agregar la aplicación de escritorio más tarde con wonda app install:

# npm
npm i -g @degausai/wonda

# Homebrew
brew tap degausai/tap && brew install wonda

Configuración

• Autenticación: wonda auth login (abre el navegador, recomendado) o establece la variable de entorno WONDA_API_KEY
• Verificar: wonda auth check

Autenticación del conector OAuth

Los conectores web de Claude y Cowork utilizan el flujo OAuth 2.1 de Wonda en lugar de un campo de clave API de CLI. El conector inicia sesión a través de Wonda en el navegador, otorga el acceso a la cuenta solicitada y recibe tokens OAuth vinculados al recurso de la API de Wonda. El servidor intercambia esos tokens por la clave API interna de la cuenta solo dentro de Wonda, por lo que los agentes y los hosts del conector nunca ven la clave sk_.... Para la CLI y la ruta MCP stdio local, sigue usando wonda auth login o WONDA_API_KEY.

Relay local de Claude Cowork

Claude Cowork (la aplicación de escritorio) ejecuta servidores MCP locales en el host, por lo que puede cargar el paquete .mcpb o una configuración local stdio wonda-mcp directamente, incluidas las escrituras WAB (verificado 2026-07-07). La web de Claude no puede. El relay local de Wonda es la ruta alternativa: permite que el conector REMOTO (web o Cowork) ejecute acciones en el propio Mac del usuario y su IP residencial sin ninguna configuración MCP local:

1. Abre https://wonda.sh/download mientras has iniciado sesión e instala el paquete notarizado de Mac.
2. Vincula el relay con wonda relay pair o la entrega del navegador en el primer inicio. Esto utiliza el flujo cli-auth existente con una credencial wrelay_... con ámbito de relay almacenada en el Llavero de macOS. No le pidas al usuario que pegue una clave API o un código de dispositivo.
3. Abre https://wonda.sh/setup, conecta LinkedIn, X y Reddit a través del WAB local con interfaz gráfica, luego aprueba el conector de Wonda una vez en Claude.

La política del motor es auto | my_machine | cloud. auto usa el relay local cuando está en línea y cloud en caso contrario. my_machine no debe caer silenciosamente: si el relay está fuera de línea, pregunta si se debe cambiar a cloud.

Organizaciones y contexto de gasto

Las organizaciones de Wondercat son carteras compartidas con sus propios asientos y facturación. Los miembros pueden gastar desde la cartera de la organización (en lugar de sus créditos personales) cambiando de contexto:

• wonda organizations list (alias: wonda orgs list, wonda org list) — ve cada organización a la que perteneces con tu rol y plan de asiento en cada una.
• wonda use --org <slug> — contexto de organización persistente para esta máquina. Establece X-Wonda-Org en cada solicitud; retiene, cobra y wonda balance se enruta a través de la cartera de la organización.
• wonda use --personal — vuelve a personal.
• wonda usage — resumen de uso solo de gasto (total + desglose por modelo + por proyecto) para un período (--month 2026-05, o --from/--to; por defecto es el mes actual, UTC). --project <name> restringe el informe a un proyecto. En contexto de organización, informa el uso de toda la organización, incluido un desglose por miembro — se requiere rol de administrador/propietario. Los administradores también pueden descargar un informe completo de Excel desde la página de organización en la web.

Proyectos (etiquetado de gasto)

Los proyectos atribuyen el gasto a un flujo de trabajo con nombre para su monitoreo. Los agentes deben verificar el proyecto activo al inicio de la tarea (wonda use lo imprime) y establecer uno por tarea cuando el operador monitorea el gasto por proyecto:

• wonda use --project <name> — persistente: cada cargo subsiguiente lleva el proyecto (en wonda usage, la API y el informe de Excel de la organización). wonda use --no-project deja de etiquetar; cambiar el contexto de organización/personal limpia el proyecto automáticamente (los proyectos son por ámbito).
• --project <name> en cualquier comando — anulación única para esa invocación.
• wonda project list|create|delete — gestiona el registro en el ámbito activo. Los proyectos de organización son creados solo por administradores/propietarios de la organización; los proyectos personales son de autoservicio. El etiquetado contra un nombre que no existe falla con unknown_project (sin nuevos depósitos silenciosos, por lo que los errores tipográficos no pueden dividir los datos de monitoreo).

wonda topup siempre recarga tu cartera personal, independientemente del contexto. Recargar la cartera de la organización (y configurar la recarga automática) es solo para administradores y ocurre en la web en /organizations/<slug>. Si un miembro se queda sin créditos de la organización, el error le indica que pida a un administrador o que vuelva a personal; no pueden recargar la cartera de la organización desde la CLI.

Los roles dentro de una organización están separados del plan de asientos:

• Propietario: el creador original. No puede ser degradado ni expulsado. Puede transferir la propiedad a otro miembro desde la página de la organización (raro).
• Administrador: puede invitar (individual o masivamente mediante pegado), expulsar, cambiar roles, cambiar asientos, recargar, configurar recarga automática, cambiar límites mensuales.
• Usuario: solo puede gastar dentro de la cartera de la organización (sujeto a un límite mensual por miembro si el administrador lo ha establecido).

Un asiento de organización de pago (WONDA / WONDA_PREMIUM) otorga el mismo acceso a funciones de pago (habilidades, etc.) que un plan personal de pago, pero solo en contexto de organización. wonda use --personal vuelve al plan de cuenta personal del usuario.

Niveles de acceso

Wonda es solo de pago: cada superficie de producto requiere un plan de pago, incluidas llamadas API, lecturas de plataforma local, automatización del navegador, composición de medios, edición de archivos, diagnóstico, generación, publicación, raspado, análisis, habilidades, operación de relay y twin en la nube. Antes de que cualquier comando de producto realice trabajo, la CLI realiza una verificación de derechos en vivo contra Wonda. La verificación falla de forma cerrada cuando no se puede verificar el acceso. Las cuentas nuevas no obtienen acceso al producto hasta que se suscriben, y un saldo de crédito positivo no sustituye a un plan.

Nivel	Acceso
Anónimo (sin inicio de sesión)	Sin acceso al producto. La autenticación, configuración, precios, descubrimiento/selección de organización, finalización de shell y comandos de apagado local permanecen disponibles para que el usuario pueda suscribirse, recuperarse o detener servicios en segundo plano. Ejecuta wonda auth login y luego suscríbete.
Gratuito (inició sesión, sin plan de pago)	Sin acceso al producto. Suscríbete en https://wonda.sh/account para usar el producto.
WONDA ($19.99/mes, "Pro")	Todo excepto twin en la nube: generación (image/generate, video/generate, ...), carga/descarga de medios, publicación, raspado, análisis, análisis de video, habilidades (wonda skill install/list/get), transiciones, recorte, correo electrónico, creación de cuentas de reddit/linkedin, estilos, marca.
WONDA_PREMIUM ($49.99/mes, "Premium")	Todo en WONDA, más twin en la nube (wonda twin: aprovisionamiento, ejecuciones programadas, inicio de sesión transmitido) con protección antidetect/shadowban, sin límites y creación de cuentas en EE. UU.
Marcado (interruptores de eliminación PostHog por cuenta)	Incluido en el plan de pago pero aún controlable por una bandera por cuenta: wonda reddit signup (redditAccountCreationEnabled), wonda email (emailServerApiEnabled), enriquecimiento de perfil público de LinkedIn (linkedinProfileEnrichmentEnabled).

Si un comando devuelve un 403 (paid_plan_required), suscríbete en https://wonda.sh/account.

Esto se aplica también a la ruta MCP stdio local porque MCP ejecuta la misma CLI. Las cookies y los datos de la plataforma permanecen en el dispositivo, pero el comando debe recibir primero una decisión de acceso de pago exitosa de GET /api/v1/auth/access. Una instalación solo de relay puede usar su credencial wrelay_... con ámbito para esa sonda de derechos. La credencial con ámbito aún no puede llamar a las API de cuenta ordinarias.

Clonación de voz

Clona una voz a partir de un clip de audio de 10 segundos o más y úsala en TTS. Límite estricto: 20 voces clonadas por cuenta. Costo: $1.50 por clonación.

# Clonar desde un archivo local (se sube automáticamente a la biblioteca de medios primero)
wonda voice create "Andu" --file ./sample.mp3 --description "Mi voz"

# Clonar desde un medio wonda existente
wonda voice create "Marca" --media-id <uuid>

# Preprocesamiento opcional del audio fuente
wonda voice create "Limpia" --file ./raw.wav --noise-reduction --normalize-volume

# Listar voces clonadas (cada fila informa isExpired y expiresInDays)
wonda voice list

# Una voz
wonda voice get <voice-id>

# Renombrar / redescripciones (solo local, sin llamada al proveedor)
wonda voice update <voice-id> --name "Nuevo Nombre" --description "..."

# Eliminar
wonda voice delete <voice-id>

Usa una voz clonada en TTS pasando el providerVoiceId de voice get como voiceId a /audio/speech:

wonda audio speech "Hola mundo" \
  --model minimax-speech-2-8-hd \
  --params '{"voiceId":"<providerVoiceId>"}'

Caducidad de 7 días: las voces clonadas que no se hayan usado en TTS en 7 días caducan automáticamente. Ejecutar TTS con una voz clonada renueva automáticamente su caducidad. Las voces inactivas que caduquen deben volver a clonarse ($1.50 nuevamente).

Bóveda de credenciales

Persiste los inicios de sesión creados en plataformas externas (Instagram, TikTok, Twitter, etc.) para que puedan reutilizarse en la siguiente ejecución. Las contraseñas se cifran con AES-256-GCM con una clave del lado del servidor y solo se descifran en get.

# Crear
wonda credentials create --website instagram.com --username miusuario \
  --email [email protected] --password-stdin <<< "cazar2" \
  --metadata '{"signup_source":"wonda-email"}'

# Listar (contraseñas omitidas)
wonda credentials list --website instagram.com

# Obtener registro completo incluida la contraseña descifrada
wonda credentials get <id>

# Actualizar cualquier campo (usa --password-stdin para rotar; --username "" para limpiar)
wonda credentials update <id> --username nuevousuario

# Eliminar
wonda credentials delete <id>

# Obtener y registrar por qué lo estás usando en una sola llamada — POST, no GET, porque
# escribe un evento 'usado' con el motivo. Prefiere esto sobre `get` siempre que
# puedas articular el motivo.
wonda credentials use <id> --reason "flujo de registro en instagram"

# Ver eventos recientes (creado / usado / rotado / actualizado) para auditoría
wonda credentials events <id>

Campos: website (obligatorio — la entrada escrita como insta se canonaliza a instagram.com), username, email, password (obligatorio), metadata (JSON arbitrario). Al menos uno de username / email debe estar presente. Se permiten múltiples registros por (website, username) — desduplica por tu cuenta si es necesario.

Registro de eventos: cada credentials get/use, create, rotación de contraseña y otras actualizaciones se registran como eventos en la credencial (actor: cli | web | system). Usa credentials events <id> o el icono de historial de la interfaz web para auditar. El registro de eventos es de solo añadidura y se elimina en cascada al eliminar la credencial.

Banderas de salida globales

Todos los comandos admiten estas banderas de control de salida:

• --json — Forzar salida JSON (se habilita automáticamente cuando stdout se redirige)
• --quiet — Solo mostrar el identificador principal (ID de trabajo, ID de medio, etc.) — ideal para scripting
• -o <ruta> — Descargar la salida a un archivo (implica --wait)
• --fields status,outputs — Seleccionar campos JSON específicos
• --jq '.outputs[0].media.url' — Filtrar la salida JSON con una expresión jq

Anuncios de CLI y advertencias de obsolescencia

En cada comando, la CLI consulta GET /api/v1/updates (anónimo, caché de 1 hora en ~/.wonda/state.json) para obtener anuncios activos: avisos de obsolescencia, alertas de incidentes, indicaciones de actualización. Los mensajes se imprimen solo en stderr, por lo que stdout/JSON se mantiene limpio para la tubería.

Las sugerencias de obsolescencia por solicitud llegan como el encabezado HTTP estándar Warning: 299 - "<mensaje>" y se muestran en stderr por el cliente HTTP de la CLI como [deprecated METHOD /ruta] <mensaje>.

Silencia ambos canales con WONDA_QUIET=1 (variable de entorno) o --quiet (bandera). Deshabilita solo las comprobaciones de red con WONDA_NO_UPDATE_CHECK=1.

WAB / Navegador de Automatización Wonda (wonda wab)

El Navegador de Automatización Wonda (WAB) es un navegador antidetect de sigilo premium, endurecido para que las plataformas no puedan identificarlo como automatización. wonda wab es el comando único para la pila Chromium antidetect (un fork indetectado de Playwright). Tiene dos caras:

• Sesiones autenticadas. Un Chromium con interfaz gráfica persistente por persona que mantiene sesiones iniciadas para LinkedIn, X, Reddit y otros. La CLI lo inicia bajo demanda, lo deja en espera y enruta las lecturas/escrituras de la plataforma a través de él cada vez que un comando se ejecuta --via wab. Las cookies viven en el perfil de Chromium de la persona, no en ~/.wonda/config.json.
• Captura anónima. wonda wab record <url> (y wonda brand extract) manejan un Chromium efímero con una huella digital nueva, sin persona, sin cookies. Consulta el bloque record a continuación.

El modelo mental: tienes cuentas (una identidad por plataforma). Cada comando de plataforma se enruta a las cookies de esa cuenta a través del almacén JSON plano (--via cookies, rápido, sin Chromium) o la persona de la cuenta (--via wab, Chromium antidetect en vivo). Una persona es el sobre de Chromium que puede contener múltiples cuentas bajo una sola huella digital.