Puedes probar el proyecto en vivo en javierdelgado.com.ve/voicegraph.

#El problema con "otro chatbot con RAG"

Cualquiera puede envolver un LLM con una búsqueda vectorial y llamarlo "asistente inteligente". Eso no demuestra nada sobre orquestación: es un if/else con marketing. Lo que quería mostrar era otra cosa: una conversación real tiene ramas (¿el usuario quiere charlar, cambiar de tema, cambiar de nivel, o terminar?), pasos que pueden fallar y necesitan reintentarse, y estado que persiste entre turnos. Eso es exactamente lo que LangGraph modela de forma explícita como grafo, en vez de esconderlo dentro de un script largo.

La decisión de diseño más importante fue esta: el frontend tiene que visualizar el grafo ejecutándose en vivo — qué nodo está activo, qué edge se tomó, cómo se ve el estado en cada paso — porque ese panel es lo que convierte "confía en que uso LangGraph" en "mira, esto es un grafo con estado".

#Diseño del grafo

El estado (GraphState, un TypedDict) lleva lo que cualquier conversación necesita, más los campos que hacen visible la orquestación:

conversation_id: str
messages: Annotated[list[BaseMessage], add_messages]
input_audio: bytes | None
input_text: str | None
retrieved_context: list[dict] | None
intent: Literal["chat", "change_topic", "change_level", "end_conversation"] | None
response_text: str | None
response_audio: bytes | None
student_level: Literal["beginner", "intermediate", "advanced"]
error: str | None
retry_count: dict[str, int]

El grafo tiene 9 nodos: transcribe_audio → classify_intent → {retrieve_context → generate_response, handle_change_level, handle_change_topic, end_conversation} → synthesize_speech → END, con handle_error como terminal de fallback. Algunas decisiones que dieron trabajo real:

• classify_intent es el nodo que justifica el grafo. Es el punto donde un pipeline lineal de if/else se vuelve frágil rápido: cada intención nueva es una rama nueva, y con LangGraph eso es un edge condicional más, no un elif más en una función que ya tiene quince.
• Retries como self-loop, no como try/except anidado. Cada nodo con llamada de red incrementa retry_count[nodo]; si supera el máximo, enruta a handle_error. Esto lo hace visible en el panel: cuando un nodo falla y reintenta, se ve como una arista que vuelve sobre sí misma, no como una excepción silenciosa en un log.
• Checkpointing con MemorySaver, usando conversation_id como thread_id. Para un demo de tráfico bajo es suficiente y lo documenté como trade-off explícito: si esto escalara a más de una instancia, MemorySaver no persiste entre procesos y habría que mover a un checkpointer con Redis o Postgres. Es, a propósito, un buen punto de conversación en una entrevista.

