Localhost equivocado: tu agente edita y tú no lo ves

Si tu agente modifica archivos pero el navegador sigue mostrando lo mismo, comprueba que estás viendo el servidor asociado a esos archivos antes de pedir otro parche. En desarrollo local, una pestaña abierta y un servidor recién arrancado pueden apuntar a puertos distintos. La URL forma parte del diagnóstico.

Una pantalla sin cambios no demuestra que el parche falle

Suspende las modificaciones hasta relacionar la pestaña con el servidor que estás usando. Si el navegador está mostrando otra instancia de la aplicación, su aspecto no permite evaluar el trabajo del agente. Pedirle que vuelva a corregir el componente introduce cambios sin haber comprobado el anterior.

Supongamos que tienes una aplicación con Vite y pides al agente cambiar el texto de un botón. El archivo contiene la modificación, pero la pestaña conserva el texto anterior. Podrías sospechar del componente, de la ruta o de la recarga automática. Antes de investigar esas posibilidades, falta una comprobación más básica: qué dirección estás abriendo y qué servidor responde allí.

Este diagnóstico está pensado para una aplicación web en desarrollo local cuyo servidor puedes identificar. No necesitas cambiar de agente ni darle acceso al navegador: puedes recoger tú la información y pasársela. Lo importante es que el diagnóstico parta de observaciones concretas, no únicamente de la frase "sigue igual".

Como criterio práctico, separa estas preguntas: ¿se guardó el cambio?, ¿se está sirviendo desde la instancia esperada?, ¿produce el comportamiento correcto? Aquí vas a resolver la segunda. Que el archivo tenga el contenido solicitado permite continuar la investigación, pero todavía no demuestra qué contenido ha recibido la pestaña que estás mirando.

Vite puede arrancar en un puerto distinto del solicitado

El puerto configurado no siempre coincide con el puerto efectivo. Según la documentación oficial de las opciones del servidor, si el puerto solicitado está ocupado, Vite intenta utilizar el siguiente disponible. Por tanto, debes consultar el arranque real, no deducir la dirección únicamente de la configuración.

Supongamos que una instancia anterior ocupa el puerto 5173 y arrancas otra mientras 5174 está libre. Con ese comportamiento predeterminado, la nueva instancia podría quedar en el segundo puerto. Una pestaña que conserve la dirección del primero seguiría apuntando a la instancia anterior. Es un escenario hipotético, no un resultado medido.

También debes identificar el directorio servido. La documentación de inicio de Vite explica que el directorio de trabajo actúa como raíz al arrancar vite, salvo que se especifique una raíz alternativa. Un nombre de carpeta parecido no basta para relacionar el servidor con los archivos que edita el agente.

Pide la ruta absoluta del proyecto, la orden de arranque y la URL anunciada. Si el agente no conserva esa salida, debe señalar que falta esa evidencia. No conviertas una dirección supuesta en un hecho porque aparezca en una respuesta convincente. Tampoco cierres un servidor todavía: primero identifica cuál corresponde al trabajo actual y cuál podría pertenecer a otra tarea.

Comprueba la dirección que recibe realmente el navegador

Contrasta la URL del servidor con una petición del navegador. Para una conexión local directa, compara protocolo, nombre del host y puerto. Conserva también la ruta de la página donde esperas ver el cambio, porque abrir otra pantalla impediría comprobar el resultado aunque el servidor fuese correcto.

En Chrome, abre DevTools y entra en Network. Recarga la página y localiza la petición del documento. La referencia oficial del panel Network documenta las columnas URL y Remote address, que muestran la dirección completa solicitada y la dirección IP con el puerto remoto. Puedes activarlas desde el menú de las cabeceras de la tabla.

Anota los valores observados y compáralos con el arranque que has identificado. Si no coinciden y no utilizas intermediarios, abre la dirección de ese arranque y vuelve a comprobar el cambio. No hace falta modificar el código para realizar esta prueba. Su resultado esperado es determinar si estabas evaluando otra instancia.

Si las direcciones coinciden, aún queda por comprobar el contenido recibido. Network permite seleccionar una petición y consultar su cuerpo en Response, según la misma referencia. Busca el recurso relacionado con la modificación, no una petición cualquiera de la página.

