takana/docs/17-cierres-frontera.md

SDD 17 — Cierres de frontera priorizados × cruce tawasuyu

Análisis 2026-07-15. Origen: la jaula (SDD 16) y la capa CRDT (SDD 15 H2) cayeron "de casualidad" — eran básicas y no estaban en el plan. Este doc responde: ¿qué otros cierres, tecnologías de frontera o complementos dan ventaja competitiva, y qué crate o arquitectura de ../tawasuyu los abarata? Es, en la práctica, la "parte 2" de tawasuyu/shared/PLAN-CRUCES.md (que no menciona a hammer ni una vez).

0. Tesis

Los tres invariantes ya pagados — bit-reproducibilidad (SDD 11/13), direccionamiento por contenido (SDD 06) y clausura-como-política (SDD 16) — hacen casi gratis para hammer tecnologías que para todos los demás son carísimas. La búsqueda correcta no es "qué frontera agregar" sino "qué cae solo del invariante", igual que la jaula cayó del sandbox y el CRDT cayó de H2.

Rieles ya cableados entre repos (doc maestro: tawasuyu/03_ukupacha/arje/PLAN-ATESTACION-Y-HAMMER.md): bus arje↔hammerd con contrato wire por bytes, CAS BLAKE3 b3: compartido, boot-graph (ADR 0010), arje-absorb --attest-from, BuildSys::Cargo.

Crates de tawasuyu/shared/ limpios para importar (no_std o casi, deps mínimas): fork-proof, reconcile, dataflow, umbral, grafo-nav, format, crdt.

1. Los diez cierres, en orden de prioridad

1. Consenso de reconstrucción — caché sin confianza

N builders independientes reproducen el mismo hash ⇒ el binario es confiable sin que nadie firme nada. Piezas hammer listas: bit-repro verificada (selfhost, kernel), granja efímera, embrión del log de transparencia (bootstrap.json, SDD 11 §4 / SDD 09 §4). Nix/Debian no pueden ofrecerlo (repro incompleta). Convierte la repro de QA en primitiva de distribución: cualquiera puede ser mirror, nadie puede envenenar el repo.

Cruce: fork-proof (log firmado hash-encadenado BLAKE3+Ed25519, no_std, con detectar_fork = detección de equivocation no repudiable — el log de transparencia ya está escrito y testeado, no hay que construir un rekor) · umbral (quórum M-de-N de builders, agnóstico del backend cripto) · card-net (DhtKey = kind_tag ++ blake3, el mismo hash que b3: — distribución de artefactos por hash en la malla) · reconcile (sync de índices de mirrors en O(diferencia)). Economía del reparto: sheafsync::BudgetRouter

• escrow (créditos de cómputo; el gancho a H2 ya está previsto en PLAN-OS-CRDT §E3c).

2. hammer why-differs — diffoscope propio

Cuando un hash no reproduce, explicar por qué (sección, timestamp, orden de símbolos). Multiplicador doble: hace escalar el barrido de granja (hoy debuggear una no-reproducción es artesanal) y produce evidencia legible por máquina para el bucle agéntico.

Cruce: format (grafo blob+árbol BLAKE3 no_std: dos árboles idénticos colapsan al mismo hash ⇒ el diff estructural = descender sólo donde difiere) · reconcile (ese descenso ES su algoritmo, huellas por rango) · foreign-fs (chunking content-defined de 256 KiB bit-reproducible) · grafo-nav (verbo "bifurcación" para pintarlo).

3. Política de runtime derivada del closure

Fase 3 natural de harkaq: la clausura de ficheros medida en build ES la política Landlock del binario instalado. AppArmor/flatpak escriben políticas a mano; hammer las deriva. Nadie tiene esto y la receta sellada ya contiene la evidencia.

Cruce (oro, el riel existe): ConcesionCapacidad firmada sobre (blake3(binario), permisos) que arje verifica al arranque + arje-absorb --attest-from <json> que integra concesiones emitidas por hammer (PLAN-ATESTACION §B.3, hecho). La clausura de harkaq son los permisos de esa concesión — el veredicto Hermetico se convierte en política atestada sin inventar formato. Filosofía de referencia: el modelo wawa "capacidad = frontera física, no tabla de permisos" (WAWA.md §4.2). Lado runtime: pacha-core / sandokan-lifecycle.

4. CVE por grafo

hammer affected CVE-X exacto (grafo fuente→artefacto→instalado) + frontera mínima de rebuild + hydrate para repartir el parche rebuild-free. Donde Debian/Alpine aproximan por nombre-versión, hammer responde exacto. Tabla de mesa para adopción seria.

Cruce: dataflow (DepGraph<K> no_std: dirty_cone = literalmente la frontera mínima de rebuild; topo_order = la agenda determinista) · grafo-nav (cono/verbos).

5. Sellar el arranque: verity + medida

