tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1457Shell 147Markdown 90Rust 853012 Definiciones

⎇ efe1dfcc4612fe975db5d9798a23a7a4ecb2eca2 docs/15-frontier-ai-native.md Markdown · 204 líneas · 13.9 KB Historia crudo

docs: SDD 15 §H2c — núcleo de confianza hecho (sellado + verificar-reproduciendo) efe1dfcc4 · sergio ·

1# SDD 15 — Frontera AI-nativa: código por contenido, evidencia sobre confianza, cómputo como dato
2
3> Estado: propuesta (2026-07-02). Nace de una revisión externa de las 4 piezas del stack
4> (wawa · hammer/BLAKE3 · wasm determinista · hifas) que propuso seis puentes. Tres caen del
5> lado de hammer/wawa y se recogen aquí; los otros tres (fuente monótona en el kernel,
6> fork-consistency, OS-como-CRDT) viven en `tawasuyu/03_ukupacha/PLAN-OS-CRDT.md`.
7>
8> **Este doc NO reemplaza nada cerrado.** Fases 0–6 + bootstrap Stage 0–2 + los 6 swaps
9> reproducibles siguen siendo la base (ver `docs/10-roadmap.md`). Esto es *frontera*: apuestas
10> ordenadas de "extensión natural de lo que ya hacemos" a "otro modelo de datos, design-doc".
11
12---
13
14## 0. El principio que ya tenemos y hay que empujar
15
16El modelo de confianza de hammer (SDD 09) es **"verificar, no confiar"**: el binario ajeno
17nunca viaja, viaja la receta, y `hammer apply` **reproduce y compara** el `expected_hash`. La
18integración de IA (SDD 08 §4) es exactamente la arquitectura de frontera correcta: *la IA
19propone `.swm`; el sistema reproduce; el humano hace commit; la IA nunca promueve sola.*
20
21La revisión externa nombra esto bien: **la frontera de confianza no está en quien genera sino
22en quien verifica.** Las tres ideas de abajo *empujan esa misma frontera* a territorio nuevo,
23sin moverla de sitio. Ninguna pide confiar más en el modelo; todas piden **verificar más**.
24
25Nota de higiene (de la propia revisión, adoptada): nada aquí es "matemáticamente invulnerable".
26Es "verificado bajo supuestos nombrados" — reproducibilidad bajo toolchain fijado, determinismo
27del sandbox, el checker es pequeño y auditable. seL4 se formula así; nosotros también.
28
29---
30
31## H1 — Proof-carrying recipes: de "reproduce" a "trae evidencia que pasa" (la idea 4)
32
33**Qué ya hacemos.** El bucle agéntico (SDD 08 §2) es PLAN → BUILD → TRY → **VERIFY** → PROPOSE
34→ humano. Hoy VERIFY = "corre el test harness, escucha `BUILD_FAILED`/`CRASHED`". La garantía
35dura es **reproducibilidad**: dos máquinas ⇒ mismo `artifact_hash`. Eso certifica *identidad*,
36no *comportamiento*.
37
38**El salto.** Que la IA entregue, junto al `.swm`, **evidencia de comportamiento**: property
39tests, contratos, y —cuando el crate lo permita— pruebas tipo Kani/Creusot. hammer admite la
40mutación sólo si un **checker pequeño y confiable** confirma que la evidencia pasa. Proof-carrying
41code (Necula 1997), pero **el generador es un modelo**: el sistema mejora solo sin poder
42corromperse solo, porque la confianza vive en el checker, no en el generador.
43
44**Por qué encaja aquí y no en otro lado.** hammer ya tiene el sandbox hermético (bwrap) donde
45correr esa evidencia de forma reproducible, ya tiene el `Orchestrator` con paso VERIFY, y ya
46tiene procedencia (`.hammer/recipe.toml` sellado en el artefacto). La atestación por-hash de
47arje (concesiones matcheadas por hash de binario; ver `tawasuyu` `arje/SDD`) es el mismo patrón
48del lado del init: **el permiso deriva de una propiedad verificada del artefacto, no de quién lo
49firmó.** H1 es esa idea, subida del boot al build.
50
51**Tickets:**
52- **H1a** ✅ — Extender el `.swm` (SDD 06) con un bloque `evidence`: lista de `{kind, cmd, expected}`
53  donde `kind ∈ {proptest, contract, kani, cmd-exit}`. Serialización YAML estable + `verify_schema`.
54- **H1b** ✅ — El checker: `hammer swm-verify --evidence` corre cada ítem **dentro del sandbox
55  reproducible** y exige `expected`. Pequeño y auditable a propósito (no un framework: un runner
56  de comandos con hash del output). Falla ⇒ no se propone. Reusa `Sandbox::run` + el `log_tail`
57  ya existente (Fase 5).
58- **H1c** ✅ — Cablear al `Orchestrator`: VERIFY consume `evidence`; el `Proposal` lleva el
59  **veredicto de evidencia** además del diff. El humano ve "reproduce + estas N pruebas pasan",
60  no sólo "reproduce". **Frontera:** el checker confía en que las pruebas *cubren* lo que
61  importa — eso lo juzga el humano; H1 garantiza que *lo declarado pasa*, no que *lo declarado
62  basta*. Se dice así.
63  **Implementación:** la evidencia corre del lado del BUILD (no del agente — `hammer-agent` no
64  depende de `hammer-build`, separación PROPONE/CONSTRUYE). `proto::RecipeInline` lleva `evidence`
65  y `Event::BuildReady` lleva `verdict: Option<EvidenceVerdict>`; `hammerd::bus` la ejecuta tras
66  sellar el artefacto (`run_evidence` vía `swm_bridge::recipe_from_source_patch`) y adjunta el
67  veredicto; el `Orchestrator` lee el veredicto y, si `all_passed=false`, empuja `VerifyCheck::fail`
68  y **aborta antes de hidratar** (el artefacto queda sellado pero no toca el sistema).
69
70**Frontera honesta.** Property tests no son prueba; Kani/Creusot sí pero sólo cubren crates que
71se dejan. H1 **estratifica** la confianza (`cmd-exit` < `proptest` < `contract` < `kani`) y la
72reporta; no finge que todo es prueba formal.
73
74---
75
76## H2 — Cómputo como dato: memoización de ejecución sobre wasm determinista (la idea 5)
77
78**La observación.** Si wawa ejecuta wasm **determinista**, entonces
79`blake3(módulo) + blake3(entrada) → blake3(salida)` es una **función pura**. Nix memoiza
80*builds* por hash de entrada; esto memoiza **ejecución en runtime**. La caché de resultados es
81content-addressed y **compartible por la malla** vía la capa CRDT de
82`tawasuyu/shared/crdt` (es un `GSet`/`LwwMap` de `(módulo,entrada) → salida`, monótono ⇒ viaja
83por anti-entropy sin coordinar).
84
85**Los tres regalos gratis** que la revisión nombra bien:
861. **Caché global de cómputo** — la malla comparte resultados; un cómputo caro se hace una vez.
872. **Replay perfecto** — depuración con viaje en el tiempo: un proceso *es* su módulo + su log
88   de entradas (gancho directo con el `MonotonicLog` de PLAN-OS-CRDT E1).
893. **Migración de procesos como transferencia de datos** — mover un proceso = copiar `(módulo,
90   log de entradas)` y re-ejecutar; el estado se reconstruye determinísticamente.
91
92**El gancho con hammer.** La caché es un **recurso acotado ruteable**: `hifas::router`
93(`BudgetRouter`) reparte "créditos de cómputo" por la malla (PLAN-OS-CRDT E3c). Y la
94verificación de un resultado memoizado es *reproducir la ejecución* — el mismo "verificar, no
95confiar" de SDD 09, ahora sobre runtime en vez de build.
96
97**Precondición dura (la apuesta).** Requiere **determinismo total de wasm en wawa**: sin
98`float` no determinista, sin fuentes de entropía ocultas, orden de scheduling irrelevante para
99la salida. `wasmi` es determinista para el core, pero hay que **auditar y sellar** que ninguna
100capacidad expuesta (tiempo, random, I/O) filtre no-determinismo a la salida hasheada. Eso es un
101spike de wawa, no de hammer.
102
103**Tickets (spike, no fase):**
104- **H2a** ✅ — Auditar determinismo del runtime wasm de wawa: enumerar toda fuente de no-determinismo
105  alcanzable por una app (`wawa-kernel/src/wasm/`), y definir el subconjunto "puro" (módulo +
106  entrada explícita, sin syscalls no deterministas). Salida: un doc `wawa/SDD` §determinismo con
107  el veredicto honesto (qué es puro, qué no).
108  **Hecho (2026-07-03):** `tawasuyu/03_ukupacha/wawa/SDD-determinismo.md`. Veredicto: el subconjunto
109  puro **ya existe** en el código (`ejecutar_dinamico`/`_v2`, `wasm/mod.rs:335,430` — linker VACÍO +
110  reloj virtual + fuel/memoria fijos + wasmi 1.0 sin simd). H2a no era construirlo sino **sellarlo**:
111  contrato de clave `blake3(módulo)⊕blake3(entrada)⊕E` con `E` = hash-de-entorno (pin wasmi/features/
112  fuel/mem/ABI); único vector residual acotado = payload de NaN vía `reinterpret` (sólo cross-build,
113  irrelevante para H2b local). La superficie de capacidades (`env/*.rs`) reintroduce no-determinismo
114  o efectos ⇒ NO memoizable; sólo la vía linker-vacío lo es.
115- **H2b** ✅ — Prototipo de `blake3(módulo)+blake3(entrada) → blake3(salida)` como caché local
116  (un `LwwMap` de `shared/crdt`), sin malla todavía. Test: misma entrada ⇒ hit; recompute ⇒
117  byte-idéntico (o el determinismo está roto y H2a mintió).
118  **Hecho (2026-07-03):** crate `tawasuyu/03_ukupacha/wawa/wawa-memo` (host/std, standalone).
119  Reproduce fiel la vía pura del kernel (`ejecutar_dinamico_v2`: linker vacío + fuel 500k + 1 MiB
120  + wasmi sin simd + despacho polimórfico) y monta la clave del contrato §4 (`blake3(bytecode) ‖
121  blake3(entrada_le) ‖ E`, con `E` = hash de entorno que pinnea wasmi/features/fuel/mem/abi). El
122  test de §5 **da verde**: 9 módulos × 8 entradas ejecutados dos veces ⇒ `blake3(salida)`
123  byte-idéntico (H2a no mintió); Miss→Hit sirve valor idéntico al recomputado; las fallas
124  (`Trampa`/`SinCombustible`/`Carga`) se cachean (§4 regla 4); `E` distinta ⇒ clave distinta (§4
125  regla 2); y dos réplicas convergen al fundir el `LwwMap` (anti-entropy, preview de H2c). Como la
126  clave es content-addressed y la función pura, el LWW nunca tiene conflicto real ⇒ el mapa es
127  monótono y compartible sin coordinar. **Verde ⇒ H2c desbloqueado** (compartir por la malla).
128- **H2c** — (si H2b pasa) compartir la caché por la malla minga/agora. Frontera: envenenamiento
129  de caché por un peer ⇒ se **verifica reproduciendo** en el primer uso dudoso (no se confía en
130  el resultado ajeno; se confía en poder recomputarlo). Es el modelo de confianza de SDD 09
131  aplicado a runtime.
132  **Núcleo de confianza hecho (2026-07-03, en `wawa-memo`):** dos piezas que hacen *seguro* el
133  compartir, independientes del transporte. (1) **Sellado de portabilidad** (`sellado.rs`, §4
134  regla 3a): un escáner conservador del bytecode clasifica cada módulo `Portable` (enteros puros
135  ⇒ sin vector NaN ⇒ idéntico cross-arch) o `SoloLocal` (toca floats / no decodifica). Decodifica
136  los inmediatos correctamente (no confunde un `i32.const 0xBC` con el opcode `reinterpret_f32`).
137  (2) **Modelo de confianza** (`malla.rs`): `ingerir_ajeno` **verifica reproduciendo** una entrada
138  ofrecida por un peer y **rechaza** la envenenada (afirmar `Ok(99)` donde `cuadrado(6)=36`, o `Ok`
139  donde hay `Trampa`) — nunca entra a la caché local; el valor correcto sigue recomputable. Política
140  `ConfiarSiPortable` = optimización que confía sin recomputar sólo módulos `Portable` (descarta el
141  vector NaN, no la deshonestidad del peer — dicho explícito). **Diferido (es del otro agente):** el
142  transporte real (anti-entropy sobre minga/agora) vive en `PLAN-OS-CRDT.md` (E3). Tests: `h2c.rs`.
143
144**Frontera honesta.** Sin determinismo total (H2a), H2 no existe — es la apuesta. No prometer
145la caché de malla antes de que H2a dé verde. Y "cómputo puro" excluye lo interesante-con-I/O:
146la memoización cubre la parte funcional, no el proceso entero con efectos.
147
148---
149
150## H3 — Código direccionado por contenido estilo Unison (la idea 3) — DESIGN-DOC, no sprint
151
152**La visión.** Hoy hammer direcciona por hash el **artefacto** (binario) y la **receta**. wawa
153direcciona el **módulo wasm** y el **almacenamiento**. La idea 3 empuja al límite: direccionar
154**funciones por el hash de su AST** (Unison). La IA no editaría archivos —insertaría
155definiciones en una base content-addressed donde **nada se rompe por renombrar o actualizar**—
156y el store de hammer, los módulos wasm de wawa y el código fuente **colapsarían en un solo
157espacio de nombres: el hash**. Paquete, función y proceso = el mismo tipo de objeto.
158
159**Por qué es design-doc y no ticket.** Es **otro modelo de datos**, no una extensión. hammer y
160Unison content-addressan *cosas distintas*: hammer el artefacto compilado (grano grueso,
161lenguaje-agnóstico, encaja con "recetas sobre fuente upstream"); Unison el AST de cada función
162(grano fino, requiere un lenguaje y toolchain propios). Colapsarlos pide reescribir la unidad de
163compilación entera. El valor es real (fin del dependency-hell para la IA) pero el costo es un
164proyecto, no una fase.
165
166**Qué SÍ hacer ahora (el puente barato hacia la visión):**
167- **H3a** ✅ — Doc de diseño `docs/adr/0009-content-addressed-code.md` (2026-07-03): registra la
168  visión Unison y decide **no reescribir la unidad de compilación**. Puente barato = procedencia
169  por-símbolo como **metadata** (extender `parse_elf_needed`, `query.rs:298`, para emitir exports de
170  `.dynsym` además de `DT_NEEDED`), fuera de `hash_inputs` (misma disciplina que la evidencia de H1).
171  El grano fino real (función-por-hash) se difiere a H3b sobre **wasm**, gateado por H2.
172- **H3b** — (exploratorio, opcional) Un experimento aislado: una base content-addressed de
173  funciones **wasm** (grano: un `.wasm` por función pura de H2), viendo si el modelo "insertar
174  definición, nunca romper" se sostiene sobre el runtime de wawa. Es el subconjunto de Unison
175  que nuestro stack *ya* podría soportar (wasm + BLAKE3 + determinismo H2), sin un lenguaje nuevo.
176
177**Frontera honesta.** No prometer "una distro donde paquete = función = proceso" hasta que H3b
178demuestre que el grano fino se sostiene sobre wasm. Es la idea más disruptiva y la menos madura;
179tratarla como tal.
180
181---
182
183## Orden y dependencias
184
185```
186H1 (proof-carrying)  ── extensión natural del VERIFY actual ──► arrancable ya, alto valor
187H2a (auditar determinismo wasm)  ──► gate de todo H2 (spike wawa)
188   └► H2b (caché local) ──► H2c (caché de malla)  [sólo si H2a da verde]
189H3a (design-doc)  ──► registrar la visión, barato
190   └► H3b (experimento wasm-por-función)  [depende de H2 puro]
191```
192
193Recomendación: **H1 primero** (empuja la frontera que ya tenemos, sin apuestas). **H2a** en
194paralelo como spike de wawa (decide si H2/H3b existen). **H3a** cuando haya un rato: es escribir,
195no construir. H2c y H3b son futuro condicionado a verdes previos.
196
197## Qué NO promete este doc
198
199- **No mueve la frontera de confianza.** Sigue en el verificador (checker H1, reproducción H2c);
200  la IA nunca se auto-promueve — SDD 08 §4 intacto.
201- **No reclama verificación formal del sistema.** H1 estratifica evidencia y la reporta;
202  "verificado bajo supuestos", no "invulnerable".
203- **No promete memoización de malla sin determinismo probado** (H2a es el gate).
204- **No promete el colapso Unison** hasta que H3b lo demuestre sobre wasm. Design-doc primero.

