diff --git a/recipes/incoming-wlr/gdk-pixbuf.toml b/recipes/incoming-wlr/gdk-pixbuf.toml
new file mode 100644
index 00000000..88542363
--- /dev/null
+++ b/recipes/incoming-wlr/gdk-pixbuf.toml
@@ -0,0 +1,41 @@
+# gdk-pixbuf 2.44.6 — SOMBRA de `recipes/gdk-pixbuf.toml` para la cola wlr/sway.
+#
+# ── QUÉ CAMBIA Y POR QUÉ ────────────────────────────────────────────────────────────────────────
+# UNA sola línea: `libpng` → `libpng-shared` en `[deps]`. El resto es copia literal del canónico.
+#
+# El canónico muere enlazando:
+#     ld.lld: error: relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC
+#     >>> in archive /usr/lib/libpng16.a
+# y en la misma tanda de errores aparece `libc.so`, o sea que ESE link acabó siendo DINÁMICO pese a
+# que la receta declara `link = "static"`. Con un link dinámico, una `.a` sin PIC no se puede usar:
+# `recipes/libpng.toml` es `--disable-shared` y sus objetos no son PIC. `libpng-shared` existe
+# justamente para este caso — su cabecera lo dice: «no enlaza dentro de un .so».
+#
+# ⚠ NO ES UN FALLO NUEVO: es una REGRESIÓN CONGELADA que la reconstrucción destapa. gdk-pixbuf tenía
+# artefacto sellado y se servía por cache-hit, así que el fallo llevaba tiempo invisible. Es el mismo
+# patrón que documenta la campaña del lab: «no re-hashea nada sellado» ≠ «es seguro».
+#
+# ── POR QUÉ SOMBRA Y NO TOCAR EL CANÓNICO ───────────────────────────────────────────────────────
+# Decisión del usuario (2026-08-21). El canónico tiene 12 dependientes en cuatro colas y es estático
+# por diseño; cambiarle la dep es una decisión de arquitectura del corpus, no un arreglo de receta.
+# Mismo patrón que la sombra de libadwaita en incoming-gnome.
+#
+# ⚠ ALCANCE REAL, y hay que tenerlo presente: la resolución de deps es HERMANO→PADRE — una receta del
+# CORPUS no ve las de `incoming-*`. Así que esta sombra la usan las recetas de ESTA cola, y las 7 del
+# corpus (gtk4, libadwaita, gtksourceview…) siguen resolviendo el canónico roto.
+name    = "gdk-pixbuf"
+version = "2.44.6"
+license = "LGPL-2.1-or-later"
+[source]
+tarball = "https://download.gnome.org/sources/gdk-pixbuf/2.44/gdk-pixbuf-2.44.6.tar.xz"
+sha256  = "140c2d0b899fcf853ee92b26373c9dc228dbcde0820a4246693f4328a27466fa"
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+[build.phases]
+configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload --prefer-static -Ddefault_library=static -Dpng=enabled -Djpeg=disabled -Dtiff=disabled -Dothers=disabled -Dglycin=disabled -Dbuiltin_loaders=png -Dgio_sniffing=false -Dman=false -Dintrospection=disabled -Dtests=false -Dinstalled_tests=false -Dgtk_doc=false -Dc_args=-Wno-error=date-time"
+compile   = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
+install   = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
+[deps]
+build = ["meson", "samurai", "python3", "pkgconf", "glib", "libpng-pic", "libffi", "pcre2", "zlib"]
diff --git a/recipes/libpng-pic.toml b/recipes/libpng-pic.toml
new file mode 100644
index 00000000..eae9cdfd
--- /dev/null
+++ b/recipes/libpng-pic.toml
@@ -0,0 +1,40 @@
+# libpng-pic 1.6.58 — variante ESTÁTICA pero PIC (`libpng16.a` compilada con -fPIC).
+#
+# ── EL HUECO QUE LLENA, ENTRE EL CANÓNICO Y LA -shared ──────────────────────────────────────────
+# El corpus tenía dos libpng y ninguna sirve para el caso de gdk-pixbuf:
+#
+#   `libpng`         → `--disable-shared`, objetos SIN PIC. Si el link acaba siendo dinámico:
+#                      «relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC».
+#   `libpng-shared`  → sólo `libpng16.so`. Si el consumidor pide estático (`--prefer-static`):
+#                      «unable to find static system library 'png16'».
+#
+# Las dos las probé con gdk-pixbuf el 2026-08-21 y fallan por los extremos opuestos. La salida no es
+# elegir un extremo, es una `.a` que TAMBIÉN sea PIC: satisface a quien pide la estática por nombre
+# y además se puede reubicar dentro de un link dinámico. Es la misma clase de muro que deja a CPython
+# sin `_curses` («relocation R_X86_64_PC32 against symbol 'stdscr'»), así que esta variante es un
+# primer ladrillo de ese frente, no un parche de una receta.
+#
+# ── QUÉ CAMBIA RESPECTO A `recipes/libpng.toml` ─────────────────────────────────────────────────
+# Sólo el `configure`: se añade `--with-pic` (autoconf/libtool: compila los objetos del archivo
+# estático con -fPIC). Nada más — mismo tarball, mismo sha256, mismo compilador, mismas deps.
+#
+# NO toca al canónico ni lo reemplaza: nombre distinto ⇒ sin colisión, igual que `libpng-shared`
+# (ver la nota de promoción ahí). Vive en el CORPUS, no en una cola, porque la resolución de deps es
+# HERMANO→PADRE: una receta del corpus no vería una variante metida en `incoming-*`.
+name    = "libpng-pic"
+version = "1.6.58"
+license = "Libpng"
+[source]
+tarball = "https://downloads.sourceforge.net/libpng/libpng-1.6.58.tar.gz"
+sha256  = "8c9b05b675ca7301a458df2c2e46f26e1d41ff36b8863f8c33530bc58c2e6225"
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+flags    = []
+[build.phases]
+configure = './configure --build=$CBUILD --host=$CHOST --prefix=/usr --disable-shared --enable-static --with-pic CPPFLAGS=-I/usr/include LDFLAGS=-L/usr/lib'
+compile   = 'make LDFLAGS="-all-static -no-pie" -j"$(nproc)"'
+install   = 'make DESTDIR=/out install LDFLAGS="-all-static -no-pie"'
+[deps]
+build = ["zlib", "make"]