sergio/takana

Faltaba decir en el ADR lo que se confunde solo: "pinear" no significa que la
imagen no se actualice. El digest es la IDENTIDAD, igual que en el rootfs del
lab. Lo que se pinea es el suelo; lo que instalás adentro con dnf/pacman ni
está pineado ni puede estarlo, y se actualiza normal.

Subir la base de versión es barato PRECISAMENTE por D3: manifiesto = verdad,
upper = caché ⇒ cambiar el digest y recrear. Y el riesgo del pin (que upstream
borre el tarball) ya lo resolvió ADR 0013: la URL no entra en la identidad,
sólo el sha256, así que espejar es gratis.

Curaduría decidida con el usuario — TRES, cada una por un trabajo distinto:
- Arch bootstrap (juegos: multilib 32-bit y SteamOS es Arch ⇒ extiende D6),
- Ubuntu base LTS (binarios comerciales: es contra lo que se compilan),
- Steam Runtime sniper (la única SELLABLE: inmutable ⇒ file_drop al store).
Fedora queda BYO: hace el mismo trabajo que Arch en el slot "fresco" y una
tercera cadena mutable es la normalización que §NO-resuelve 3 quiere evitar.

Los pines de las dos primeras están VERIFICADOS contra upstream hoy (Arch
2026.09.01 sha 895661bd…, Ubuntu 24.04.3 sha 6bc2cde3…); el de sniper NO, y se
dice que no en vez de suponerlo.

Y queda anotado que hacerlas compartibles más adelante no pide diseño nuevo:
una imagen pineada es cuerpo inmutable direccionado por contenido ⇒ ADR 0014
se le aplica tal cual. Lo único que hay que mirar antes de publicarlas a
terceros es licencia y marca, que no es una pregunta técnica.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U5cQtQrYNjWJVXVE6aEpQ2

diff --git a/docs/adr/0015-imagenes-ajenas.md b/docs/adr/0015-imagenes-ajenas.md
index 670644e0..3e60969a 100644
--- a/docs/adr/0015-imagenes-ajenas.md
+++ b/docs/adr/0015-imagenes-ajenas.md
@@ -235,6 +235,52 @@ se compila al mismo `PolicySpec` que ya consume `harkaq-exec`.
 
 Un `dnf` que no alcanza `~/.ssh` es un argumento que ninguna distro ofrece.
 
+### D8 — Qué se pinea (el suelo, no la instancia) y cuántas imágenes se curan
+
+Dos preguntas que se confunden y tienen respuestas distintas.
+
+**a) Pinear no congela: fija el punto de partida.** El digest ES la identidad, igual que
+`alpine-minirootfs`, `zig` y el rootfs del lab. Lo que queda dentro y fuera del pin:
+
+| qué | ¿pineado? | cómo se actualiza |
+|---|---|---|
+| el rootfs base | **sí**, por sha256 | cambiar el digest en `instancia.toml` + `hammer qorpa recrear` |
+| lo que instalás adentro (`dnf install steam`, `pacman -Syu`) | **no, y no puede estarlo** | con el gestor de la imagen, cuando quieras |
+
+Subir la base de versión es barato **precisamente por D3**: como el manifiesto es la verdad y el
+`upper/` es caché, se cambia `base = "sha256:…"` y se recrea. Sin D3 sería un rebase sobre un blob
+irreemplazable; con D3 son dos líneas y un rato de red.
+
+El riesgo real del pin —que upstream borre el tarball— **ya está resuelto por
+[ADR 0013](0013-mirror-de-fuentes.md)**: la URL no entra en la identidad, sólo el sha256, así que
+espejar una imagen es gratis y una imagen pineada no se puede perder.
+
+**b) Pinear ≠ lista cerrada.** `hammer qorpa traer <url> --sha256` acepta cualquier rootfs. Lo corto
+no es lo que *se puede* traer, sino lo que **nosotros probamos, espejamos y publicamos**, porque cada
+imagen curada es una segunda cadena de suministro que hay que sostener (§NO-resuelve 3). Se curan
+**tres**, y cada una entra por un trabajo distinto — no por sabor:
+
+| imagen | tipo | qué trabajo hace | pin (verificado 2026-09-03) |
+|---|---|---|---|
+| **Arch bootstrap** | 1 | juegos: `multilib` de 32 bits de primera clase, y SteamOS *es* Arch ⇒ extiende el argumento de D6 («la configuración exacta que Valve prueba») | `archlinux-bootstrap-2026.09.01-x86_64.tar.zst`, sha256 `895661bd…`, en `archive.archlinux.org` (archivado para siempre) |
+| **Ubuntu base LTS** | 1 | binarios comerciales: Zoom, Slack, Discord, Spotify, Chrome, JetBrains se compilan y prueban contra esto | `ubuntu-base-24.04.3-base-amd64.tar.gz`, sha256 `6bc2cde3…`, `cdimage.ubuntu.com` + `old-releases` |
+| **Steam Runtime «sniper»** | 2 | la única **sellable**: al no mutar entra al store por `file_drop` y su digest va al índice firmado — cadena de custodia nuestra | ⚠ pin sin verificar todavía |
+
+**Fedora queda BYO, no curada.** No por calidad —publica `Fedora-Container-Base-Generic-43-1.6`
+con CHECKSUM firmado y se pinea igual de bien— sino porque hace el **mismo trabajo que Arch** en el
+slot «fresco», y una tercera cadena mutable es justo la normalización que §NO-resuelve 3 quiere
+evitar. El ejemplo de D3 sigue diciendo `fedora-43` a propósito: el mecanismo no distingue, y eso es
+la demostración de que la terna es una decisión de curaduría, no del diseño.
+
+**c) Compartibles, más adelante.** Una imagen pineada es cuerpo inmutable direccionado por
+contenido, así que **[ADR 0014](0014-distribucion-multiorigen.md) se le aplica sin cambiar nada**:
+puede servirse desde cualquier origen porque el digest la verifica, y ausencia ⇒ seguir mientras que
+contenido distinto ⇒ ABORTAR. No se hace el día uno, pero no hay que diseñar nada para que se pueda:
+lo único que falta es la decisión. ⚠ Antes de publicarlas a terceros (no a nuestras propias
+máquinas, que es lo que ya hace ADR 0013 con las fuentes) hay que mirar licencia y **marca**:
+redistribuir un rootfs de Ubuntu o Fedora sin modificar suele estar permitido, pero la política de
+marca es cosa aparte y no es una pregunta técnica.
+
 ---
 
 ## Lo que este ADR admite que NO resuelve