sergio/takana

diff --git a/recipes/designcraft.toml b/recipes/designcraft.toml
index b485bbde..728e0657 100644
--- a/recipes/designcraft.toml
+++ b/recipes/designcraft.toml
@@ -52,6 +52,10 @@
 #    se los enciende otro miembro del workspace (`<app>-ui-egui`). Leer sólo el manifiesto de la app
 #    para decidir qué camino gráfico toma una de éstas da la respuesta equivocada; lo que manda es
 #    lo que aparece en el log del build y en el del binario corriendo.
+# ⚠ Esta app trae `[patch.crates-io] winit = { git = "…/skylartaylor/winit", rev = "3d51077f" }`:
+# el binario sellado NO lleva el winit de crates.io sino un fork. No rompe nada —`cargo vendor` baja
+# un patch por git igual que cualquier dep, y el `--locked` lo fija— pero si un día esta app se
+# comporta distinto de sus once hermanas en Wayland, el fork es el primer lugar donde mirar.
 name    = "designcraft"
 version = "0.7.1"
 license = "MIT OR Apache-2.0"
diff --git a/recipes/lightcraft.toml b/recipes/lightcraft.toml
index 7c7c6571..3ed9bd04 100644
--- a/recipes/lightcraft.toml
+++ b/recipes/lightcraft.toml
@@ -55,6 +55,13 @@
 #    se los enciende otro miembro del workspace (`<app>-ui-egui`). Leer sólo el manifiesto de la app
 #    para decidir qué camino gráfico toma una de éstas da la respuesta equivocada; lo que manda es
 #    lo que aparece en el log del build y en el del binario corriendo.
+# ⚠ **Medido al correrla (2026-10-13): esta app se queda SIN PORTAPAPELES en esta distro.**
+#     egui_winit::clipboard: Failed to initialize arboard clipboard: … X11 server connection timed
+#     out because it was unreachable
+# `arboard` intentó X11 porque acá —a diferencia de `gridcraft`, `photocraft` o `wordcraft`— la app
+# NO le enciende el feature `wayland-data-control`. Copiar y pegar queda apagado y nada falla: la
+# misma forma de fallo que el diálogo de ficheros sin portal. Se arregla con un feature (parche de
+# una línea al manifiesto) o aguas arriba; no se hizo todavía para no mezclarlo con el primer sellado.
 name    = "lightcraft"
 version = "0.7.1"
 license = "MIT OR Apache-2.0"
diff --git a/recipes/pdfcraft.toml b/recipes/pdfcraft.toml
index d7e9b694..159d8ab6 100644
--- a/recipes/pdfcraft.toml
+++ b/recipes/pdfcraft.toml
@@ -71,6 +71,21 @@ commit = "7163ba3dee8becfff6871c9a65d0d8314314742b"
 # sólo hay `[alias] xtask`, que estas recetas no usan— pero si un bump mete ahí un `rustflags` o un
 # `linker`, desaparece sin un solo aviso y el fallo no va a nombrar al config.
 # El `Cargo.lock` está committeado ⇒ el vendoreo va con `--locked` y queda pineado en el tiempo.
+#
+# ⚠ **`cargo_vendor_dir` NO es cosmético acá: sin él esta receta FALLA, y falló** (medido
+# 2026-10-13, `rc=1` a los 8 segundos). pdfcraft **committea su propio `vendor/`** con cuatro crates
+# —`hayro`, `hayro-syntax`, `hayro-interpret`, `hayro-jbig2`— enganchados por
+# `[patch.crates-io]` **POR RUTA**. El `cargo vendor` de takana escribe por defecto en `vendor/`, así
+# que los BORRA, y el error no nombra nada de esto:
+#
+#     failed to load checksum `.cargo-checksum.json` of hayro-interpret v0.7.0
+#     failed to read `/src/vendor/hayro-interpret/.cargo-checksum.json`
+#
+# Es exactamente la trampa que ya documentan `boveda.toml` (smithay en tawasuyu) y `mise.toml`
+# (su `vendor/aqua-registry`). Mandando el vendoreo a `.hammer-cargo-vendor/` el árbol de upstream
+# queda intacto. **Y ojo con el efecto colateral**: el bloque `LOCKSTEP_XML_PATH` de abajo tiene que
+# mirar ESA ruta y no `vendor/`, o la comprobación a gritos grita por el motivo equivocado.
+cargo_vendor_dir = ".hammer-cargo-vendor"
 
 [build]
 compiler = "zig-cc"
@@ -89,8 +104,8 @@ set -e
 # panic volvería con el error lejos de la causa.
 XMLDIR="$PWD/.atspi-lockstep-xml"
 mkdir -p "$XMLDIR"
-ls vendor/atspi-common/xml/*.xml >/dev/null 2>&1 || { echo "no hay vendor/atspi-common/xml/*.xml — ¿cambió el vendoreo o la versión de atspi? sin esto zbus-lockstep-macros panica en xml/schemas/" >&2; exit 1; }
-cp vendor/atspi-common/xml/*.xml "$XMLDIR"/
+ls .hammer-cargo-vendor/atspi-common/xml/*.xml >/dev/null 2>&1 || { echo "no hay .hammer-cargo-vendor/atspi-common/xml/*.xml — ¿cambió el vendoreo o la versión de atspi? sin esto zbus-lockstep-macros panica en xml/schemas/" >&2; exit 1; }
+cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
 export LOCKSTEP_XML_PATH="$XMLDIR"
 
 # El envoltorio de zig-cc, igual que en las otras winit+wgpu del corpus.
diff --git a/recipes/vectorcraft.toml b/recipes/vectorcraft.toml
index a25a0d75..76861d9b 100644
--- a/recipes/vectorcraft.toml
+++ b/recipes/vectorcraft.toml
@@ -75,6 +75,13 @@ commit = "71174477cc056020fe712ae59901d76b870ca9d9"
 # sólo hay `[alias] xtask`, que estas recetas no usan— pero si un bump mete ahí un `rustflags` o un
 # `linker`, desaparece sin un solo aviso y el fallo no va a nombrar al config.
 # El `Cargo.lock` está committeado ⇒ el vendoreo va con `--locked` y queda pineado en el tiempo.
+#
+# ⚠ `cargo_vendor_dir` acá es PREVENTIVO, y se pone porque la receta hermana `pdfcraft` murió por
+# esto mismo: vectorcraft **también committea un `vendor/`** y el `cargo vendor` de takana, que
+# escribe ahí por defecto, lo borra. Hoy dentro sólo hay `windows-link` —que en Linux no se compila,
+# y por eso la primera versión de esta receta selló igual sin darse cuenta— pero el día que ese dir
+# tenga algo que el build use, el fallo va a hablar de un `.cargo-checksum.json` y no de esto.
+cargo_vendor_dir = ".hammer-cargo-vendor"
 
 [build]
 compiler = "zig-cc"