zehuichan/vibe-harness

Notas de Agente

As Notas de Agente mantêm o corpus de decisões pequeno e autoritativo: cada nota registra a fundamentação que o código e a documentação não podem carregar, e nada mais. As regras para layout, classes e o formato no arquivo residem em .agents/notes/README.md; este skill possui o workflow. Julgue cada nota semanticamente; contagem de palavras e idade são auxílios de descoberta, nunca critérios. Isto é orientação, não uma lista de verificação.

Decida se uma nota é necessária

Escreva ou atualize uma nota apenas para fundamentação de decisão duradoura: por que um design venceu, o que ele sacrificou, quais alternativas perderam e por quê, e qual verificação o ancora. Não escreva para edições mecânicas ou locais, incluindo alterações de apresentação de UI locais, ou para fatos que pertencem ao código, documentação de API, READMEs ou um livro de receitas.

• Uma proposta para trabalho futuro substancial vai para proposed/<class>/; uma decisão tomada na alteração atual vai para implemented/<class>/.
• Se uma nota ativa já possui a decisão, atualize-a em vez de criar uma duplicata.
• Uma reversão de uma decisão é uma nova nota que faz referência cruzada à antiga; nunca edite uma nota para transformá-la em uma decisão diferente.

Escreva a nota

1. Escolha a classe na tabela em .agents/notes/README.md e nomeie o arquivo yyyy-mm-dd-topic-title.md, usando a data em que o tópico foi proposto pela primeira vez.
2. Use o cabeçalho exato e o esqueleto de seção do ciclo de vida do README. ## Alternativas consideradas é obrigatório: registre cada alternativa genuína e por que ela perdeu; nunca invente alternativas.
3. Escreva notas implementadas no tempo presente como realidade entregue: sem planos, listas de verificação de aceitação ou "deveria". Mantenha a verificação que ancora o comportamento e quaisquer lacunas de cobertura nomeadas.
4. Vincule outras notas e documentos com links relativos em Markdown. Siga prose-standard e trim-cot-leakage: sem coreografia de revisão, citações de sessão ou narração de alterações fora das próprias seções de histórico de alterações da nota.

Verifique a substituição para cada nova nota

Antes de redigir, pesquise a árvore ativa (proposed/, implemented/, rejected/) em busca de notas que cobrem a mesma decisão, mecanismo ou alternativa rejeitada. Classifique cada correspondência ao escrever a nova nota:

• Substituição total de uma nota implementada: consolide (o novo proprietário preserva toda fundamentação única, alternativa, consequência, verificação e lacuna de cobertura, então a nota antiga é excluída e os links de entrada são reparados) ou arquive-a na mesma alteração.
• Substituição parcial: mantenha ambas ativas, faça referência cruzada e atualize todos os fatos que permanecem atuais.
• Proposta obsoleta: mova-a para rejected/ com uma razão honesta de uma linha.
• Rejeição obsoleta: exclua-a quando não impedir mais um erro plausível.

Não adie uma correspondência conhecida para uma auditoria posterior.

Classifique notas existentes por valor futuro

Ao auditar ou podar, aplique estes resultados por ciclo de vida:

• Implementada, excluir: notas que descrevem apenas pequenos ajustes de UI ou alterações puramente mecânicas. Repare ou remova links de entrada. Correções de bugs locais, alterações de desempenho, novas capacidades e decisões substantivas de comportamento ou propriedade não se qualificam meramente porque sua implementação foi pequena. Aplique este teste antes de manter ou arquivar.
• Implementada, manter ativa: fundamentação, alternativas, garantias negativas, semântica durável ou de fio, limites de propriedade, regras de segurança ou condições de reintrodução que provavelmente guiarão uma alteração futura. Classifique a decisão, não o tamanho de sua implementação: uma renomeação mecânica ainda pode registrar uma regra de nomenclatura ou compatibilidade duradoura.
• Implementada, arquivar: uma decisão histórica substantiva que está completa e é improvável de guiar trabalho futuro, mas cuja fundamentação ainda justifica preservação.
• Proposta, nunca arquivar: mantenha uma proposta viva ativa; se não valer mais a pena perseguir, rejeite-a com uma razão honesta.
• Rejeitada, manter apenas como salvaguarda: retenha uma rejeição apenas enquanto a proposta perdedora continuar sendo um erro tentador e significativo e a nota explicar por que perde; caso contrário, exclua-a.

Não arquive em direção a uma cota. Inspecione cada nota no escopo, classifique grupos análogos sob um princípio e registre decisões genuinamente limítrofes para o relatório.

Calibração: uma nota sobre o estilo de um controle de barra lateral recolhida é excluída por mais longa que seja; uma nota que estabelece que as sessões são baseadas em eventos, ou que nomeia o único proprietário de um diretório de armazenamento, permanece ativa por mais curta que seja; uma nota que registra por que dois pacotes não devem ser mesclados permanece como salvaguarda enquanto mesclá-los continuar tentador.

Arquive uma nota implementada

1. Mova a nota completa, com qualquer contraparte traduzida, de implemented/<class>/ para archived/<class>/.
2. Não faça edições no corpo. Insira apenas Arquivado: AAAA-MM-DD imediatamente abaixo de Status: implementada em cada arquivo de idioma, com a mesma data.
3. Pesquise na prosa ativa por links de entrada. Redirecione-os para a autoridade atual, redirecione-os para o caminho arquivado apenas quando o instantâneo histórico for intencionalmente citado, ou exclua-os. Nunca verifique ou repare links que saem da nota arquivada.

Após o arquivamento, nunca edite, mova, traduza, reformate ou exclua a nota. Notas arquivadas permanecem alvos de link válidos, mas não são autoridade para o comportamento atual.

Valide e relate

Execute o commands.docs-check e git diff --check do perfil, e confirme que cada link relativo alterado resolve. Relate notas criadas ou atualizadas, notas mantidas ativas, excluídas, arquivadas ou rejeitadas, e cada caso limítrofe com o resultado escolhido.