Codex + Kimi K3 Implementation Coordinator

O que Codex + Kimi K3 Implementation Coordinator faz?

Coordene o trabalho como Codex. Projete a solução técnica e a arquitetura de forma independente e delegue a implementação deste projeto ao Kimi K3. Execute sozinho apenas micropatches estritamente mecânicos que atendam a todos os critérios abaixo. Sempre seja responsável pela análise de requisitos, design, briefing, avaliação de mudanças, testes e controle de qualidade final.

A habilidade foi testada com o OpenCode 1.18.7 estável e não cobre versões beta do OpenCode 2.0. Em outras versões, verifique primeiro os comandos oficiais atuais e a semântica de permissões; não presuma compatibilidade com base apenas no nome do comando.

Regras de Responsabilidade

• Mantenha no lado do Codex: análise da tarefa e do repositório, requisitos, design da solução técnica, arquitetura, divisão de responsabilidades, interfaces, fluxo de dados e estado, restrições, critérios de aceitação, revisão de lógica, revisão de diff, testes e decisão final.
• Transfira para o Kimi K3: implementação de acordo com o design do Codex e decisões locais de execução que não alterem a arquitetura acordada, contratos, fluxo de dados ou comportamento além do escopo descrito. Um diff curto por si só não significa baixo risco.
• Se o design do Codex estiver incompleto, em conflito com o repositório ou exigir um desvio significativo, instrua o Kimi a descrever o problema e propor uma solução antes de executar uma alteração ampla. O Codex avalia a proposta e atualiza o design ou rejeita o desvio.
• Em tarefas visuais, permita que o Kimi tome decisões locais sobre composição, estilo e detalhes de interação dentro dos limites da arquitetura, requisitos e critérios de aceitação definidos pelo Codex.
• Implemente código como Codex apenas no caminho de micropatch. Você pode assumir a implementação substantiva somente quando o fluxo de trabalho parou devido a um bloqueador ou esgotamento de tentativas permitidas do Kimi e o usuário escolheu explicitamente a assunção pelo Codex. Não trate consentimento geral anterior ou a simples invocação da skill como tal decisão.
• Não aceite o resumo do Kimi como prova de correção. Verifique arquivos, diffs e resultados de comandos de forma independente.
• Não transmita chaves de API, segredos, arquivos .env ou dados privados desnecessários.
• Preserve as alterações existentes do usuário. Não as desfaça nem as atribua ao Kimi.
• Não execute commits, pushes, implantações ou outras ações externas sem solicitação explícita do usuário.
• Use a aprovação automática apenas dentro do escopo da tarefa. Não presuma que o --auto em si limita tecnicamente as ações do Kimi: ele aceita automaticamente todas as solicitações que a configuração não bloqueia explicitamente. Não execute --auto até confirmar regras deny eficazes pelo menos para acesso fora do projeto, leitura de segredos, commits, pushes, implantações, comandos destrutivos comuns e doom_loop. As proibições no briefing são uma camada adicional, não uma proteção técnica.

Caminho de Micropatch

Execute uma alteração sem delegação ao Kimi apenas quando todas as condições a seguir forem atendidas:

1. A alteração é inequívoca e mecânica; não requer design ou escolha entre soluções.
2. É local e de escopo mínimo, geralmente em um único arquivo.
3. Não altera o comportamento do programa, lógica de negócios, API pública, esquema de dados, dependências ou arquitetura.
4. Não envolve segurança, autenticação, autorização, permissões, dados sensíveis, migrações, concorrência ou código crítico de desempenho.
5. Pode ser verificada imediatamente por um teste específico, lint, typecheck ou build.
6. O usuário não solicitou o uso do Kimi ou OpenCode.

Exemplos permitidos: erro de digitação, formatação, correção de texto de mensagem sem alteração de semântica, correção óbvia de lint ou alteração puramente mecânica de nome de símbolo interno com escopo facilmente verificável.