15-frontier-ai-native.md

SDD 15 — Frontera AI-nativa: código por contenido, evidencia sobre confianza, cómputo como dato

Estado: propuesta (2026-07-02). Nace de una revisión externa de las 4 piezas del stack (wawa · hammer/BLAKE3 · wasm determinista · hifas) que propuso seis puentes. Tres caen del lado de hammer/wawa y se recogen aquí; los otros tres (fuente monótona en el kernel, fork-consistency, OS-como-CRDT) viven en tawasuyu/03_ukupacha/PLAN-OS-CRDT.md.

Este doc NO reemplaza nada cerrado. Fases 0–6 + bootstrap Stage 0–2 + los 6 swaps reproducibles siguen siendo la base (ver docs/10-roadmap.md). Esto es frontera: apuestas ordenadas de "extensión natural de lo que ya hacemos" a "otro modelo de datos, design-doc".


0. El principio que ya tenemos y hay que empujar

El modelo de confianza de hammer (SDD 09) es "verificar, no confiar": el binario ajeno nunca viaja, viaja la receta, y hammer apply reproduce y compara el expected_hash. La integración de IA (SDD 08 §4) es exactamente la arquitectura de frontera correcta: la IA propone .swm; el sistema reproduce; el humano hace commit; la IA nunca promueve sola.

