Conceptos de la plataforma

Whet se organiza alrededor de dos superficies complementarias:

• Pipelines — el contrato recurrente: Source → Processing → Output, manejado por runs.
• Sessions — la superficie scratch-pad: snapshotteás inputs, attacheás variantes de generación, iterás, exportás.

Los dashboards observan ambas.

Entidades del lado pipelines

Entidad	Qué es
Pipeline	Contrato re-ejecutable: configuración de source + processing + output + tone. Persistente.
Source	De dónde sale el contenido. Tres capas: official API, managed scraping, manual paste. Ver Pipelines.
Run	Una ejecución del pipeline. FSM pending → running → succeeded / failed / cancelled.
Artifact	Lo que el run produce. Dos tipos concretos: Riff (single-source, prefijo rf_) y Brief (síntesis multi-source, hasta 50 source posts, prefijo bf_). Ambos comparten la FSM review → ready → published / discarded.
Riff	Artifact generado por POST /artifacts con kind=riff. Es el verbo del producto: "riffear" un pattern es generar un draft nuevo en tu voz sobre la misma estructura.
Brief	Artifact agregado generado por POST /artifacts con kind=brief desde un array de source_post_ids.
Decode	Análisis estructural de un único post (extrae hook, tone, format, triggers). Emite decode.ready.
Refinement	Acción que toma un artifact y produce un artifact hijo (variante). Acciones disponibles: shorter, change_tone, match_voice, more_punchy. Se preserva la genealogía (parent_id). Disparado por POST /artifacts/{parent_id}/refine.
Workspace	El singleton de configuración por organización. Una instancia de Whet = un workspace.
Operator	El humano (o agente) que opera el workbench. Ver Operadores.

Entidades del lado sessions

La superficie de sessions es independiente de los pipelines — podés correr una session contra cualquier combinación de items upstream sin que pertenezcan al mismo pipeline. Ver Sessions para el modelo completo.

Entidad	Qué es
Session canvas	Workspace de drafting scopeado a un par (organization, user). Contiene items seleccionados, variantes y exports. El lifecycle es independiente de los pipelines.
Session item	Snapshot inmutable de un item upstream (X post / webpage / RSS / custom) en el momento de la selección. Tiene su propia copia de title/snippet/metrics — los cambios upstream no se propagan.
Variant	Slot de generación: preset + prompt + style + (opcional) credencial LLM por variante. Tiene una historia append-only de rounds.
Round	Una única salida de generación para una variante. Append-only — seleccionar un round viejo no borra los nuevos.
User preset	Tupla (prompt, style, typeTag) nombrada y guardada por el usuario, scopeada a la org. Los presets built-in son slugs estables (x-thread, blog-with-images, linkedin-long, newsletter-section, tldr-brief).
Export	Evento registrado cuando un round se exporta (hoy solo markdown). Alimenta el KPI EXPORTS 7D.
Activity	Row de log escrito en cada acción que afecta a la session (clicks en UI + tool calls MCP). Alimenta el NowFeed de /console.

Entidades del lado dashboards

Entidad	Qué es
Dashboard	Colección nombrada de widgets, scopeada al workspace. El layout son posiciones estilo GridLayout.
Widget	Chart tipado (kpi, timeseries, donut, bar, topN, table) respaldado por un querySpec validado en escritura contra el catálogo de datasets.
Dataset	Catálogo read-only de métricas/dimensiones/filtros expuesto por el engine. La tool MCP dashboards_list_datasets lo devuelve.

Flujo end-to-end (pipelines)

1. Un operador crea un pipeline (UI / CLI / MCP) con una intención: "trackeá @growth_dr y armá drafts analíticos por cada post."
2. Whet schedule runs según el scope (per_post / daily_digest / weekly_digest).
3. Cada run ingiere desde la capa configurada, procesa con el LLM elegido y persiste uno o más artifacts.
4. El operador (o un agente vía MCP) revisa el inbox, posiblemente dispara refinements que producen variantes hijas, y eventualmente publica con confirmación humana.

Flujo end-to-end (sessions)

1. El operador abre un session canvas nuevo desde /console (o vía session_create).
2. Snapshottea items upstream en la session — se convierten en session items (inmutables).
3. Attachea variantes: cada una con un preset, un prompt, un style, opcionalmente un LLM por variante.
4. session_generate_variant (o session_generate_all) encola calls al LLM; cada call appendea un round a la variante.
5. El operador elige el mejor round (session_select_round) y session_export_variant para shippearlo como markdown.

Eventos webhook

Los nombres exactos de eventos que el backend emite:

Evento	Cuándo
scrape.completed	Un scrape de un operator (handle de X) finalizó.
tweet.ready	Se ingestó un tweet nuevo.
webpage.ready	Un tracked_webpage (URL pública) fue refetcheado con cambios.
decode.ready	El decode de un post produjo su análisis estructural. Trae post_id.
riff.ready	Un riff generado pasó a status=ready.
riff.refined	Un refinement de riff produjo un hijo. Trae parent_id.
brief.ready	Un brief multi-source pasó a status=ready.
brief.refined	Un refinement de brief produjo un hijo. Trae parent_id.
pattern.detected	El decoder identificó un pattern nuevo o reincidente.
operator.error	Un scrape o ingest de un operator falló con un error que requiere atención (ej. credenciales muertas).

Para el lifecycle del job en sí (de pending a succeeded/failed/cancelled) hay polling de GET /runs/{id}. Los webhooks son el canal para "se completó algo útil" — no para "este run cambió de estado".

Si estás construyendo un agente o un dashboard externo, suscribite a estos webhooks en lugar de hacer polling. Ver Webhooks.

Ver también

• Pipelines — el concepto central explicado con las tres capas.
• Sessions — el canvas de drafting.
• Operadores — el rol humano que opera el workbench.
• Patterns y riffs — cómo se preserva la voz durante la generación.
• Glosario — todos los términos en una tabla.