OrenSegal/audit

Execute uma auditoria adversarial deste código-fonte e conclua-a. Relate e entregue primeiro; altere o código-fonte apenas com --fix ou quando o usuário escolher as correções.

Você é o adversário. Cada lente faz uma pergunta de um ângulo diferente: qual entrada, momento, usuário ou atacante faz este código dar uma resposta errada, perder dados, vazar dados ou prejudicar o usuário?

Esta pasta contém tudo que a auditoria precisa. Resolva estes caminhos a partir do diretório deste arquivo:

• lentes/<lente>.md: uma por lente. Sua linha Dispara: diz quando a lente é executada (sempre ou quando <condição>). Cada sonda é incondicional (sempre respondida) ou marcada (quando <condição>) (respondida quando a condição é válida, caso contrário encerrada como não aplicável). Em seguida, o artefato que a lente produz e sua linha de conclusão.
• scripts/scan.py: identifica o repositório, roteia lentes e lista os próprios analisadores do projeto a serem executados. scripts/sinais.tsv: cada detecção e padrão de semente; scripts/ferramentas.tsv: cada analisador que conhece. Um projeto adiciona suas próprias linhas em docs/agents/audit-sinais.tsv.
• scripts/verify.py: verifica arquivos de descobertas contra os arquivos de lente. scripts/cochange.sh: arquivos que mudam juntos.
• ENTREGAR.md: notas de passagem, o mapa da auditoria e seus tickets.
• DESEMBARCAR.md: a refatoração estrutural, para --untangle e para tickets estruturais.

1. Escopo

• Argumentos: um caminho (padrão: raiz do repositório); --lente a,b para executar apenas essas; --desde REF para auditar o que mudou desde uma referência (uma base de PR, ou o commit da última auditoria); --fix; --untangle [area|ticket] para pular direto para DESEMBARCAR.md; --saida DIR (padrão .audit/).
• Quando nenhuma resposta pode chegar (CI, claude -p), perguntas não respondidas permanecem em HANDOFF.md como perguntas em aberto, a entrega vai apenas para o rastreador local, e o código-fonte permanece intocado a menos que um ticket esteja na linha approved:.
• Crie o diretório de saída com um .gitignore contendo *, para que a auditoria não toque em nenhum arquivo rastreado. Ao iniciar uma nova execução (nunca ao retomar), primeiro mova os arquivos RUN.md, REPORT.md e descobertas/ de uma execução anterior para <saida>/history/<sua data>/, para que a nova execução possa comparar com ela.
• Retomar: se <saida>/HANDOFF.md existir, continue a partir de sua próxima fase, deixando os arquivos da execução onde estão. Tickets em sua linha approved: estão liberados para alterações no código-fonte sem perguntar novamente; trabalhe o primeiro da fronteira, um ticket por sessão, conforme ENTREGAR.md diz. Qualquer outro ticket volta para o usuário primeiro. Se uma execução anterior existir em history/, ofereça --desde <seu commit> e carregue refutado.md adiante.

Cada fase abaixo termina reescrevendo <saida>/HANDOFF.md conforme ENTREGAR.md descreve.

2. Escaneamento e reconhecimento

Execute python3 scripts/scan.py <caminho> [--desde REF] [--lente a,b] > <saida>/SCAN.md, para que SCAN.md seja a saída bruta do script: stacks, pacotes, quais lentes disparam e por quê, pontos críticos, o plano de execução, os analisadores a serem executados, locais candidatos por sonda (arquivos mais quentes primeiro) e contagens de casos especiais.

Execute cada analisador listado em Ferramentas cujo comando esteja disponível, salvando sua saída em <saida>/ferramentas/<ferramenta>.txt. Seus avisos são pistas para a lente que cada linha nomeia, da mesma forma que locais de escaneamento; uma ferramenta que está faltando ou falha é anotada em RECON.md, nunca instalada.

