Resolución de conflictos de responsabilidad cuando agentes paralelos editan el mismo artefacto

Objetivo

Estado a 25 de octubre de 2026. Restablecer un estado coherente cuando varios agentes paralelos han editado el mismo artefacto partiendo de supuestos incompatibles. Volver a comprobar la política de fusión del repositorio, los requisitos actuales y el aislamiento real de los espacios de trabajo. Esta propuesta parte de un conflicto de responsabilidad; no es una introducción general a los worktrees ni a la combinación de resultados independientes.

Requisitos previos

Identificar al responsable de integración, la revisión de destino actual, las revisiones candidatas en conflicto y los requisitos asignados a cada colaborador. Conservar el trabajo local antes de modificar el destino. Los worktrees de Git proporcionan árboles de trabajo e índices separados mientras comparten los datos del repositorio; no considerar un worktree como un límite de seguridad ni suponer que los recursos externos de compilación están aislados.

Pasos

1. Congelar los cambios en conflicto. Impedir que los colaboradores afectados sigan modificando el destino compartido. Conservar cada versión candidata como un commit inmutable o un parche guardado, incluido el trabajo sin commit y los archivos no rastreados que le correspondan. Registrar su revisión base, el objetivo asignado, las rutas modificadas y las evidencias de verificación. Permitir que el trabajo ajeno al conflicto continúe únicamente donde no pueda alterar los datos de entrada en disputa.
2. Asignar un único responsable por artefacto. Registrar quién puede aceptar o sustituir la versión final. Otros agentes pueden proponer correcciones, pero la integración corresponde a ese responsable. Serializar la publicación en el destino y rechazar las entregas que hagan referencia a una revisión aceptada que ya esté obsoleta. El mensaje de finalización de un colaborador es una propuesta, no una transferencia de responsabilidad.
3. Clasificar el desacuerdo. Distinguir el solapamiento de texto de la incompatibilidad de comportamiento. Comparar interfaces compartidas, valores predeterminados de configuración, dependencias, archivos generados y sus fuentes. Por ejemplo, un productor que cambia el nombre de un campo y un consumidor que conserva el nombre anterior necesitan conciliarse aunque sus cambios estén en archivos distintos. Expresar por escrito el requisito en disputa antes de resolver las líneas en conflicto.
4. Resolver a partir de requisitos y evidencias. Pedir a los colaboradores el motivo de cada decisión incompatible. El responsable debe seleccionar o construir la versión candidata que cumpla el contrato aceptado y registrar qué alternativa se rechazó y por qué. Regenerar los artefactos derivados a partir de la fuente seleccionada cuando el proyecto disponga de ese flujo. Conservar una prueba de regresión centrada en el desacuerdo; no debilitar las comprobaciones para que ambas versiones candidatas parezcan compatibles.
5. Integrar desde un estado recuperable. Utilizar un espacio de integración limpio con los commits de las versiones candidatas y del destino registrados. La documentación de fusión de Git advierte de que abortar la operación puede no recuperar los cambios sin commit que ya existían. Inspeccionar los conflictos explícitamente. Si se utiliza --no-commit como pausa de inspección, tener en cuenta las fusiones por avance rápido: Git documenta que no se detienen en esa pausa.
6. Verificar el artefacto resuelto y cerrar el conflicto de responsabilidad. Ejecutar git diff --name-only --diff-filter=U para enumerar las entradas de fusión sin resolver. Tras resolverlas, utilizar git diff --check BASE, sustituyendo BASE por el commit inicial del destino registrado. Git diff comprueba si se han introducido marcadores de conflicto y errores de espacios en blanco; no demuestra que el comportamiento sea correcto. Ejecutar las comprobaciones pertinentes del proyecto sobre la versión candidata combinada, incluida la interfaz en disputa. Registrar el commit aceptado y notificar a los colaboradores qué versiones candidatas sustituye.

Resultado esperado

El conflicto termina con una decisión atribuible a un responsable, una versión candidata reproducible y una verificación vinculada a su revisión exacta. Las entregas tardías requieren una nueva comparación con el artefacto aceptado. Retirar los espacios de trabajo temporales después de confirmar que se conservan el trabajo aceptado y las evidencias necesarias.

Límites y base de verificación

Este procedimiento no se ha probado aquí. Probarlo con cambios contrapuestos inocuos que puedan fusionarse a nivel de texto, pero discrepen en una interfaz. Una recuperación satisfactoria requiere detectar ese desacuerdo y excluir una nueva entrega obsoleta. La fusión de repositorios no concilia las acciones externas ya realizadas por los agentes; estas necesitan un registro separado de resultados.