diodesign/diosix-agent-skills

Revisando o Diosix

Toda alteração de código e documentação no Diosix deve passar por uma auditoria rigorosa e multi-perspectiva antes do commit ou merge. Nunca aprove mudanças de forma automática e nunca assine a aprovação de código quebrado, incompleto ou não verificado. Os critérios de revisão abaixo espelham developing-diosix e documenting-diosix 1:1 para que a aplicação das habilidades de criação elimine retrabalho pré-commit e pré-merge.

Workflow Obrigatório de Verificação em 4 Etapas

1. Gate de Compilação, Completude e Testes (Condição Básica):
   • Verifique se a funcionalidade está 100% implementada conforme o projeto, com zero stubs TODO, código morto ou caminhos de produção simulados (mocked).
   • Ao refatorar arquivos com mais de 500 linhas, nunca trunque funcionalidades ou testes unitários; sempre componentize arquivos muito grandes em subpastas coesas (vm/run.zig, panes/modal.zig, tests/gui.zig) em vez de arquivos planos prefix_subname.zig, e verifique se cada submódulo é referenciado no bloco test de seu pai (_ = @import("vm/run.zig");) para que zig build test execute seus testes unitários.
   • Verifique se os testes unitários estão no mesmo arquivo .zig que testam e se os testes de integração residem em diretórios tests/ separados.
   • Escopo das verificações de formato de arquivo e linha/coluna para diretórios de origem rastreados (build.zig, hypervisor, tools, scripts) em vez de executar globs recursivos sem escopo em .zig-cache/ ou zig-out/.
   • Execute ./scripts/build.sh test --summary all e ./scripts/build.sh até que 100% das etapas de compilação e testes passem com zero avisos ou vazamentos.
2. Revisão Profunda com 4 Personas:
   • Audite cada arquivo modificado e seu contexto circundante através de quatro lentes distintas:
     1. Engenheiro Veterano Cético (completude, expressões idiomáticas, hierarquia de subpastas em vez de arquivos planos prefix_subname.zig, literais hexadecimais em minúsculas 0xfff, constantes/auxiliares nomeados como PAGE_OFFSET_MASK e crossesPageBoundary em vez de bitmasks mágicos, zero duplicação de copiar-colar de Spinlock/alinhamento/validadores de caminho, nenhum array de fallback de lista de candidatos histórica como DEFAULT_GUEST_CANDIDATES para caminhos internos co-versionados, tipos ABI explícitos de largura fixa u64 em vez de usize, anotações de tipo explícitas usize em @min/@max com literais, componentização de arquivos >500 linhas sem truncamento, limite <=80 colunas, buffers dinâmicos vs. estáticos, externalização de política para configuração de compilação/tempo de execução, nenhuma síntese binária/ELF/imagem on-the-fly em Zig, nenhum arquivo gerado dentro de tools/overlay-common/)
     2. Especialista em Segurança Paranóico (isolamento do raio de explosão do hypervisor, prevenção de double-fetch/TOCTOU de cópia única na memória do convidado, bloqueio seguro para IRQ via atomic.Spinlock, zeragem criptográfica/de página, limites aritméticos verificados)
     3. Mantenedor do Diosix (modularidade, legibilidade, defer/errdefer, asserções comptime de tamanho/deslocamento ABI, compatibilidade reversa de contrato externo vs. migração atômica in-tree, cobertura de teste de submódulo)
     4. Usuário Iniciante e Avançado (UX sem esforço, erros claros em inglês, flexibilidade de configuração, desempenho)
3. Auditoria de Lifetime de Ponteiros e Borrow-Checker Estilo Rust:
   • Rastreie manualmente cada ponteiro, slice e alocação em todos os caminhos de fluxo de controle para garantir zero Use-After-Free (UAF), double-free, invalidação de ponteiro em redimensionamento/remapeamento ou referências de pilha pendentes.
4. Gate de Documentação, Ortografia e Estilo:
   • Verifique se docs/ corresponde a todas as alterações de código (incluindo SBI FIDs, tipos de struct C, flags de CLI e caminhos de arquivo modularizados), está escrito em inglês americano claro e gramaticalmente correto com ortografia verificada e está em conformidade com docs/style-guide.md e docs/development.md.
   • Execute novamente zig fmt --check build.zig hypervisor tools scripts e ./scripts/build.sh test --summary all após quaisquer correções de revisão.
5. Quando Estiver Inseguro, Pare e Pergunte ao Mantenedor Principal: Se uma revisão descobrir uma compensação arquitetural ou primitiva ausente, pare e pergunte ao mantenedor principal por orientação antes de fazer suposições.

Guias de Referência Focados

Consulte estas listas de verificação de referência durante cada revisão:

• Lista de Verificação das 4 Personas de Revisão: Critérios de inspeção detalhados para o Engenheiro Veterano Cético, Especialista em Segurança Paranóico, Mantenedor do Diosix e Usuário Iniciante/Avançado.
• Auditoria de Borrow-Checker: Metodologia passo a passo para rastrear proveniência de ponteiros, lifetimes, mutabilidade de alias e segurança de memória entre privilégios em Zig.
• Gates Pré-Commit: Comandos de verificação concretos e critérios de aprovação necessários antes de commitar ou fazer merge em devel ou stable.