kkestell/xauto

Orquestar el flujo de trabajo x completo

La sesión actual es el coordinador principal. Lee references/workflow.md antes de despachar. Lee las otras tres habilidades según sea necesario; su semántica de etapa y el contrato compartido se aplican a cada trabajador. No ejecutes un flujo de trabajo kauto no relacionado debido a un error tipográfico en el nombre de una solicitud.

Preparar y asignar

1. Establece el resultado solicitado, las restricciones y el alcance. Encuentra la raíz de Git, la rama/HEAD actual, las instrucciones aplicables y el estado sucio/índice. Git es obligatorio; detente en lugar de inicializarlo silenciosamente. Elige un checkout de tarea limpio y exclusivo. Preserva el trabajo no relacionado; aíslalo cuando sea posible, de lo contrario pregunta por la disposición necesaria. No prometas un commit en la rama original del usuario cuando trabajes en una rama separada.
2. Asigna el ID de la tarea y las rutas de artefactos canónicas. Un planificador puede proponer múltiples unidades acotadas más un diseño compartido; el padre asigna IDs adicionales de forma centralizada y preserva la cobertura de la solicitud completa.
3. Descubre las herramientas de delegación disponibles. Usa sesiones hijas primero; solo cuando no estén disponibles usa subagentes. Sigue las reglas de delegación/ciclo de vida del anfitrión. No asumas un nombre de herramienta ni falsifiques un contexto nuevo con otro mensaje en el padre. Si ningún mecanismo existe, detente y explica que el flujo de trabajo orquestado independiente no está disponible; no ejecutes silenciosamente cada rol en línea.
4. Hereda el modelo/herramientas/esfuerzo a menos que el usuario o las instrucciones aplicables los seleccionen. Usa un contexto de revisor nuevo, no un fork que contenga el razonamiento privado del autor. El revisor puede ver la solicitud, el código, los artefactos y los hallazgos públicos anteriores, pero no es el trabajador que escribió el plan/implementación revisada.
5. Captura la procedencia de la sesión del padre usando el contrato compartido. Solicita el ID del coordinador de cada trabajador y el ID de conversación nativo en su entrega; consérvalos en el registro de trabajo antes de la limpieza, no solo los nombres de trabajador transitorios.

Despachar instrucciones de etapa explícitas

Cada trabajador recibe el objetivo, las restricciones de usuario relevantes, la habilidad y la invocación, el ID de la tarea, el checkout exacto y el HEAD inicial, las rutas de entrada/salida, las ediciones permitidas, la autoridad de commit, los requisitos de verificación y la evidencia de verificación existente, la entrega esperada (incluyendo la procedencia de la sesión) y la condición de parada. Incluye dónde se utilizará el resultado. Proporciona un plan o solicitud, no suposiciones que se supone que el trabajador debe verificar de forma independiente.

Las etapas son secuenciales en un checkout compartido. Por defecto, un escritor a la vez; ejecuta unidades separadas concurrentemente solo cuando sus archivos y dependencias son verdaderamente independientes y la propiedad de integración/revisión es explícita. Confirma el directorio/HEAD real de cada hijo; integra los commits de entrega del trabajador aislado antes de la siguiente etapa, como se describe en el contrato compartido. Nunca borres un resultado no transferido.

Planificar → revisar el plan

• Inicia un planificador con xplan <solicitud> y sin autoridad de edición de código de producción. El planificador investiga preguntas difíciles, resuelve decisiones de ingeniería y devuelve planes listos, una breve descripción de tarea pequeña o bloqueadores concretos.
• Inspecciona los artefactos devueltos y la cobertura. Confirma los registros del plan/diseño compartido como plan, luego envía cada plan de ejecución a un trabajador independiente usando xreview plan .agents/plans/ID.md. Confirma su ronda de revisión como plan-review.
• Para los hallazgos, devuelve una asignación de corrección concreta al planificador. Confirma el plan revisado. El padre verifica las correcciones contra los hallazgos y la evidencia relevante, registra su disposición y los blobs finales del plan/orientación, y procede cuando no quede ningún defecto de consecuencia. Esta es la decisión de ejecución del padre, no una afirmación de que el revisor aprobó revisiones no vistas. No envíes cada revisión a través de otra revisión completa del plan. Una evaluación independiente adicional necesita una pregunta de consecuencia específica que la revisión anterior y la verificación de corrección no puedan resolver; nombra esa pregunta y solicita solo la evaluación necesaria. La redacción, los metadatos y las correcciones rutinarias no justifican reiniciar la revisión. Las ediciones de diseño compartido requieren verificar las unidades afectadas, no encargar automáticamente otra revisión de cada una.
• Para trabajo realmente pequeño, conserva la breve descripción acotada del planificador para xwork y omite los artefactos separados de plan/revisión; el registro de trabajo posterior registra la razón. No eludas la normalización llamando a una asignación grande no resuelta una breve descripción.
• Una solicitud dividida no está terminada después de su primera unidad. Rastrea las dependencias de las unidades en el diseño compartido, ejecuta cada unidad solicitada en orden y vuelve a verificar las interfaces compartidas/estados intermedios cuando una dependencia cambie.

