Prototipo trazable

La fase 3 del workflow: validar los PRDs (Product Requirements Document) con los stakeholders mediante un prototipo navegable antes de preparar la construcción. El prototipo no es un entregable decorativo — es el mecanismo de validación que evita construir sobre definiciones equivocadas, y al aprobarse se convierte en la referencia visual canónica del producto.

Por qué un prototipo y no código

Un PRD se valida mal leyéndolo: los stakeholders no leen documentos largos y aprueban cosas que no entendieron. Un prototipo navegable les muestra exactamente lo que el PRD describe. Cambiar el prototipo y el PRD en esta fase cuesta horas; cambiar código de producción cuesta sprints.

Propiedades del prototipo

No funcional: navegable, con datos de ejemplo. No tiene backend ni lógica real.
Trazable al PRD: cada bloque de la UI (interfaz de usuario) declara qué sección del PRD lo define.
Comentable: los stakeholders pueden dejar feedback por bloque sin fricción.
Estático y autónomo: se publica como sitio estático; la recolección de feedback no requiere que nadie esté presente.

Dirección de diseño y calidad visual

El prototipo se convierte en la referencia visual canónica del producto (ver cierre de fase): de él se consolida el design system. Por eso no puede verse improvisado — desde el primer prototipo se construye con criterio de diseño profesional, no como wireframe descartable.

Esto no contradice el principio de no sobre-invertir antes de validar: la calidad visual no es inversión funcional. Un prototipo estático bien diseñado cuesta casi lo mismo que uno feo cuando lo construye un agente UX/UI (experiencia / interfaz de usuario) con criterio y una skill de diseño — y el retorno es doble: los stakeholders aprueban lo que entienden, y la referencia canónica nace sólida.

Dirección de diseño ligera (antes de maquetar)

Antes de construir pantallas, el agente UX/UI fija una dirección de diseño ligera: paleta, tipografía, tono visual y componentes base. No es el design system completo (eso se formaliza en la fase 4, tras la aprobación) — es lo mínimo para que el prototipo se vea coherente y profesional desde el inicio.

Si el cliente tiene manual de marca, la dirección se deriva de él: colores, tipografías, logo, tono y componentes salen de la identidad existente. El manual entra como material de initial-references/ (confidencial por defecto).
Si no hay manual de marca, el agente UX/UI toma decisiones razonables y explícitas para tener una dirección provisional, marcada como tal para validarse con el stakeholder.

Skill de diseño

El agente UX/UI usa siempre la skill de diseño disponible (p. ej. frontend-design) antes de generar UI desde cero. Una skill de diseño sobre un modelo económico supera a un modelo caro sin ella — por eso el UX/UI se mantiene en un tier intermedio (ver efficiency.md).

El design system crece con el prototipo (no nace en fase 4)

La dirección de diseño ligera es la semilla de un design system que crece dentro del prototipo —su CSS lo va encarnando— durante toda la iteración, y que la fase 4 consolida: lo extrae a artefacto canónico (documento + tokens en código, accesibilidad por defecto). No lo crea de cero. Son tres estados de una misma cosa:

Semilla (aquí, antes de maquetar): paleta, tipografía, tono, componentes base.
Crecimiento (durante la iteración): cada ajuste confirmado refina prototipo, design system y PRD juntos (ver la Definition of Done (DoD) abajo y el comando de ciclo de ajustes).
Consolidación (fase 4): se extrae del prototipo aprobado al design system formal.

Si el cliente trae design system / manual de marca de entrada, ese artefacto ya es canónico desde la semilla y el prototipo se ciñe a él; la fase 4 reconcilia tokens y lo cierra, no rehace.

Mecanismo de trazabilidad granular

Cada feature/bloque lleva un atributo de referencia (ej. data-prd="§7.3 · RDA automática").
En modo demo, ese atributo pinta una insignia clicable junto al componente (ej. RF-2 · F3 · decisión 8) que enlaza a la sección exacta del PRD.
Las dudas y aclaraciones para el cliente se agregan como pequeñas notas en los lugares adecuados del prototipo. Cada duda está también registrada en el PRD y enlazada desde el demo. Estas notas solo se ven en modo demo.