La revisión externa nombra esto bien: la frontera de confianza no está en quien genera sino en quien verifica. Las tres ideas de abajo empujan esa misma frontera a territorio nuevo, sin moverla de sitio. Ninguna pide confiar más en el modelo; todas piden verificar más.

Nota de higiene (de la propia revisión, adoptada): nada aquí es "matemáticamente invulnerable". Es "verificado bajo supuestos nombrados" — reproducibilidad bajo toolchain fijado, determinismo del sandbox, el checker es pequeño y auditable. seL4 se formula así; nosotros también.


H1 — Proof-carrying recipes: de "reproduce" a "trae evidencia que pasa" (la idea 4)

Qué ya hacemos. El bucle agéntico (SDD 08 §2) es PLAN → BUILD → TRY → VERIFY → PROPOSE → humano. Hoy VERIFY = "corre el test harness, escucha BUILD_FAILED/CRASHED". La garantía dura es reproducibilidad: dos máquinas ⇒ mismo artifact_hash. Eso certifica identidad, no comportamiento.

El salto. Que la IA entregue, junto al .swm, evidencia de comportamiento: property tests, contratos, y —cuando el crate lo permita— pruebas tipo Kani/Creusot. hammer admite la mutación sólo si un checker pequeño y confiable confirma que la evidencia pasa. Proof-carrying code (Necula 1997), pero el generador es un modelo: el sistema mejora solo sin poder corromperse solo, porque la confianza vive en el checker, no en el generador.