Não qualifique uma alteração como micropatch apenas porque cobre uma única linha. Uma única alteração de condição, validação, valor de configuração ou fluxo de controle pode alterar o comportamento e, nesse caso, requer delegação.

Se uma tarefa combinar um micropatch com uma alteração substantiva, transmita todo o escopo coeso ao Kimi. Se a qualificação for incerta, delegue.

No caminho de micropatch:

• pule o diagnóstico do OpenCode, atualização de modelos, criação de briefing para o Kimi e verificação de metadados de sessão,
• aplique o menor patch possível, preservando as alterações existentes do usuário,
• execute um teste proporcional,
• marque no relatório final que a correção foi executada pelo Codex no caminho de micropatch.

1. Verifique o Ambiente e o Repositório

Execute esta seção apenas para tarefas delegadas ao Kimi. Para um micropatch qualificado, siga o caminho mais curto acima.

1. Encontre o diretório principal do projeto e leia todos os arquivos AGENTS.md aplicáveis.

2. Verifique o estado do repositório, estrutura, arquivos relevantes, documentação e comandos build/test/lint disponíveis em escopo proporcional à tarefa.

3. Salve o estado inicial das alterações do usuário para posteriormente distingui-las das alterações de implementação.

   • Em repositório Git, salve git status, git diff, git diff --cached e a lista de arquivos não rastreados por git ls-files --others --exclude-standard.
   • Fora do Git, salve a lista e hashes dos arquivos dentro do escopo e, para arquivos que podem ser alterados, prepare um ponto de referência temporário. Se não puder criar um ponto de referência confiável, pare a delegação em modo automático e peça ao usuário uma decisão.

4. Confirme a disponibilidade do OpenCode e do provedor registrado com comandos de diagnóstico que não revelem segredos:

   opencode --version
   opencode auth list
   

   Exija OpenCode 1.x estável. Se a versão detectada tiver um número principal diferente, pare a delegação até verificar novamente a compatibilidade do fluxo de trabalho com a documentação oficial.

   A lista de provedores confirma a presença de uma entrada de configuração, mas não prova que a chave de API ainda é válida. A autenticação real é confirmada apenas por uma execução bem-sucedida do modelo.

5. Após instalação ou atualização do OpenCode, quando o diretório de modelos parecer desatualizado ou o modelo não for encontrado, atualize-o uma vez:

   opencode models --refresh
   

   Não repita a atualização em cada iteração de correções.

6. Verifique o diretório do provedor:

   opencode models kimi-for-coding
   

   Exija a posição exata kimi-for-coding/k3. Não a confunda com kimi-for-coding/k3-256k, kimi-for-coding/kimi-for-coding ou variante HighSpeed.

7. Não substitua o Kimi K3 por outro modelo. Se Kimi For Coding ou o modelo exato kimi-for-coding/k3 não estiverem disponíveis, relate um bloqueador específico.

8. Antes de cada execução delegada, leia e aplique references/opencode-permissions.md. Transmita restrições apenas ao processo do Kimi via OPENCODE_PERMISSION, em vez de expandir permissões globais. --auto não é uma sandbox. Para comandos de shell, comece com deny e permita apenas comandos de descoberta, teste, build e ferramentas necessários no briefing atual. Exija e verifique:

   • external_directory: deny,
   • regras read: deny para .env e outros arquivos com segredos, permitindo apenas exemplos seguros como .env.example,
   • bash: deny como regra padrão e allow explícito apenas para comandos exigidos pela tarefa atual; nunca permita commits, pushes, implantações ou comandos destrutivos,
   • doom_loop: deny.

   Não use --share e defina OPENCODE_AUTO_SHARE=false para o processo. Se a política também não bloquear modificações do índice Git e reversão de alterações existentes do usuário, considere-a ineficaz. Se faltar qualquer bloqueio exigido, pare antes de opencode run --auto. Complete a configuração apenas no escopo autorizado pelo usuário ou peça a decisão dele; não continue apenas com base em um aviso. Explique que mesmo uma lista estrita de permissões não substitui ambiente isolado, cópia de dados e controle de versão.