Validación de consistencia (opcional, recomendada)

Un script liviano verifica que cada §x referido en el prototipo existe en el PRD, y que cada sección relevante del PRD tiene al menos un ancla en el prototipo. Detecta divergencias antes de que lo haga un stakeholder.

Mecanismo de feedback

Dos canales complementarios, ambos de baja fricción:

Comentario por bloque: los comentarios se acumulan (localStorage) y se exportan como lista Markdown/JSON — ese export es literalmente el input para iterar los PRDs.
Formulario por correo: un servicio tipo Formspree envía el feedback directo al correo, sin backend propio. Funciona bien sin agregar fricción.

Definition of Done de todo cambio al prototipo

Ningún cambio al prototipo se considera terminado si no actualiza las superficies que toca:

(a) el HTML del prototipo
(b) la prosa del PRD (y su tabla de requisitos si aplica)
(c) la referencia de trazabilidad (PRD_REF / data-prd)
(d) los specs
(e) el design system — cuando el ajuste toca apariencia (tokens, componentes, patrones). Si el cliente trae un design system formal, se actualiza ahí; si no, se actualiza la dirección de diseño que el prototipo encarna. Mantiene el hilo progresivo alineado.

Esta DoD se codifica como tareas en el change de OpenSpec correspondiente — así no se olvida.

El ciclo es de a un ajuste, con confirmación humana antes de propagar: se aplica el cambio solo al prototipo → el stakeholder lo confirma o lo descarta → si lo descarta, se revierte; solo si lo confirma se propaga a las demás superficies que toque (PRD, design system, trazabilidad, specs) y se reporta exactamente qué se propagó. Se limpia contexto entre ajustes. Este ciclo se opera con el comando de ciclo de ajustes (templates/commands/prototype-adjust.md).

Andamiaje reutilizable

La maquinaria de este capítulo — modo demo, insignias data-prd clicables, notas de aclaración, comentario por bloque con export Markdown/JSON, envío opcional por Formspree y el script de validación de consistencia — es idéntica entre proyectos. Argui la entrega como artefacto reutilizable en templates/prototype/: HTML/CSS/JS vanilla, sin framework, que se copia al prototipo y se cablea con atributos data-prd.

Es un mecanismo, no un agente: por eso sí se distribuye (a diferencia de los agentes). Para proyectos en Claude Code se incluye además un envoltorio de skill (SKILL.md). El mecanismo es portable; la skill es solo el empaquetado.

Cierre de la fase ✋

La fase termina cuando los stakeholders aprueban el prototipo explícitamente. A partir de ahí:

El prototipo es la referencia visual canónica del producto.
El primer item del backlog (fase 4) consolida el design system que venía creciendo en el prototipo: lo extrae del prototipo aprobado a artefacto canónico —documento de referencia + tokens en código— para que no haya divergencia de apariencia entre lo que el stakeholder aprobó y lo que se entrega. No lo crea de cero; lo formaliza. (Si el cliente trajo design system de entrada, este paso reconcilia tokens y lo cierra como canónico.) El design system incluye accesibilidad por defecto (foco visible, contraste verificado en los tokens, semántica de componentes) — ver standards.md §3.
Los PRDs quedan sincronizados con lo aprobado (la DoD lo garantiza).

El prototipo después del lanzamiento

Su trabajo —validar definiciones antes de construir— termina al aprobarse el prototipo y consolidarse el design system. En evolución continua (ver workflow.md fase 6) su rol es acotado, no fuente de verdad:

Las fuentes de verdad post-lanzamiento son el PRD/specs (comportamiento), el design system (apariencia) y el producto/código (lo construido).
No se actualiza con cambios chicos ni espeja lo que ya está en producción —espejear algo que se puede clicar es sobre-inversión.
Sí se usa para maquetar trabajo nuevo, significativo y visible antes de construirlo, ahora con los componentes del design system canónico (más fidelidad, más barato, y siembra la implementación). La maquinaria de trazabilidad y feedback de este capítulo sigue aplicando a ese slice nuevo.