Blog
Llevar la corrección de un error desde el teléfono hasta la aceptación: el caso del enlace de imagen
Siga un error de enlace de imagen desde un informe reproducible hasta un parche específico, comprobaciones de regresión y aceptación local, con prompts preparados para móviles y un ejemplo ejecutable.
Sigue las novedades de producto e ingeniería de esta categoría.
Ver categoríaUna captura de pantalla era visible dentro de un artículo de Tactic Remote, pero el enlace destinado a abrir la imagen original se estaba reescribiendo como una URL de página. En un artículo en chino, eso significaba añadir /zh-CN/ a la dirección de una imagen compartida. La imagen en sí estaba presente; su enlace era el que estaba mal.
Este es un tamaño de tarea muy conveniente para dirigir desde un teléfono: un síntoma específico, un cambio pequeño para inspeccionar y un resultado que usted mismo puede comprobar. También expone un error común en el trabajo asistido por IA: aceptar el estado «corregido» antes de comprobar la acción que originalmente fallaba.
El caso expuesto a continuación proviene de una reparación real efectuada en este sitio web. Volvimos a ejecutar la función auxiliar (helper) de URL real antes y después de dicha reparación. La implementación histórica y las pruebas se ejecutaron en una computadora; los mensajes que siguen son ejemplos que puede enviar a través de Tactic Remote, no una transcripción de una reparación realizada íntegramente desde el teléfono. La captura de pantalla en el iPhone constituye el recurso de imagen real utilizado en la prueba de regresión. La edición de código y las pruebas se ejecutan en su computadora de desarrollo conectada, no localmente en iOS.
1. Informar la acción, el resultado esperado y el alcance
Decir «Arregla las imágenes» deja demasiado margen de interpretación. Un Agent podría reemplazar recursos que funcionan, reescribir el artículo o modificar todo el enrutamiento de idiomas. Un mensaje inicial más adecuado describe una sola acción y lo que debe seguir funcionando:
En la guía para iPhone en chino, la captura de pantalla se visualiza correctamente, pero al abrir la imagen original se utiliza una dirección errónea. Reproduce primero ese comportamiento del enlace. Las imágenes compartidas deben abrirse con su URL
/images/existente; los enlaces de artículos y documentación deben seguir respetando el idioma seleccionado. Identifica la reparación más pequeña y una prueba de regresión antes de editar el código. No modifiques el texto del artículo ni hagas cambios no relacionados.
Antes de enviarlo, seleccione el proyecto del sitio web y verifique el directorio y la rama de la conversación. Si el Agent menciona un repositorio diferente, corríjalo antes de que edite nada. La guía de configuración para iPhone cubre cómo conectarse; este caso comienza una vez que el host y el proyecto deseado están disponibles.
La distinción clave en este informe es que la imagen se muestra, pero el enlace cambia. Un elemento de imagen carga su atributo src; al hacer clic en él se sigue el atributo href del enlace contenedor. Comprobar solo la primera acción pasa por alto la segunda.
2. Solicitar un ejemplo con error antes del parche
El recurso afectado era:
La función auxiliar anterior trataba esa dirección de archivo como si fuera la dirección de una página del mismo sitio web. Su salida era:
| Idioma seleccionado | Modificación no deseada en la dirección de la imagen |
|---|---|
| Inglés | Añade una / final |
| Chino simplificado | Añade el prefijo /zh-CN/ y una / final |
En ambos idiomas debería devolverse sin cambios la dirección original de la imagen mostrada arriba.
La versión en inglés también se vio afectada: la normalización de la página añadía una barra inclinada final. Una dirección de imagen con una cadena de consulta (query string) y un fragmento también perdía dichos elementos. El archivo compartido debía evitar por completo la localización de la página.
Nuestra verificación HTTP local devolvió 200, image/png para la dirección de archivo sin modificar. La dirección no válida /zh-CN/images/...png devolvió un error 404. Estas solicitudes se realizaron contra la versión candidata local; no constituyen una medición de fallos históricos en producción ni de visitantes afectados.
Una instrucción de seguimiento útil desde el teléfono es:
Muestra la URL de entrada, la salida real y la salida esperada para un caso que falle. Incluye un enlace ordinario de documentación como control. No modifiques el resultado esperado solo para que la prueba pase.
3. Revisar el alcance de la corrección
La función auxiliar en producción ya dejaba intactas las direcciones de los ejemplos descargables. La reparación consistió en agregar las imágenes compartidas al mismo retorno temprano (early return):
Los enlaces a páginas continúan utilizando la función existente de enrutamiento por idioma. Esto está deliberadamente vinculado a los dos directorios de recursos compartidos de este sitio web; no es una regla de que toda URL que contenga un punto deba evitar la localización.
Pídale al Agent que muestre la lista de archivos modificados y este diff en la conversación, y luego inspeccione el cambio real en la vista de archivos/cambios que ofrece la aplicación. Compare la rama y las rutas mostradas con el proyecto seleccionado. Si la respuesta sugiere una reescritura amplia del enrutamiento, pregunte por qué es necesario para este fallo específico.
La reparación original se incluyó en el mismo commit que las mejoras de los artículos y las fechas. La corrección del enlace en sí es la pequeña condición anterior; el commit completo no fue un cambio de una sola línea. En su propia tarea, revise todo el diff y considere por separado el trabajo preexistente no relacionado antes de aceptar el parche.
4. Leer el resultado de la prueba, no solo la palabra «passed»
Para este caso, comprobamos seis resultados esperados en cada uno de los ocho idiomas del sitio web:
| Expectativa | Lo que protege |
|---|---|
| La dirección de imagen compartida permanece sin cambios | El enlace a la imagen original |
| La consulta y el fragmento de la imagen permanecen sin cambios | La información adjunta a una URL de imagen |
| La dirección del ejemplo compartido permanece sin cambios | Los ejemplos existentes para descargar |
| La URL externa permanece sin cambios | Enlaces a otro sitio web |
| El fragmento dentro de la página permanece sin cambios | Enlaces a secciones del artículo |
| La URL de documentación sigue el idioma | Navegación estándar del sitio |
Esto representa 48 comprobaciones, con los siguientes resultados registrados:
| Versión real de la función auxiliar | Aprobadas | Fallidas |
|---|---|---|
| Antes de la reparación | 32 | 16 |
| Después de la reparación | 48 | 0 |
Los 16 fallos corresponden a dos expectativas relacionadas con imágenes en ocho idiomas. No se trata de 16 artículos dañados, 16 usuarios ni 16 errores independientes. Los casos de control aprobados son cruciales: un parche que simplemente dejara de localizar todos los enlaces repararía el ejemplo de la imagen pero rompería la navegación por la documentación.
Descargue la reproducción ejecutable, inspecciónela y ejecútela en su computadora de desarrollo:
Utiliza las aserciones nativas de Node, se ejecuta en memoria y no realiza solicitudes de red ni modificaciones de archivos. Contiene el comportamiento pertinente de las URL antes y después, habiéndose eliminado los tipos de TypeScript. Su resultado coincide con la ejecución independiente realizada sobre las revisiones reales del repositorio. Es una reproducción enfocada, no un sustituto de la compilación o las pruebas de integración de su proyecto.
Desde su teléfono, solicite pruebas vinculadas al cambio revisado:
Informa el comando exacto, directorio, rama o commit, código de salida y las aserciones fallidas. Separa las comprobaciones completadas de las que solo recomiendas. Si editas el parche después de las pruebas, vuelve a ejecutar las comprobaciones afectadas en esa versión.
En la reparación original del sitio web, el lint del repositorio, la compilación de producción y las verificaciones de SEO también se superaron con éxito. Esas revisiones más amplias cubren aspectos distintos; ninguna de ellas por sí sola demuestra que una persona pueda abrir la imagen original en un navegador.
5. Repetir la acción del usuario en la vista previa local
Ahora regrese al artículo que originó el problema. Asegúrese de que la imagen insertada continúe cargándose, abra el archivo original, confirme que se trata de una imagen y no de una página de error, y regrese al artículo. Verifique también un enlace ordinario de documentación. Repita la operación en inglés, en una versión traducida y luego con el ancho estrecho de un teléfono.
El recurso de imagen real utilizado en esta comprobación. Tóquelo para abrir el original. Su pantalla de ejemplo nativa ilustra la configuración de la conversación; el error estaba en el enlace del sitio web, no en estos controles de la aplicación.
Cuando la vista previa se esté ejecutando en su computadora, recuerde que una dirección 127.0.0.1 abierta en un iPhone físico hace referencia al teléfono mismo. Utilice la ruta de acceso a la vista previa existente en su proyecto para comprobarla desde otro dispositivo. Un navegador de escritorio ajustado al ancho de un teléfono es una evidencia visual útil para el diseño, pero no es una prueba en un iPhone físico.
6. Aceptar el resultado en un punto de parada específico
En este caso, el sitio local reparado superó sus comprobaciones y fue aceptado en la revisión de la vista previa local. Dicha aceptación correspondió a la versión candidata del sitio web; no publicó la actualización. Tampoco establece que la tarea histórica se haya llevado a cabo íntegramente desde un iPhone.
Para una tarea similar, su mensaje final puede ser concreto:
He comprobado la imagen original y el enlace de la documentación en la vista previa local. Conserva este parche y su prueba de regresión. Resume las limitaciones restantes y luego detente antes de publicar o hacer más cambios.
Si no ha abierto la vista previa, indique lo que queda por hacer: «Las comprobaciones de la función auxiliar pasan; la aceptación visual sigue pendiente». El estado de inactividad de un Agent, un resumen de pruebas en verde y su aceptación del resultado visible responden a cuestiones diferentes.
La parte reutilizable de este caso radica en la secuencia: describir la acción que falla, conservar un caso de control, inspeccionar el cambio mínimo justificado, vincular las pruebas a esa versión y repetir la acción del usuario antes de decidir el siguiente paso. Puede tomar esas decisiones desde el teléfono mientras la computadora de desarrollo se ocupa del código. Si la conversación deja de responder en el transcurso, consulte la guía de resolución de problemas de conexión y estado de entrega antes de volver a enviar la misma instrucción.
Prueba Tactic Remote
Controla tus agentes de programación desde el móvil
Conéctate a Claude Code, Codex y otros agentes en tu Mac, Windows o Linux. Consulta el progreso y envía la siguiente instrucción desde el iPhone o iPad.