GT-605: la tabla de aristas de evidencia, y con ella la pregunta que el gap no podía responder

[beyondnetPeru]

Segunda pieza del cluster de evidencia. Construye la mitad persistente contra el contrato que #89 dejó pineado.

Qué faltaba

Existían dos grafos de evidencia, cada uno sin la mitad del otro: el Core declaraba aristas tipadas que nada persistía, y este repositorio persistía References como List<string> en jsonb cuyo único lector no-test era un Contains() lineal — sin tabla, sin tipo, sin búsqueda inversa y sin cota de profundidad.

Consecuencia: «qué ADR se movió por causa de qué decisión de compuerta por causa de qué turno de agente» no tenía respuesta. Ahora la tiene, y hay un test que la escribe.

Qué aterriza

• El modelo tipado en dominio — EvidenceNodeRef con su forma canónica evidence://<kind>/<id>, EvidenceEdge, y el vocabulario cerrado de nodos y aristas, espejo de evidence-edge.schema.json. Lo que impide que el espejo derive no es la disciplina de quien lo edita: si el Core cambia el vocabulario cambia el sha256, y conform se pone rojo antes de que nadie pueda fusionar.
• La tabla evidence_edges con las diez columnas y los tres índices que EVIDENCE_EDGE_STORAGE_CONTRACT fija, generada con dotnet ef y no a mano. idx_evidence_edges_to es el que hace posible la búsqueda inversa.
• La travesía acotada, espejo de traverseEvidenceGraph().
• El backfill desde references.

Dos decisiones que el diff no explica solo

El repositorio devuelve aristas, no nodos. Podría recorrer el grafo en SQL y devolver el resultado, pero entonces habría dos semánticas de travesía —una en SQL, otra en el contrato— sin nada que garantice que coinciden. Devolviendo aristas, la respuesta la produce la misma función que los tests comparan con el contrato. Es exactamente el fallo que este gap cierra, así que repetirlo aquí sería irónico.

La cota de profundidad no es una optimización, es la corrección. El ledger es append-only y una travesía sin límite es trabajo sin límite sobre una tabla que sólo crece. Pedir más que el techo devuelve el máximo y no un error: el límite protege a la base de datos, no al llamante.

Verificación — el backfill se ejecutó de verdad

Es SQL crudo con regex, y en CI correría sobre una tabla vacía: habría pasado en verde sin probar nada. Así que se levantó un Postgres 16 en Docker y se sembró con las seis formas que importan. De 6 referencias produjo exactamente las 3 correctas:

Referencia sembrada	¿Arista?	Por qué
evidence://adr/ADR-0101	sí	canónica, vocabulario válido
evidence://gate-decision/gate-7	sí	idem
evidence://artifact/src/apps/foo.ts	sí	y el id sobrevive entero, no se trocea por la segunda barra
EXT-999	no	id externo opaco — verificado que sigue en References
evidence://inventado/x	no	el vocabulario es cerrado
evidence://evidence-record/<su propio id>	no	autolazo

Re-ejecutado: INSERT 0 0. Idempotente por el índice de identidad.

Además: has-pending-model-changes confirma modelo y snapshot consistentes; 28 tests de dominio, 5 de persistencia contra la base real, y la suite completa en 1144/1144 con cero fallos — la primera vez en esta línea, porque los 10 que fallaban dependían de Postgres.

Fuera de alcance

El endpoint GET /initiatives/{id}/evidence-graph va en un PR aparte.

🤖 Generated with Claude Code