hifas/REACH.md

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.