# Guías de integración por harness

Objective Guard es un runtime de verificación continua para agentes de programación. Funciona como CLI local (`oguard`) más hooks del harness. La CLI se comporta igual en todos lados; lo que cambia por harness es qué eventos existen, qué payload recibe el hook y dónde vive la configuración del hook.

Una guía por harness. Cada guía cubre sólo la integración: cómo conectar los hooks, cómo probar que se dispararon y qué no puede observar el harness. La puesta en marcha inicial — instalar la CLI, abrir la primera ronda, leer el contrato — vive en [../getting-started.es.md](../getting-started.es.md) y no se repite acá. Para el modelo de niveles detrás del loop (nivel 0 por edición, nivel 1 por turno, nivel 2 al cierre), ver [../product/04-technical-architecture.es.md](../product/04-technical-architecture.es.md). La entrada de la documentación es [../README.es.md](../README.es.md).

Versión en inglés: [README.md](README.es.md).

## Guías disponibles

| Guía | Usá esta cuando |
| --- | --- |
| [Claude Code](claude-code.es.md) | Editás con las herramientas estructuradas `Edit`/`Write` de Claude Code y querés que el gate `PreToolUse` deniegue mutaciones hasta que `task-flow` devuelva `ready`. |
| [Codex](codex.es.md) | Editás con `apply_patch` de Codex y querés detectores por parche más el mismo gate pre-edición e inyección de prompt. |

Hoy no hay ningún otro harness integrado en código. Cursor, Gemini CLI, Copilot y Aider no tienen script de hook, ni test, ni ejemplo de configuración en este repositorio. No los documentes hasta que exista el cableado.

## El contrato que toda guía debe cumplir

Usá estos siete headings H2, en este orden, sin agregar otras secciones H2:

```
## Qué aporta esta integración
## Requisitos
## Instalación
## Verificar la integración
## El loop en la práctica
## Qué no puede ver el harness
## Resolución de problemas
```

Reglas de contenido:

- **Qué aporta esta integración** — de tres a seis bullets. Cada uno nombra una capacidad concreta (detectores en tiempo de edición, gate de preflight pre-edición, inyección de prompt de `task-flow`, evidencia de ronda, telemetría sanitizada) y dice qué no prueba esa capacidad.
- **Requisitos** — la versión de Node de `package.json#engines`, un repositorio Git y las capacidades del harness de las que el código realmente depende. No inventes un número de versión del harness que el código no implica.
- **Instalación** — comandos copiables y la ruta real del archivo de configuración que lee el harness, con la configuración del hook en un bloque JSON. Decí explícitamente si esa configuración es a nivel usuario o a nivel proyecto.
- **Verificar la integración** — comandos cuya salida prueba de forma observable que el hook se disparó, más el archivo de test que cubre el mismo cableado.
- **El loop en la práctica** — un bloque con la secuencia normal y después una línea de prosa por paso. Mantenelo secuencial y corto.
- **Qué no puede ver el harness** — los límites honestos. Como mínimo: el gate sólo inspecciona payloads estructurados de herramientas y no clasifica escrituras hechas dentro de comandos de shell; un repositorio sin contrato no queda bloqueado; una autorización `ready` se cachea contra el hash del contrato y expira; la telemetría es sanitizada y prueba uso, no beneficio.
- **Resolución de problemas** — una tabla de síntoma, causa probable y el comando que muestra la verdad.

Dos reglas están por encima de las preferencias de estilo. Todo comando de una guía debe existir en el código — preferí `node src/cli.mjs <cmd>` para uso dentro del repositorio y `oguard <cmd>` una vez instalada la CLI, y aclará cuál es cuál. Y nunca sobreafirmes: un guard que pasa significa solamente que los checks en alcance no encontraron violación, no que se alcanzó el objetivo.

## Agregar una guía nueva

1. Copiá [_template.md](_template.es.md) a `docs/guides/<harness>.md`.
2. Conservá los siete headings H2 y su orden. Reemplazá cada `TODO` por algo que hayas verificado en el propio script de hook del harness, o eliminá la afirmación.
3. Agregá la contraparte en español en `docs/guides/<harness>.es.md` — misma estructura, mismos comandos, headings traducidos.
4. Agregá una fila a la tabla de arriba (y a la tabla de `README.md`) con un "usá esta cuando" de una línea.
5. Corré `npm run validate:docs`. Valida la topología documental y todos los enlaces relativos.