Por qué encaja aquí y no en otro lado. hammer ya tiene el sandbox hermético (bwrap) donde correr esa evidencia de forma reproducible, ya tiene el Orchestrator con paso VERIFY, y ya tiene procedencia (.hammer/recipe.toml sellado en el artefacto). La atestación por-hash de arje (concesiones matcheadas por hash de binario; ver tawasuyu arje/SDD) es el mismo patrón del lado del init: el permiso deriva de una propiedad verificada del artefacto, no de quién lo firmó. H1 es esa idea, subida del boot al build.

Tickets:

Frontera honesta. Property tests no son prueba; Kani/Creusot sí pero sólo cubren crates que se dejan. H1 estratifica la confianza (cmd-exit < proptest < contract < kani) y la reporta; no finge que todo es prueba formal.


H2 — Cómputo como dato: memoización de ejecución sobre wasm determinista (la idea 5)

La observación. Si wawa ejecuta wasm determinista, entonces blake3(módulo) + blake3(entrada) → blake3(salida) es una función pura. Nix memoiza builds por hash de entrada; esto memoiza ejecución en runtime. La caché de resultados es content-addressed y compartible por la malla vía la capa CRDT de tawasuyu/shared/crdt (es un GSet/LwwMap de (módulo,entrada) → salida, monótono ⇒ viaja por anti-entropy sin coordinar).