Un detalle que vale la pena anotar porque no es obvio la primera vez: todo nodo que retorna éxito tiene que limpiar explícitamente error y el sentinel de retry ("error": None, "__retry_target__": None"). Si no lo hace, el edge condicional sigue viendo el error anterior como verdadero y el grafo entra en loop infinito. Es el tipo de bug que solo aparece la segunda vez que un nodo falla y se recupera, no la primera.

#El panel de visualización: la pieza que realmente importa

El transporte es SSE, no WebSocket. El backend usa el streaming nativo de LangGraph (astream(stream_mode="debug")) y traduce cada paso a eventos: node_start, node_end, edge_taken, final. No hace falta instrumentar cada nodo a mano con eventos custom — LangGraph ya expone el estado después de cada paso, solo hay que traducirlo.

En el frontend, GraphVisualizer dibuja el grafo con Mermaid (usando draw_mermaid(), que LangGraph expone directamente sobre el grafo ya compilado) y resalta el nodo activo mientras llegan los eventos. StatePanel muestra el JSON del estado actual y el historial de transiciones. Con esto, un visitante del portafolio ve literalmente los nodos iluminándose en orden, no una respuesta de chat que aparece por arte de magia.

Un matiz gracioso: con los providers en modo mock (útil para desarrollo sin API keys) cada nodo corre en microsegundos, así que todos los eventos SSE de un turno llegan en el mismo tick de red — animar "nodo por nodo" se vuelve un parpadeo imperceptible. La solución fue encolar los eventos en el frontend y drenarlos con un pacing artificial (~350ms por paso), sin tocar el backend ni afectar el modo con providers reales, donde las llamadas de red ya dan tiempo de sobra.

#Comparar lineal vs grafo, en vivo

La pieza que más convence sin necesidad de explicar nada es el endpoint POST /compare/linear: corre el mismo turno de conversación (mismo intent → extract → retrieve → generate) pero como una función lineal, sin edges condicionales, sin retries y sin checkpointing — el mismo trabajo, sin la estructura del grafo alrededor. El frontend lo muestra lado a lado con la versión orquestada por LangGraph.

No es una comparación de "cuál es más rápido" (para una sola llamada, la diferencia es marginal). Es una comparación de qué pasa cuando algo falla o cuando la conversación se ramifica: en la versión lineal, cada caso nuevo es una condición más apilada en una función; en la versión con grafo, es una arista más en una estructura que ya sabe reintentar y ya sabe en qué nodo estás.

#App Runner, no Lambda

El streaming SSE fue la restricción que decidió esto. Ya tengo un backend multi-app (el de levelup) corriendo en AWS App Runner, con Dockerfile probado y healthcheck. Ese mismo backend migró antes de WebSocket a SSE precisamente por incompatibilidad de App Runner con conexiones persistentes tipo WebSocket — así que VoiceGraph siguió el mismo patrón desde el inicio en vez de descubrir el problema tarde.

Lambda quedó descartado por tres razones concretas:

1. Cold starts inaceptables para un demo interactivo que un reclutador prueba una sola vez y no va a esperar.
2. Requiere un adaptador ASGI (Mangum) y empaquetado de dependencias pesadas (LangGraph, LangChain) en capas o contenedor — complejidad extra sin beneficio para este caso de uso.
3. No hay ningún patrón de Lambda para servir APIs ya probado en mi infraestructura — la única Lambda que tengo corriendo es auxiliar (notificaciones), no un servicio HTTP con estado conversacional.

Con App Runner, integrar VoiceGraph al backend existente es, al final, un app.mount("/portfolio-langgraph", ...). Cero infraestructura nueva, cero costo adicional de servicio.

#Diseñar para la migración desde el primer commit

Aquí está la decisión de arquitectura que más se nota con el tiempo: aunque VoiceGraph se desarrolla como repo standalone (con su propio main.py, Dockerfile y uvicorn), sabía desde el principio que el destino final era vivir como sub-app dentro del gateway FastAPI multi-app que ya tengo en producción. Así que el backend se construyó con dos reglas simples:

• Los endpoints se definen como APIRouter, nunca atados directamente a la instancia raíz de FastAPI(). El mismo router se puede incluir en la app standalone de desarrollo o en la sub-app montada del gateway sin reescribir una línea.
• La configuración usa un prefijo de variables de entorno propio (VG_*), para no chocar con las demás apps del gateway (levelup, shopify, whatsapp_agent_voice) cuando conviva con ellas bajo el mismo proceso.

Esto significa que la migración final (renombrar la carpeta destino, copiar el código, cambiar main.py para que use root_path="/portfolio-langgraph" en vez de ser la app raíz, y montar con app.mount()) es mecánica, no un rediseño. El código de negocio — grafo, nodos, providers, RAG — no cambia una línea; solo cambia cómo se expone.

#Providers reales detrás de un feature flag

Para poder desarrollar y testear sin gastar en llamadas a APIs externas, todo el backend corre con VG_USE_MOCK_PROVIDERS=true por defecto: LLM, STT, TTS y vector store son deterministas y no tocan la red. Los providers reales (OpenAI para chat/Whisper/TTS, Pinecone para el vector store) están detrás del mismo flag, con una interfaz base compartida (BaseChatLLM, etc.) para que cambiar de mock a real — o de un proveedor a otro en el futuro — no toque los nodos del grafo.

La base de conocimiento del RAG (knowledge_base/*.md) es contenido editorial propio: quién soy, mis proyectos, y las decisiones de arquitectura de este mismo proyecto. Es deliberado — así el asistente puede responder preguntas sobre VoiceGraph usando VoiceGraph, que es el tipo de detalle que un reclutador técnico sí nota.

#Preguntas frecuentes

#¿Por qué usar LangGraph en vez de encadenar llamadas a un LLM directamente?

Porque una conversación real tiene ramas, reintentos y estado que persiste entre turnos. Modelar eso como funciones anidadas con if/else funciona al principio, pero cada caso nuevo aumenta la complejidad de forma lineal con el número de ramas. LangGraph hace esa estructura explícita: nodos, edges condicionales y checkpointing son parte del modelo, no un efecto secundario del código.

#¿Por qué elegir App Runner en vez de Lambda para un backend con IA?

Porque el transporte es streaming (SSE) y porque ya existe un backend en App Runner al que integrarse sin costo de infraestructura nuevo. Lambda tiene sentido para trabajo corto y sin estado; para un servicio conversacional con cold starts que importan y dependencias pesadas como LangGraph, un contenedor de larga duración es más simple y más barato de operar.

#¿Vale la pena construir el panel de visualización del grafo, o es solo estética?

Para un proyecto de portafolio, no es solo estética: es la diferencia entre decir "usé LangGraph" y mostrarlo. El panel convierte una afirmación técnica en algo que se verifica mirando la pantalla — el nodo activo cambia, el edge se resalta, el estado se actualiza. Para un producto real sin ese objetivo de demostración, la prioridad cambiaría (probablemente hacia logs estructurados y trazas en un sistema como LangSmith, que también integré aquí).

#Conclusión

VoiceGraph no es un chatbot con una capa de RAG encima; es un ejercicio deliberado de mostrar cómo se ve una conversación modelada como grafo de estado — con ramas, reintentos, checkpointing y una comparación directa contra el enfoque lineal para que la diferencia no quede en abstracto. Construirlo como servicio standalone pero con la migración a producción pensada desde el día uno (APIRouter, config con prefijo propio) hizo que integrarlo al backend existente en App Runner fuera un paso mecánico, no una reescritura.

Si quieres verlo en acción, el demo está en javierdelgado.com.ve/voicegraph.

#Empezar por la seguridad, no por el framework

Lo primero no fue tocar Vue. Fue revisar qué había en el repositorio que pudiera hacer daño hoy mismo:

• Una API key de Google Maps escrita en el index.html, para un mapa que ni siquiera se mostraba. Se eliminó del código, pero como sigue en el historial público de git, la única solución real es rotarla y restringirla por dominio.
• Un formulario de contacto en PHP sin validación ni protección. El componente Vue ya enviaba los datos a otro backend, así que el PHP era código muerto y peligroso a la vez.
• Una integración con la API v1.1 de Twitter, cerrada hace años.
• La carpeta dist/ versionada en git y dos archivos .zip con copias del proyecto.

Todo eso se puede limpiar en una tarde y no depende de ninguna migración. Si el proyecto muere a mitad del camino, al menos queda más seguro que antes.

#Un roadmap por fases, en una rama separada

Escribí el plan en un archivo Markdown dentro del propio repositorio, con casillas para marcar el avance. Las fases fueron:

La clave fue trabajar en la rama migration/vue3 mientras master seguía sirviendo el sitio viejo. Nada de "big bang".

#Vue 3 sin reescribir los componentes

Vue 3 sigue soportando la Options API, así que casi todos los componentes se movieron con cambios mínimos: new Vue() pasó a createApp(), los filtros desaparecieron y el eventBus (que en Vue 2 era una instancia vacía de Vue) se reemplazó por mitt, que hace lo mismo en 200 bytes.

Lo que sí exigió trabajo fue todo lo que hacía jQuery desde core.js, el script de la plantilla original: el loader de página, el header que se fija al hacer scroll, el panel lateral móvil y el modal de proyectos. Cada uno se reescribió como comportamiento Vue:

// App.vue — header fijo al pasar la altura del top-bar (antes lo hacía core.js con jQuery)
mounted() {
  document.body.classList.add('loaded')
  this.setHeader()
  window.addEventListener('scroll', this.setHeader, { passive: true })
},
methods: {
  setHeader() {
    const topBar = document.getElementById('top-bar')
    const limit = topBar ? topBar.offsetHeight : 0
    document.body.classList.toggle('sticky-layout', window.scrollY >= limit)
  }
}

Con eso, jQuery, Bootstrap JS, Masonry, Owl Carousel e Isotope salieron del proyecto de golpe.

#Qué reemplazó a cada dependencia de Vue 2

Esta fue la parte más entretenida. La regla: si un plugin no se actualizó a Vue 3, buscar el reemplazo más pequeño posible, y si lo que hace cabe en veinte líneas, escribirlo.

La última fila es la más importante: la mitad de las dependencias de un proyecto viejo no se usan. Antes de migrar algo, comprueba que realmente se importa en algún componente.

#Vite en lugar de Webpack 3

El toolchain original (Webpack 3 + Babel 6) rompía en Node 17 o superior por cambios en OpenSSL. Migrar Webpack de la versión 3 a la 5 era casi tanto trabajo como cambiar a Vite, así que fui directo a Vite:

// vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig({
  base: './', // rutas relativas para GitHub Pages
  plugins: [vue()],
  resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } }
})

El resultado: vite build termina en unos segundos, con 240 kB de JavaScript y 306 kB de CSS. El CSS sigue siendo grande porque la plantilla original carga Bootstrap 3 completo; reducirlo es la siguiente fase.

#Despliegue automático

Con Vite, publicar fue lo más sencillo: un workflow de GitHub Actions instala dependencias, ejecuta npm run build y sube dist/ a GitHub Pages en cada push a master. La carpeta dist/ dejó de estar en git.

#Lo que queda pendiente

• Trasladar el SCSS de la plantilla al pipeline de Vite y eliminar el CSS que no se usa.
• Sustituir las fuentes de iconos (FontAwesome, Themify) por SVG inline.
• Auditoría con Lighthouse: rendimiento, accesibilidad y SEO.

#Preguntas frecuentes

#¿Conviene migrar a Vue 3 o reescribir con otro framework?

Si el diseño y los componentes siguen valiendo, migrar es más barato: Vue 3 mantiene la Options API y la mayoría del código se mueve sin cambios. Reescribir solo tiene sentido si el diseño también va a cambiar.

#¿Cuánto tiempo llevó la migración?

Las fases 0 a 3 (seguridad, limpieza, Vue 3 + Vite y reemplazo de dependencias) se completaron en pocas sesiones de trabajo repartidas en unos días, porque el plan estaba escrito de antemano y cada tarea era pequeña.

#¿Qué hago con una API key que quedó en el historial de git?

Rotarla. Borrarla del código actual no sirve de nada si el repositorio es público: cualquiera puede leer los commits antiguos. Genera una nueva clave y restríngela por dominio (HTTP referrer) en la consola del proveedor.

#¿Vale la pena mantener la Options API en Vue 3?

Para un proyecto migrado, sí. La Composition API es mejor para lógica compleja y reutilizable, pero cambiar componentes que ya funcionan solo por cambiar de estilo añade riesgo sin beneficio inmediato.

#Conclusión

Migrar un proyecto heredado no es una sola tarea grande sino muchas pequeñas: primero seguridad, luego limpieza, después el andamiaje y por último las dependencias. Escribir el plan en el repositorio y trabajar en una rama separada hizo que el proceso fuera predecible y que el sitio nunca se cayera.

#Por qué estático y por qué cPanel

Un blog personal no necesita base de datos ni panel de administración. Con archivos HTML:

• No hay nada que actualizar ni parchear en el servidor (adiós a los avisos de "WordPress necesita actualizarse").
• La página carga en milisegundos, porque Apache solo tiene que servir archivos.
• El contenido está en git, en texto plano, y se puede editar con cualquier editor.

Y cPanel, con todos sus años, tiene lo único que hace falta: un servidor Apache que sirve carpetas, soporta .htaccess y acepta subidas por FTP.

#Escribir: Markdown con front matter

Cada entrada es un archivo en posts/<idioma>/ con un encabezado de metadatos (front matter) y el contenido en Markdown:

---
title: Título de la entrada
description: Resumen de 140-160 caracteres para Google y redes.
date: 2026-09-10
category: Herramientas
tags: [cpanel, ftp]
cover: /assets/img/mi-portada.jpg
keyPoints:
  - Primera idea clave.
  - Segunda idea clave.
---

Contenido en **Markdown**…

La URL sale del nombre del archivo: posts/es/2026-09-10-mi-titulo.md se publica en /es/posts/mi-titulo/. Si el archivo tiene draft: true, no se publica. Un comando (npm run new -- "Título" --lang es) crea el archivo con la plantilla lista.

#Generar: un script de Node sin frameworks

El generador es un único archivo, build.js, que hace tres cosas: lee los .md, los convierte a HTML con marked y los inserta en plantillas HTML con un motor de variables mínimo ({{ titulo }}, {{#if}}, {{#each}}). El resultado va a dist/:

dist/
├── index.html                  portada (paginada en /page/2/, /page/3/…)
├── posts/<slug>/index.html     cada entrada
├── posts/<slug>.md             la misma entrada en Markdown limpio
├── categoria/<nombre>/         listados por categoría (category/<name>/ en inglés)
├── assets/                     css, js, imágenes
├── sitemap.xml · rss.xml · robots.txt · llms.txt · 404.html
└── .htaccess                   configuración de Apache

Sin Jekyll, Hugo ni Astro. No tengo nada en contra de ellos, pero para un blog con un diseño propio (el mismo del portafolio) me resultó más rápido escribir 500 líneas de JavaScript que aprender la forma de hacer plantillas de cada herramienta. Y npm run dev levanta un servidor local que imita a Apache para revisar el resultado antes de subirlo.

#Configurar Apache: el archivo .htaccess

Aquí está la diferencia con un CDN moderno: en cPanel todo se configura con un .htaccess que el generador escribe automáticamente en dist/. Lo esencial:

Options -Indexes
DirectoryIndex index.html
AddType text/markdown .md
ErrorDocument 404 /404.html

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  <FilesMatch "\.(html|md|txt|xml)$">
    Header set Cache-Control "public, max-age=300, must-revalidate"
  </FilesMatch>
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript
</IfModule>

Las URLs limpias (/posts/mi-titulo/) funcionan solas porque cada entrada es una carpeta con su index.html. El CSS y el JS llevan ?v=<id-del-build> en la URL, así que pueden cachearse un año sin miedo a servir versiones viejas.

#Publicar: FTP incremental con un manifiesto

Subir todo el dist/ en cada cambio es lento por FTP. En su lugar, el script de deploy guarda en el servidor un archivo .deploy-manifest.json con el hash SHA-1 de cada archivo subido. En el siguiente deploy:

1. Descarga el manifiesto y calcula los hashes de dist/.
2. Sube solo los archivos nuevos o modificados.
3. Borra del servidor los archivos que estaban en el manifiesto y ya no existen (por ejemplo, una entrada eliminada). Nunca toca archivos que no subió él.
4. Sube el manifiesto actualizado.

Corregir una errata en una entrada supone subir dos archivos (el HTML y el .md) más los feeds, no cientos. El cliente FTP es el paquete basic-ftp de Node y las credenciales viven en un .env que no se versiona:

npm run deploy:dry   # conecta y muestra qué subiría, sin tocar nada
npm run deploy       # build + subida incremental

#SEO y asistentes de IA

Como el HTML se genera completo, es fácil incluir lo que los buscadores esperan: canonical, Open Graph, datos estructurados JSON-LD (BlogPosting, BreadcrumbList, FAQPage a partir de la sección de preguntas frecuentes), sitemap.xml y RSS.

Y para los asistentes de IA (ChatGPT, Claude, Perplexity), que cada vez envían más tráfico, el blog publica:

• /llms.txt, un índice del sitio en el formato de llmstxt.org.
• /llms-full.txt, con todo el contenido en un solo Markdown.
• Cada entrada en /posts/<slug>.md, enlazada desde el HTML con <link rel="alternate" type="text/markdown">.
• Un bloque "En resumen" al inicio de cada artículo con las ideas clave.

#Preguntas frecuentes

#¿Funciona en un subdominio o solo en la raíz?

En ambos. El generador tiene un basePath configurable por idioma: vacío para el idioma por defecto (por ejemplo, inglés en la raíz de blog.midominio.com), o /es para el resto. Todas las rutas internas, el .htaccess, el hreflang y el sitemap se ajustan solos.

#¿Qué pasa si el hosting no soporta FTPS?

El script funciona con FTP plano, FTPS explícito o implícito; se elige con una variable en .env. Si el certificado del hosting no coincide con el nombre del servidor, otra variable permite aceptarlo.

#¿Cómo agrego imágenes a una entrada?

Se copian a assets/img/ y se referencian como /assets/img/archivo.jpg. Conviene mantener las portadas por debajo de 250 KB. Si reemplazas una imagen, usa un nombre nuevo: las imágenes se cachean un mes.

#¿Puedo usar este sistema con otro diseño?

Sí. Las plantillas están en layout/ (cabecera, pie, tarjeta de entrada, página de entrada) y los estilos en un único CSS sin frameworks. Cambiar el diseño es editar esos archivos.

#Conclusión

Un hosting compartido no es un límite para tener un blog rápido, bien posicionado y fácil de mantener. Markdown para escribir, un script de Node para generar, .htaccess para configurar Apache y FTP incremental para publicar: cuatro piezas pequeñas que se entienden completas.

#1. Una clave de API en el HTML

En el index.html había un <script> de Google Maps con la clave de API escrita en la URL. El mapa ni siquiera se mostraba: el div que lo contenía estaba comentado. Pero la clave seguía ahí, en un repositorio público, disponible para cualquiera.

Lo que hice: borrar el script. Lo que hay que hacer además: rotar la clave. Eliminarla del código no basta, porque el historial de git conserva cada versión anterior del archivo. La nueva clave debe restringirse por dominio (HTTP referrer) para que solo funcione desde el sitio.

Regla práctica: si un secreto tocó alguna vez un commit público, está comprometido. Rótalo.

#2. Un formulario de contacto en PHP que nadie usaba

El proyecto incluía contact-form.php, el script que traía la plantilla original para enviar correos. El componente Vue de contacto ya enviaba los datos a otro servicio, así que el PHP no se usaba… pero seguía desplegado y era alcanzable por URL.

Un script así, sin validación ni límite de envíos, es un relay de spam listo para usar. Lo que hice: eliminarlo y, ya puestos, eliminar toda la sección de contacto, que era la única razón para cargar jQuery Validate.

#3. Una integración con una API muerta

Había una carpeta api/twitter/ con código para la API v1.1 de Twitter, cerrada hace años, con su archivo de configuración para tokens. Código muerto no da errores, así que nadie lo revisa; pero cualquier archivo PHP servible es superficie de ataque y cualquier archivo de configuración es un candidato a filtrar credenciales.

Lo que hice: borrar la carpeta completa. Si algún día vuelve a hacer falta, está en el historial de git.

#4. Artefactos de build y zips dentro del repositorio

La carpeta dist/ (el resultado compilado) estaba versionada, junto con un dist.zip y un src.zip. Tres copias del proyecto, cada una con sus propias versiones de dependencias y potencialmente con secretos ya "borrados" del código fuente.

Lo que hice: git rm -r --cached dist/, borrar los zips y comprobar que .gitignore los excluye. El despliegue debe generar el build, no leerlo del repositorio.

#5. jQuery 1.12 y una auditoría que sorprendió

jQuery 1.12 tiene vulnerabilidades conocidas y ya no recibe parches. La reacción obvia es "quitarlo", pero primero conviene saber quién lo usa. La auditoría dio un resultado curioso: de todo el código, solo el script de la plantilla (core.js) y la validación del formulario dependían de jQuery. Los componentes Vue no.

Al eliminar la sección de contacto (punto 2), el único uso restante quedó en core.js, que se reemplazó por comportamiento Vue durante la migración. La lección: antes de auditar o reemplazar una dependencia, mide su uso real; muchas veces es más pequeño de lo que parece.

#Una lista para tu próximo proyecto heredado

Si vas a retomar un frontend viejo, esta revisión cabe en una tarde:

#Preguntas frecuentes

#¿De verdad hay que rotar una clave que ya borré del código?

Sí. En un repositorio público cualquiera puede recuperar la versión anterior del archivo con git log -p. Incluso en repositorios privados, los clones y forks conservan el historial.

#¿Cómo sé si un archivo PHP viejo sigue siendo accesible?

Si está dentro de la carpeta pública del hosting (public_html o equivalente), es accesible por URL aunque nada lo enlace. Bórralo o muévelo fuera de la carpeta pública.

#¿Sirve npm audit para un proyecto de 2016?

Sirve como inventario, pero producirá cientos de avisos, muchos de dependencias que no se usan. Prioriza las que realmente se importan en el código y las que se ejecutan en el servidor.

#Conclusión

Ninguno de estos cinco problemas requería migrar el proyecto para resolverse. Se corrigieron antes de tocar Vue, en una rama aparte y con commits pequeños. Empezar por la seguridad hace que la migración posterior sea más simple, porque hay menos código que mover, y garantiza que el esfuerzo valga la pena aunque el proyecto se quede a medias.