El prototipo que produce el requerimiento

Hay un caso donde preguntar no alcanza, y es el más caro: un módulo nuevo, con pantallas que no existen en ningún lado, y alguien de negocio que sabe qué necesita pero no cómo se captura ni cómo debería verse.

Ahí las preguntas abiertas se acumulan porque no se pueden contestar en abstracto: nadie sabe describir una pantalla que nunca vio. Y el prototipo de kbspec no llegaba, porque nacía de las fichas PT-NN del análisis —que en ese momento todavía no existen—.

Es más fácil reaccionar a algo que imaginarlo.

Los dos caminos, y cuándo es cada uno

	Cuándo	De dónde sale
`kb prototipo --brief`	Ya está claro qué hace la pantalla y se quiere acordar el diseño antes de programar	De las fichas `PT-NN` del `03`
`kb prototipo --explorar`	Todavía no hay qué especificar: módulo nuevo, definición floja	De la solicitud, de las preguntas abiertas y del sistema de diseño de la app

--explorar va antes de la ficha, no después. Si el expediente no tiene preguntas abiertas, el comando lo dice y te manda al camino normal: ese no es su caso.

La ronda

1 · La pregunta va arriba del archivo

Visible y en una línea: qué se está tratando de decidir. Un prototipo que contesta la pregunta equivocada es trabajo tirado, por bien que se vea.

kb prototipo --explorar --pregunta "¿cómo registra una sucursal una excepción?"

Queda también como marca dentro del HTML (), para que kbspec la lea después sin que nadie la vuelva a escribir.

2 · Tres variantes, no una

Con una sola, quien revisa dice «está bien» porque no tiene contra qué compararla. La opinión útil aparece cuando hay tres: «el encabezado de la B con la barra lateral de la C».

Las variantes tienen que estar en desacuerdo sobre la estructura: qué se ve primero, qué se esconde, si el detalle es una página o un panel, si el filtro va arriba o al costado. Tres veces el mismo diseño con otro color no son tres opciones: son una.

Lo que no cambia entre variantes son los tokens, los componentes y el patrón de página — eso es lo que las hace parecerse a la app. El brief los saca de la ficha interfaz.md (kb interfaz sembrar <APP> la genera desde el código real).

3 · La vuelta al expediente

Es lo que hace que esto sea parte del ciclo y no un dibujo:

kb prototipo --decidir --variante B --porque "el filtro al costado deja ver la lista" \
    --responde P-02="Sí, el supervisor la devuelve a Borrador" \
    --abre "¿qué pasa si editan mientras el supervisor revisa?"

Tres cosas vuelven, y no son iguales de valiosas:

Qué variante ganó y por qué — queda en la bitácora de auditoría, no en la conversación.
Qué preguntas quedaron contestadas — cada P-NN pasa a ✅ en el 01 con su respuesta.
Qué preguntas abrió — el «pará, eso no debería poder hacerse». Vale más que lo que confirmó, porque es un hallazgo sobre el requerimiento y no sobre el dibujo.

Cuando la pregunta es cómo se comporta

Una pantalla se entiende mirándola; un flujo de aprobación, no. Quién puede devolver un trámite, a qué estado vuelve, qué pasa si el aprobador es el mismo que lo creó: eso no se ve en una imagen ni se entiende leyendo una tabla de transiciones. Hay que poder apretarle botones, y tiene que poder apretárselos quien conoce el negocio.

kb prototipo --comportamiento --pregunta "¿quién puede devolver y a qué estado vuelve?"

El brief pide un HTML autocontenido con el estado a la vista, un botón por transición —habilitado o no según el estado, y que se vea por qué no se puede apretar— y pestañas con recorridos guiados: un escenario por pestaña. Se nombra con el glosario del equipo, no con las palabras del código.

La lógica va en un módulo aparte de la pantalla, para que la versión validada se levante tal cual al código real.