ui-lab

Laboratorio de UI: sugerencias de UX

Una sugerencia de UX pasa por tres fases:

1. Maqueta — solo cambia el código del laboratorio, en la plataforma que indican las notas del proyecto. El propietario navega por las opciones.
2. Cerrar la ronda — la ronda se etiqueta y se documenta en docs/ux-history/, y sus archivos de laboratorio se eliminan.
3. Promover — después de que el propietario elija una opción y apruebe un plan, se convierte en la pantalla real, con su lógica compartida y la otra plataforma si la aplicación la tiene.

Notas del laboratorio del proyecto

Este skill es el proceso; los detalles específicos de cada proyecto viven en su .claude/ui-lab.md. Léelo antes que nada. Proporciona:

• Plataforma: qué aplicación de laboratorio usar en esta máquina (uname -s), su id, dónde va el código del laboratorio y el comando que abre una pantalla;
• Carpetas de opciones: la carpeta y el paquete por plataforma, y dónde van las cadenas de texto;
• Archivos: el tema o los colores que usa una pantalla de opción, y hacia dónde se mueve su estado al promover;
• Datos de muestra: de qué construyen los datos las opciones;
• Falsificaciones y casos límite: qué datos inventados no se pueden mostrar en esta aplicación, y los casos a verificar;
• Capturas de pantalla: cómo tomar una por plataforma;
• Promover: rutas de destino, manejo de la otra plataforma, documentos a actualizar y comandos de compilación de lanzamiento;
• cómo funciona el laboratorio en sí (un enlace a un documento).

Las notas tienen prioridad donde difieren de este skill. Si el proyecto no tiene .claude/ui-lab.md, o le falta algo de lo que se necesita a continuación, pregúntale al propietario en lugar de adivinar, y añade la respuesta a las notas.

Fase 1: maqueta

Trabaja en una rama ux/<pantalla> desde la rama actual, para que otra máquina pueda descargar la ronda. Si el árbol tiene cambios sin confirmar que no son tuyos, pregunta antes de cambiar.

Una carpeta por opción

Cada opción vive en su propia carpeta (las notas indican dónde), para que pueda eliminarse, revivirse o promoverse sola. Está en el paquete de pantallas, por lo que promoverla es mover un archivo.

Archivo	Contiene	Al promover
<Pantalla>Opción<B>	la pantalla, <Pantalla>Screen<B>(estado, acciones): calidad de producción (las cadenas de texto y el tema de la aplicación, según las notas) y libre de tipos de laboratorio	se mueve a la aplicación
<Pantalla>Opción<B>State	estado que la lógica de la aplicación aún no produce, modelado como lo produciría	se mueve a donde indican las notas
<Pantalla>Opción<B>Lab	sus datos de muestra, comportamiento falso, acciones vacías, y su valor LabOption con lo que falsifica arriba	se elimina
las cadenas de texto de la opción, cuando la aplicación usa recursos de cadenas (nombres y ubicación según las notas)	el texto nuevo de la opción	se mueve a las cadenas de la aplicación

• Además de la carpeta (y los archivos de cadenas donde los recursos no pueden estar en ella), una opción añade una línea: su entrada en la lista de su pantalla en LabScreens (<pantalla>OptionB,).
• Todo en la carpeta es private excepto la pantalla, su estado y el valor LabOption, cuyos nombres llevan la opción, para que las opciones nunca choquen.
• Una opción que necesita una versión modificada de un componente existente de la aplicación usa su propia copia, en su carpeta.
• Los datos de muestra provienen de las fuentes que nombran las notas, tal como son, más lo que la opción añade en su archivo Lab. No inventes texto donde las notas dicen que los datos son reales.

Pasos

1. Abre la pantalla en el laboratorio y observa current, la pantalla tal como la tiene la aplicación ahora.
2. Escribe 2–3 direcciones distintas como opciones a, b, c después de current, cada una con una nota de una línea sobre qué cambia.
3. Sobre cada valor LabOption, enumera lo que la opción falsifica: datos que la lógica de la aplicación no tiene, comportamiento que no está construido, y qué datos inventados no pueden mostrar (las notas enumeran los habituales de esta aplicación).
4. Verifica los casos límite que enumeran las notas, más lo que sea inusual para la pantalla. Un caso que cambie el diseño se convierte en su propia opción (a-rtl, a-dark).
5. Compila, abre cada opción y mira una captura de pantalla (comandos en las notas; el skill de emulador de Android cubre los dispositivos Android). Una captura de pantalla completamente negra de un teléfono significa que está bloqueado: pídele al propietario que lo desbloquee.
6. Confirma en la rama e informa al propietario los ids de las opciones (<pantalla> <opción>), qué falsifica cada una, y el dispositivo.

