sergio/takana

zlib-ng: el veredicto T5 hecho receta — dispatch SIMD en runtime en vez de
variantes v3; modo ZLIB_COMPAT, zlib.toml intocada (dep del frente rust).
dwarves: pahole para destrabar sched-ext; el kernel NO lo declara aún (el
análisis de repro BTF/pahole-skew va primero). Ambas al worker.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

diff --git a/recipes/dwarves.toml b/recipes/dwarves.toml
new file mode 100644
index 00000000..0d5cf53a
--- /dev/null
+++ b/recipes/dwarves.toml
@@ -0,0 +1,39 @@
+# dwarves 1.30 (pahole) — la llave que destraba sched-ext (plan-jaula-juegos T1.2, diferido
+# con causa verificada): en 6.16.12 SCHED_CLASS_EXT depende de DEBUG_INFO_BTF, y generar BTF
+# exige pahole en las build-deps del kernel. Sin esta receta, sched-ext (los schedulers scx
+# de juego: scx_lavd, scx_bpfland) queda fuera del kernel propio para siempre.
+#
+# OJO REPRO: meter pahole en el kernel no es sólo declarar la dep — BTF mete la versión de
+# pahole en el juego de la bit-repro (pahole-skew entre builders cambia el .BTF). El análisis
+# está pendiente en el plan; ESTA receta sólo pone la herramienta en el catálogo para poder
+# hacerlo. El kernel NO la declara todavía.
+#
+# libbpf EMBEBIDO (-DLIBBPF_EMBEDDED=ON, el default del tarball que vendorea libbpf): evita
+# una receta libbpf aparte hoy; si libbpf entra al catálogo por otro frente, se despega.
+#
+# PENDIENTE construir en el WORKER (el laptop no compila recetas C). sha256 verificado del
+# tarball de fedorapeople 2026-07-17. Deps reales: libdw de elfutils + zlib (ambas selladas).
+
+name    = "dwarves"
+version = "1.30"
+
+[source]
+tarball = "https://fedorapeople.org/~acme/dwarves/dwarves-1.30.tar.xz"
+sha256  = "1c89f47dc4f127c4b9d3fb46c8386a40be45c36ef82e8df472418de9423fc5bb"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+
+[deps]
+build = ["busybox", "make", "cmake", "elfutils", "zlib"]
+
+[build.phases]
+configure = """
+cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -D__LIB=lib \
+  -DBUILD_SHARED_LIBS=OFF -DLIBBPF_EMBEDDED=ON \
+  -DCMAKE_C_FLAGS='-O2 -fno-sanitize=undefined'
+"""
+compile = "make -C build -j\"$(nproc)\""
+install = "make -C build install DESTDIR=/out"
diff --git a/recipes/zlib-ng.toml b/recipes/zlib-ng.toml
new file mode 100644
index 00000000..d06331a5
--- /dev/null
+++ b/recipes/zlib-ng.toml
@@ -0,0 +1,44 @@
+# zlib-ng 2.2.4 — el veredicto del piloto T5 (plan-variantes-cpu, 2026-07-17): la respuesta a
+# "¿zlib v3?" no es una variante de la zlib de madler sino este fork — SIMD (SSE4/AVX2/AVX512)
+# con DISPATCH EN RUNTIME ⇒ un solo artefacto rinde en cualquier CPU, cero maquinaria de
+# variantes. Probado en serio: Fedora 40 lo envía como la zlib del sistema.
+#
+# ENTRADA AL CATÁLOGO, NO REEMPLAZO: recipes/zlib.toml queda INTOCADA (es dep del frente rust
+# —mrustc la enlaza— y pieza del toolchain sellado). zlib-ng se construye en modo compat
+# (ZLIB_COMPAT=ON ⇒ libz.a con la ABI de zlib) para poder medir zlib-ng vs zlib en una máquina
+# quieta y, si paga, adoptarla consumidor a consumidor vía [deps] — jamás con un rename mágico.
+#
+# cmake y no el ./configure propio: el configure de zlib-ng asume bash-ismos que el busybox sh
+# del sandbox no trae; el generador cmake ya está sellado en el catálogo (y tras matar-gcc no
+# arrastra runtime C++ de Alpine).
+#
+# PENDIENTE construir en el WORKER (el laptop no compila recetas C). sha256 verificado del
+# tarball de GitHub 2026-07-17.
+
+name    = "zlib-ng"
+version = "2.2.4"
+
+[source]
+tarball = "https://github.com/zlib-ng/zlib-ng/archive/refs/tags/2.2.4.tar.gz"
+sha256  = "a73343c3093e5cdc50d9377997c3815b878fd110bf6511c2c7759f2afb90f5a3"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+
+[deps]
+build = ["busybox", "make", "cmake"]
+
+[build.phases]
+# -fno-sanitize=undefined: mismo motivo que zlib/libarchive (UBSan de zig cc en el .a estático).
+# WITH_GTEST/ZLIB_ENABLE_TESTS off: el sandbox no corre tests y gtest arrastraría C++.
+# CMAKE_POSITION_INDEPENDENT_CODE: mismo argumento que el -fPIC de zlib (enlazable en .so).
+configure = """
+cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr \
+  -DZLIB_COMPAT=ON -DBUILD_SHARED_LIBS=OFF -DZLIB_ENABLE_TESTS=OFF -DWITH_GTEST=OFF \
+  -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
+  -DCMAKE_C_FLAGS='-O2 -fno-sanitize=undefined'
+"""
+compile = "make -C build -j\"$(nproc)\""
+install = "make -C build install DESTDIR=/out"
diff --git a/tandas/planes-freebsd-2.txt b/tandas/planes-freebsd-2.txt
new file mode 100644
index 00000000..1a9f9556
--- /dev/null
+++ b/tandas/planes-freebsd-2.txt
@@ -0,0 +1,7 @@
+# planes-freebsd-2 — segunda cola worker de los planes (2026-07-17)
+# zlib-ng: veredicto T5 de plan-variantes-cpu (dispatch runtime > variantes); modo compat,
+#          NO reemplaza a zlib.toml — entra al catálogo para medir y adoptar por consumidor.
+# dwarves: pahole, destraba sched-ext (plan-jaula-juegos T1.2); el kernel NO lo declara aún
+#          (falta el análisis de repro de BTF/pahole-skew).
+zlib-ng
+dwarves