simi: REPRODUCE bit a bit — y dos trampas operativas que costaron dos corridas

scripts/verificar-repro.sh simi en el worker: «✓ simi REPRODUCE», 0
no-determinismos. Queda anotado en docs/state/repro-verificado.tsv con su hash,
que es la clave del libro: si la receta o alguna dep cambia, la entrada deja de
casar y hay que volver a verificar.

Las dos trampas, anotadas en el SDD porque las dos fallan en silencio:

1. --store <tirable> NO sirve para verificar reproducibilidad. Un store vacío da
   «Error: io: No such file or directory» a secas —sin decir qué falta— porque las
   deps del build no están ahí. El método correcto ya estaba escrito: apartar el
   artefacto dentro del MISMO store y reconstruir. Dos corridas perdidas por
   inventar un instrumento en vez de leer el que existía.

2. La cosecha BORRA una receta sembrada a mano: siembra hub→worker con
   rsync --delete, y el hub del que siembra es gioser, no el clon donde se
   trabaja. El worker perdió recipes/simi.toml entre el build y la verificación
   (el artefacto sellado sobrevivió, la receta no) y el verificador informó
   «REPRODUCEN: 0 · sin artefacto: 0» — o sea nada, porque su primer [ -f ] falla
   y salta en silencio.

Comprobado de paso: editar los comentarios de la receta NO cambia el hash
(hash_inputs es una lista explícita de campos). Y el artefacto vive sólo en el
store del worker: sella con PROMOTE=0 y la cosecha baja el manifiesto, no el
store. Promoverlo es otro paso.

docs/plan-botar-busybox.md

@@ -948,6 +948,7 @@ El artefacto trae exactamente dos ficheros: `usr/bin/simi` y su `.hammer/recipe.
 | `scripts/static-audit.sh simi` | «estáticos de verdad: 1 · MIENTEN: 0» |
 | banco diferencial, 159 casos vs el ash | **0 divergencias** (bash: 8 · brush: 35) |
 | latencia de arranque | **468 µs** contra **449 µs** del ash — **1,04×** (brush: 1569 µs, 3,5×) |
+| `scripts/verificar-repro.sh simi` | **`✓ simi REPRODUCE`** — bit a bit, apartando el artefacto y reconstruyendo |
 
 ⚠ **La latencia del estático musl no es la del build nativo**: el build del hub (glibc, dinámico)
 daba 865 µs, o sea 1,4× el ash. El estático baja a 1,04×. **Medir el binario que viaja, no el que se
@@ -956,6 +957,26 @@ compila a mano** — la diferencia acá fue de un 35 % y habría quedado escrita
 ⚠ Todavía NO está en ningún perfil de `docs/state/targets.toml`. Declararla es meterla en la raíz de
 confianza del arranque, y eso es el paso 3 de abajo.
 
+⚠ **Y el artefacto vive SÓLO en el store del worker.** El worker sella con `PROMOTE=0` y la cosecha
+baja el **manifiesto**, no el store: el hub no lo tiene. Promoverlo es otro paso.
+
+### Dos trampas operativas que costaron dos corridas
+
+**1. `--store <tirable>` NO sirve para verificar reproducibilidad, y falla con un error que no dice
+nada.** Un store vacío da `Error: io: No such file or directory (os error 2)` a secas, sin decir qué
+falta, porque las DEPS del build no están ahí. El método correcto ya estaba escrito y es
+`scripts/verificar-repro.sh`: **aparta** el artefacto dentro del MISMO store (un rename, que sobrevive
+a un kill) y reconstruye, así las deps siguen en su sitio. Dos corridas perdidas por no leer el
+instrumento que ya existía antes de inventar uno.
+
+**2. La cosecha BORRA una receta sembrada a mano.** `cosecha-cron.sh` siembra hub→worker con
+`rsync --delete`, y el hub del que siembra es **gioser**, no el clon donde se trabaja. Entre el build
+y la verificación, el worker perdió `recipes/simi.toml` —el artefacto sellado sobrevivió, la receta
+no— y el verificador informó `REPRODUCEN: 0 · sin artefacto: 0`, o sea **nada**, porque su primer
+`[ -f "$f" ]` falla y salta en silencio. Hasta que gioser haga `pull` del commit, cualquier corrida en
+el worker necesita reponer la receta primero. Comprobado de paso que el hash NO cambia al editar los
+comentarios de la receta: `hash_inputs` es una lista explícita de campos.
+
 ## El alcance salió de la medición, no de POSIX
 
 | consumidor | qué necesita | estado |

docs/state/repro-verificado.tsv

@@ -251,3 +251,4 @@ gocryptfs	0caf96352eae21ed51b32be9ead8d5525bb07e8aa124eb33c4b9588f1a02421d	2026-
 sq	86de0799d816abb671cc3192daa9986adf9f6210a0be8cc1b4dfab0033d23dcf	2026-09-14	reproduce (tras poner al día un artefacto derivado)
 usql	820d3f10cf37da8603adc5da554800715705492c3ae8819f3a0a82ce0ad41d05	2026-09-14	reproduce (tras poner al día un artefacto derivado)
 gitea	5edf9c16b3a48cb44198a7d590f7c05a0f24e57429c3d05ecce92f75ce9ca19b	2026-09-14	reproduce (tras poner al día un artefacto derivado)
+simi	46ff6fcf67bd23dece4d130c92855908520200f88ca85981317f81fcc56bb834	2026-09-21	reproduce