# Evidencia de lo terminado

Un archivo por tarea cerrada, con el slug de la tarea como nombre: `alta-de-cliente.md` es lo que esa
tarea entregó y con qué se comprueba.

```markdown
- [x] **alta-de-cliente** (epic: 001) — Alta de cliente
  acept: el alta rechaza un duplicado
  fecha: 2026-09-08
  done: cambios y comandos de verificación con exit codes
  qa: comportamiento observado por el camino real
  tests: C1 → api/alta_test.go › «TestAltaDuplicada» — rechaza el segundo; C2 → nombre de prueba o comando
  decisions: decisión no obvia [fuente: ruta/archivo] o [supuesto: motivo verificable]
  commit: abc1234 feat(scope): subject (repo@branch)
  lane: full
  review: aprobado por tech-lead, sobre api/alta.go
  critique: cambió el plan por: comprobar también el texto exacto del error
```

El contrato completo de esos campos está en `../PROTOCOL.md`; acá va por qué el archivo es uno por tarea.

En `tests:`, una prueba se nombra por su archivo y su nombre, como en `C1`: el archivo, ` › `, el nombre
entre `«»` tal como está escrito en el archivo, y después de ` — ` lo que haga falta aclarar. Con esa forma
`ops evidence` la va a buscar sin adivinar dónde termina el nombre. Lo que no es una prueba en un archivo
—un comando, una comprobación a mano— va en prosa, como en `C2`.

## Por qué uno por tarea

Cerrar es lo que más se hace, y mientras la evidencia se acumulaba en un archivo compartido, cerrar era
agregarle una entrada a algo que otro también estaba tocando. Con un archivo por tarea, **dos personas
—o dos agentes— que cierran a la vez escriben archivos distintos**: no hay conflicto que resolver ni
regla de merge que aplicar.

El nombre del archivo es una conveniencia; lo que identifica la tarea es el slug de la viñeta. Renombrar
el archivo no cambia de qué tarea habla, y cerrar dos veces la misma sigue siendo un error que `check`
rechaza, ahora entre archivos.

## Por qué el carril

El carril decide qué fases corre una tarea: `express` se saltea Ready, Plan y QA; `full` las corre
todas. Ese dato vive en la línea del BACKLOG, y la línea **se borra al cerrar** — así que la pregunta
«¿esta tarea recibió la ceremonia que su superficie pedía?» dejaba de tener dónde contestarse, y quedaba
en la memoria de quien estuvo en la sesión. `lane:` la devuelve al registro.

Se escribe aunque sea `sin clasificar`, que es distinto de no escribirlo: uno dice que la tarea corrió
sin carril declarado y el otro, que nadie llenó el campo.

## Por qué la revisión

El carril dice cuánta ceremonia **merecía** la tarea; `review:` dice cuánta **recibió**. Con los dos, la
pregunta que OPS-006 dejó pendiente —«¿el carril elegido fue el correcto?»— se contesta desde el registro
en vez de desde la memoria de la sesión.

`express` y `manual` son los únicos que no convocan revisor —`manual` ni siquiera corre el recorrido: la
cierra la sesión—, así que ahí `n/a — razón` es lo correcto. En
`directo`, `lite` y `full` una revisión que no corrió es la ADR incumplida, y `check` lo avisa nombrando
la tarea. Avisa y no falla: es un hecho del pasado que no se arregla editando la entrada, y el único
camino al verde sería reescribir el registro.

## Por qué la crítica

La crítica del plan es la fase que más fácil se saltea sin que nada lo muestre: no toca código ni deja un
commit. Escrita junto con el plan en un mismo paso, dos de tres runners sin recorrido la leyeron como una sola
fase y no criticaron (caso 433). `critique:` guarda lo que objetó la crítica —al menos la objeción más fuerte— y
qué cambió en el plan por eso. En una tarea `full`, `check` lo exige desde la primera entrada de la instancia que lo
trae: la cerrada después sin el campo, o con `n/a`, se nombra; la de antes se cuenta, como un campo nuevo, porque
no tenía dónde escribirla. No hay una fecha fija porque cada instancia recibe el campo cuando actualiza, y eso no
queda escrito en ningún lado salvo en su propio registro. Lo escribe el mismo agente que criticó, así que atrapa la
crítica que falta y no la que se dice hecha sin hacerla. Para eso está Review, que comprueba sobre el diff lo que la
crítica dice que cambió en el plan (caso 436). Que la objeción haya sido la que más importaba lo sigue juzgando una
persona.

## Por qué la fecha

Mientras las entradas vivían en un archivo, «la última» era la última del archivo. Con archivos sueltos
el orden lo daría el listado del directorio, que es alfabético: la respuesta equivocada se leería igual
de bien que la correcta. Por eso `fecha:` es la del cierre y es obligatoria — y por eso `ops evidence`
sin `--task` puede contestar por la más reciente.

## Qué más vive acá

`human-actions.md`, con las filas resueltas que `ops archive human-actions` mueve desde
`../HUMAN_ACTIONS.md`. Es una tabla y no una entrada, así que el lector no la confunde con una tarea —
igual que a este README—.