Resolução de conflitos de responsabilidade quando agentes paralelos editam o mesmo artefato

Objetivo

Situação em 25 de outubro de 2026. Recuperar o trabalho quando agentes paralelos editaram o mesmo artefato sob premissas incompatíveis. Confira novamente a política de merge do repositório, os requisitos atuais e o isolamento real dos espaços de trabalho. Esta proposta parte de um conflito de responsabilidade; não é uma introdução geral a worktrees nem à combinação de resultados independentes.

Pré-requisitos

Identifique o responsável pela integração, a revisão atual do destino, as revisões candidatas concorrentes e os requisitos atribuídos a cada colaborador. Preserve o trabalho local antes de alterar o destino. Os worktrees do Git fornecem árvores de trabalho e índices separados, mas compartilham os dados do repositório; não trate um worktree como uma barreira de segurança nem presuma que os recursos externos de build estejam isolados.

Passos

1. Congele o conflito. Impeça os colaboradores afetados de alterar o destino compartilhado. Capture cada versão candidata em um commit imutável ou patch preservado, incluindo o trabalho que lhe pertence ainda não commitado ou não rastreado. Registre sua revisão de base, o objetivo atribuído, os caminhos modificados e as evidências de verificação. Deixe o trabalho não relacionado avançar apenas onde ele não puder alterar as entradas em disputa.
2. Atribua um único responsável a cada artefato. Registre quem pode aceitar ou substituir a versão final. Outros agentes podem propor correções, mas a integração cabe a esse responsável. Serialize a publicação no destino e rejeite entregas que se refiram a uma revisão aceita que já esteja obsoleta. A mensagem de conclusão de um colaborador é uma proposta, e não uma transferência de responsabilidade.
3. Classifique a divergência. Separe sobreposições de texto de comportamentos incompatíveis. Compare interfaces compartilhadas, valores padrão de configuração, dependências, saídas geradas e suas fontes. Por exemplo, um produtor que renomeia um campo e um consumidor que mantém o nome antigo precisam ser conciliados mesmo quando as alterações estão em arquivos diferentes. Explicite por escrito o requisito em disputa antes de resolver as linhas em conflito.
4. Resolva com base em requisitos e evidências. Peça aos colaboradores a justificativa de cada escolha incompatível. Faça com que o responsável selecione ou construa a versão candidata que atenda ao contrato aceito, registrando qual alternativa foi rejeitada e por quê. Gere novamente os artefatos derivados a partir da fonte selecionada quando o projeto oferecer esse fluxo. Preserve uma verificação de regressão focada na divergência; não enfraqueça as verificações para fazer as duas versões candidatas parecerem compatíveis.
5. Integre a partir de um estado recuperável. Use um espaço de integração limpo, com os commits da versão candidata e do destino registrados. A documentação de merge do Git alerta que abortar pode não recuperar alterações preexistentes ainda não commitadas. Inspecione os conflitos explicitamente. Se usar --no-commit como pausa para inspeção, leve em conta os merges fast-forward: o Git documenta que eles não param nessa pausa.
6. Verifique o artefato resolvido e encerre a disputa de responsabilidade. Execute git diff --name-only --diff-filter=U para listar as entradas de merge não resolvidas. Após a resolução, use git diff --check BASE, substituindo BASE pelo commit inicial do destino que foi registrado. O Git diff verifica a introdução de marcadores de conflito e erros de espaços em branco; ele não comprova a correção do comportamento. Execute as verificações pertinentes do projeto sobre a versão candidata combinada, incluindo a interface em disputa. Registre o commit aceito e informe aos colaboradores quais versões candidatas ele substitui.

Resultado esperado

O conflito termina com uma decisão de autoria identificável, uma versão candidata reproduzível e uma verificação vinculada à sua revisão exata. Entregas tardias exigem uma nova comparação com o artefato aceito. Remova os espaços de trabalho temporários depois de confirmar que o trabalho aceito e as evidências necessárias foram preservados.

Limites e base de verificação

Este procedimento não foi testado aqui. Teste-o com alterações concorrentes inofensivas que possam ser mescladas textualmente, mas discordem sobre uma interface. Uma recuperação bem-sucedida exige detectar essa divergência e excluir o reenvio de uma versão desatualizada. O merge do repositório não concilia ações externas já realizadas pelos agentes; elas precisam de um registro de resultado separado.