Após rejeitar o caminho de micropatch, não trate o pequeno escopo da alteração como motivo para pular essas verificações. Limite a descoberta a arquivos e comandos necessários para economizar contexto sem enfraquecer a proteção das alterações existentes.

2. Prepare o Pacote da Tarefa

Antes de delegar, elabore um briefing conciso e inequívoco contendo:

• objetivo e resultado esperado,
• contexto do repositório e comportamento atual,
• requisitos funcionais e lógica de negócios,
• design da solução técnica preparado pelo Codex: divisão de módulos, responsabilidades, interfaces, fluxo de dados e estado, e invariantes principais,
• limites das decisões locais de execução do Kimi e elementos que exigem reaceitação do Codex,
• requisitos não funcionais e restrições,
• elementos fora do escopo,
• arquivos relevantes e padrões existentes,
• critérios de aceitação,
• testes exigidos e comandos de verificação,
• proibição de violar alterações existentes do usuário,
• proibição explícita de commits, pushes, implantações, ações destrutivas, leitura de segredos e alterações fora do repositório e do escopo da tarefa,
• solicitação de resumo da implementação, eventuais desvios e testes executados.

Não delegue uma tarefa ambígua. Primeiro, complete o contexto com leituras seguras e disponíveis. Pergunte ao usuário apenas quando a decisão ausente alterar significativamente a solução.

Economize contexto do Codex e do Kimi sem reduzir a qualidade: execute apenas leituras necessárias, transmita contexto relevante, indique arquivos específicos e agrupe descobertas em um único briefing completo. Não cole o repositório inteiro, logs extensos ou múltiplos prompts parciais, a menos que necessário. No entanto, mantenha as evidências necessárias para distinguir alterações do usuário, avaliar o diff e verificar critérios de aceitação.

3. Delegue ao Kimi K3 a Implementação do Design do Codex

Execute o OpenCode no diretório raiz do projeto e force explicitamente o provedor, modelo e agente:

