OwenBell0930/stop-chatter

Stop Chatter

Mantenha apenas o que o usuário solicitou no momento. Uma correção deve alterar o alvo de trabalho, não se tornar novo conteúdo sobre o erro anterior.

Escolha o modo mais leve

• Modo leve (padrão): Use para correções comuns e complementos posteriores. Mantenha o alvo no contexto de trabalho e siga as regras abaixo. Não crie estado transitório ou outros artefatos de fluxo de trabalho. Ler este skill ou reafirmar o plano no chat não é entrega; altere os arquivos.
• Modo protegido: Use apenas quando o usuário solicitar explicitamente, ou quando o mesmo item retratado já tiver retornado e o escopo da verificação puder ser limitado a esse resíduo. Leia references/protocol.md antes de alterar as entregas, inicialize uma vez e execute o verificador antes da entrega.

Não mude para Protegido apenas porque a tarefa é longa, envolve Git ou abrange vários arquivos. Após esta correção terminar, a continuação comum retorna ao Leve. Uma transferência explícita inacabada pode reutilizar o mesmo estado da tarefa; não escreva a lista de itens retirados na memória durável.

Não mencione Stop Chatter, um modo de conformidade ou o histórico de correções na entrega. Mantenha o resumo de conclusão da conversa útil: relate mudanças materiais, verificações e limites conhecidos quando o usuário precisar deles para alinhar o que aconteceu.

Recompile o alvo atual

Após cada correção:

1. Reescreva o objetivo como o resultado positivo atual.
2. Mantenha apenas os requisitos ainda ativos. Um item retratado é excluído, não mantido como requisito negativo.
3. Separe meta-restrições como conciso, eficiente ou não superdimensionar. Elas moldam a execução e não devem se tornar títulos, rótulos, cópia de interface, nomes de versão ou preferências duráveis.
4. Mantenha exclusões explícitas apenas quando a ausência for por si só um contrato externo ativo, propriedade de segurança ou critério de aceitação.

Coloque esse alvo reescrito nos arquivos antes de remover resíduos. Esta rodada não mencionou algo ≠ retratá-lo. Retratar um item não autoriza descartar recursos ainda ativos ou limpar o resto do projeto. Não use a conversa bruta como especificação contínua após este passo.

O que pode ser removido

Apenas conteúdo explicitamente retratado e derivados que evidências visíveis mostram que existem exclusivamente para servi-lo entram no conjunto de limpeza. Arquivos existentes e as edições anteriores do usuário permanecem por padrão. Recursos ainda válidos, propriedades de segurança e contratos de compatibilidade permanecem. Se a origem de um arquivo não estiver clara, mantenha-o.

Após o artefato primário corresponder ao alvo atual, verifique uma vez por derivados que existem exclusivamente para servir o item retirado: changelog comemorativo ou notas de versão para esta correção, testes cujo único trabalho é provar que o item retratado está ausente, registros da opção rejeitada e arquivos nomeados após o recurso retirado. Essa passagem não é uma limpeza de todo o projeto.

Pergunte apenas quando a ambiguidade bloquear a entrega. Não adicione uma etapa de confirmação para cada arquivo.

Não adicione um teste meramente para comemorar uma correção ou para provar que um item não solicitado está ausente. Mantenha um teste negativo apenas quando um requisito ativo tornar essa ausência observável externamente ou crítica para a segurança. Os próprios testes de contrato de operação de arquivo do verificador podem permanecer.

Registre as operações de arquivo desta rodada

Cada arquivo adicionado ou modificado nesta rodada deve mapear para pelo menos um requisito ativo. Mapear um caminho como permitido para alteração não autoriza a exclusão do arquivo inteiro. Exclua um arquivo inteiro apenas quando evidências visíveis da tarefa suportarem essa remoção.

Comentários explicam propriedades não óbvias do código que ainda existe. Texto de PR e versão descrevem o estado positivo resultante. A interface contém conteúdo de produto voltado ao usuário, nunca requisitos internos ou histórico de correções. Não adicione números de versão, alegações de versão imutável, hashes ou cerimônia extra, a menos que o usuário ou o processo de versão os exija.

Mantenha a memória limpa

Trate correções como locais por padrão. Persista uma apenas quando o usuário solicitar explicitamente memória durável ou declarar claramente uma preferência estável entre tarefas. Armazene o comportamento abstrato positivo e o escopo, não o exemplo rejeitado. Após as edições, examine os arquivos restantes — incluindo memória — em busca do item retirado e seus aliases em outros idiomas ou nomes próximos; remova esses vestígios apenas.

Verificação protegida

No modo Protegido, inicialize antes de alterar as entregas. Se já existir um estado de tarefa válido para esta raiz, reutilize-o; não o sobrescreva nem redefina a linha de base inicial. Se o estado for inválido ou pertencer a uma raiz diferente, pare em vez de reutilizá-lo ou substituí-lo.

python3 <skill-dir>/scripts/stop_chatter.py init --root .

Substitua os valores do modelo pelo alvo atual, os caminhos de adição/modificação mais restritos, os caminhos exatos must_remove suportados por evidências visíveis, rótulos e aliases retirados e marcadores de vazamento de meta-instrução. Não edite a linha de base capturada pelo init. Defina ready como true apenas após esses valores estarem atualizados. Em seguida, verifique uma vez:

python3 <skill-dir>/scripts/stop_chatter.py check --root . --cleanup-state-on-pass

Em caso de sucesso, este mesmo comando remove apenas .stop-chatter/state.json. Não execute uma segunda verificação bem-sucedida ou um comando de limpeza separado. Não exclua caches do interpretador, caches de teste ou outros arquivos do usuário para "limpar estado". Em caso de falha, o estado é preservado; corrija apenas problemas de escopo ou resíduo evidenciados e execute novamente no máximo uma vez.

O verificador apenas relata. Ele não exclui ou restaura entregas e não decide a propriedade do produto. Uma aprovação significa que as verificações configuradas passaram, não que a implementação está correta ou que nada resta.

Se uma transferência ativa ainda precisar do estado, omita --cleanup-state-on-pass e remova o arquivo quando essa transferência terminar. Nunca promova o livro-razão transitório de itens retirados para a memória.

Para caminhos de instalação e invocação específica do host, leia references/host-setup.md apenas ao instalar ou diagnosticar a descoberta.

Entregue o resultado

Pare apenas quando os arquivos corresponderem ao alvo atual. Retorne o artefato solicitado mais informações de conclusão suficientes para o usuário entender mudanças materiais, validação e limites conhecidos. Não suprimir status útil apenas para fazer a resposta parecer limpa. Mantenha o artefato em linguagem de estado atual: não o chame de versão corrigida, limpa, concisa, sem-X ou de estado final. Na resposta, mencione o histórico removido quando o usuário solicitar uma trilha de auditoria ou quando a remoção for materialmente relevante para escopo, migração, segurança ou compatibilidade.