1# REACH — invariantes acoplados y el Laplaciano de haces vectorial (EXPERIMENTAL)
2
3Estado: **experimental** (`src/reach.rs`). **No toca M4** ni la API que Tawasuyu
4consume. Este archivo es el veredicto honesto de si el haz aporta algo en el reach
5multi-invariante — el sitio que Balegas (SRDS 2015) marca como no resuelto
6("constraints over multiple counters... store them in a single object").
7
8Fuimos "directo al Laplaciano de haces vectorial" a propósito, aceptando el riesgo
9de repetir el patrón "el haz era la trampa". Aquí está lo que salió.
10
11## Qué se construyó (y qué prueba cada test)
12
13| Pieza | Qué es | Test |
14|---|---|---|
15| Certificado del politopo | escrow-por-restricción: `C·Σ b_v ≤ slack`, gasto `s_v ≤ b_v` ⟹ todas las restricciones aguantan (`C ≥ 0`) | `certificado_politopo` |
16| Laplaciano de haces `L = δᵀδ` | stalks vectoriales `ℝ^{d_r}`; ker = totales conservados | `el_nucleo_son_los_totales_conservados` |
17| Difusión vectorial | `x ← x − αLx`: conserva cada recurso, reduce la energía | `la_difusion_conserva_los_totales` |
18| Colapso identidad | con restricciones `I`, `L` = `d_r` Laplacianos escalares | `identidad_colapsa_a_d_difusiones_escalares` |
19
20## El veredicto (sin adornos)
21
22**1. La corrección NO necesita haces.** El multi-invariante coordination-free se
23resuelve con **escrow-por-restricción sobre el politopo**: presupuesto vectorial
24por dispositivo, un gasto es local-seguro sii cabe en el presupuesto de *cada*
25restricción que toca. El certificado (`C·consumed ≤ slack`) sale de que `C ≥ 0` y
26`Σ gastos ≤ Σ presupuestos`. Es la extensión natural de T9–T11 a varios
27contadores, y es **exactamente** el "razonar sobre todos juntos / un solo objeto"
28que Balegas dice que hace falta. Real, usable, sobrio — y **prior-art conceptual**,
29no novedad.
30
31**2. El haz, con las restricciones que un presupuesto de verdad tiene (identidad),
32NO aporta corrección ni nada nuevo.** El Laplaciano de haces del haz constante es
33`Laplaciano_de_grafo ⊗ I`: difundir el presupuesto vectorial es, literalmente,
34correr `d_r` veces el **router escalar de T9b** (`identidad_colapsa_...` lo prueba
35entrada por entrada). El haz sólo se separaría del caso escalar con **restricciones
36no triviales `R_e ≠ I`** — dispositivos que miden recursos acoplados en **bases
37incompatibles**. Eso no es un requisito de ningún sistema de presupuestos real que
38conozcamos; es una solución buscándose un problema.
39
40**3. Lo único genuinamente bonito es una conexión, no una capacidad.** `ker L` =
41secciones globales = los `d_r` totales conservados = el `H⁰` del MVP (§7.2). La
42misma álgebra lineal que en el motor lineal era un **detector con falso-positivo**
43aquí lee las **cantidades que la difusión conserva**. Es un cierre de arco elegante
44y honesto — pero es interpretación, no un teorema nuevo.
45
46## Consistente con todo el proyecto
47
48El patrón se repite por última vez, y conviene nombrarlo: **cada vez que el haz fue
49la protagonista, no fue lo que sostuvo la garantía.** La corrección vino del
50politopo/escrow (T9–T11, prior-art bien hecho); el haz fue, en el mejor caso, una
51lente o una comodidad de ruteo que colapsa al caso escalar. El reach multi-
52invariante **no** cambia eso.
53
54## Recomendación (para no ser contraproducente)
55
56- **Si Tawasuyu necesita multi-invariante:** dale **escrow-por-restricción** (el
57  certificado del politopo) y rutea con `d_r` routers escalares de T9b. **No** lo
58  vendas ni lo cablees como "multi-invariante potenciado por haces": no lo es.
59- **No promuevas `reach.rs` a la API estable** hasta que aparezca un caso real con
60  coupling-en-bases-incompatibles que justifique el Laplaciano de haces sobre `d_r`
61  difusiones escalares. Hasta entonces es más máquina de la que el problema pide.
62- **Lo que sí es sólido y adoptable:** el `CoupledInvariants` + certificado del
63  politopo. Eso extiende M4 a varios contadores de forma correcta y probada.
64
65## Frontera abierta (donde NO llegamos, dicho)
66
67- **Restricciones no monótonas (`C` con signos mixtos):** el certificado de escrow
68  **no aplica** (consumir un recurso puede *liberar* slack de otra restricción). Es
69  otro problema, probablemente necesita reservas de otro tipo; no está resuelto aquí.
70- **Reparto óptimo del presupuesto vectorial:** el certificado aguanta cualquier
71  reparto válido; cuál minimiza rebalanceos futuros es optimización sobre el
72  politopo — ahí la difusión ayuda, pero es rendimiento, no corrección (R-T9a
73  elevado a vectores).
74
75**Conclusión de una línea:** el reach multi-invariante es real y lo resolvimos
76—con escrow sobre el politopo, no con haces—; el Laplaciano de haces vectorial es
77correcto pero, con restricciones identidad, no es más que el router escalar `d_r`
78veces. Registrado como tal.