De requisitos a aceptación
1. Parafrasear y confirmar
Parafrasea los objetivos del usuario, no objetivos, condiciones de aceptación observables, riesgos y restricciones presupuestarias. Una vez confirmado, procede a la implementación; si ya existe una confirmación clara, úsala sin volver a solicitar autorización. Solo pregunta por las brechas que realmente afecten la implementación. Este flujo no amplía los permisos de herramientas, costos, envíos, fusiones o despliegues.
2. El coordinador divide directamente
- El coordinador define directamente los límites funcionales, dependencias, interfaces, responsables y elementos de aceptación, sin añadir una capa adicional de agente de división. Las tareas independientes son paralelas; las tareas dependientes avanzan según interfaces y orden.
- Una función que pueda probarse y revertirse de forma independiente corresponde a un worktree, rama y PR real independientes. Fija la rama objetivo y los SHA de base/head; diferentes implementadores no comparten el directorio de trabajo ni toman prestadas ramas de otras tareas.
- Las adiciones + eliminaciones finales de un PR de función única no deben superar las 1000 líneas, incluyendo pruebas, documentación y archivos generados. Si se supera, divídelo razonablemente primero; si no se puede dividir, explica el motivo y el tamaño, sin ocultar archivos generados ni dividir a medias una función.
- Para lotes multifunción, registra las URL de los sub-PR, dependencias y elementos de aceptación independientes. Pueden organizarse mediante PR apilados o ramas de integración ya soportados por el proyecto; verifica las capacidades reales; los números de tarea en la documentación no pueden hacerse pasar por PR reales.
3. El implementador ejecuta y se autoverifica
- El implementador completa la implementación, la autocomprobación y la ejecución de las rutas clave del usuario antes de enviar a revisión independiente, sin transferir el trabajo principal de verificación de ejecución y capturas de pantalla al revisor.
- Registra el SHA exacto, comandos, entorno, resultados reales, elementos no probados y riesgos. Los errores proporcionan la reproducción antes de la corrección y el resultado después de la corrección en la misma ruta. Separa los informes de compilación, mock y aceptación con servicio real.
- Los cambios de UI proporcionan capturas de pantalla reales de los pasos clave y resultados. Coloca las capturas en los comentarios del PR o archivos adjuntos, no las envíes a la rama de código. Primero verifica los parámetros admitidos por la herramienta de carga; si la carga falla, informa el bloqueo, no inventes URL de archivos adjuntos.
- Los cambios de permisos de backend, datos o comportamiento financiero proporcionan evidencia de API/datos correspondiente. Las pruebas utilizan entornos aislados y datos sintéticos, sin filtrar credenciales ni datos personales.
- Los cambios de reglas o documentación sin UI no fingen capturas de pantalla; basta con verificar el alcance, enlaces, coherencia de reglas y diff. La verificación en contenedores utiliza entornos aislados autorizados, sin revertir la máquina personal del usuario.
- Los PR utilizan la plantilla de cuatro secciones, cada evidencia vinculada a una confirmación real.
4. Revisión de código y seguridad por separado
- Prioriza la reutilización de las revisiones automáticas de código y seguridad ya configuradas en el repositorio, verificando respectivamente el estado de finalización, el SHA cubierto y los hallazgos pendientes. No envíes revisiones duplicadas adicionales ni actives manualmente repetidamente.
- Si no está configurado, no se activó o no cubre el SHA objetivo, informa la brecha; maneja según el plan de respaldo autorizado, si no hay autorización de respaldo, obtén una decisión. La ausencia de comentarios no equivale a revisión completada.
- Para calidad de código, lee
yushen-code-quality-reviewsegún sea necesario; para seguridad, leeyushen-security-reviewsegún sea necesario. La ruta se basa en la ubicación de instalación real; si falta o no se lee, explícalo. - Las revisiones solo plantean problemas con evidencia; para implementaciones externas se puede comparar y sugerir, pero sin la adopción del usuario no se cambia el plan, se migra ni se añaden dependencias.
5. Convergencia en un máximo de tres rondas
Una ronda es: comentarios de revisión → corrección o manejo con evidencia → verificación. Las revisiones de código y seguridad cuentan juntas, total máximo tres rondas; cambiar de agente, modelo, reintentar, restack o reabrir el mismo PR de trabajo no reinicia el contador.
La primera ronda revisa el diff completo con los requisitos; la segunda y tercera revisan el nuevo diff, el cierre de problemas existentes y las regresiones afectadas. Utiliza ID de problema estables para fusionar hallazgos de la misma causa raíz, registrando ubicación, evidencia, ronda inicial, estado, SHA de corrección y verificación. Los falsos positivos se explican con evidencia; no se hacen modificaciones sin sentido solo para eliminar comentarios. No se marca como resuelto sin una nueva verificación.
Si un mismo problema no avanza después de dos rondas de corrección válidas, se puede escalar antes. Si en la tercera ronda aún hay problemas sin resolver, se detiene la convergencia automática, el coordinador reúne evidencia, reconsidera el plan y solicita una decisión; no se baja el listón, se aprueba automáticamente ni se fusiona.
6. Verificación de la versión combinada
El coordinador verifica la CI final necesaria, la resolución de conflictos, el estado compartido y las rutas de usuario combinadas, registrando el SHA de cada sub-PR y el SHA candidato combinado. La aprobación a nivel individual no implica aprobación combinada. Después de rebase, resolución de conflictos o cambios de implementación, actualiza el mapeo de SHA y complementa las regresiones afectadas; la evidencia antigua no puede hacerse pasar por resultados de la versión actual.
7. Aceptación humana
Proporciona el SHA candidato, el producto ejecutable, los pasos de prueba mínimos, los resultados esperados y los riesgos restantes. El usuario mismo prueba y confirma explícitamente la versión correspondiente antes de fusionar según la autorización real. Después de cambios de código, se reconfirma la parte afectada; las pruebas automáticas y la aprobación del robot no reemplazan la aceptación personal. El lanzamiento y despliegue se manejan según sus respectivas autorizaciones.
Al entregar instaladores, aplicaciones de escritorio u otros productos de lanzamiento reales, lee yushen-release-acceptance según sea necesario, verifica la ruta completa desde el archivo descargado hasta su uso, y distingue las conclusiones por plataforma y las limitaciones de vista previa. Los cambios puramente textuales o internos menores no obligan a ejecutar toda la aceptación de lanzamiento.
Estrategia de modelo y costos
Selecciona el modelo según la dificultad de la tarea, riesgo, presupuesto y capacidades disponibles: prioriza scripts para verificaciones deterministas; para implementaciones locales claras, prioriza el nivel de bajo costo; para diagnósticos complejos, diseño y juicios de alto riesgo, elige un nivel de capacidad adecuado; para organización de evidencia, usa un nivel de menor costo. Al inicio, explica el rol seleccionado, los límites de costos y las condiciones de escalado, sin asumir que un modelo específico está disponible por defecto en entornos públicos.
Primero descarta fallos ambientales y falta de contexto antes de decidir escalar. Si se supera el presupuesto, se añaden llamadas pagadas o se excede la capacidad autorizada, primero obtén la decisión correspondiente; no reintentes indefinidamente. Al final del lote, usa resumen de retrabajo según sea necesario; las actualizaciones de reglas siguen el flujo de aceptación normal.
Integración de reglas del proyecto
En el archivo AGENTS.md del proyecto, especifica claramente que se deben leer las habilidades relevantes y REVIEW.md según la tarea; no asumas que los enlaces se expanden automáticamente. En REVIEW.md solo coloca reglas de proyecto a largo plazo que se puedan juzgar; los hallazgos y evidencia de cada ronda quedan en el PR. Si faltan archivos o hay conflictos de restricciones, infórmalo, no inventes mecanismos.
Al crear reglas de proyecto, puedes consultar el ejemplo de REVIEW general según sea necesario, conservando solo las cláusulas realmente aplicables y verificables.