O que Entrega de Engenharia faz?
Use para estruturar, coordenar ou concluir uma iniciativa de engenharia. Ela suporta uma mudança completa entre repositórios, e não um gerenciador por repositório ou camada. Trabalhos pequenos podem permanecer em uma única conversa; implementação ou revisão independente obtém um subordinado nativo delimitado quando útil.
Conheça a intenção antes de delegar
Mantenha visíveis o resultado desejado pelo usuário, os critérios de aceitação, as restrições e as mudanças de prioridade. Leia o contrato da equipe uma vez por contexto de trabalho e as lições de feedback do mantenedor relevantes. Leia seletivamente por caso/ID de lição; releia quando o contexto estiver faltando ou as orientações mudarem. O chefe e o gerente consultam frdel e suas perguntas de planejamento antes de escolher uma abordagem; os trabalhadores recebem critérios relevantes e referências de fonte. Isso é suporte à decisão, não poder de veto para estilo histórico.
Para cada repositório afetado, descubra sua raiz, branch/diff atual, cadeia AGENTS.md aplicável e DOX profunda. No Agent Zero, arquivos *.py.dox.md adjacentes descrevem o comportamento de helpers/ferramentas. Siga índices reais e contratos referenciados em cada repositório; não presuma que todo repositório usa o mesmo formato de nível de arquivo. Leia chamadores, hooks de extensão, configuração, testes e caminhos de instalação antes de decidir o que pode ser movido. A DOX atual é autoritativa; não congele suas regras detalhadas nesta skill.
Registre a escolha e seu custo: proprietário/primitiva existente reutilizada, alternativa rejeitada e porquê, comportamento protegido, incertezas e a verificação que pode refutar a hipótese. Nova estrutura precisa de uma obrigação concreta; simplicidade nunca desculpa comportamento solicitado omitido ou compatibilidade quebrada.
Limites de execução
Este fluxo de trabalho é executado através das ferramentas nativas, contextos e jobs do Agent Zero. Skills e perfis são arquivos instalados comuns sob /a0/usr/. Um conector pode fornecer acesso autorizado ao repositório host; um papel em si não concede capacidade. Descubra o checkout e o modo de leitura/gravação acessíveis reais antes de atribuir trabalho ao host. Uma sonda de host bloqueada não bloqueia trabalho independente do servidor.
Siga as regras de mensagem de commit, branch de staging e seleção de destino no contrato de equipe compartilhado. Use um destino de desenvolvimento/teste explicitamente configurado; caso contrário, o padrão é a instância de hospedagem atual. Configuração ausente permite trabalho na mesma instância sob autorização normal. Reporte um destino explícito inválido ou inalcançável sem recorrer silenciosamente ao fallback. Registre a instância de hospedagem, destino selecionado, checkout/binds reais, branch e escopo de gravação. Considere a interrupção de trabalhadores ativos quando um reload/restart for necessário, usando coordenação de ciclo de vida/checkpoint existente. Um fixture auxiliar de propriedade da tarefa prova apenas seu comportamento delimitado; nenhum serviço de frota é necessário.
Papéis e transferências
| ID do Perfil | Responsabilidade |
|---|---|
chief-of-staff | Intenção do usuário, prioridade e resultados em iniciativas independentes. |
delivery-manager | Uma mudança completa, incluindo integração entre repositórios. |
engineering-worker | Implementação ou investigação delimitada com propriedade de gravação nomeada. |
engineering-reviewer | Correção independente, contratos e decisões de desenvolvimento. |
design-reviewer | Fluxo de trabalho independente, linguagem, componentes, acessibilidade e estado verdadeiro. |
engineering-verifier | Prova de comportamento independente no artefato/runtime pretendido. |
Revisores e verificador reportam ao gerente de entrega; eles não editam silenciosamente os resultados. O gerente arbitra, retorna os resultados aceitos ao trabalhador responsável e solicita uma reavaliação focada. O chefe recebe resultados integrados dos gerentes. Não adicione gerentes intermediários por padrão nem crie uma cerimônia fixa de seis agentes para pequenas edições.
Leia delegação nativa para as APIs reais de continuação e paralelas e um registro de tarefa mínimo. Dê a trabalhadores independentes escopos de gravação disjuntos. Contratos compartilhados, edições dependentes, alterações de configuração e integração são sequenciados. Mantenha IDs de contexto nativo e handles de job existentes; não construa uma fila, registro, daemon ou serviço de orquestração.
Finalize a mudança completa
- Estabeleça um defeito reproduzível ou comportamento alvo observável. Teste suposições incertas antes de uma edição ampla.
- Implemente dentro dos limites de propriedade, cobrindo chamadores, config, migrações, testes e DOX afetados pela mudança. Ao remover/reverter algo, rastreie também seus consumidores indiretos e dados persistidos.
- Solicite revisão independente proporcional à consequência. Use
engineering-reviewpara correção/design/verificação, e as skills existentesa0-development, plugin authoring ea0-e2e-testingpara seus procedimentos nativos. - Verifique o runtime/artefato exato alterado e o fluxo de usuário real. Distinga verificações automatizadas, observação de UI e comportamento orientado por modelo; nenhum substitui silenciosamente o outro. Preserve dados do usuário e restaure configurações temporárias de propriedade da tarefa.
- Feche com resultado, decisões significativas, evidência, trabalho restante e risco. Uma chamada de modelo bloqueada é bloqueada, não aprovada. Continue trabalho autorizado de forma autônoma; aprovação é necessária apenas para um limite de permissão real, não para etapas reversíveis de rotina.
Nenhuma permissão para instalar, commitar, fazer push, publicar, enviar mensagens externas ou alterar acesso é implícita por um papel. Leia as permissões de cada repositório e a autorização existente do usuário. Não exponha segredos ou histórico de chat bruto em registros de tarefas ou DOX rastreada.
Usando a equipe
Escolha o Chief of Staff para várias iniciativas, ou o Delivery Manager para um resultado. Um gerente pode iniciar múltiplas conversas independentes de trabalhador/revisor usando os mesmos perfis reutilizáveis. Selecionar um perfil em um chat novo ou subordinado criado carrega seu papel; chats/configurações não relacionados existentes não são migrados. Predefinições de escopo filho não padrão substituem uma substituição do chat pai; apenas filhos Padrão podem herdá-la. Registre a predefinição/provedor/modelo efetivo para filhos importantes sem alterar os padrões do usuário. Nenhum modelo/provedor é prescrito aqui.