Operadores

Un operador es el humano (o agente actuando bajo permisos del humano) que opera el workbench de Whet. Cada workspace tiene uno o más operadores con roles definidos por better-auth.

¿Qué hace un operador?

Acción	Dónde
Crear pipelines	UI / CLI / MCP
Pausar / archivar pipelines	UI
Revisar inbox de artifacts	UI / CLI / MCP
Disparar refinement loops	UI / MCP (prompt refine_post)
Publicar con confirmación	UI / CLI / MCP
Conectar/rotar cookies de X	UI (Settings → X accounts) o MCP (connect_x_account)
Conectar BYOK de LLM providers	API REST (/api/v1/whet/llm_credentials)
Rotar API key + signing secret	API REST (POST /api_keys/{id}/rotate_secret, 24h overlap)
Rotar webhook signing secret	API REST (POST /webhook_endpoints/{id}/rotate_secret, 24h overlap)

nota

La UI de Settings hoy sólo expone X accounts. La rotación de API keys, webhook secrets y la gestión de BYOK de LLMs se hace por API (con scope admin:write). Una UI unificada de credenciales está en roadmap.

El sistema de scopes hoy es básico: la API key trae scopes con valor admin:write para acciones administrativas (gestión de api_keys). Scopes granulares finos (pipelines:write, artifacts:publish, etc.) están en roadmap. Para limitar acciones de un agente, controlá qué token le pasás y mantené el de publicación cerca de un humano que confirme.

Refinement workflow

El operador no tiene que aceptar el primer draft. Para cada artifact en estado ready, puede disparar uno o más refinements que producen variantes hijas. Las acciones disponibles:

• shorter — recorta manteniendo intención.
• change_tone — pasa de un tono a otro (analítico ↔ punchy, neutral ↔ snarky).
• match_voice — ajusta al style_reference que el operador pase con la acción (el perfil de voz persistente está en roadmap; ver Patterns y Riffs · Modelo de voz).
• more_punchy — agrega fricción / edge.

Cada refinement crea un artifact hijo que preserva parent_id, así que la genealogía completa queda navegable. Podés tener un árbol de variantes de profundidad N.

Publicación

Whet nunca publica en background. Cada publicación (vía UI, CLI o MCP) requiere una intención explícita del operador o de un agente con permisos delegados. El flow es:

1. Operador (o agente) elige un artifact ready.
2. Confirma el texto final (opcional override).
3. Whet marca el artifact como published y, si el pipeline tiene auto_fanout, dispara el envío a las superficies conectadas.

Esta política es por diseño, no es un toggle. Existe para defender la posición legal (operador = responsable de su publicación) y para evitar errores destructivos de agentes.

Agentes actuando como operadores

Vía MCP, un agente puede ejercer cualquier permiso que el agent token le otorgue. Hoy el alcance es todo o nada a nivel workspace (excepto admin:write para gestión de api_keys, que sí está separado). Si te importa limitar a un agente a "leer pero no publicar", la forma robusta es operacional: no le pases el token de publicación.

Recomendación: para agentes de producción, usá tokens en modo test (pk_test_…) — los endpoints "live-only" rechazan estos tokens con test_key_required 403, así reducís blast radius mientras desarrollás. La separación fina por acción (pipelines:read, artifacts:publish, etc.) está en roadmap.

Roles dentro del workspace

Rol	Permisos
Owner	Todo. Único que puede invitar miembros y rotar el master key.
Operator	Operar pipelines y refinements; no puede tocar billing ni conexiones.
Viewer	Read-only en pipelines y artifacts.

Los roles se gestionan desde Settings → Members (better-auth organization plugin).