Revisión de evidencia de Caveman

Revisar evidencia de Caveman

Actúa como un operador de solo lectura. Construye conclusiones a partir de los datos actuales de Caveman, no de suposiciones del repositorio. Nunca inicies, apruebes, canceles o reviertas un experimento desde esta habilidad.

Reglas estrictas

1. Mantén estos buckets separados:
   • costo medido completo de lista del proveedor;
   • inferred capacidad diaria;
   • verified ahorros en el libro mayor;
   • costo de evidencia. Nunca los agregues o renombres.
2. No obtengas cargas útiles de prompts, completaciones, herramientas o artefactos a menos que el usuario solicite explícitamente la revisión de cargas útiles. Los metadatos, spans, tiempos, modelos, conteos de tokens, estado y atribución del optimizador son suficientes para la revisión predeterminada.
3. Limita cada lectura al proyecto seleccionado por el contexto de Caveman. Nunca proporciones un ID de organización.
4. Los resultados vacíos son evidencia de que no hay señal actual, no costo cero o riesgo cero.
5. Cita los IDs de traza y las ventanas de tiempo exactas utilizadas. No afirmes una causa basándote únicamente en un agregado.

Paso 1 — Cargar contexto

Prefiere MCP:

caveman_context {}

Fallback CLI:

caveman cloud whoami
caveman cloud projects list

Detente si falta el inicio de sesión o la selección del proyecto. Pide al usuario que ejecute caveman login o seleccione un proyecto; nunca adivines.

Paso 2 — Establecer línea base

Usa caveman_report para:

• overview
• costs
• score
• workflows
• verified_savings

Luego usa caveman_plan para la capacidad diaria clasificada. Si la pregunta es específica, omite los informes no relacionados. Lee el conjunto más corto que pueda responderla.

Fallback CLI:

caveman cloud costs
caveman cloud score
caveman cloud plan --json

Indica la ventana del informe y la base antes de interpretar la dirección.

Paso 3 — Probar la explicación principal con trazas

Usa caveman_trace_search. Elige una ventana acotada y filtros cerrados: flujo de trabajo, agente, modelo, proveedor, código de error, modo de ejecución, estado de caché, ID de optimización, clase de estado, límites de token/costo/latencia, compresión o veredicto del monitor.

Agrupaciones útiles:

• workflow — encuentra trabajos que generan costos o fallos;
• model — compara la mezcla de modelos;
• session — aísla comportamiento de reintentos o bucles;
• sin agrupar — identifica trazas exactas.

Compara un cohorte sospechoso con un cohorte de control o una ventana anterior acotada. No infieras causalidad a partir de una sola traza costosa.

Fallback CLI:

caveman cloud traces search \
  --workflow <slug> \
  --from <RFC3339> \
  --to <RFC3339> \
  --sort total_cost_usd \
  --dir desc \
  --limit 25

Paso 4 — Inspeccionar trazas representativas

Llama a caveman_trace_get para un pequeño número de IDs de traza con alta señal. Inspecciona los metadatos de la solicitud y los spans, latencia, estado, conteos de tokens, estado de caché, optimizadores aplicados y ruta del modelo. Mantén desactivada la recuperación de cargas útiles.

Fallback CLI:

caveman cloud traces show <trace-id> --spans

Paso 5 — Informar

Usa esta estructura:

## Revisión de evidencia de Caveman

Alcance: <proyecto> · <desde> hasta <hasta>
Costo medido: <valor y base>
Ahorros verificados: <valor del libro mayor, mantenido separado>
Capacidad inferida: <banda por día, mantenida separada>

Hallazgos:
1. <hallazgo> — <evidencia agregada> — trazas <ids>
2. <hallazgo> — <evidencia agregada> — trazas <ids>

No probado:
- <explicación plausible que carece de control, traza o evaluación>

Próxima verificación de solo lectura:
- <una consulta acotada>

Acción posible:
- <solo propuesta; usa caveman-manage para revisión de ciclo de vida de solo lectura y puerta de seguridad>

Si faltan datos, nombra la señal faltante y detente en la afirmación más sólida respaldada. Nunca conviertas un subtotal de catálogo en una factura ni un resultado de experimento en ahorros verificados.