takana/docs/adr/0007-arje-como-init-propio.md

ADR 0007 — arje como init propio del track posterior

• Estado: propuesta
• Fecha: 2026-06-10

Contexto

El roadmap (SDD 10 §Track posterior) deja un ítem abierto: "reemplazar el init de Alpine por tu init (bus por pipes nativo) — habilita el CRASHED real que la Fase 5 dejó diferido". Construir ese init de cero sería meses de trabajo contra una pieza que ya existe en el monorepo tawasuyu: arje (03_ukupacha/arje), un init/bootloader from-scratch en Rust con PID 1 (arje-zero), supervisión real de servicios (RestartTracker + sandokan-lifecycle::Backoff, restarts visibles end-to-end), bus interno por socket Unix (arje-bus, postcard, SO_PEERCRED), CAS (arje-cas), snapshot (arje-snapshot), runtime WASM (arje-soma+arje-wasm) y absorción de sistemas existentes (arje-absorb).

Al revisar arje contra takana aparece que ambos convergieron en los mismos primitivos por caminos distintos: CAS direccionado por contenido, bus de agente sobre socket Unix con SO_PEERCRED, firma Ed25519, y el principio "la IA propone, el humano dispone". Mantenerlos separados duplicaría bus, CAS y modelo de confianza.

Decisión

1. arje es el init del track posterior de takana. No se escribe un init nuevo. arje aporta PID 1 + supervisión, lo que entrega el CRASHED real que la Fase 5 dejó diferido.
2. Frontera de responsabilidades (PID 1 fino):
   • arje = boot, PID 1, supervisión/restart, mount del overlay, snapshot, CAS, atestación al arranque.
   • takana = laboratorio de build determinista, diario de mutaciones (fanotify), .swm reproducible + firma, bucle agéntico con IA. hammerd corre como servicio supervisado por arje.
3. Un solo bus. El control de ciclo de vida de hammerd va por arje-bus. El agent.sock (JSON-líneas) de takana queda como API de IA de alto nivel encima, no como segundo plano de control del init. takana-core::proto se comparte; el transporte es arje-bus.
4. CAS unificado en BLAKE3. takana ya usa BLAKE3 (prefijo b3:). arje migra arje-cas de SHA-256 a BLAKE3 para hablar el mismo hash. El store pasa a ser un crate compartido.
5. Modelo de confianza en capas. takana garantiza procedencia (reproducir desde fuente pública → expected_hash BLAKE3). arje/agora atesta autorización (verificar_capacidad sobre (blake3, permisos) al boot). El expected_hash de un .swm ES el BLAKE3 que arje atesta. Un takana commit promovido emite una concesión firmada que arje-absorb integra al seed → el binario mutado por la IA queda atestado en el próximo arranque.

Razones

• No reinventar lo resuelto (coherente con ADR 0004): arje es un init supervisor maduro; el CRASHED real sale gratis.
• Bajar entropía, no subirla: dos buses y dos CAS con la misma semántica son deuda. Un wire, un hash, una política de capacidades.
• El modelo de confianza se refuerza: "verificar, no confiar" (procedencia) + "atestar al boot" (autorización) cubren amenazas distintas y se encadenan por el hash sin acoplarse.

Consecuencias

• Track posterior deja de necesitar "init propio from-scratch": adopta arje. El bootstrap Stage 0/1 (toolchain semilla) sigue siendo de takana; el init lo pone arje.
• takana asume BLAKE3 como hash único del store (ya lo es) y arje se alinea.
• Surge una dependencia de coordinación entre repos (takana ↔ tawasuyu/03_ukupacha/arje): el wire de arje-bus y takana-core::proto, y el formato de la concesión de capacidad.

Caveat estratégico

arje también es "the natural bootloader for wawa-kernel" (un SO nativo sin glibc/TCP-IP). La cage glibc para software propietario (Steam/NVIDIA) es feature del mundo takana/Linux, no de arje core — arje declara de sí mismo "for boot, not for governing the running system". Mantenerla fuera de PID 1 preserva tanto el init fino como el norte nativo de wawa.

Coordinación

Plan completo (lado arje, con los puntos de inserción en el código y los primitivos de agora a reusar): tawasuyu:03_ukupacha/arje/PLAN-ATESTACION-Y-HAMMER.md.