Em seguida, escreva <saida>/RECON.md, completando o que um script não pode ver. Termine apenas quando cada cabeçalho tiver uma resposta ou nenhum:

• Limites: todo lugar onde dados de fora entram (HTTP, webhooks, leituras de BD, arquivos, env, links profundos, payloads de push, saída de modelo, entrada do usuário).
• Persistência: armazenamentos locais, BD do servidor, caches, filas e qual deles é dono de cada fato.
• Caminhos críticos: dinheiro, autenticação, exclusão de dados, migrações, qualquer coisa relacionada à segurança, o loop principal do usuário.
• Comandos: construir, testar, lintar, executar; se os testes passam agora.
• Regras da casa: CLAUDE.md/AGENTS.md; a linguagem do domínio em GLOSSARIO.md (ou GLOSSARIO-MAPA.md), usado para cada nome em descobertas e correções; ADRs, cujos riscos aceitos permanecem resolvidos a menos que o risco tenha mudado; o rastreador de issues em docs/agents/.
• Condições: para cada lente que dispara, quais sondas condicionais são válidas aqui, com evidência.
• Substituições de lente: uma lente que o escaneamento pulou e que o reconhecimento mostra ser necessária, ou uma que disparou por um sinal falso, com o motivo.

Escreva <saida>/RUN.md: commit, data, argumentos, lista final de lentes.

3. Caçar

Siga o plano do escaneamento: sequencial executa cada lente aqui, uma após a outra; paralelo dá a cada lente um subagente, e uma lente fragmentada um subagente por pacote listado. Um host que limita a concorrência executa ondas, emparelhando as lentes com menos locais; um host sem subagentes executa tudo em sequência.

Subagentes começam sem habilidades e sem esta conversa, então cada resumo é independente. Ele nomeia: o arquivo de lente, este arquivo (para Métodos e Formato de descoberta), RECON.md, a seção da lente em SCAN.md, o escopo e o caminho de saída <saida>/descobertas/<lente>[-<pacote>].md. Caçadores são folhas somente leitura: eles leem código, executam testes, scripts e o aplicativo, escrevem apenas seu arquivo de descobertas e reproduções, e retornam ao contexto principal, que sozinho despacha.

Métodos

• Pré-mortem: três meses após o lançamento, a avaliação de 1 estrela principal é sobre esta área. Escreva-a, depois encontre o código que a causou.
• Inversão: como você faria este recurso falhar tão mal quanto possível? Verifique os blocos de código em cada direção.
• Livro de suposições: para cada função em um caminho crítico, liste o que ela assume. Qual um tipo ou restrição impõe, e quais dependem de esperança?
• Cerca de Chesterton: antes de chamar uma guarda, caso especial ou linha estranha de bug, descubra por que ela existe (git log -L, blame, o PR). Uma cerca com um motivo vivo não é uma descoberta.
• Candidatos são pistas: um local de escaneamento é um lugar para começar a ler. Uma sonda com zero locais ainda é respondida, e um local se torna uma descoberta apenas com um cenário concreto.

Formato de descoberta

### <LENTE>-<n> <a alegação em menos de 60 caracteres>
- onde: caminho:linha
- sonda: <id da sonda do arquivo de lente>
- cenário: <entrada, estado ou momento concreto> → <resultado errado que um usuário ou sistema vê>
- gravidade: critico | alto | medio | baixo
- detectabilidade: barulhento (crash, alerta, teste falha) | silencioso (resposta errada que alguém pode notar) | imperceptivel (ninguém vai notar)
- veredito: CONFIRMADO (<o teste, script, consulta ou captura de tela que reproduziu>) | PLAUSIVEL (justificado, não executado)
- família de correção: <o tipo de mudança, não o patch>

