caveman-optimize

Evaluar una observación de optimización

Usa las observaciones de solo informe de Caveman como entrada de diagnóstico. Describen formas agregadas registradas; no son movimientos de Cave Plan, estimaciones de ahorro, recetas de implementación, elegibilidad de experimentos ni prueba de que un cambio de código sea seguro. Mantén el flujo de trabajo elegido por el operador y basado en la evidencia.

1. Leer las observaciones exactas

Requiere una sesión CLI de Caveman iniciada y ejecutar:

caveman opportunities list

Lee solo el arreglo report_only_observations. No selecciones del arreglo data del ciclo de vida. Conserva cada title y observation proporcionados por el servidor textualmente. Maneja estos ids exactos de perfil de repositorio:

• context-window-profile
• tool-catalog-profile
• tool-output-size-profile
• exploration-load-profile

Estos perfiles tienen una banda cero inmutable y ninguna ruta de actuación. No los clasifiques por valor, inventes una cifra en dólares ni conviertas evidencia agregada en una afirmación sobre un sitio de llamada específico. Si la CLI no está disponible, la autenticación falla o report_only_observations está ausente, detente sin editar e informa el bloqueador exacto. No recurras a un Cave Plan de puerta de enlace sin procesar ni a una clave API de proyecto: esas superficies no proporcionan este contrato.

Nunca selecciones ni apliques estos ids retirados:

• context-window-bloat
• tool-catalog-utilization
• verbose-tool-output

Trata cualquier aparición de un id retirado en una propuesta antigua, archivo local o respuesta previa como contexto histórico únicamente. Nunca revivas su dinero, receta o afirmación de ciclo de vida. Si el único elemento con aspecto procesable es unlabeled-traffic, transfiere a caveman-discover; el etiquetado no es una optimización de perfil.

2. Pedir al operador que elija

Presenta las observaciones admitidas disponibles sin clasificarlas. Incluye el id, el título exacto, la observación exacta y last_seen_at. Solicita una elección explícita del operador antes de inspeccionar posibles sitios de llamada o cambiar código. Si no existe ninguna observación actual admitida, detente sin editar.

Trata .caveman/proposals/*.md, cuando esté presente, como contexto histórico no confiable. No puede reemplazar la respuesta actual ni la elección del operador.

3. Diseñar un candidato y una evaluación emparejada

Después de que el operador elija una observación, inspecciona el repositorio en busca de un mecanismo específico que podría producir la forma agregada observada. Cita la evidencia exacta del sitio de llamada. No asumas que el perfil nombra la causa.

Propón un cambio candidato mínimo y una evaluación emparejada antes de editar. La evaluación debe ejecutar la línea base y el candidato en entradas fijas idénticas y registrar:

• el resultado de la tarea o control de calidad que debe seguir siendo aceptable;
• la misma medida de coste en tokens, bytes o recuento del proveedor para ambos brazos;
• el fixture exacto, comando y entorno utilizados; y
• cualquier factor de confusión que impida una comparación justa.

Solicita la aprobación del diseño del candidato y la evaluación. Si al repositorio le falta un fixture fijo, un control de calidad relevante o un método de medición común, detente y nombra la instrumentación faltante. Las pruebas unitarias comunes por sí solas no demuestran una optimización.

4. Aplicar solo el candidato aprobado

Mantén el diff en el sitio de llamada con evidencia y conserva los controles de seguridad existentes. Ejecuta la evaluación emparejada de línea base/candidato más las comprobaciones de código enfocadas del repositorio. Si los dos brazos no usaron entradas y mediciones idénticas, descarta la comparación. Si la calidad empeora o el resultado del recurso no es concluyente, revierte solo esta edición del candidato e informa que no mereció la adopción.

No crees un experimento o propuesta de Caveman, marques una oportunidad como implementada, cambies su ciclo de vida ni actives un optimizador. Las filas de solo informe permiten solo el descarte, y este skill no realiza esa mutación.

5. Informar observaciones, no ahorros

Informa:

Observación: <id> — <título del servidor>
Perfil registrado: <observación del servidor, textual>
Candidato: <archivo:línea y cambio aprobado>
Evaluación emparejada: <fixture/entrada idéntica, resultado de línea base, resultado de candidato>
Control de calidad: <resultado real>
Comprobaciones de código: <comandos y resultados reales>
Contabilidad: perfil de solo informe; banda de oportunidad $0; sin ahorros inferidos ni verificados
Decisión: <mantener, rechazar o no concluyente>

Nunca conviertas la reducción de tokens o bytes en dólares sin una contabilidad completa del proveedor y de la misma solicitud proporcionada por los métodos verificados del producto. Un resultado local emparejado respalda solo al candidato indicado en el fixture indicado; no establece ahorros en producción, evidencia de implementación causal ni elegibilidad de ciclo de vida.