Cómo trabajamos

El mapa del proyecto: quién es quién, de dónde sale el contenido, dónde vive todo y cómo se monta una página. Escrito para alguien de diseño que llega nuevo, no para un perfil técnico.

Qué es esto

La web nueva de SEK (colegios SEK International School y la universidad UCJC), en WordPress con Gutenberg. Tres equipos en el mismo repositorio: UX hace los wireframes, UI —nosotros— los convierte en maquetas de alta fidelidad, y dev las lleva al theme de WordPress.

Lo que entregamos no es código para copiar: es la especificación visual. Dice cómo tiene que verse; dev reproduce los estilos y reescribe el HTML por debajo con sus propios bloques.

El equipo

Quién	Equipo	Qué hace	Su rama
Carla López	UX	Wireframes y contenido. Es a quien se le pide el copy que falta y quien decide cuando el wireframe deja algo abierto	`ux/carla`
Irene Galán	UX	Wireframes	`ux/irene`
Guillermo Varela	UI	Maquetación y sistema de diseño	`ui/guille`
Gabriela Preda	dev	Theme de WordPress	`dev/gabriela`
Eduardo Gil	dev	Theme de WordPress	`dev/eduardo`

Para lo que falta de contenido o hay que decidir, la interlocución es con UX — está todo listado en Para UX. Para bugs del theme y cómo migrar, con dev — en Para dev.

De dónde sale una página

El board de sprints manda. Es un Google Sheet donde UX marca qué wireframes están listos. Una página es «pintable» cuando su columna UX está en ✓ DONE. El mapa está en SEK 2026/brain/Architecture/sprints-board.md, con el enlace al sheet.
El wireframe está en Figma, en el archivo [SEK] Library 2026. Unos llegan como capturas de pantalla y otros —los últimos— como texto: doce secciones con su título, su contenido y el «Formato» que pide cada una. Los de texto son mucho mejores: el copy es literal y no hay que interpretar.
Se monta a partir de los bloques reales de staging, no escribiendo HTML: se descarga el bloque ya publicado y se le sustituye el contenido. Así la paridad con el theme es 1:1 por construcción y dev no tiene que adivinar nada.
Se revisa mirando, no leyendo código: se abre la página y se compara con el wireframe.

La regla que más disgustos ha evitado: cuando el wireframe describe algo pero no lo aporta —un testimonio, unas cifras, una foto real— no se inventa. Se monta la estructura con el hueco marcado como pendiente y se anota en Para UX. Un dato inventado que llega a producción es mucho peor que un hueco visible.

Dónde vive todo

Qué	Dónde
El repositorio	Bitbucket · `pixeldivisiondev/sek-gutenberg`
En el ordenador	`~/Documents/Gut Projects/SEK 2026/dev/sek-gutenberg`
Donde se trabaja	`ui/guille/` — una carpeta `dev-<página>/` por maqueta
Lo que coge dev	`ui/output/` — solo lo revisado
Los wireframes de UX	`ux/output/` en el repo, y el Figma [SEK] Library 2026
El theme de WordPress	La raíz del repo — no se toca

Nuestra rama es ui/guille, y de ahí se sube a ui/main. Solo se toca la carpeta ui/: ni ux/ ni el theme.

Cómo se monta una maqueta

Cada página tiene dos ficheros dentro de su carpeta dev-<nombre>/:

contenido.mjs — el copy, literal del wireframe. Es donde se cambian los textos, y se puede tocar sin saber programar: son frases entre comillas.
build.mjs — qué módulo usa cada sección y con qué fotos.

Y un solo comando lo hace todo:

node compilar.mjs

Compila las 12 páginas, comprueba que cumplen los criterios, publica en ui/output las revisadas y regenera estas pestañas. Si algo incumple un criterio, no publica: avisa y para.

Por qué las 12 páginas se parecen entre sí

Esto es lo más importante que hay que entender del proyecto, porque cambia cómo se trabaja.

Al principio, cada criterio de diseño se arreglaba en la página que se estaba mirando. Resultado: la siguiente nacía con el mismo fallo y la revisión repetía el mismo comentario una y otra vez.

Ahora cada acuerdo es una comprobación automática. Hay 27 reglas que se pasan a todas las páginas en cada compilación —que los enlaces vayan en negro, que la tinta se lea sobre su fondo, que los iconos tengan un solo grosor, que el espaciado salga de un token…—. La lista completa, con el motivo de cada una, está en Para dev.

De ahí sale la regla de oro: un arreglo nunca se hace en la página que se está mirando, sino en la librería común, donde llega a todas. Si te ves editando el build.mjs de una página para corregir algo de estilo, casi seguro que estás en el sitio equivocado.

Las tres pestañas

Pestaña	Para quién	Qué hay
Páginas	Todos	Las 12 maquetas por sprint
Para dev	Gabriela y Eduardo	Lo que está roto en staging, lo que corregimos nosotros y los criterios a mantener al migrar
Para UX	Carla e Irene	Los 41 puntos pendientes, cada uno con enlace a la sección donde se ve y al wireframe de Figma

Las tres se generan solas al compilar. No se editan a mano: se escriben en ui/output/registro-dev.md y ui/context/registro-ux.md, que son la fuente.

Si algo se atasca

Un cambio no se ve. Casi siempre es la caché del navegador: Cmd+Shift+R. Pasó una vez y costó un rato.
El enlace que se comparte deja de funcionar. El túnel cambia de nombre al reiniciarse aunque el proceso siga vivo. Se relanza y da uno nuevo.
Algo se ve raro en una maqueta. Antes de arreglarlo, mirar si es un criterio: está en Para dev con su motivo.
La documentación larga está en ui/CLAUDE.md (el proceso) y ui/guille/README.md (el taller y las trampas conocidas).