Los tres regalos gratis que la revisión nombra bien:

  1. Caché global de cómputo — la malla comparte resultados; un cómputo caro se hace una vez.
  2. Replay perfecto — depuración con viaje en el tiempo: un proceso es su módulo + su log de entradas (gancho directo con el MonotonicLog de PLAN-OS-CRDT E1).
  3. Migración de procesos como transferencia de datos — mover un proceso = copiar (módulo, log de entradas) y re-ejecutar; el estado se reconstruye determinísticamente.

El gancho con hammer. La caché es un recurso acotado ruteable: hifas::router (BudgetRouter) reparte "créditos de cómputo" por la malla (PLAN-OS-CRDT E3c). Y la verificación de un resultado memoizado es reproducir la ejecución — el mismo "verificar, no confiar" de SDD 09, ahora sobre runtime en vez de build.

Precondición dura (la apuesta). Requiere determinismo total de wasm en wawa: sin float no determinista, sin fuentes de entropía ocultas, orden de scheduling irrelevante para la salida. wasmi es determinista para el core, pero hay que auditar y sellar que ninguna capacidad expuesta (tiempo, random, I/O) filtre no-determinismo a la salida hasheada. Eso es un spike de wawa, no de hammer.

Tickets (spike, no fase):

Frontera honesta. Sin determinismo total (H2a), H2 no existe — es la apuesta. No prometer la caché de malla antes de que H2a dé verde. Y "cómputo puro" excluye lo interesante-con-I/O: la memoización cubre la parte funcional, no el proceso entero con efectos.


