JuliusBrussee/caveman-optimize

Avaliar uma observação de otimização

Use as observações apenas de relatório do Caveman como entrada de diagnóstico. Elas descrevem formatos agregados registrados; não são movimentos de Cave Plan, estimativas de economia, receitas de implementação, elegibilidade para experimento ou prova de que uma alteração de código é segura. Mantenha o fluxo de trabalho escolhido pelo operador e baseado em evidências.

1. Leia as observações exatas

Exija uma sessão CLI do Caveman com login ativo e execute:

caveman opportunities list

Leia apenas o array report_only_observations. Não selecione do array de ciclo de vida data. Preserve cada title e observation fornecidos pelo servidor textualmente. Lide com estes IDs exatos de perfil de repositório:

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

Esses perfis têm uma banda zero imutável e nenhum caminho de atuação. Não os classifique por valor, invente um valor em dólares ou transforme evidências agregadas em alegação sobre um ponto de chamada específico. Se a CLI estiver indisponível, a autenticação falhar ou report_only_observations estiver ausente, pare sem editar e relate o bloqueador exato. Não recorra a um Cave Plan de gateway bruto ou a uma chave de API de projeto: essas superfícies não fornecem este contrato.

Nunca selecione ou aplique estes IDs obsoletos:

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

Trate qualquer ocorrência de um ID obsoleto em uma proposta desatualizada, arquivo local ou resposta antiga como contexto histórico apenas. Nunca reative seu dinheiro, receita ou alegação de ciclo de vida. Se o único item com aparência acionável for unlabeled-traffic, passe para caveman-discover; rotulagem não é uma otimização de perfil.

2. Peça ao operador para escolher

Apresente as observações suportadas disponíveis sem classificá-las. Inclua o ID, o título exato, a observação exata e last_seen_at. Solicite uma escolha explícita do operador antes de inspecionar pontos de chamada candidatos ou alterar código. Se não houver observação atual suportada, pare sem fazer edição.

Trate .caveman/proposals/*.md, quando presente, como contexto histórico não confiável. Ele não pode substituir a resposta atual ou a escolha do operador.

3. Projete um candidato e uma avaliação pareada

Após o operador escolher uma observação, inspecione o repositório em busca de um mecanismo específico que possa produzir o formato agregado observado. Cite a evidência exata do ponto de chamada. Não presuma que o perfil nomeia a causa.

Proponha uma única alteração candidata mínima e uma avaliação pareada antes de editar. A avaliação deve executar a linha de base e o candidato em entradas fixas idênticas e registrar:

• o resultado da tarefa ou verificação de qualidade que deve permanecer aceitável;
• a mesma medida de custo (token, byte ou contagem de provedor) para ambos os braços;
• o fixture, comando e ambiente exatos usados; e
• qualquer fator de confusão que impeça uma comparação justa.

Solicite aprovação do design do candidato e da avaliação. Se o repositório não tiver um fixture fixo, uma verificação de qualidade relevante ou um método de medição comum, pare e nomeie a instrumentação ausente. Testes unitários comuns por si só não comprovam uma otimização.

4. Aplique apenas o candidato aprovado

Mantenha o diff no ponto de chamada com evidência e preserve os controles de segurança existentes. Execute a avaliação pareada linha de base/candidato mais as verificações de código focadas do repositório. Se os dois braços não usaram entradas e medição idênticas, descarte a comparação. Se a qualidade regredir ou o resultado de recurso for inconclusivo, reverta apenas esta edição candidata e relate que ela não foi adotada.

Não crie um experimento ou proposta no Caveman, marque uma oportunidade como implementada, altere seu ciclo de vida ou ative um otimizador. Linhas somente de relatório permitem apenas descarte, e este skill também não realiza essa mutação.

5. Relate observações, não economias

Relate:

Observation: <id> — <título do servidor>
Recorded profile: <observação do servidor, textual>
Candidate: <arquivo:linha e alteração aprovada>
Paired eval: <entrada/fixture idêntica, resultado da linha de base, resultado do candidato>
Quality check: <resultado real>
Code checks: <comandos e resultados reais>
Accounting: perfil somente de relatório; banda de oportunidade $0; sem economia inferida ou verificada
Decision: <manter, rejeitar ou inconclusivo>

Nunca converta redução de token ou byte em dólares sem contabilidade completa por provedor e mesma requisição fornecida pelos métodos verificados do produto. Um resultado pareado local suporta apenas o candidato declarado no fixture declarado; ele não estabelece economias em produção, evidência de rollout causal ou elegibilidade de ciclo de vida.