Una captura de pantalla puede acompañar el diagnóstico, pero conserva también la URL observada como texto. Así, el agente puede contrastarla con el arranque sin tener que inferirla del aspecto de la aplicación.

Usa una marca temporal para relacionar archivo y respuesta

Una marca reconocible permite comprobar si llega el contenido esperado sin rehacer la funcionalidad. Como técnica de diagnóstico propuesta, cambia temporalmente un texto visible y estático de la pantalla afectada por una cadena singular, por ejemplo LOCAL-CHECK-ORANGE. Elige un elemento que ya exista y evita introducir condiciones nuevas.

Haz esta prueba únicamente en tu entorno de desarrollo. Anota el archivo modificado y dónde debería aparecer la marca. Después, comprueba tanto la pantalla como la respuesta del recurso correspondiente. La ausencia de la marca en una petición aislada no demuestra que el servidor sea incorrecto: podrías haber seleccionado un recurso que no contiene ese texto.

Esta plantilla sirve para encargar al agente la investigación y registrar lo que todavía falta por observar:

Investiga por qué el navegador no refleja el cambio; pausa los parches funcionales.
Proyecto editado, ruta absoluta: [ruta]
Archivo y texto temporal esperado: [archivo / marca]
Orden de arranque y directorio: [orden / directorio]
URL anunciada por el servidor: [URL o no disponible]
URL observada en Network: [URL]
Marca en la respuesta y en pantalla: [sí / no / sin comprobar]
Indica qué evidencia falta antes de proponer otro cambio.

Si la marca llega al recurso esperado pero no aparece en pantalla, continúa investigando el renderizado de ese elemento. Si aparece donde corresponde, ya tienes una señal útil de que esa edición llega a esa vista. Retira después la marca y conserva cualquier modificación funcional que estuvieras evaluando.

Si había otro servidor, haz explícita la elección del puerto

Activa un puerto estricto cuando necesites una dirección local predecible. La opción server.strictPort hace que Vite termine si el puerto está ocupado, en lugar de buscar otro, según su documentación de configuración del servidor. Esto convierte el conflicto en una señal que debes resolver.

Este ejemplo fija el puerto elegido para el desarrollo. Requiere un proyecto que ya utilice Vite; integra las propiedades en su configuración existente, conservando plugins y demás opciones. El uso de defineConfig y del archivo vite.config.ts está documentado en la referencia de configuración de Vite.

import { defineConfig } from 'vite';

export default defineConfig({
  server: {
    port: 5173,
    strictPort: true,
  },
});

Tras aplicar la configuración, utiliza el procedimiento habitual del proyecto para volver a arrancar el servidor. Si el puerto está ocupado, el resultado esperado es que ese arranque termine. Identifica la instancia anterior y decide si corresponde detenerla o asignar deliberadamente otro puerto al trabajo actual.

No interpretes el conflicto como una razón para terminar todos los procesos relacionados con JavaScript. Podrías cerrar herramientas ajenas a esta tarea. Del mismo modo, arrancar correctamente en un puerto estricto no demuestra que estés en el directorio adecuado: conserva esa comprobación.

Si necesitas varias instancias simultáneas, asigna una dirección a cada una y registra su correspondencia. Un puerto único compartido por todas no encaja con ese flujo; lo útil es que la elección sea explícita.

Decide el siguiente paso según la evidencia

Si has confirmado que llega el archivo actualizado, deja de investigar un localhost equivocado. El diagnóstico debe cambiar cuando la evidencia descarte esa hipótesis. Utiliza esta tabla como árbol de decisión práctico, no como una lista de causas demostradas.

Las últimas ramas tienen mecanismos específicos. Vite documenta problemas de detección de archivos y de actualización HMR en su apartado de diagnóstico. Para archivos .env, indica que se cargan al arrancar y que debes reiniciar el servidor después de modificarlos.

No apliques la comparación directa de puertos como prueba concluyente si trabajas con un proxy, un contenedor o un entorno remoto. En esos casos, documenta también cómo se conecta la dirección visible con el servidor de desarrollo. Si desconoces esa relación, el resultado debe quedar como pendiente de comprobar, sin justificar todavía otro parche funcional.