Este portfolio
La web que estás leyendo: un sistema de información sobre un desarrollador en el que cada afirmación enlaza con su evidencia. El contenido, un contrato OpenAPI común, una API en Node y una web en React renderizada en servidor, desplegadas en contenedores.
En producción desde septiembre de 2026 y en evolución continua. Lo siguiente, sobre la misma API: un analizador de ofertas con LLM y un servidor MCP generado del contrato. Más adelante, un backoffice en lugar del contenido en ficheros, y otros backends y frontends sobre el mismo contrato.
Qué demuestra
- Node, React y TypeScript aprendidos construyendo: de la primera línea, el 24-09-2026, a producción el 27-09-2026, con agentes y con las mismas garantías que en mi stack habitual.
- Diseño guiado por contrato: una implementación de referencia independiente decide si la API cumple, y la integración continua no publica si no coinciden.
- Contenido tratado como código: un grafo en YAML con validador, un informe de cobertura generado y reglas de confidencialidad comprobadas antes de publicar.
- Despliegue profesional en una máquina mínima: contenedores, integración continua y publicación de imágenes probadas, despliegue manual con comprobaciones de salud, TLS, cabeceras de seguridad y vuelta atrás automática.
- Una arquitectura pensada para la siguiente fase: el mismo contrato admite otro backend u otro frontend, y el contenido en ficheros puede pasar a un backoffice sin cambiar lo que sirve la API.
El problema
Un currículum afirma y nadie puede comprobarlo. Quien selecciona perfiles busca palabras clave; quien evalúa código no sabe por dónde empezar; y un portfolio al uso enseña capturas de proyectos que no se pueden abrir.
La decisión que lo define
Un sistema de información, no una galería, y a propósito más sistema del que necesita una web personal: una página estática bastaría para contar, pero no para demostrar. Cada pieza —el contenido validado como código, el contrato independiente, la API, la web renderizada en servidor, los contenedores y la integración continua— es una capacidad que se enseña funcionando. El contrato va primero, así que backend y frontend son intercambiables y el siguiente stack se enchufa sin tocar el resto.
Cómo está hecho
El contenido vive en YAML, con un validador propio, y se importa a una base de datos que se reconstruye entera en cada versión. Un contrato OpenAPI, fuera de cualquier implementación, fija las respuestas; una implementación de referencia en Python construye respuestas desde el corpus, y la API en Node se compara con ella en sus recursos y en una muestra de filtros y errores. La web, en React con renderizado en servidor, genera sus propios tipos del contrato y no comparte código con la API.
- Grafo navegable: cada referencia es una identidad tipada que el frontend traduce a su propia ruta, y ninguna lleva a un enlace roto; se comprueba recorriendo todos los enlaces de la API y de la web.
- Lo que depende del resto del portfolio se calcula, no se escribe: el uso de cada tecnología, su primer y último uso, y el mejor ejemplo de cada capacidad.
- La integración continua construye las imágenes, las prueba y publica exactamente lo probado; el despliegue comprueba que la nueva versión responde y, si no, vuelve sola a la anterior.
Las evidencias46
CapacidadAfirmaciónFuerzaCómo comprobarlo
- Adopción rápida de stacks nuevos con IAHistorial de commits · Bajo petición
Primer commit de la implementación el 24-09-2026; en producción el 27-09-2026, con la API cumpliendo el contrato y la web sin un enlace roto.
- Diseño de APIs RESTCódigo · Bajo petición
- Tests de regresión y equivalenciaCódigo · Bajo petición
- Protección de datos y confidencialidadCódigo · Bajo petición
- Auditoría técnica y retrospectivasCódigo · Bajo petición
- CI/CDCódigo · Bajo petición
- Docker y contenedoresMejor ejemplo del portfolioCódigo · Bajo petición
- Despliegues reversibles (rollback)Código · Bajo petición
- Frontend con framework de cliente (React)Mejor ejemplo del portfolioEn producción · Acceso público
- Modelado de dominioCódigo · Bajo petición
- Desarrollo con agentes de código (AI-native)Documento · Bajo petición
- Entrega rápida con IA sin perder calidadHistorial de commits · Bajo petición
- Desarrollo web full stackEn producción · Acceso público
- Arquitectura por capas (capa de servicios)Código · Bajo petición
- Arquitectura hexagonal (puertos y adaptadores)Código · Bajo petición
- Diseño modularCódigo · Bajo petición
- Configuración por entornoCódigo · Bajo petición
- Renderizado en servidor (SSR)En producción · Acceso público
- Diseño de UX para usuarios no técnicosEn producción · Acceso público
- Sistema de diseñoEn producción · Acceso público
- Accesibilidad webEn producción · Acceso público
- Visualización de datosEn producción · Acceso público
- Refactorización del modelo de datosDecisión escrita · Bajo petición
- ETL e ingesta de datosCódigo · Bajo petición
- Integridad de datosCódigo · Bajo petición
- Migraciones de base de datosCódigo · Bajo petición
- Búsqueda de texto completo y semánticaEn producción · Acceso público
- Modelado minimalista (YAGNI)Decisión escrita · Bajo petición
- Context engineeringDocumento · Bajo petición
- Revisión de código generado por IACódigo · Bajo petición
- Administración de servidores LinuxCódigo · Bajo petición
- Planificación de capacidadCódigo · Bajo petición
- ObservabilidadCódigo · Bajo petición
- Seguridad de aplicaciones webCódigo · Bajo petición
- Gestión de secretosCódigo · Bajo petición
- Tests de arquitectura y coherenciaCódigo · Bajo petición
- Testing automatizadoCódigo · Bajo petición
- Registros de decisiones de arquitectura (ADR)Documento · Bajo petición
- Documentación técnicaDocumento · Bajo petición
- Desarrollo de productoDocumento · Bajo petición
- Análisis de requisitos de negocioDecisión escrita · Bajo petición
- Gestión del alcanceDecisión escrita · Bajo petición
- Autonomía de extremo a extremoHistorial de commits · Bajo petición
- Transparencia técnicaEn producción · Acceso público
- Comunicación escritaDocumento · Bajo petición
- Aprendizaje rápidoHistorial de commits · Bajo petición
Principios que se ven aquí21
- PrincipioCuando migro o refactorizo, verifico la equivalencia con código, no con confianza
- Una implementación de referencia en Python, escrita aparte, se compara con los recursos de la API y una muestra de filtros y errores; la integración continua no publica si esas comprobaciones fallan
- PrincipioCuando el uso contradice el modelo, se rehace el modelo — y se escribe por qué
- El modelo del grafo, rehecho tras la primera revisión real de un proyecto, con el diagnóstico y la decisión escritos
- El concepto de hueco se retiró de la web después de verlo publicado, con la decisión y su porqué escritos
- PrincipioRigor donde importa, deuda consciente donde no — y saber decir en cuál está cada cosa
- Tests de invariantes sobre el contenido real, no de cifras; una base de pruebas propia se descartó por su coste de mantenimiento
- PrincipioLa autocrítica se publica, no se guarda
- La web publica el nivel real de cada capacidad, calculado de sus evidencias, y un informe generado señala lo que el propio portfolio sostiene con una sola evidencia
- PrincipioPrefiero lo que sobrevive diez años a lo que brilla seis meses
- El contrato no usa expresiones regulares en texto libre porque cada lenguaje las interpreta distinto, y la misma imagen sirve en cualquier máquina
- PrincipioUna acción existe una vez; todas las interfaces la llaman
- La misma capa de servicios en Node, con las rutas como adaptadores finos; las demás superficies entran por la API, una sola puerta para todas
- PrincipioUna decisión sin su porqué es una decisión que se va a repetir mal
- Decisiones de proyecto numeradas y registros de arquitectura de la implementación; la que cambia otra la marca como superada, sin borrarla
- PrincipioEn producción, lo mínimo que resuelve el problema
- Un SVG propio para el grafo interactivo en lugar de una librería de grafos de cientos de kB
- PrincipioConstruyo sistemas, no piezas: diseño la siguiente fase y construyo solo la actual
- Un contrato de API que admite otro backend u otro frontend, y contenido en ficheros que podrá pasar a un backoffice sin cambiar lo que sirve la API; ni lo uno ni lo otro se ha construido antes de hacer falta
- PrincipioNo construyo nada que no haya entendido antes
- Con un stack nuevo, cada paso se explica con su equivalente en el que ya domino, lo ejecuto yo y deja una nota de aprendizaje
- PrincipioLo que se puede calcular no se escribe a mano
- El nivel de cada capacidad y el uso de cada tecnología salen de las evidencias de los proyectos; a mano solo se escribe un ajuste con su motivo
- PrincipioLo seguro es el camino por defecto, y se garantiza en un solo sitio
- Lo reservado nunca sale del servidor, la API solo admite lectura y lo que declara, y los contenedores corren en solo lectura
- PrincipioPrefiero un fallo visible a un éxito aparente
- La API responde con un error a un parámetro que no conoce: una errata en un filtro no se ignora en silencio
- PrincipioUna red de seguridad que no he visto fallar no es una red
- La vuelta atrás automática del despliegue se probó desplegando una versión rota a propósito
- PrincipioLas reglas que importan las vigila una comprobación, no la memoria
- Un validador impide publicar un término confidencial y la conformidad sigue todos los enlaces del grafo; avisar en un informe se descartó porque el problema vuelve en cuanto se deja de mirar
- PrincipioEl dato dice cuánto sabe: vacío, provisional o validado
- Cada evidencia dice su fuerza y cómo se puede comprobar
- PrincipioLo irreversible lo ejecuta una persona
- El agente instala, importa y verifica en una copia y hace los commits locales; el push y el despliegue remoto los ejecuta una persona
- PrincipioEl sistema no promete lo que no hace
- La prosa pública no repite cifras que el sistema ya calcula: en cuanto cambia un proyecto, dejarían de ser verdad
- PrincipioUn «no» lleva escrita la condición que lo reabriría
- Monorepo sin herramienta propia hasta un tercer espacio de trabajo, y un recurso de API para el grafo cuando aparezca un segundo consumidor
- PrincipioLa documentación es el contexto de quien viene detrás, y cambia en el mismo paso que el código
- Cada paso actualiza el estado, el mapa y el contexto de la aplicación, y las notas de aprendizaje van aparte de lo construido
- PrincipioDel dato personal, solo el que sirve a un propósito, durante un plazo y a la vista
- El registro de visitas conserva la IP un plazo fijo y la borra solo; la ubicación aproximada se deduce con una base de datos local, de modo que la IP no sale del servidor, y la página legal cuenta qué se registra, para qué y durante cuánto