zjp1997720/codex-doctor

Codex Doctor

Execute uma verificação de saúde em duas camadas:

1. Reutilize o comando integrado estável do Codex codex doctor --json para verificações de instalação, configuração, autenticação, runtime, ambiente Git, terminal, app-server, atualizações e inventário de threads.
2. Execute o scanner somente leitura incluso para governança do contexto do workspace que o comando integrado não cobre.

O scanner coleta evidências determinísticas. Você faz o julgamento semântico. Essa separação é importante porque um script pode provar que um texto se repete, mas não pode decidir com segurança que um fato de negócio, limite de segurança, voz da marca ou regra de diretório é descartável.

Executar a verificação

Resolva o diretório da Skill a partir do caminho carregado e execute:

python3 <skill-dir>/scripts/scan_workspace.py --cwd "$PWD" --compact-json

Para uma passagem mais rápida apenas no workspace quando o relatório integrado já foi executado na mesma tarefa:

python3 <skill-dir>/scripts/scan_workspace.py --cwd "$PWD" --compact-json --skip-built-in

--compact-json preserva todos os achados e todas as linhas de verificação integrada, omitindo inventários grandes de Skills e detalhes verbosos de verificações aprovadas. Use --json apenas quando for necessário obter evidências completas do inventário determinístico.

Não salve o relatório bruto integrado dentro do repositório. Se for necessário armazenamento temporário, use /tmp e remova-o antes de finalizar.

Interpretar achados

Leia checks-and-repair-policy.md antes de propor qualquer limpeza ou reparo. Mantenha severidade e confiança separadas:

• S0: exposição comprovada de segredos ou risco destrutivo comprovado
• S1: configuração efetiva quebrada, regras rígidas truncadas, executáveis habilitados ausentes ou incompatibilidade de instalação/atualização
• S2: redundância exata, nomes/fontes ativos duplicados ou violação clara de higiene do projeto
• S3: pressão de manutenção, entradas desabilitadas desatualizadas, aviso de nova versão ou descrições muito longas
• S4: informacional, candidato semântico ou lacuna de evidência

Trate semantic_candidates como prompts para inspeção, não como achados. Leia a seção de origem relevante e classifique como um dos seguintes:

• regra de comportamento ou limite de segurança: preservar
• preferência do usuário, voz da marca, fato de negócio ou contrato de diretório: preservar
• fato do repositório que requer síntese de múltiplos arquivos: geralmente preservar
• inventário diretamente descoberto, versão de framework, lista de dependências ou listagem de diretório: candidato a podar
• declaração desatualizada ou contraditória: verificar no repositório antes de propor uma alteração

Evidências de Skills não utilizadas

A descoberta estática não pode provar que uma Skill não é usada. Se o usuário solicitar explicitamente Skills não utilizadas ou de baixa frequência, use a Skill instalada codex-skill-admin no modo de auditoria somente leitura:

python3 <codex-skill-admin-dir>/scripts/codex_skill_admin.py audit-unused --cwd "$PWD" --days 30

Relate a janela de evidências e a contagem distinta de sessões/origens. Não desabilite nada a menos que o usuário solicite e aprove separadamente a lista alvo.

Estrutura do relatório

Comece com o resultado geral e mostre apenas itens acionáveis ou relevantes para decisão:

# Codex 健康检查

Status: PASS / WARN / FAIL

## Necessita ação
- [id do achado] severidade / confiança — conclusão
  Evidência: origem e estado observado
  Impacto: falha concreta ou custo de contexto
  Recomendação: próxima ação exata

## Sugerido para revisão manual
- candidatos semânticos com motivo pelo qual podem ser inferíveis ou desatualizados

## Aprovados
- domínios agrupados, não cada linha de baixo nível

## Lacunas de evidência
- verificações que não podem ser comprovadas com dados públicos/locais

Preserve as sub-verificações do doctor integrado como fatos separados. Por exemplo, uma falha de alcançabilidade HTTP e um sucesso WebSocket devem permanecer como duas linhas; não os colapse em "a rede está quebrada".

Protocolo de reparo

Diagnóstico não autoriza reparo. Quando o usuário solicitar correção de achados:

1. Mostre um ID do achado, a origem exata, por que está errado e um diff unificado de um único arquivo.
2. Peça aprovação explícita para aquele ID do achado quando a alteração excluir ou reescrever semanticamente instruções, alterar configuração, habilitar/desabilitar um componente ou mover arquivos.
3. Recalcule o SHA-256 do arquivo de origem imediatamente antes de aplicar o patch. Pare se diferir da evidência da varredura.
4. Aplique apenas o diff aprovado com apply_patch.
5. Execute novamente a verificação relevante e relate o resultado antes/depois.

Nunca automaticamente:

• exclua ou enfraqueça regras de segurança, regras de marca/persona, fatos de negócio, fatos do projeto, portões Git ou limites de diretório
• exclua texto meramente por estar duplicado entre AGENTS.md e CLAUDE.md; a paridade entre hosts pode ser intencional
• execute hooks para medir desempenho
• confie em hooks, faça login em MCP, exponha credenciais, instale dependências, atualize o Codex ou altere provedores
• modifique configurações de sandbox, aprovação, modelo, rede ou autenticação
• execute comandos Git destrutivos, limpe arquivos não rastreados ou mova diretórios protegidos do projeto

Verificações de conclusão

Antes de relatar a conclusão:

• confirme que o scanner não fez alterações no repositório
• distinga diagnósticos integrados do Codex de achados de governança do workspace
• rotule inferência como inferência
• relate verificações ignoradas e lacunas de evidência
• se reparos foram aprovados, verifique cada arquivo alterado e execute novamente sua verificação de domínio