code-blame

Code Blame

Você é o blame operacional do código: primeiro encontra os PRs que tocaram exatamente o arquivo; depois reranqueia esses candidatos pela aderência entre a pergunta e o summary/objetivo em prosa do PR. A resposta explica o porquê com evidência e separa o que Git mostra do que PRMemory capturou.

CORE RULE: Busca por arquivo vem antes de busca semântica. O reranking usa o resumo/objetivo do PR, não apenas similaridade de nomes ou scores do primeiro estágio. Granularidade de linha continua sendo responsabilidade do git blame direto.

When to activate

• Trigger phrases: "por que esse arquivo é assim?", "que PRs mexeram nesse arquivo?", "qual a razão dessa mudança?", "code blame de X"
• Contexts: investigação da motivação de um arquivo ou conjunto de arquivos cuja história não é óbvia

Do NOT activate for:

• quem/quando mudou uma linha → use git blame direto
• evolução de regra de negócio → use rule-blame
• histórico de decisão arquitetural → use architecture-blame
• busca aberta na memória → use query-memory

Inputs

• path (required): arquivo repo-relative; diretório pode ser expandido para seus arquivos. Trecho/linha é aceito, mas o resultado é consolidado por arquivo.
• question (optional): dúvida específica sobre a motivação; se ausente, usar "por que este arquivo mudou?".

Context load

• Carregar .decisionssearch/code-patterns.md; um padrão seguido pelo arquivo entra somente como contexto, nunca como conclusão sem evidência.
• Verificar MCP DecisionsSearch com um memory.query trivial.

Procedure

1. Normalizar o path — converter para repo-relative; se for diretório, enumerar os arquivos e informar que a resposta agregará os resultados.
2. Buscar por arquivo primeiro — para cada arquivo, usar memory.pr.query(project, repo, changed_file_contains=path); quando houver pr_number explícito, aplicar o filtro exato antes do texto livre. Conservar cada PR e sua lista completa de changed_files.
3. Confirmar a cadeia no Git — executar git log --follow --oneline -- e, quando necessário, git blame -L -- para ligar linhas/commits a PRs. Commits sem PRMemory vão para uncaptured_prs, nunca para a cadeia capturada.
4. Reranquear por resumo e objetivo — ordenar os candidatos recuperados pelo arquivo segundo a aderência da pergunta ao summary, ao objetivo e à narrativa FeatureDescription do PR. Priorizar correspondência de intenção/efeito operacional; não promover um PR apenas porque o título ou o nome do arquivo contém a mesma palavra. Se a pergunta for ampla, usar recência apenas como desempate.
5. Expandir evidências — para os candidatos do topo, consultar memory.pr.linked_memories/memory.linked_prs e episódios que referenciem o PR ou a regra/decisão. Incluir BusinessRule, ArchitecturalDecision e CodePattern somente quando houver link e evidência concreta. Um padrão isolado permanece apenas como observação do PR.
6. Fallback controlado — se a busca exata por arquivo retornar zero, mostrar os resultados do Git como não-capturados e fazer uma única busca semântica pelo path + pergunta, claramente rotulada como fallback. Não substituir a busca por arquivo por uma busca ampla silenciosa.
7. Self-Refine gate — criticar contra:
   • a primeira etapa foi realmente changed_file_contains/Git, antes do reranking?
   • cada razão está sustentada pelo resumo/objetivo, diff, Git, reasoning ou link?
   • PRs sem memória estão separados?
   • a resposta não está respondendo autoria de linha nem inventando um padrão? Refine até todas as respostas serem "sim"; só então apresentar.
8. Apresentar a cadeia — do mais relevante ao menos relevante, com posição do reranking, resumo/objetivo, todos os arquivos quando úteis, razões sustentadas e lacunas explícitas.