Gravidade: crítico perde ou corrompe dados, viola segurança ou privacidade, erra valores monetários ou arrisca segurança; alto mostra uma resposta errada ou prejudica o usuário em um caminho comum; médio faz o mesmo em um caminho raro ou degrada a qualidade; baixo é higiene. A gravidade é definida por quem pode acioná-la hoje na configuração entregue: um cenário crítico ou alto nomeia essa pessoa (qualquer visitante, qualquer usuário autenticado, um atacante com X); um caminho que apenas um operador ou uma configuração morta alcança reduz um nível.

Redação: descobertas, reproduções, relatórios e tickets são compartilhados. Escreva <REDACTED> no lugar de qualquer segredo, token ou dado pessoal, e aponte para onde ele vive em vez de citá-lo.

Um arquivo de descobertas abre com o artefato da lente. Cada sonda termina em pelo menos uma descoberta ou uma linha limpo:: limpo: <sonda> — <evidência>, ou para uma sonda condicional cuja condição não se aplica, limpo: <sonda> — n/a: <motivo>. Um caçador está pronto quando sua linha de conclusão é válida e python3 scripts/verify.py <saida> --raiz <caminho> --lente <lente> passa.

4. Verificar

1. Mesclar duplicatas entre lentes: quando duas descobertas compartilham localização e mecanismo, mantenha o bloco mais grave, adicione - também: <os outros ids> a ele e exclua o outro bloco, para que cada problema apareça uma vez.
2. Refutar: toda descoberta crítica ou alta recebe um refutador novo; o restante é agrupado por lente. Um refutador recebe apenas o bloco da descoberta, nunca o raciocínio do caçador. Para uma descoberta PLAUSIVEL, ele tenta matar a alegação: uma guarda upstream, uma restrição no BD, um caminho inalcançável, uma cerca com um motivo. Para uma descoberta CONFIRMADO, ele verifica a reprodução: ela fica vermelha pelo motivo declarado, através de código que um usuário ou atacante real alcança? Quando o anfitrião oferece um modelo diferente, os refutadores o usam, já que vieses compartilhados tornam a concordância entre o mesmo modelo uma evidência fraca.
3. Promover por evidência: sobreviveu e reproduziu → CONFIRMADO; sobreviveu no raciocínio → PLAUSIVEL; morto → <saida>/refutado.md com o motivo.
4. Crítico de cobertura: um subagente novo recebe os caminhos críticos de RECON.md e as linhas limpo: de cada lente, e nomeia cada caminho crítico cuja evidência é fraca (uma frase onde um rastreamento ou teste era necessário) ou que nenhuma lente alcançou. Cada um volta para a lente correspondente para uma segunda olhada antes do relatório.

Uma reprodução é um loop de feedback apertado que fica vermelho nesta descoberta e em nenhuma outra: um teste com falha na costura mais próxima, um script, uma consulta. Construa um onde custar menos de dez minutos, em <saida>/repro/, apenas contra sistemas locais, branch, sandbox ou modo de teste. Uma descoberta morta por um motivo que valerá no próximo trimestre (um risco aceito, uma troca deliberada) pertence a um ADR, oferecido na entrega, para que auditorias posteriores o leiam no reconhecimento.

5. Relatar

Escreva <saida>/REPORTA.md:

1. Resumo: contagens por gravidade e lente, e as três correções a fazer primeiro, com o por quê.
2. Correções: agrupe descobertas por causa raiz, cada correção escrita acima das descobertas que resolve; procure a única correção por trás de várias descobertas, que muitas vezes não se parece com elas. Marque cada como estrutural (acoplamento, duplicação, um tipo faltando, um módulo raso, uma costura mal colocada) ou local (um lugar, uma mudança), e descreva correções estruturais no vocabulário de módulo profundo: módulo, interface, profundidade, costura, adaptador, alavancagem, localidade, o teste de exclusão.
3. Descobertas não agrupadas, classificadas por gravidade, depois detectabilidade (imperceptível primeiro), depois alcance.
4. Cobertura: as linhas limpo: de cada lente, lentes puladas com seus motivos, analisadores executados ou faltando, e o que o crítico de cobertura enviou de volta.
5. Desde a última auditoria, quando history/ contém uma execução anterior: corrigido, ainda aberto, novo e regredido (corrigido antes, de volta agora).

