# REACH — invariantes acoplados y el Laplaciano de haces vectorial (EXPERIMENTAL)

Estado: **experimental** (`src/reach.rs`). **No toca M4** ni la API que Tawasuyu
consume. Este archivo es el veredicto honesto de si el haz aporta algo en el reach
multi-invariante — el sitio que Balegas (SRDS 2015) marca como no resuelto
("constraints over multiple counters... store them in a single object").

Fuimos "directo al Laplaciano de haces vectorial" a propósito, aceptando el riesgo
de repetir el patrón "el haz era la trampa". Aquí está lo que salió.

## Qué se construyó (y qué prueba cada test)

| Pieza | Qué es | Test |
|---|---|---|
| Certificado del politopo | escrow-por-restricción: `C·Σ b_v ≤ slack`, gasto `s_v ≤ b_v` ⟹ todas las restricciones aguantan (`C ≥ 0`) | `certificado_politopo` |
| Laplaciano de haces `L = δᵀδ` | stalks vectoriales `ℝ^{d_r}`; ker = totales conservados | `el_nucleo_son_los_totales_conservados` |
| Difusión vectorial | `x ← x − αLx`: conserva cada recurso, reduce la energía | `la_difusion_conserva_los_totales` |
| Colapso identidad | con restricciones `I`, `L` = `d_r` Laplacianos escalares | `identidad_colapsa_a_d_difusiones_escalares` |

## El veredicto (sin adornos)

**1. La corrección NO necesita haces.** El multi-invariante coordination-free se
resuelve con **escrow-por-restricción sobre el politopo**: presupuesto vectorial
por dispositivo, un gasto es local-seguro sii cabe en el presupuesto de *cada*
restricción que toca. El certificado (`C·consumed ≤ slack`) sale de que `C ≥ 0` y
`Σ gastos ≤ Σ presupuestos`. Es la extensión natural de T9–T11 a varios
contadores, y es **exactamente** el "razonar sobre todos juntos / un solo objeto"
que Balegas dice que hace falta. Real, usable, sobrio — y **prior-art conceptual**,
no novedad.

**2. El haz, con las restricciones que un presupuesto de verdad tiene (identidad),
NO aporta corrección ni nada nuevo.** El Laplaciano de haces del haz constante es
`Laplaciano_de_grafo ⊗ I`: difundir el presupuesto vectorial es, literalmente,
correr `d_r` veces el **router escalar de T9b** (`identidad_colapsa_...` lo prueba
entrada por entrada). El haz sólo se separaría del caso escalar con **restricciones
no triviales `R_e ≠ I`** — dispositivos que miden recursos acoplados en **bases
incompatibles**. Eso no es un requisito de ningún sistema de presupuestos real que
conozcamos; es una solución buscándose un problema.

**3. Lo único genuinamente bonito es una conexión, no una capacidad.** `ker L` =
secciones globales = los `d_r` totales conservados = el `H⁰` del MVP (§7.2). La
misma álgebra lineal que en el motor lineal era un **detector con falso-positivo**
aquí lee las **cantidades que la difusión conserva**. Es un cierre de arco elegante
y honesto — pero es interpretación, no un teorema nuevo.

## Consistente con todo el proyecto

El patrón se repite por última vez, y conviene nombrarlo: **cada vez que el haz fue
la protagonista, no fue lo que sostuvo la garantía.** La corrección vino del
politopo/escrow (T9–T11, prior-art bien hecho); el haz fue, en el mejor caso, una
lente o una comodidad de ruteo que colapsa al caso escalar. El reach multi-
invariante **no** cambia eso.

## Recomendación (para no ser contraproducente)

- **Si Tawasuyu necesita multi-invariante:** dale **escrow-por-restricción** (el
  certificado del politopo) y rutea con `d_r` routers escalares de T9b. **No** lo
  vendas ni lo cablees como "multi-invariante potenciado por haces": no lo es.
- **No promuevas `reach.rs` a la API estable** hasta que aparezca un caso real con
  coupling-en-bases-incompatibles que justifique el Laplaciano de haces sobre `d_r`
  difusiones escalares. Hasta entonces es más máquina de la que el problema pide.
- **Lo que sí es sólido y adoptable:** el `CoupledInvariants` + certificado del
  politopo. Eso extiende M4 a varios contadores de forma correcta y probada.

## Frontera abierta (donde NO llegamos, dicho)

- **Restricciones no monótonas (`C` con signos mixtos):** el certificado de escrow
  **no aplica** (consumir un recurso puede *liberar* slack de otra restricción). Es
  otro problema, probablemente necesita reservas de otro tipo; no está resuelto aquí.
- **Reparto óptimo del presupuesto vectorial:** el certificado aguanta cualquier
  reparto válido; cuál minimiza rebalanceos futuros es optimización sobre el
  politopo — ahí la difusión ayuda, pero es rendimiento, no corrección (R-T9a
  elevado a vectores).

**Conclusión de una línea:** el reach multi-invariante es real y lo resolvimos
—con escrow sobre el politopo, no con haces—; el Laplaciano de haces vectorial es
correcto pero, con restricciones identidad, no es más que el router escalar `d_r`
veces. Registrado como tal.