Cuando el propietario pida cambiar una opción, el cambio se convierte en una nueva opción en su propia carpeta (b2 junto a b). Las opciones que el propietario descarta permanecen hasta que se cierra la ronda, para que la etiqueta de la ronda las tenga todas.

Fase 2: cerrar la ronda

Cuando el propietario haya elegido una opción o las haya rechazado todas:

1. Etiqueta el último commit de la ronda, mientras todas las opciones aún están en él, y sube la etiqueta: git tag ux/<pantalla>/<aaaa-mm-dd> && git push origin ux/<pantalla>/<aaaa-mm-dd>. La etiqueta mantiene el código accesible después de que la rama desaparezca; una segunda ronda el mismo día recibe -2.
2. Escribe docs/ux-history/<pantalla>/<aaaa-mm-dd>-<tema>.md en el formato siguiente, y enlácelo desde donde digan las notas (el documento de una pantalla, por ejemplo).
3. Elimina las carpetas de las otras opciones, los archivos de cadenas y las líneas de LabScreens; la opción elegida permanece hasta la fase 3.
4. Confirma. Con todas las opciones rechazadas, la ronda termina aquí: fusiona la rama (el archivo de historial es su único cambio duradero) o elimínala, según prefiera el propietario.

# <Pantalla> — <tema> (<aaaa-mm-dd>, <plataforma>)

Etiqueta: `ux/<pantalla>/<aaaa-mm-dd>`

## Opciones
- **a — <nombre>**: <qué cambia>. *Elegida*, promovida en <commit>.
- **b — <nombre>**: <qué cambia>. *Rechazada*: <la razón del propietario, cuando se da>.

## Lo que falsificaron
- b: <lo que mostró la maqueta que la aplicación aún no puede hacer>.

## Revivir una opción
    git checkout ux/<pantalla>/<aaaa-mm-dd> -- <carpeta de opción> <archivos de cadenas>
Luego añade `<Pantalla>Option<B>,` a `LabScreens`.
Construido contra <componentes y datos de muestra que usó> a partir de la etiqueta. Los errores de compilación después de revivir están en las copias de la opción y los datos de muestra; arréglalos allí.

Revivir

Cuando el propietario pida una opción anterior, sigue su archivo de historial: saca las rutas de la etiqueta a una rama ux/<pantalla>, añade la línea de LabScreens, corrige lo que ya no compile dentro de la carpeta de la opción, y ábrela. Entonces es una opción viva de una nueva ronda.

Fase 3: promover

Con la ronda cerrada sobre una opción elegida, ingresa al modo plan (EnterPlanMode) y presenta el plan con ExitPlanMode; el propietario lo aprueba con su botón. El plan cubre:

• los archivos que se mueven y la pantalla que reemplazan;
• el trabajo de lógica detrás de cada elemento falsificado: los cambios propuestos de estado, modelo de vista o controlador, y sus pruebas;
• la otra plataforma, cuando la aplicación la tiene, según las notas;
• los documentos que las notas indican actualizar.

Después de la aprobación, en la misma rama:

1. git mv el archivo de la pantalla de la opción a la aplicación (destino según las notas), reemplazando la pantalla anterior, y dale a la función o vista el nombre de la pantalla.
2. Mueve sus cadenas de texto a las de la aplicación, sin el prefijo ni la tabla de la opción.
3. Mueve su estado a donde indican las notas, haz que la lógica de la aplicación lo produzca con pruebas y conecta las acciones.
4. Fusiona sus componentes copiados de nuevo a los originales y elimina el resto de su carpeta y su línea de LabScreens; apunta el current de la pantalla en LabScreens a la pantalla promovida.
5. Compila la versión de lanzamiento con los comandos de las notas, donde cualquier referencia al código de laboratorio falle al compilar.
6. Haz las partes de la otra plataforma y los documentos del plan, y coloca el commit de promoción en el archivo de historial de la ronda.

Fusionar la rama es decisión del propietario.