- Torne o servidor o único escritor de `scan_count`, decrementado atomicamente com `where scan_count > 0`, para que o cliente não possa derivar, gastar duas vezes ou redefini-lo. [estrutural, critico]
  - DINHEIRO-2 `ScanQuota.swift:40` decrementa localmente antes do upload, e novamente na repetição.
  - DINHEIRO-3 reinstalar o aplicativo redefine `scansUsed` no armazenamento local para 0.
  - ESTADO-5 a cota semanal é redefinida na segunda-feira local do dispositivo, então voar para oeste concede uma segunda semana.

Execute python3 scripts/verify.py <saida> --raiz <caminho>; o relatório é final quando passa. Quando o anfitrião renderiza descobertas estruturadas (uma ferramenta ReportFindings), também relate cada descoberta sobrevivente lá, mais grave primeiro.

Ajuste o funil para este projeto: uma linha de semente cujos locais terminaram todos refutados ou limpos, ou uma descoberta que nenhuma semente apontou, é uma linha proposta para o docs/agents/audit-sinais.tsv do projeto. Liste as propostas no relatório; elas são escritas apenas quando o usuário as aceita.

6. Entregar e passar

Leia ENTREGAR.md. Mapeie o relatório como um mapa de auditoria com um ticket por correção, tipado, com arestas de bloqueio, no rastreador de issues do repositório (local .scratch/ quando nenhum estiver configurado; confirme antes de postar em um rastreador remoto). Em seguida, pergunte quais correções iniciar como uma rodada de grill: numere cada uma como uma pergunta com sua resposta recomendada, redigida para que "sim" a aceite. Com --fix, aceite toda recomendação. Registre os números de ticket aprovados na linha approved: do HANDOFF.md.

Roteie cada ticket por sua forma. As habilidades nomeadas são mattpocock-skills; chame uma com a ferramenta Skill quando disponível, e caso contrário execute seu passo inline:

Forma do ticket	Rota
Precisa de uma decisão primeiro: onde vai uma costura, um ADR que contradiz, um termo de domínio difuso, um risco a aceitar	grill-com-docs, que registra a resposta como um ADR e termos do glossário
Estrutural, um módulo, vale explorar com o usuário antes de confirmar	melhorar-arquitetura-codigo nessa área
Estrutural, designs de interface concorrentes	design-codigo, seu padrão de projetar-duas-vezes
Estrutural, o caminho está claro e cabe em uma sessão	DESEMBARCAR.md, com o ticket e REPORTA.md como sua lista inicial
Estrutural, maior que uma sessão	orientador, mapeando tickets de decisão até o destino
Muitas correções para fatiar para agentes trabalhando sem supervisão	para-tickets (fatias de bala-traçante, arestas de bloqueio, refatorações amplas como expandir-contrato), depois implementar
Correção local	tdd: a reprodução é o primeiro teste vermelho, em uma costura acordada com o usuário; a suíte completa permanece verde
PLAUSIVEL e crítico, sem reprodução ainda	diagnosticando-bugs fase 1: construa o loop apertado primeiro

Quando a fronteira estiver vazia, reaudite com --desde <o commit da auditoria>. O destino da auditoria é uma reauditoria que verifica sem nenhuma descoberta crítica ou alta sobrevivente.

Concluído quando

• Cada lente que dispara tem um arquivo de descobertas que atende à sua linha de conclusão, e verify.py passa em toda a saída.
• Cada descoberta sobrevivente tem localização, sonda, cenário, gravidade, detectabilidade e veredito; cada uma morta está em refutado.md.
• REPORTA.md coloca cada descoberta sob uma correção ou na lista não agrupada, o mapa contém um ticket por correção, e HANDOFF.md nomeia o próximo ticket.