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 1569Shell 203Rust 109Markdown 993728 Definitions

feat(perfiles): typst y valkey — y la contradicción que leí mal era yo

Cierra los 12 del censo. `typst` → `cli`, `valkey` → `servidor`:

· **`typst`** tapa «documentos técnicos», que estaba 3/4: sin texlive, pandoc ni groff, la distro no
  sabía producir un PDF desde texto marcado por NINGÚN camino. Rust puro y CLI, sin toolkit.
· **`valkey`** tapa «caché en memoria», que estaba VACÍA. Su propia receta cuenta cómo se vio:
  `scripts/mudanza/planear.py` agrupa el software del origen en familias y ésa salía sin nada — ni
  redis, ni valkey, ni memcached—, o sea que un servidor de origen con redis no tenía reemplazo.
  Trae los `redis-*` además de los `valkey-*`, así que un cliente viejo no se entera.
  ⚠ Se declara en `paquetes` (instala), NO en `servicios`: levantar una caché por defecto es otra
  decisión (memoria reservada, bind, persistencia).

⚠ **Y LA CORRECCIÓN, que es el valor del commit: dije que estos dos eran trabajo de granja y no lo
eran.** Mi `takana hash --check` decía NO VIGENTE y el grafo decía `sealed`; leí la contradicción
como «falta construirlo». Las dos fuentes eran ciertas y medían cosas distintas:

    takana hash --check    mira el store LOCAL                      ⇒ no está en el hub   ✔ cierto
    build-state.json       lee ADEMÁS el manifiesto del worker      ⇒ está sellado        ✔ cierto

Los dos artefactos estaban construidos en el worker desde antes (typst 52M, valkey 14M) y no habían
bajado, porque la cosecha ya NO baja el store (es lo que evita que el disco del hub se llene). No
era construir: era traerlos — `rsync -azH` excluyendo `.dmerge`, aterrizando por `.incoming-*` y
`mv` al final, para que un directorio a medias no quede como cache-hit envenenado (regla 3).

Balance de los 12: **9 declarados** (uv, micro, elvish, gopass, wtype, kubectl, helm, typst,
valkey) · **2 excluidos con motivo escrito** (`mako` es el motor de plantillas de Mesa, no el daemon
de notificaciones — error mío de clasificación por el nombre; `nodejs` dice en su receta que la
distro no lo publica) · **1 pendiente de verdad**: `kakoune`, que vive en `tandas/staged-2026-06-26/`
fuera del catálogo y nunca se construyó.

El censo pasa de 6 a 15 en `tiene-y-viaja` y de 12 a 3 en `tiene-sin-viajar`. **La clausura sigue en
10 de 10** — verificado antes de publicar.

De paso: el worker estaba al **99% (2,9 G)** y `target/debug/incremental` había vuelto a 15 G cuatro
días después de soltarlo. Liberado otra vez ⇒ 16 G. Eso ya no es una limpieza, es un patrón:
conviene `CARGO_INCREMENTAL=0` en ese flujo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

777252e65fd04b91f10809e5f18362259c3dc871 · by Sergio · (3 d ago) · parent fadc46b31 · browse the tree at this commit

Semantic delta

No definition changed: this change is text, documentation or data.

2 files · +32 −12

diff --git a/docs/state/distro-huecos.json b/docs/state/distro-huecos.json
index 39470cd3..fba81ad4 100644
--- a/docs/state/distro-huecos.json
+++ b/docs/state/distro-huecos.json
@@ -168,7 +168,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "micro",
      "parientes": []
     },
@@ -197,7 +197,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "elvish",
      "parientes": []
     }
@@ -343,7 +343,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "wtype",
      "parientes": []
     },
@@ -513,7 +513,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "typst",
      "parientes": []
     },
@@ -664,7 +664,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "valkey",
      "parientes": []
     }
@@ -833,7 +833,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "uv",
      "parientes": []
     },