Trabajar → revisar la implementación

• Despacha un implementador con xwork .agents/plans/ID.md, o la breve descripción de tarea pequeña explícita. Proporciona los blobs de revisión aceptada/plan y orientación vinculada. Autoriza solo el código propiedad de la tarea y los commits de registro. xwork registra una base de Código fija, confirma el código verificado, luego confirma por separado su registro con un head de Código conocido.
• Verifica la entrega contra Git y la salida de prueba registrada; el mensaje de "listo" de un hijo no es evidencia del árbol correcto, las verificaciones completadas o los archivos confirmados. Resuelve los mapeos de integración y usa los hashes del checkout de la tarea en el registro final.
• Inicia un revisor independiente con xreview work .agents/work/ID.md. Proporciona la solicitud, el plan/breve descripción, el rango completo de base de Código..head de Código, el registro de trabajo y las instrucciones relevantes del repositorio. El revisor lee el código y las pruebas, no solo el registro, y escribe una revisión sin corregir la implementación. Confirma su revisión como work-review.
• Pasa los resultados de verificación inspeccionables para el head de Código registrado. Pide al revisor que inspeccione/reutilice esa evidencia primero e identifique cualquier incertidumbre restante antes de seleccionar verificaciones nuevas. No solicites de forma rutinaria repeticiones enfocadas, una ejecución completa del paquete y la suite del repositorio nuevamente para el mismo código sin cambios. Los requisitos explícitos de ejecución nueva aún se aplican.
• Envía los hallazgos procesables al implementador. Este confirma las correcciones y una entrada de registro adjunta, conservando la base original. Devuelve el cambio completo actualizado al revisor independiente; los hallazgos anteriores necesitan evidencia de resolución, no una lista de verificación vacía nueva. Conserva todas las rondas de revisión. El revisor puede reutilizarse mientras sea independiente del autor; ningún rol puede aprobar código que acaba de escribir.
• Si la implementación expone un diseño inválido, redirige la decisión de vuelta a través del planificador y el padre antes de continuar. Aplica la misma verificación de corrección a las unidades dependientes afectadas; la evaluación independiente adicional necesita una incertidumbre de consecuencia específica, no solo un blob de plan cambiado. No dejes que xwork expanda silenciosamente el alcance ni deje la decisión difícil para la codificación.

Resolver hallazgos y finalizar honestamente

Procede sin confirmación rutinaria, pero pregunta cuando la intención, el alcance, los permisos o una compensación material realmente requieran al usuario. Detente en herramientas/verificaciones requeridas no disponibles en debates disputados. Continúa las reparaciones ordinarias mientras progresen; si una ronda repite el mismo enfoque fallido, necesita una decisión del usuario o supera un presupuesto explícito, detente e informa la evidencia no resuelta en lugar de generar un bucle de revisión indefinido. Nunca aceptes un defecto para terminar el ciclo.

Antes del éxito, el padre verifica:

1. Cada unidad de ejecución solicitada está implementada, las verificaciones requeridas realmente pasaron, y su código final tiene una revisión de trabajo aceptada independiente.
2. Cada cambio de código/prueba/configuración después del head de Código revisado de una unidad está cubierto por el rango de revisión aceptada de una unidad posterior en el checkout de tarea integrado, o vuelve a través de la verificación y la revisión de trabajo. Los cambios conocidos solo de registro de flujo de trabajo no necesitan una nueva revisión de código. Cuenta todos los commits/diffs, no solo los nombres de ruta coincidentes. Las correcciones de conflictos de integración y los contratos anteriores rotos requieren verificaciones/revisión renovadas; una unidad aceptada posterior no los excusa automáticamente.
3. Los registros de trabajo contienen el plan/breve descripción aceptado, la base fija, el head revisado final, los commits reales, los IDs de conversación nativos del padre/trabajador (o razones explícitas de no disponibilidad), la evidencia de verificación ejecutada/reutilizada y las rutas de revisión. Establécelos como complete y confirma los registros restantes propiedad de la tarea como complete.
4. Todos los cambios propiedad de la tarea y los nuevos registros están confirmados en la rama informada. Verifica con Git, preserva el trabajo no relacionado y no hagas push ni fusiones automáticas en una rama diferente. Los heads de código originales no necesitan ser iguales al HEAD final porque los commits posteriores contienen registros u otras unidades aceptadas independientemente.
5. Guarda la procedencia de la sesión de cada hijo e integra/guarda cada resultado antes de terminar las sesiones que eliminan sus ramas/worktrees. Deja un resultado confirmado accesible y sigue las reglas de limpieza del anfitrión. Los ciclos fallidos informan commits parciales y bloqueadores, no éxito.

Devuelve un resultado conciso, IDs de tarea, rutas de artefactos, rama e IDs de commit final, verificaciones, veredictos de revisión y cualquier limitación restante. El padre es dueño de esta verificación e informe final; no te limites a concatenar resúmenes de trabajadores.