El store content-addressed hace fs-verity/dm-verity casi gratis (el hash YA es la identidad del artefacto). EFI-stub propio (ADR 0010) ⇒ firmar la UKI + measured boot con TPM. Cierra la cadena firmware→PID1→store; sin esto, la soberanía del build descansa sobre un rootfs mutable.

Cruce: la atestación al arranque de arje ya existe (gate Halt/Degraded/Warn, dry-run off-boot, verify_chain_from_cas — PLAN-ATESTACION §A); el expected_hash del .swm ES el BLAKE3 que arje atesta. TPM/verity = extender ese gate hacia el firmware, no construir la capa.

6. Matar el trusting-trust: DDC (Diverse Double-Compiling)

Con la cadena mrustc cerrada y bit-repro verificada, hammer es de los poquísimos proyectos del mundo que puede ejecutar DDC: compilar la cadena partiendo de Alpine vs partiendo de sí misma y comparar hashes. Un fin de semana de granja, resultado publicable. Largo plazo: semilla full-source (stage0/Mes).

Cruce: el resultado se ancla en el log de §1 (fork-proof); sandokan (Engine/RemoteEngine sobre brahman-ssh-multiplex) como supervisor de jobs remotos.

7. De-Alpinizar el rootfs del sandbox

El hallazgo del plugin LTO (binutils de hammer cargando el gcc de Alpine) mostró un canal impuro estructural mientras el sandbox se apoye en Alpine. Harkaq lo mide; el cierre es rootfs de build 100% hammer-built (el patrón de de-Alpinización ya existe).

Cruce: ninguno directo (trabajo interno de hammer). Disciplina análoga en tawasuyu: scripts/check-shared-cores.sh (guardián de simetría no_std).

8. hammer oci

Emitir imágenes distroless bit-reproducibles desde un closure (closure → capas → manifest). Vector de adopción realista: la gente consume hammer vía contenedores años antes de instalar la distro.

Cruce: format/foreign-fs para capas dedup por contenido · card-net como distribución por hash alternativa al registry.

9. Updates diferenciales content-defined

Chunking estilo casync sobre el store; el Merkle-DAG de H3 (SDD 15) es media implementación. Complementa hydrate para metal/USB.

Cruce: reconcile (Meyer/Willow, el candidato canónico) · chunking de foreign-fs · crdt::wire (anti-entropy agnóstico de transporte) · transporte card-net / Akasha-over-Ether.

10. Bucle agéntico con juez mecánico

Agente propone receta → harkaq da veredicto → granja reproduce ×2 → catálogo acepta. Ya demostrado a mano con zlib (Impuro→Hermetico ×3 fases guiado sólo por harkaq). LA tesis AI-nativa: el catálogo se cultiva solo porque el juez es mecánico. Sin juez, recetas LLM son deuda; con él, son cosecha.

Cruce: willay-checkpoint (Propuesta = "lo que la IA observó/propuso + veredicto del simulador" — mapea 1:1 a receta+veredicto-harkaq) · willay-hilo (caja negra forense por-device sobre fork-proof ⇒ bucle agéntico no repudiable) · atipay (catálogo determinista de capacidades → plan tool-use) · sandokan-journal (replay del plano de control) · rag-motor (contrato RAG con citación, alimentado por why-differs). PLAN-ATESTACION ya enuncia el ciclo: "IA propone → humano commitea (hammer) → init atesta (arje)".

2. Qué NO priorizar

• Solver SAT de versiones: el grafo es curado, no lo necesita.
• Multi-arch: costo enorme; esperar demanda (la historia RISC-V puede reabrirlo).
• Config declarativa estilo NixOS: cancha ajena; si acaso, allichay ya es ese vocabulario en tawasuyu.

3. Nota CRDT

El cierre CRDT en hammer = journal/catálogo replicado granja↔laptop sin git como bus (anti-entropy crdt::wire sobre el LwwMap de H2). El transporte real vive en PLAN-OS-CRDT §E3 (tawasuyu) — no duplicar. Estado real de ese plan a 2026-07-15: E2 (fork-proof) y E3c (BudgetRouter) ya son código con tests; E1 (MonotonicLog en el kernel wawa) sigue siendo plan — la parte que hammer necesita ya existe.

4. Caveats del cruce

• sheafsync es scaffold M0 y su teoría de haces fracasó honestamente (PLAN-OS-CRDT §0); reutilizar escrow/BudgetRouter/fencing, no la cohomología.
• willay es v1 en construcción; tejido/willay-rag arrastran libp2p/tokio/iniy — no importarlos al build hermético. Usar el patrón ya validado con hammerd: contrato wire por bytes, sin dependencia de crate (PLAN-ATESTACION §B.2).

5. Elegidos (ventaja competitiva por unidad de esfuerzo)

1. Consenso de reconstrucción — nadie más puede; fork-proof+umbral lo bajan de "proyecto" a "wiring sobre la granja". Le da razón de existir al log de transparencia de SDD 09 §4.
2. why-differs — multiplicador de todo lo demás (granja Y agente); format+reconcile regalan el esqueleto.