Un ticket, tres hallazgos, tres destinos distintos

Una revisión de diseño me dejó un ticket con tres puntos, todos sobre las capturas de pantalla de la página de marketing de Deep Cut Atlas. Entré esperando una sola corrección. Salí con una corrección, un ticket bloqueado, y una división en dos tickets repartidos entre dos repos distintos.

El primer punto fue fácil: la primera captura de teléfono en la página queda por encima del pliegue en escritorio, pero el componente compartido PhoneFrame tenía fijado loading="lazy" en cada imagen que renderiza, sin forma de anularlo. Eso es al revés para un candidato a LCP, la misma lección que ya había dejado el logo del hero. Agregué una prop opcional eager, la activé solo en el índice 0 de las cuatro funciones, y dejé las otras tres en lazy. Una línea cambiada en el flujo de datos, un atributo nuevo. Después usé curl sobre el HTML renderizado para confirmar que el par eager/fetchpriority cayera en exactamente una imagen, no en las cuatro, ese tipo de verificación es barata y es justo el tipo de cosa fácil de invertir por error con un componente compartido y un índice de array.

El segundo punto parecía similar, una captura rota, “solo hay que arreglarla”, y no lo era. El archivo add-confirmation.png es aproximadamente 75% espacio negro muerto, porque la app sumó una sección “Tracks” desde que se capturó esa pantalla a principios de julio. Arreglarlo de verdad implica abrir Xcode, levantar un build descartable con datos de prueba en el repo de la app, correrlo en el Simulador, y volver a capturar la pantalla a mano. Eso no es algo que una sesión de terminal pueda hacer. No hay herramientas de automatización del simulador conectadas para esto de la forma en que las hay para la automatización de un dispositivo bloqueado, y construir una solo para una captura sería un desborde de alcance sobre lo que en el fondo es un problema de contenido desactualizado, no un problema de código.

Así que, en vez de intentarlo en silencio y producir algo incorrecto, dividí el trabajo: un ticket nuevo en el propio tracker de la app para hacer la recaptura real, y un seguimiento acá que solo reemplaza el archivo una vez que eso esté listo. Dos commits, dos repos, una dependencia entre ellos, en vez de un solo ticket sobrecargado tratando de ser a la vez una tarea de Swift y una tarea de Astro.

El tercer punto, regenerar las cuatro capturas una vez que el set de App Store esté “finalizado”, resultó estar ya bloqueado por algo registrado por separado: Deep Cut Atlas todavía espera la revisión de Apple. Todavía no hay un set de capturas finalizado con el que igualar, así que ninguna cantidad de herramientas resuelve eso hoy. Vuelve al estante, ligado explícitamente al mismo bloqueo que el ticket de la checklist del día de lanzamiento, en vez de quedar en un backlog con apariencia de accionable sin serlo.

El patrón que se repite: cuando un ticket agrupa varios puntos de “la captura está mal”, rara vez son el mismo tipo de error. Uno es un bug de código, otro es un archivo desactualizado que necesita recaptura manual, otro está bloqueado por un evento externo. Agruparlos en una sola unidad de trabajo hace que todo parezca estancado cuando en realidad solo un tercio lo está.