# Capa 6 — Roadmap y criterios de Objective Guard

## Orden de construcción

### Fase 0 — Contrato y dogfooding documental

Entregables:

- documentación canónica por capas;
- guard documental reproducible;
- investigación preservada como historial;
- criterios explícitos de MVP.

Gate: `node scripts/validate-docs.mjs` pasa sin excepciones.

### Fase 1 — Reflejo universal

Entregables:

- hook por edición;
- detectores `syntax`, `weak-test`, `stub-prod`, `new-dep`;
- fingerprints delta-only;
- salida compacta;
- eventos append-only;
- corpus golden y benchmark de latencia.

Gate: cumple presupuestos, detecta casos sembrados y no requiere contrato.

La calibración se rige por el [protocolo de Fase 1](07-phase-1-calibration-protocol.es.md): el gate ejecutable es un corpus congelado de 100 escenarios y la evidencia orgánica se observa sin prometer una tasa base de errores.

### Fase 2 — Sesión y contrato

Entregables:

- tipos de tarea;
- objetivo original y criterios;
- scope objetivo y zonas sensibles;
- obligaciones de evidencia;
- estados por criterio;
- excepciones auditables.

Gate: un bugfix no puede cerrar sin evidencia de regresión cuando la política lo exige.

### Fase 3 — Impacto incremental

Entregables:

- descubrimiento de workspaces;
- grafo inicial de paths/imports;
- selección de checks;
- caché por entradas;
- modos rápido y final.

Gate: un refactor interno evita checks de workspaces no afectados sin omitir consumidores públicos.

### Endurecimiento de protocolo para rondas multiagente extensas

Este trabajo sigue a la base de sesión/contrato y precede cualquier dependencia de un producto de orquestación:

- separar gobernanza versionada de estado local de ronda activa;
- soportar subrondas heredadas de definición, implementación, review y corrección;
- fingerprint de fallos de checks preexistentes y comparación incremental;
- clasificar fallos de cierre por origen y ejecutabilidad;
- acumular evidencia y contradicciones por criterio;
- agregar `objective-status --json` y la matriz de trazabilidad de cierre;
- explicar vigencia e invalidación del preflight;
- aceptar IDs genéricos de correlación externa.

Gate: dos subrondas paralelas pueden heredar un objetivo padre, aportar y contradecir evidencia de criterios sin reescribirlo, y cerrar con una matriz reproducible de requisito a commit.

### Fase 4 — Señales estadísticas pasivas

Entregables:

- superficie vectorial;
- AUS;
- evidencia relativa;
- datasets separados de calibración y evaluación;
- reportes offline sin alertar al agente.

Gate: supera baselines simples fuera de muestra.

### Fase 5 — Intervención calibrada

Entregables:

- ensayo control/placebo/guard;
- política de advertencias;
- explicación de factores;
- monitoreo de falsos positivos.

Gate: reduce costo sin reducir resolución correcta.

## MVP

El MVP de producto es la Fase 1, no el plano de control completo.

Incluye:

1. CLI ejecutable localmente.
2. Integración genérica por hook.
3. Soporte inicial JS/TS; Java condicionado al spike.
4. Cuatro detectores universales.
5. Fingerprints y delta-only.
6. Máximo cinco líneas por evento.
7. JSON opcional con códigos estables.
8. Estado descartable y event log append-only.
9. Timeout y fail-open visible como `error` en log.
10. Corpus golden y medición de latencia.

No incluye todavía:

- índices semánticos repo-wide;
- contratos de tarea;
- detector estadístico activo;
- dashboard;
- SDK público de plugins;
- ejecución distribuida.

## Criterios de aceptación

### Funcionales

- Detecta un test recién deshabilitado y señala la línea.
- Detecta sintaxis inválida en el archivo editado.
- Advierte un stub nuevo en código de producción.
- Advierte una dependencia nueva.
- No re-emite el mismo fingerprint en la siguiente ejecución.
- Resume hallazgos resueltos.
- Emite JSON válido cuando se solicita.
- Registra un evento reproducible por ejecución.

### Rendimiento

- p95 warm menor a 200 ms en la máquina objetivo.
- p95 cold menor a 400 ms.
- Cada detector posee timeout individual.

### Calidad

- Cero falsos negativos en el corpus golden congelado.
- La tasa de falsos positivos se reporta, no se oculta.
- El usuario no necesita desactivar el hook durante el piloto.
- Al menos un caso real o sembrado demuestra detección antes del check tradicional.

### Protocolo

- Un `error` nunca produce `pass`.
- La salida identifica su alcance.
- Los hallazgos incluyen regla, archivo, ubicación y reproducción.
- El event log permite reconstruir la trayectoria.

## Decisiones diferidas

### Lenguaje

Se decide mediante spike de cold start y parsing. No se fija por preferencia.

### Nombre de CLI

`oguard` es provisional. El nombre de producto es Objective Guard.

### Formato del contrato

YAML o JSON se decide al implementar la Fase 2; internamente habrá una representación validada por schema.

### Base de datos

SQLite es la opción inicial para evidencia; el MVP sólo necesita archivos de estado y JSONL.

### Severidad de `new-dep`

Comienza como warning. Requiere política local para bloquear.

### Activación de estadísticas

No se decide por calendario. Depende de calibración, generalización y ensayo de intervención.

### Integración con Orca

Diferida. El core define primero protocolos genéricos de subrondas y evidencia externa. Un futuro adaptador de Orca podrá correlacionar eventos Run, Task, Dispatch, worker, commit y finalización sin convertir a Orca en una dependencia de runtime de Objective Guard.