@@ -956,7 +956,7 @@
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "gopass",
      "parientes": []
     }
@@ -1338,12 +1338,12 @@
    ],
    "items": [
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "kubectl",
      "parientes": []
     },
     {
-     "estado": "tiene-sin-viajar",
+     "estado": "tiene-y-viaja",
      "nombre": "helm",
      "parientes": []
     },
@@ -1365,12 +1365,12 @@
    "porque": "decisión abierta: son herramientas de operar OTRA cosa"
   }
  ],
- "en_alguna_imagen": 592,
+ "en_alguna_imagen": 601,
  "recetas_alcanzables": 1375,
  "resumen": {
   "falta": 152,
-  "tiene-sin-viajar": 12,
-  "tiene-y-viaja": 6
+  "tiene-sin-viajar": 3,
+  "tiene-y-viaja": 15
  },
  "schema": "takana-censo-distro/1"
 }
diff --git a/docs/state/targets.toml b/docs/state/targets.toml
index 7219d1ed..9b9dcf75 100644
--- a/docs/state/targets.toml
+++ b/docs/state/targets.toml
@@ -397,6 +397,16 @@ paquetes = [
                # del sistema — `base` define el del sistema y son dos hechos distintos
   "gopass",    # gestor de contraseñas. El censo marca la categoría entera como hueco (nada:
                # ni keepassxc, ni pass) y éste ya estaba sellado — tapa la mitad de CLI del hueco
+  # `typst` (2026-10-19): composición tipográfica. Tapa el hueco de «documentos técnicos», que el
+  # censo marcaba 3/4 — no hay texlive, ni pandoc, ni groff, o sea que la distro no sabía producir
+  # un PDF desde texto marcado por NINGÚN camino. Es Rust puro y CLI: ni toolkit ni muro gráfico.
+  # ⚠ Su artefacto estaba sellado en el WORKER y no en el hub. No era trabajo de granja: era
+  # traerlo (`rsync -azH`, excluyendo `.dmerge`, aterrizando por `.incoming-*` + `mv` para que un
+  # directorio a medias no quede como cache-hit envenenado). El grafo decía `sealed` con razón —
+  # lee el manifiesto del worker además del store local—; `takana hash --check` decía NO VIGENTE
+  # con razón también, porque mira el store LOCAL. Las dos fuentes eran ciertas y medían cosas
+  # distintas, y yo leí la contradicción como «falta construirlo».
+  "typst",
 ]
 
 [perfil.escritorio-mirada]
@@ -2118,6 +2128,16 @@ paquetes = [
   # estaba—. ⚠ Declarar kubectl no los activa por sí solo: los dos siguen fuera de todo perfil, y
   # eso es su propia línea de trabajo. Lo que cambia es que ahora hay dónde declararlos.
   "kubectl", "helm",
+  # `valkey` (2026-10-19): la caché en memoria. El censo marcaba «bases de datos de servidor» 3/4
+  # y su propia receta cuenta cómo se vio el hueco: `scripts/mudanza/planear.py` agrupa el software
+  # del origen en familias y la familia «caché en memoria» salía SIN NADA — ni redis, ni valkey, ni
+  # memcached—, o sea que un servidor de origen que use redis no tenía con qué reemplazarse.
+  # Trae los `redis-*` además de los `valkey-*`, así que un cliente viejo no se entera.
+  # ⚠ Sellado en el worker y traído al hub hoy, igual que `typst`.
+  # ⚠ NO se habilita como servicio en este commit: levantar una caché en memoria por defecto es
+  # otra decisión (memoria reservada, bind, persistencia) y va en `servicios`, que es el «enable»
+  # de abajo. Declararlo en `paquetes` sólo lo INSTALA.
+  "valkey",
 ]
 
 # ── QUÉ ARRANCA (el «enable»; SDD 30 §3) ────────────────────────────────────────────────────────