En El 99% que se queda en el cajón argumenté que lo sin terminar a menudo es matrícula, no vergüenza. Este es el otro lado: el 1% que shippeó. Shippear no es el triunfo por sí solo. Shippear sin forma de saber que te equivocaste es teatro con badge de deploy.

"Funciona en la demo" no es éxito

Un happy path en mi máquina, una grabación limpia, un slide de "ahorramos 80%" sin baseline — nada de eso es éxito. Éxito es un claim que puede morir cuando aparece la realidad. Si no puedes escribir la condición de apagado antes del happy path, estás construyendo una historia. Las historias van en decks. Los sistemas necesitan falsificadores.

Define el falsificador antes de codear

Antes de que un script, un tool o un path de producto se lleve tiempo serio, quiero una frase: Apagaría esto si _____. Ejemplos que sí cuentan:

• El rework después de "listo" sigue por encima del baseline manual por dos semanas.
• Los operadores siguen saltando el mismo número de contextos para terminar el trabajo.
• El tiempo hasta "listo para juicio humano" no baja en las colas que importan.
• El fallo es silencioso más de una vez en una semana real.

Vibes vagas ("la gente se ve más feliz") no cuentan. Si no mides la condición de apagado, no puedes reclamar la victoria.

Tres métricas que sí uso

1. Rework — qué tan seguido vuelve lo "terminado".
2. Saltos de contexto — cuántos portales, tabs o handoffs quedan.
3. Tiempo hasta el juicio — cuánto tarda hasta que un humano puede decidir, no hasta que para un spinner.

Eso mapea a la misma alergia de Un hito que no era un cargo: gente contratada por criterio no debería vivir como digitadores. Automatización que solo mueve tipeo de un lado a otro no es automatización.

Tool chico vs producto de empresa — misma barra, otro usuario

En tools.danieldiaz.dev, el usuario a menudo soy yo. La condición de apagado puede ser personal y estricta (si capturar tarda demasiado, el tool falló). En ECORPA, la condición de apagado habla de timelines de contratación de otras personas. Misma forma de regla. Distinto blast radius. Por eso las superficies se quedan separadas — ver por qué tools va aparte de ECORPA.

Qué enseñó el 1% que el cajón no podía

El cajón enseña restricciones y callejones sin salida. El 1% enseña contacto con la realidad: qué condiciones de apagado disparan, qué métricas eran fantasía, qué features "obvias" nunca merecieron quedarse. Los builds que importan comparten ese patrón. Sobrevivieron un falsificador. El resto sirvió como espacio negativo.

Checklist antes del siguiente ship

1. Escribe primero la frase de apagado.
2. Nombra el baseline con el que comparas.
3. Decide qué falla ruidoso vs qué falla cerrado.
4. Limita el blast radius para que una dependencia mala no congele todo.
5. Shippea el loop más chico que pueda morir con honestidad.
6. Agenda una fecha para leer el falsificador — no una fecha para celebrar el launch.

Si la lista se siente pesada, bien. Es más liviana que mantener una historia en la que los operadores ya dejaron de creer.