Files
takana/docs
SergioandClaude Opus 5 d52824efeb mudados tawasuyu.net y gioser.net — y los padres que inventa bwrap eran 0700
Los dos sitios que quedaban con trafico real sirven desde la caja `takana`, con TLS publico y
verificados desde fuera. Los servicios viejos SIGUEN corriendo en gioser a proposito (decision del
usuario: mover el DNS y dejar el origen vivo, para poder volver en un minuto).

· `tawasuyu.net` + `www`: la raiz en gioser era EL MONOREPO ENTERO (145 G) servido por HTTP. El log
  de accesos dice que las unicas rutas con trafico son `/`, `/descargas` y `/web`, asi que se
  replicaron solo los dos subarboles que el sitio usa (1,2 M + 3,8 G) con la MISMA estructura, para
  que cada `rewrite` siga siendo el mismo.
· `gioser.net` + `www`: 428 M de estaticos + `/reencuentro`, que necesita PHP. `/hooks/*` NO se
  muda: lo atiende `webhook-deploy.py`, que redespliega aura/sigma/summa/brahman — los cuatro
  FOSILES del §6.19 — y tiene cero peticiones. Muere con la caja vieja.
· `sergio` dejo de ser `CNAME -> www` y tiene su A propio (apuntando a gioser, sin cambio visible).
  Sin eso, mover `www` se lo llevaba puesto: en esa zona casi todo cuelga de `www`.

PHP no entra al corpus y no hace falta: `php-fpm 8.5.10` corre en la instancia `gioser-php` (ADR
0015), supervisado por arje. Control contra el original en los dos sentidos: POST con la trampa
anti-robots da `{"ok":true}` 200 y GET da 405, igual que en gioser.

EL MURO, que es general y no de PHP: para montar en `/work/www/gioser-web`, bwrap crea `/work` y
`/work/www` —que la imagen no trae— y los crea **0700 root**. Adentro somos root y a mano todo
funciona; pero un servicio que BAJA de privilegio (php-fpm a `http`, o cualquier instancia con
`run_as`) no puede ni atravesarlos, y el sintoma es un «File not found» sobre un fichero que ESTA.
Medido con el control que lo separa de un problema de permisos del anfitrion: como `http`, leer un
fichero de la IMAGEN funciona y leer el directorio CONCEDIDO da Permission denied.

`grants_to_args` crea ahora los ancestros que faltan con `--perms 0755 --dir`, y SOLO los que la
imagen no trae: hacerlo sobre `/etc` o `/home` le cambiaria los modos a la imagen. Con test, y
probado rompiendolo a proposito (sale `["/etc","/etc/php"]` en vez de `["/etc/php"]`).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-15 17:58:17 +00:00
..

Documentación de diseño de takana

Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.

Software Design Documents (SDD)

# Documento Qué cubre
00 Visión y filosofía Por qué existe, qué problema resuelve, la actitud de ingeniería
01 Arquitectura general El modelo de dos mundos, componentes, flujo de datos
02 El laboratorio de build Sandbox, zig cc, recetas, CAS, grafo de dependencias
03 Hidratación y store Store content-addressed, hardlinks a FHS, patchelf, rollback
04 Overlay de experimentación overlayfs en caliente, try/commit/discard
05 Diario de mutaciones fanotify, log append-only, config-sin-ser-declarativa
06 Formato .swm Manifiesto de mutación compartible, esquema, firma
07 Bus de init y de agente /run/init.control, /run/agent.sock, protocolo
08 Integración de la IA El bucle agéntico, seguridad, intención → .swm
09 Modelo de confianza Reproducibilidad, verificar-no-confiar, log de transparencia
10 Roadmap Fases, MVP, primer entregable
11 Bootstrap from-scratch Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned
12 arje como init real del Stage 1 Contrato de runtime: seed card, hammerd supervisado, CRASHED real
16 harkaq: la jaula de takana Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad
26 atuq: el envoltorio Gecko Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no
30 Los servicios que trae un paquete [[service]] en la receta → Card de arje; por qué arje-absorb no cubre una distro construida desde fuente; los tres árboles de servicios y cuál es el canónico

Runbooks (operativos)

Runbook Para qué
Validar Stage 1 booteando en QEMU stage0stage1→initramfs→QEMU; criterios de éxito y troubleshooting

Architecture Decision Records (ADR)

Decisiones tomadas, con su contexto y consecuencias. Ver adr/.

# Decisión
0001 Rust para el tooling y daemons
0002 Validar sobre Alpine antes de la distro propia
0003 zig cc como compilador por defecto del lab
0004 No escribir nuestro propio Nix
0005 Hidratación por hardlinks
0006 Commits fijados, no HEAD vivo
0007 arje como init propio del track posterior
0008 Bootstrap en 3 stages, zig como semilla
0009 Código direccionado por contenido (estilo Unison)
0010 Arranque por grafo: el menú de boot como navegación del grafo
0011 Etapa Escritorio: campaña KDE Plasma 6
0012 El árbol de fuentes es caché y workspace a la vez — PENDIENTE, dilema abierto