Sobre o projeto

Repo Agent Orchestration é uma Codex Skill comunitária não oficial (licença MIT) que mantém as convenções de entrega de repositórios multiagentes dentro do próprio repositório, em vez de em um serviço central. Seu objetivo declarado é finalizar o trabalho de repositório nos contextos apropriados com propriedade clara, verificação proporcional e handoff recuperável. O projeto observa explicitamente que não concede permissões, não desbloqueia capacidades de produto e não reproduz nenhum sistema de orquestração proprietário. A documentação define três modos de propriedade — direta, de entrega e arquitetada — como descrições de quem detém as decisões, em vez de números fixos de conversas. As orientações abrangem a delegação de trabalho separável, a continuação de trabalho pronto para dependências em vez de consultar status inalterados, a manutenção de julgamentos de implementação e revisão independentes, e a verificação da identidade Git real e caminhos exclusivos. Escritores internos são descritos como compartilhando a árvore de seu proprietário com escopos disjuntos, enquanto escritores de App que operam independentemente usam worktrees locais do repositório registradas separadamente. A revisão de design independente é exigida por solicitações explícitas do usuário ou requisitos do repositório, ou para riscos materiais transversais ou irreversíveis. A instalação é realizada a partir do checkout da fonte com scripts/install_repository.py apontando para um caminho de repositório. Ele copia a Skill para .agents/skills/repo-agent-orchestration e atualiza idempotentemente um bloco marcado no AGENTS.md da raiz do repositório, preservando as regras fora desse bloco. Uma flag --dry-run pré-visualiza as gravações, e --check detecta desvios de arquivos instalados ou de perfil sem modificar o alvo. O instalador aceita opções que abrangem a branch principal, raiz da worktree, prefixo da branch, política de worktree raiz, política de host de tarefa, política de modelo de controlador, configurações de modelo por função, caminhos de integração compartilhados, política de continuidade e gates externos. Os padrões de modelo são app_default, que omite substituições de modelo e pensamento; as atualizações preservam vinculações explícitas existentes, exceto um padrão de instalador aposentado que migra de volta para app_default. Um adaptador estruturado opcional suporta tarefas de App explicitamente solicitadas onde o host suporta uma rota local de saved-project. Seu construtor e validador lidam com oito tipos de pacotes — binding, write, review, update, design_handoff, delivery_update, design_reopen e design_decision — compartilhando um esquema. A documentação afirma que o adaptador verifica a contenção de caminho, a identidade do saved-project, a branch e o commit Git atuais, a revisão de leitura exclusiva e as configurações de relatório preservadas, mas não prova a autorização da tarefa, a entrega real, a qualidade da revisão ou a aceitação, e que o campo DELIVERY de um relatório é uma rota pretendida e não um recibo. A validação baseia-se na descoberta de unittest da biblioteca padrão do Python, um validador de exemplo e uma demonstração local, com CI visando Python 3.11 e 3.13; o Git é necessário para os testes do instalador e da worktree. A demonstração cria um repositório Git temporário e árvores de escritores isoladas e prova apenas verificações de contrato e Git locais, não a criação de App, entrega de mensagens, modelos efetivos ou comportamento real de agentes. Casos comportamentais são fornecidos para exercícios que asserções de string não podem provar. A orientação de limpeza exige uma decisão explícita para cada worktree e branch de propriedade, removendo apenas resíduos validados como limpos, integrados ou explicitamente abandonados através do fluxo de worktree do Git, e retendo resíduos inseguros ou úteis com coordenadas exatas; nenhuma limpeza baseada em idade, exclusão forçada de trabalho recuperável, exclusão de branch remota, daemon de segundo plano ou escalonamento automático de permissões está incluída. O layout separa a Skill instalável, o instalador, o validador de exemplo, a demonstração local, as entradas comportamentais, um runbook de desktop opcional e testes determinísticos.