diff --git a/recipes/openrc.toml b/recipes/openrc.toml
index dd19c4f9..a9940bfc 100644
--- a/recipes/openrc.toml
+++ b/recipes/openrc.toml
@@ -1,14 +1,24 @@
 # openrc 0.62.6 — gestor de servicios / init dependency-based (el de Gentoo y Alpine). C, meson.
-# Por qué en hammer: hammer bootea con arje-zero como PID1, pero openrc es el SUPERVISOR de
-# servicios que falta para una distro instalable de verdad (rc-service/rc-status/rc-update sobre
-# /etc/init.d). Es musl-clean por diseño: Alpine lo corre sobre musl en producción ⇒ encaja con el
-# toolchain zig-cc/musl static de hammer sin parches.
+#
+# POR QUÉ EN EL CATÁLOGO (marco honesto): openrc es un INIT ALTERNATIVO que la distro OFRECE, NO un
+# complemento de arje-zero. arje-zero es autónomo: es PID1 *y* gestiona sus servicios; no necesita —
+# ni debe apilar — un supervisor encima (ese acople es justo lo que arje existe para evitar). openrc
+# y arje son dos opciones de init que COMPITEN por el rol de PID1, no capas que se apilan. El valor de
+# tenerlo empacado es la oferta multi-init anti-monocultivo-systemd: quien quiera openrc COMO su init
+# (p.ej. viniendo de Artix/Gentoo) lo instala del catálogo y arranca con él en vez de arje.
+#   → Este es el PATRÓN para el resto de la oferta de inits del catálogo (runit / s6 / dinit): empacar
+#     como alternativa instalable, cada uno autosuficiente como PID1, NUNCA como "supervisor sobre X".
+# (Corrige el comentario original, que justificaba openrc como "el supervisor que le falta a arje" —
+#  era una racionalización a posteriori, falsa: arje no tiene ese hueco.)
+#
+# musl-clean por diseño: Alpine lo corre sobre musl en producción ⇒ encaja con el toolchain zig-cc/
+# musl static de hammer sin parches.
 #
 # Estático (modelo hammer): -Ddefault_library=static + --prefer-static ⇒ libeinfo/librc salen .a y
 # los binarios rc/rc-service enlazan static-musl. Deps OPCIONALES desactivadas para clausura mínima:
-# audit/selinux/pam/libcap son features 'auto'/required:false en el meson.build; sin declararlas ni
-# el sandbox las provee ⇒ no se enganchan. Se pueden sumar después (libcap ya está en el corpus) si
-# se quiere capability-dropping por servicio; por ahora, el núcleo.
+# audit/selinux/pam SÍ son features 'auto'/required:false en el meson.build ⇒ sin declararlas no se
+# enganchan. libcap NO: en Linux el meson.build hace `dependency('libcap', >=2.33)` INCONDICIONAL
+# (sin -Dlibcap para saltarlo; sólo se omite en no-Linux) ⇒ es dep obligatoria, va en [deps].build.
 name    = "openrc"
 version = "0.62.6"