jgoneit/harness

¿Qué hace harness?

$harness es un enrutador de ejecución de Codex para el bucle de flujo de trabajo Harness. El idioma de explicación predeterminado es el coreano; los términos fijos del flujo de trabajo permanecen en inglés.

Plan -> Aprobación de Ejecución -> Implementar -> Revisar -> Plan de Reparación -> Aprobación de Reparación -> Implementar Reparación -> Finalización

Activación

• Usa esta habilidad solo cuando el usuario invoque explícitamente $harness.
• No te actives a partir de solicitudes ordinarias, inferencias implícitas o menciones en la documentación.
• No requieras el Modo Plan de Codex; ejecuta las compuertas de Harness dentro de la conversación.
• No asumas pila, lenguaje, framework, base de datos, ejecutor de pruebas o plataforma de despliegue.
• Antes de planificar, inspecciona las reglas locales del proyecto como AGENTS.md, README.md, documentos de contribución, manifiestos y .harness/guard.json cuando esté presente. También inspecciona los archivos de estado de Harness locales del proyecto bajo .harness/ cuando estén presentes.

Precedencia de Instrucciones

Aplica las instrucciones y convenciones en este orden:

1. Instrucciones explícitas del usuario
2. Reglas de seguridad del flujo de trabajo Harness, incluyendo reglas de denegación estricta y compuertas de aprobación
3. Política del proyecto desde las claves de política de .harness/guard.json
4. Documentos locales del repositorio como README.md, AGENTS.md y documentos de contribución
5. Convenciones inferidas

La planificación lee las claves de política de .harness/guard.json al inicio. .harness/guard.json es el único archivo de política/configuración del proyecto de Harness; no infieras harness.md, .harnessrc.yaml u otras convenciones de archivos de política del proyecto. La política del proyecto no puede debilitar las reglas de seguridad del flujo de trabajo de Harness. Las operaciones destructivas y el trabajo con configuraciones secretas o protegidas necesitan aprobación explícita independientemente de la política del proyecto.

Los archivos Markdown locales del proyecto en .harness/ son solo evidencia de Memoria y Estado. Léelos antes de planificar cuando estén disponibles, compáralos con la solicitud actual del usuario y el estado de git, marca conflictos obsoletos y pide aclaración cuando el estado obsoleto entre en conflicto con la solicitud actual. No son política y nunca proporcionan aprobación reutilizable.

Para ejemplos concretos de dimensionamiento de tareas, consulta ejemplos de clasificación. Para el contrato de artefactos de flujo de trabajo autorizado, consulta Contrato de flujo de trabajo Harness. Para la recepción de evidencia de conectores manuales y límites de resumen externos, consulta Contrato de Integración de Conectores.

Carga de Referencias Requerida

Lee las referencias relevantes antes de actuar:

• Sigue siempre ../../docs/contracts/harness-contract.md para las secciones canónicas de artefactos, compuertas de aprobación, reglas de Revisión y estados de Finalización.
• Sigue siempre ../../docs/contracts/subagent-handoff.md para informes de subagentes acotados, traspasos de roles, campos SubagentStop Summary y comportamiento de colapso de roles.
• Sigue ../../docs/contracts/memory-state.md cuando los archivos de estado .harness/ estén presentes o se solicite memoria local del proyecto; usa assets/templates/state.md, assets/templates/approval-ledger.md, assets/templates/decisions.md, assets/templates/last-run.md y assets/templates/handoff.md al inicializar o actualizar esos archivos.
• Sigue ../../docs/contracts/worktree-isolation.md cuando el usuario o el proyecto soliciten Aislamiento de Árbol de Trabajo, o cuando haya un registro de sesión de árbol de trabajo activo; usa assets/templates/worktree-session.md para un registro de árbol de trabajo mínimo local de la tarea cuando sea necesario.
• Sigue ../../docs/contracts/connector-integration.md cuando se use contexto de conector externo como un issue, pull request, resumen de CI o hilo de revisión; los conectores son solo evidencia y usan assets/templates/connector-issue-plan.md, assets/templates/connector-pr-review.md o assets/templates/external-summary.md cuando corresponda.
• Lee siempre references/classification-policy.md, references/phase-contracts.md, references/orchestrator-harness.md, references/subagent-policy.md, references/model-policy.md y references/completion-policy.md.
• Para planificación, lee references/planner-harness.md y usa assets/templates/plan.md.
• Para implementación, lee references/implementer-harness.md y usa assets/templates/implement.md.
• Para revisión, lee references/reviewer-harness.md, assets/templates/review.md y assets/templates/reviewer-brief.md.
• Para reparación, usa assets/templates/repair-plan.md.
• Para finalización, usa assets/templates/completion-report.md.
• Si la tarea es No trivial, la revisión está bloqueada/degradada, ocurrió una reparación, hubo dos o más revisiones del Plan, o las reglas/plantillas de orquestación de Harness cambiaron, lee references/improvement-policy.md y usa assets/templates/improvement.md.

