Files
SergioandClaude Opus 4.8 9de0cc601f reach: multi-invariante + Laplaciano de haces vectorial (experimental, no toca M4)
Exploración del reach que Balegas marca no resuelto (constraints over multiple
counters), en módulo aislado, sin tocar la API que Tawasuyu consume.

- reach::CoupledInvariants (politopo C·x ≤ slack, C ≥ 0) + VectorBudget:
  escrow-por-restricción. certificado_politopo (proptest): reparto válido +
  gastos ≤ presupuesto ⟹ todas las restricciones aguantan. La corrección.
- reach::{coboundary, sheaf_laplacian, SheafRouter}: el Laplaciano de haces
  vectorial (L=δᵀδ) reusando nalgebra y la idea del coboundary del MVP.
  diffuse conserva cada recurso y reduce la energía; ker L = totales
  conservados = el H⁰ del MVP.

VEREDICTO HONESTO (REACH.md): la corrección es escrow sobre el politopo, NO
necesita haces. Con restricciones identidad (lo que un presupuesto real tiene),
el Laplaciano de haces colapsa a d_r Laplacianos escalares = el router de T9b
d_r veces (test identidad_colapsa_...). El haz sólo importaría con coupling en
bases incompatibles, que no es requisito real. Consistente con todo el arco: el
haz nunca fue lo que sostuvo la garantía. Recomendación: si Tawasuyu necesita
multi-invariante, usar el certificado del politopo + routers escalares; NO
promover reach.rs a estable ni venderlo como 'potenciado por haces'. Frontera
abierta dicha: restricciones no monótonas (C con signos mixtos) no cubiertas.

85 tests, clippy limpio.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-02 00:29:26 +00:00

79 lines
4.7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 T9T11 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 (T9T11, 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.