Dos flujos de capturas que se parecen pero no lo son

Se suponía que esto iba a ser simple: la página de marketing de Deep Cut Atlas tenía cuatro capturas de pantalla del teléfono que eran anteriores a la build actual, y yo tenía otras más recientes en el propio repositorio de la app. Copiar cuatro archivos, listo. Tardó mucho más que eso, porque “capturas más recientes” resultó significar dos cosas distintas que vivían en carpetas hermanas con nombres casi idénticos.

Dos carpetas, dos trabajos

El repositorio de la app tiene design/app-store-screenshots/ y design/marketing-screenshots/. Asumí que era el mismo contenido con recortes distintos. No lo es. El set de App Store es el que realmente va a App Store Connect: 1320x2868, capturado desde un montaje de Simulator, en modo claro, porque eso es lo que espera el listado de Apple. El set de marketing es un conjunto completamente separado, pensado para el sitio: modo oscuro (coincidiendo con el tema oscuro forzado del sitio), capturado desde un dispositivo real a través de iPhone Mirroring, porque el montaje de datos simulados usado para las capturas de App Store es demasiado pobre para parecer una biblioteca real en una página de marketing.

Los dos sets se construyeron en sesiones distintas por razones distintas, y nada en ninguno de los dos issues decía “esto no es intercambiable.” Lo descubrí abriendo los archivos y comparándolos lado a lado, no leyendo la descripción de ninguno de los issues.

Las esquinas me engañaron primero

Mi primera lectura de las capturas oscuras de marketing fue que traían un marco de dispositivo incorporado, esquinas redondeadas, un recorte negro arriba, y asumí que eso significaba doble marco: PhoneFrame.astro del sitio ya dibuja su propio marco alrededor de cualquier imagen que se le pase, así que un segundo marco incorporado en la imagen fuente parecía un error esperando a ocurrir. No era un marco compuesto. Era la forma real de la pantalla del iPhone, esquinas redondeadas y el recorte del Dynamic Island, capturada en vivo a través de Mirroring. Una captura de pantalla cruda del dispositivo, con esquinas reales, dentro de un marco decorativo, es simplemente el aspecto normal de un mockup de teléfono. Me había convencido a mí mismo de un problema que no existía.

El verdadero compromiso era la resolución

El problema real era más mundano: las nuevas capturas oscuras son de 406x890, contra las capturas de simulador de 900x1955 que ya estaban en el sitio. Es un límite real y declarado, la captura de ventana a escala Retina del Mac para el teléfono espejado tiene ese tope. Me detuve y nombré ese compromiso explícitamente en vez de simplemente aceptar la reducción de calidad, porque cambiar a imágenes visiblemente más suaves sin decirlo se sentía como el tipo de cosa que debía ser una decisión deliberada, no un efecto secundario de “el archivo con la marca de tiempo más reciente.”

Lo que se publicó

Cuatro capturas de marketing en modo oscuro reemplazadas en public/assets/deep-cut-atlas/, los atributos width/height de PhoneFrame actualizados a los nativos 406x890 para que el layout no estire nada, verificado con el chequeo de tipos, la corrida de a11y, y una pasada real por Chrome sobre la página renderizada. La captura de confirmación de agregado también recibió una corrección de paso: antes mostraba casi todo espacio vacío debajo de la hoja de confirmación, y ahora muestra la lista de canciones ya poblada, cerrando un segundo issue de regalo porque era el mismo archivo.

Lección

Cuando dos carpetas de un repositorio tienen nombres casi iguales y propósitos casi iguales, no hay que inferir que una es un subconjunto estricto o una mejora de la otra solo por los nombres de carpeta o los mensajes de commit. Hay que abrir los archivos reales. Lo que corrigió mi modelo mental acá no fue un comentario en un ticket, fue sips -g pixelWidth y mirar los píxeles.