Reglas No Negociables

• La clasificación debe ocurrir antes de las compuertas de fase.
• Tiny puede ser manejado directamente por el orquestador.
• Small y No trivial requieren subagentes planificador, implementador y revisor de solo lectura con contexto limpio.
• Para Small y No trivial, el agente principal es el orquestador.
• El esfuerzo mínimo de razonamiento de Harness es high; Implementar y Revisar requieren xhigh cuando esté disponible. No uses medium, low o minimal para $harness.
• No implementes antes de la aprobación del Plan.
• El mensaje de aprobación del Plan debe ser exactamente:

¿Proceder con este Plan? [s/N]

• Solo la s minúscula aprueba la ejecución del Plan aceptado. El lenguaje natural ambiguo significa que no hay decisión; vuelve a preguntar por una s o n explícita. La no aprobación (n, respuesta vacía, variantes mayúsculas como N, variantes expandidas y cualquier otra respuesta que no sea s y no sea ambigua) se detiene por defecto; no implementes, revises ni replanifiques a menos que el usuario pida explícitamente revisar/replanificar. [s/N] significa que No es la opción predeterminada.
• No repares antes de la aprobación del Plan de Reparación.
• El mensaje de aprobación del Plan de Reparación debe ser exactamente:

¿Proceder con este Plan de Reparación? [s/N]

• Solo la s minúscula aprueba la ejecución del Plan de Reparación aceptado. El lenguaje natural ambiguo significa que no hay decisión; vuelve a preguntar por una s o n explícita. La no aprobación (n, respuesta vacía, variantes mayúsculas como N, variantes expandidas y cualquier otra respuesta que no sea s y no sea ambigua) se detiene por defecto; no repares, revises ni replanifiques a menos que el usuario pida explícitamente revisar/replanificar. [s/N] significa que No es la opción predeterminada.
• Solo un subagente revisor de solo lectura con contexto limpio puede completar la Revisión.
• La auto-revisión del agente principal no es Revisión.
• Los datos del conector, asignación de issues, creación de pull requests, éxito de CI, comentarios externos y aprobaciones previas de .harness/ son solo evidencia y nunca aprueban las compuertas de Harness.
• Los traspasos de subagentes y la salida SubagentStop Summary deben seguir el contrato de traspaso de subagentes canónico.
• El fallo de una compuerta requerida debe registrarse como bloqueado o degradado.
• Las operaciones peligrosas requieren aprobación separada.
• Se requiere un informe de Finalización.

Bucle

1. Inspecciona las reglas locales del proyecto, las claves de política de .harness/guard.json, los archivos de estado .harness/ locales del proyecto cuando estén presentes y la solicitud del usuario.
2. Clasifica la tarea como Tiny, Small o No trivial.
3. Para tareas Small o más grandes, define la topología de subagentes.
4. Produce un artefacto de Plan y pide aprobación del Plan.
5. Si el usuario responde exactamente s, implementa solo el Plan aceptado; de lo contrario, detente a menos que el usuario pida explícitamente revisar/replanificar.
6. Para tareas Small o más grandes, ejecuta la Revisión del revisor de solo lectura con contexto limpio.
7. Si la Revisión tiene hallazgos que requieren reparación, produce un Plan de Reparación y pide aprobación de la reparación.
8. Si el usuario responde exactamente s, implementa solo el Plan de Reparación aceptado y repite el bucle acotado de Revisión/Reparación si es necesario; de lo contrario, detente a menos que el usuario pida explícitamente revisar/replanificar.
9. Produce el informe de Finalización con estado, verificación, riesgos y seguimientos.

Hooks

Los validadores mínimos no destructivos se ejecutan para UserPromptSubmit, SubagentStop y Stop; PreToolUse bloquea comandos peligrosos obvios; SessionStart permanece solo de visibilidad. Los hooks no reemplazan las compuertas de Harness ni los controles de seguridad del proyecto.