JuliusBrussee/caveman-discover

Estás etiquetando los flujos de trabajo de LLM de este repositorio para Caveman Cloud. Un flujo de trabajo es un trabajo que realiza el código — "responder un ticket de soporte", "construir el digesto nocturno", "ejecutar la suite de evaluación" — no una tecnología. Cada solicitud de gateway puede llevar una etiqueta de flujo de trabajo; el tráfico no etiquetado termina todo en un cubo unlabeled-workflow. Tu trabajo: encontrar los flujos de trabajo, nombrarlos bien, conectar las etiquetas y verificar que nada se rompió.

Esto cambia código, por lo que pasa por la revisión normal del usuario: propón la tabla primero, aplica después de que el usuario esté de acuerdo. Volver a ejecutar en un repositorio ya etiquetado no debe cambiar nada (idempotente).

Este skill es invocado por el operador. Una observación del Cave Plan unlabeled-traffic es solo de revisión y no crea un archivo de asesoramiento, propuesta o PR de borrador. No infieras que la telemetría seleccionó un sitio de llamada o autorizó una edición. Realiza de forma independiente el inventario del repositorio, presenta la tabla de etiquetado y espera la aprobación del usuario antes de cambiar el código.

Paso 1 — Inventario de los flujos de trabajo

Recorre el repo desde sus puntos de entrada, no desde sus importaciones:

• Manejadores HTTP/RPC que llaman a un LLM (directamente o a través de capas)
• Trabajos programados: definiciones de cron, consumidores de cola, workers, GitHub Actions que invocan código LLM
• Comandos CLI y scripts (scripts/, bin/, scripts de package.json)
• Eval / arneses de prueba que consumen tokens reales
• Agentes o cadenas distintas dentro de un framework (cada grafo de LangGraph, cada crew, cada definición de agente es normalmente su propio flujo de trabajo)

Un flujo de trabajo = un trabajo que un humano nombraría. Diez sitios de llamada dentro del mismo manejador de solicitud son un flujo de trabajo; un ayudante llm.ts compartido usado por tres trabajos son tres flujos de trabajo (etiqueta en los llamantes, nunca en el ayudante compartido).

Paso 2 — Nómbralos

Gramática del slug (el gateway lo exige): minúsculas [a-z0-9_-], de 1 a 96 caracteres. Nombra el trabajo, no la tecnología:

• Bueno: support-reply, nightly-digest, pr-review, eval-suite, onboarding-email
• Malo: openai-calls (tecnología), main (no dice nada), SupportReply (inválido), johns-test-3 (no envejece)

Los nombres son casi para siempre — renombrar después divide el historial de gastos. Cuando el propósito de un trabajo no está claro a partir del código, deriva el slug del nombre del archivo y márcalo como review en la tabla en lugar de inventar un propósito.

Paso 3 — Propón, luego aplica

Presenta esta tabla y pide proceder:

| workflow | job | donde | cómo se etiqueta |
|---|---|---|---|
| support-reply | responde tickets entrantes | src/bot/reply.ts:41 | defaultHeaders en el cliente de respuesta |
| nightly-digest | trabajo resumen a las 02:00 | jobs/digest.ts:12 | header en el cliente del digesto |
| eval-suite (review) | scripts/eval.ts:8 — propósito inferido del nombre de archivo | scripts/eval.ts:8 | anulación de env en la invocación |

Luego conecta cada etiqueta con el mecanismo más ligero disponible en ese sitio de llamada:

• @caveman-ai/sdk / SDK caveman_cloud: opción workflow por traza, o defaultWorkflow en el cliente que construye un servicio de un solo trabajo.
• SDKs de proveedores sin procesar (OpenAI/Anthropic/LangChain/LiteLLM/Vercel): añade "x-cave-workflow": "<slug>" al mismo bloque defaultHeaders / default_headers / extra_headers que ya lleva x-cave-api-key. Cliente compartido usado por varios trabajos → pasa el header por llamada (cada SDK anterior acepta anulaciones de header por solicitud), o dale a cada trabajo su propio cliente delgado.
• Agentes de codificación envueltos (caveman wrap): bandera --workflow <slug> o env CAVE_WORKFLOW=<slug> en el sitio de invocación (línea de cron, paso de CI).
• HTTP sin procesar: añade el header x-cave-workflow a la solicitud.

Etiqueta a los llamantes, mantén el diff mínimo, respeta el estilo del repo. Si un sitio de llamada no está enrutado a través del gateway de Caveman, no lo etiquetes — menciónalo bajo "no conectado" en el informe (las etiquetas solo viajan en el tráfico del gateway; la conexión es trabajo del skill caveman-setup).

Paso 4 — Verifica

Ejecuta lo que el repo ya usa para ejercitar una ruta etiquetada (un test, un script de desarrollo, un curl). Luego confirma: la solicitud aún tiene éxito (el gateway rechaza una etiqueta inválida con 400 cave_invalid_request_header — corrige el slug si es necesario). El gasto etiquetado aparece en el panel en /activity?tab=workflows a medida que cada flujo de trabajo se ejecuta a continuación; los trabajos en un horario aparecen cuando el horario se dispara, y vale la pena decirlo en el informe en lugar de fingir que están en vivo.

Paso 5 — Informe

## Flujos de trabajo etiquetados

| workflow | job | donde |
|---|---|---|
| support-reply | responde tickets entrantes | src/bot/reply.ts:41 |
| nightly-digest | trabajo resumen a las 02:00 | jobs/digest.ts:12 |

Verificado: <la ruta etiquetada que realmente ejercitaste y lo que observaste>
Aterriza en: <DASHBOARD>/activity?tab=workflows — cada fila aparece a medida que ese flujo de trabajo
se ejecute a continuación. Cualquier cosa aún no etiquetada se muestra como `unlabeled-workflow`.
No conectado (sin enrutamiento al gateway, por lo tanto sin etiqueta): <lista o "ninguno">
Marcado como revisión: <slugs cuyo propósito se infirió de nombres de archivo, o "ninguno">

Si no encontraste ningún punto de entrada de LLM: dilo exactamente, y apunta al skill de configuración (<docs origin>/docs/agent-setup.md) en lugar de fabricar una tabla.