H3 — Código direccionado por contenido estilo Unison (la idea 3) — DESIGN-DOC, no sprint

La visión. Hoy hammer direcciona por hash el artefacto (binario) y la receta. wawa direcciona el módulo wasm y el almacenamiento. La idea 3 empuja al límite: direccionar funciones por el hash de su AST (Unison). La IA no editaría archivos —insertaría definiciones en una base content-addressed donde nada se rompe por renombrar o actualizar— y el store de hammer, los módulos wasm de wawa y el código fuente colapsarían en un solo espacio de nombres: el hash. Paquete, función y proceso = el mismo tipo de objeto.

Por qué es design-doc y no ticket. Es otro modelo de datos, no una extensión. hammer y Unison content-addressan cosas distintas: hammer el artefacto compilado (grano grueso, lenguaje-agnóstico, encaja con "recetas sobre fuente upstream"); Unison el AST de cada función (grano fino, requiere un lenguaje y toolchain propios). Colapsarlos pide reescribir la unidad de compilación entera. El valor es real (fin del dependency-hell para la IA) pero el costo es un proyecto, no una fase.

Qué SÍ hacer ahora (el puente barato hacia la visión):

Frontera honesta. No prometer "una distro donde paquete = función = proceso" hasta que H3b demuestre que el grano fino se sostiene sobre wasm. Es la idea más disruptiva y la menos madura; tratarla como tal.


Orden y dependencias

H1 (proof-carrying)  ── extensión natural del VERIFY actual ──► arrancable ya, alto valor
H2a (auditar determinismo wasm)  ──► gate de todo H2 (spike wawa)
   └► H2b (caché local) ──► H2c (caché de malla)  [sólo si H2a da verde]
H3a (design-doc)  ──► registrar la visión, barato
   └► H3b (experimento wasm-por-función)  [depende de H2 puro]

Recomendación: H1 primero (empuja la frontera que ya tenemos, sin apuestas). H2a en paralelo como spike de wawa (decide si H2/H3b existen). H3a cuando haya un rato: es escribir, no construir. H2c y H3b son futuro condicionado a verdes previos.

Qué NO promete este doc