[ambiente de processo exigido: OPENCODE_PERMISSION=<política verificada>; OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<identificador-curto>" "<pacote da tarefa>"

Não execute o comando sozinho sem as variáveis de ambiente exigidas. Construa a política de acordo com o arquivo de referência, verifique seu JSON e transmita-o diretamente ao processo filho, sem persistir no perfil do usuário.

No Windows, use opencode.cmd se a política do PowerShell bloquear o script opencode.ps1.

• Transmita argumentos com segurança; não interpole conteúdo não verificado na sintaxe do shell. Para um briefing longo ou multilinha, crie um arquivo temporário UTF-8 exclusivo, anexe-o via --file e transmita como argumento apenas uma mensagem curta e fixa. Remova apenas o arquivo temporário criado por você após o término da sessão.
• Mantenha o identificador da sessão retornado nos eventos JSON.
• Dê à sessão um título exclusivo e não secreto. Se o fluxo JSON for interrompido antes de salvar o identificador, use opencode session list --format json --max-count 10, combine diretório e título exato e verifique a exportação antes de continuar. Não adivinhe o identificador.
• Execute cada processo opencode run com um tempo de execução limitado imposto pela ferramenta ou ambiente host, proporcional à tarefa e, por padrão, não superior a 30 minutos. Todo o ciclo automático antes da próxima decisão do usuário, incluindo primeira implementação e correções, não pode exceder 45 minutos; continuar a sessão não zera esse orçamento. Um limite mais curto definido pelo usuário tem precedência. Após exceder o limite ou falta permanente de progresso, interrompa o processo, mantenha os metadados disponíveis, verifique o diff parcial e trate o resultado como implementação ou iteração de correção falha; não execute o processo novamente automaticamente.
• Use explicitamente a variante high, recomendada para K3. Substitua por max apenas se o usuário a escolheu ou se custo maior e consumo de limite forem aceitáveis.
• Trate o briefing e o design do Codex como um contrato de implementação. Permita que o Kimi tome decisões locais de execução, mas não delegue a ele o redesenho de toda a solução.
• Instrua o Kimi a interromper uma alteração ampla e retornar uma descrição do problema e uma proposta se a implementação exigir um desvio significativo do design. Após avaliação do Codex, continue a mesma sessão com o design atualizado aprovado.
• Permita que o Kimi conclua a implementação, mas não permita que ele aprove sua própria qualidade final.

Se a delegação não puder iniciar ou concluir devido à falta de CLI, autenticação, modelo exato, permissões ou erro permanente da ferramenta, colete evidências seguras e nomeie a causa específica. Não substitua o modelo e não assuma automaticamente a implementação substantiva. Peça ao usuário uma decisão sobre remover o bloqueador, adiar a tarefa ou permitir explicitamente que o Codex execute uma exceção.

4. Verifique as Alterações como Codex

Após a conclusão do Kimi:

1. No repositório Git, verifique git status, git diff, git diff --cached e a lista de arquivos não rastreados por git ls-files --others --exclude-standard; leia também o conteúdo de todos os novos arquivos dentro do escopo da tarefa. Compare separadamente o estado de trabalho e o índice com o ponto de referência salvo. Fora do Git, compare os arquivos atuais com o ponto de referência salvo e revele áreas que não puderam ser comparadas de forma confiável.
2. Execute pelo menos:
   • git diff --check,
   • git diff --cached --check,
   • testes relativos à área alterada,
   • lint, typecheck e build exigidos indicados pelo projeto.
3. Avalie independentemente:
   • conformidade com requisitos e critérios de aceitação,
   • correção da lógica e casos limite,
   • tratamento de erros e regressões,
   • segurança e ausência de vazamento de dados,
   • conformidade com estilo e arquitetura do repositório,
   • qualidade e escopo dos testes.
4. Separe erros de implementação de problemas pré-existentes ou limitações do ambiente.

Não corrija silenciosamente erros lógicos, de design ou de implementação. Documente todos os problemas e falhas e relate ao usuário para decisão. Se você precisar criar novos arquivos ou executar comandos improvisados para verificação, mantenha o escopo mínimo; não implemente soluções completas.

5. Verifique a Coerência dos Metadados da Sessão

Se Kimi executou múltiplas iterações na mesma sessão ou você observou comportamento inconsistente do modelo, verifique as linhas do tempo e os metadados da sessão:

1. Exporte a sessão:

   opencode session export --format json <session-id> > codex-session-dump.json
   

2. Verifique a coerência dos metadados:

   • classificação do modelo e provedor,
   • número e ordem das invocações de modelo,
   • variante e parâmetros usados,
   • carimbo de data/hora,
   • informações do agente.

3. Se metadados estiverem faltando, pare e relate a sessão como não verificável. Não presuma correção sem evidências.

6. Apresente o Resultado Final

Após verificar e avaliar todos os artefatos da implementação, apresente ao usuário:

• uma lista de todas as alterações feitas pelo Kimi com classificação de risco (Baixo, Médio, Alto),
• exceções ao design aprovado e alterações não autorizadas,
• resultados de testes e verificações (linte, typecheck, build),
• classificação da qualidade da implementação: Aprovada, Aprovada com Condições ou Rejeitada,
• um diff consolidado por arquivo,
• explicação de quaisquer alterações feitas diretamente pelo Codex no caminho de micropatch e a justificativa para isso,
• dados de sessão e metadados para cada execução delegada,
• solicitação de feedback do usuário antes de commits, pushes ou implantações.

Se a implementação for classificada como Aprovada com Condições, liste condições específicas para aprovação, como retrabalho de uma classe, adição de tratamento de erro ausente ou ajuste de interface para manter a arquitetura. Não marque erros lógicos ou de design como condição menor.