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 1572Shell 203Rust 109Markdown 993728 Definiciones

Clonar por HTTPS, con el git de siempre

⎇ main docs/adr/0007-arje-como-init-propio.md Markdown · 70 líneas · 4.1 KB Historia crudo

takana etapa 5b: los 59 docs de diseño, runbooks y ADR 97ceb7241 · Sergio · hace 1 mes

1# ADR 0007 — `arje` como init propio del track posterior
2
3- **Estado:** propuesta
4- **Fecha:** 2026-06-10
5
6## Contexto
7
8El roadmap ([SDD 10](../10-roadmap.md) §Track posterior) deja un ítem abierto: *"reemplazar el
9init de Alpine por **tu init** (bus por pipes nativo) — habilita el `CRASHED` real que la Fase 5
10dejó diferido"*. Construir ese init de cero sería meses de trabajo contra una pieza que **ya
11existe** en el monorepo `tawasuyu`: **`arje`** (`03_ukupacha/arje`), un init/bootloader from-scratch
12en Rust con PID 1 (`arje-zero`), supervisión real de servicios (`RestartTracker` +
13`sandokan-lifecycle::Backoff`, restarts visibles end-to-end), bus interno por socket Unix
14(`arje-bus`, postcard, `SO_PEERCRED`), CAS (`arje-cas`), snapshot (`arje-snapshot`), runtime WASM
15(`arje-soma`+`arje-wasm`) y absorción de sistemas existentes (`arje-absorb`).
16
17Al revisar arje contra takana aparece que **ambos convergieron en los mismos primitivos** por
18caminos distintos: CAS direccionado por contenido, bus de agente sobre socket Unix con
19`SO_PEERCRED`, firma Ed25519, y el principio "la IA propone, el humano dispone". Mantenerlos
20separados duplicaría bus, CAS y modelo de confianza.
21
22## Decisión
23
241. **arje es el init del track posterior de takana.** No se escribe un init nuevo. arje aporta
25   PID 1 + supervisión, lo que **entrega el `CRASHED` real** que la Fase 5 dejó diferido.
262. **Frontera de responsabilidades (PID 1 fino):**
27   - **arje** = boot, PID 1, supervisión/restart, mount del overlay, snapshot, CAS, atestación
28     al arranque.
29   - **takana** = laboratorio de build determinista, diario de mutaciones (`fanotify`), `.swm`
30     reproducible + firma, bucle agéntico con IA. `hammerd` corre como **servicio supervisado
31     por arje**.
323. **Un solo bus.** El control de ciclo de vida de `hammerd` va por `arje-bus`. El `agent.sock`
33   (JSON-líneas) de takana queda como **API de IA de alto nivel encima**, no como segundo plano
34   de control del init. `takana-core::proto` se comparte; el transporte es `arje-bus`.
354. **CAS unificado en BLAKE3.** takana ya usa BLAKE3 (prefijo `b3:`). arje migra `arje-cas` de
36   SHA-256 a BLAKE3 para hablar el mismo hash. El store pasa a ser un crate compartido.
375. **Modelo de confianza en capas.** takana **garantiza procedencia** (reproducir desde fuente
38   pública → `expected_hash` BLAKE3). arje/agora **atesta autorización** (`verificar_capacidad`
39   sobre `(blake3, permisos)` al boot). **El `expected_hash` de un `.swm` ES el BLAKE3 que arje
40   atesta.** Un `takana commit` promovido emite una concesión firmada que `arje-absorb` integra
41   al seed → el binario mutado por la IA queda atestado en el próximo arranque.
42
43## Razones
44
45- **No reinventar lo resuelto** (coherente con [ADR 0004](0004-no-custom-nix.md)): arje es un init
46  supervisor maduro; el `CRASHED` real sale gratis.
47- **Bajar entropía, no subirla:** dos buses y dos CAS con la misma semántica son deuda. Un wire,
48  un hash, una política de capacidades.
49- **El modelo de confianza se refuerza:** "verificar, no confiar" (procedencia) + "atestar al
50  boot" (autorización) cubren amenazas distintas y se encadenan por el hash sin acoplarse.
51
52## Consecuencias
53
54- **Track posterior** deja de necesitar "init propio from-scratch": adopta arje. El bootstrap
55  Stage 0/1 (toolchain semilla) sigue siendo de takana; el init lo pone arje.
56- takana asume **BLAKE3** como hash único del store (ya lo es) y arje se alinea.
57- Surge una dependencia de coordinación entre repos (`takana` ↔ `tawasuyu/03_ukupacha/arje`):
58  el wire de `arje-bus` y `takana-core::proto`, y el formato de la concesión de capacidad.
59
60## Caveat estratégico
61
62arje también es *"the natural bootloader for `wawa-kernel`"* (un SO nativo sin glibc/TCP-IP). La
63**cage glibc** para software propietario (Steam/NVIDIA) es feature del mundo **takana/Linux**, no
64de arje core — arje declara de sí mismo *"for boot, not for governing the running system"*.
65Mantenerla fuera de PID 1 preserva tanto el init fino como el norte nativo de wawa.
66
67## Coordinación
68
69Plan completo (lado arje, con los puntos de inserción en el código y los primitivos de agora a
70reusar): `tawasuyu:03_ukupacha/arje/PLAN-ATESTACION-Y-HAMMER.md`.

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

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.
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.
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.
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.
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.