Ricardo Hernan Melo Gallardo

AGÉNTICO — Construir con agentes

AGENTES · SPECS · TESTS

Este sitio es el caso: hecho con agentes de IA, specs, decisiones escritas, pruebas y auditorías sin contexto.

Caso destacado

• Este sitio, hecho con agentes (Claude Code · Codex · Specs): Specs antes del código; los agentes construyen, las pruebas verifican y una persona mira.

Cómo trabajo con agentes

• Especificar: Una spec con el problema, decisiones y pruebas.
• Delegar: Los agentes construyen dentro de AGENTS.md.
• Verificar: Pruebas en cada cambio; una persona lo mira.
• Auditar: Agentes sin contexto juzgan la deriva.

Evidencia inspeccionable — reglas → tests → revisar

• Contrato para agentes (Iron Bastion · público · AGENTS.md): Límites de arquitectura y criterios de aceptación en AGENTS.md.
• Validadores de modelos (Iron Bastion · pruebas · Tests · JavaScript): Pruebas del contrato de rigs: estructura, puntos y límites.
• Auditorías sin contexto (Obsidian Cube · proceso · Deriva): Agentes sin contexto juzgan el trabajo contra su objetivo.

Hecho con agentes

• Obsidian Cube es mi caso de trabajo con agentes: specs, decisiones, pruebas y revisión visual. Iron Bastion aporta ejemplos públicos del mismo enfoque; sus enlaces no corresponden al repositorio de este sitio.
• Specs antes del código: problema, decisiones, etapas y aceptación.
• Una constitución, AGENTS.md, que los agentes leen antes de cada cambio.
• Pruebas en CI: tipos, tests, diseño en cada pantalla, peso de la primera vista y privacidad.
• Auditorías de deriva por agentes sin contexto previo, juzgadas contra el objetivo y no contra el código.
• Las pruebas en verde no son la experiencia: cada etapa cierra con un recorrido que una persona mira.
• Evidencia pública en Iron Bastion: AGENTS.md define límites y aceptación; rig-validator.test.js permite inspeccionar pruebas del contrato de modelos. Los archivos enlazados son evidencia de ese proyecto, no de las auditorías internas de Obsidian Cube.
• Iron Bastion · contrato para agentes
• Iron Bastion · pruebas del validador

• Reglas: Iron Bastion

PRODUCTOS — Productos seleccionados

DE LA IDEA AL PRODUCTO

Tres productos propios: una experiencia 3D, un juego y una herramienta de escritorio con evidencia.

Productos seleccionados

• Obsidian Cube (Portafolio 3D · En preparación · React · TypeScript · Three.js): Un portafolio bilingüe que convierte su construcción con agentes en evidencia. · Experiencia: Seis caras y dos idiomas en una experiencia persistente. · Arquitectura: Escena, interfaz y contenido con límites comprobables. · Verificación: 191 pruebas aprobadas en la revisión del 8/11/2026.
• Iron Bastion (Juego web 3D · Demo pública · Three.js · Blender · Validadores): Un tower defense 3D con modelos verificables y decisiones que se pueden medir. · Producto: Tower defense 3D jugable con veinte oleadas. · Resultado: El README documenta un build de 62 MB a unos 13 MB. · Contrato: Modelos y disparos comparten pivotes y geometría. Iron Bastion — Jugar Iron Bastion — Ver código
• OpenMenu GDEMU Manager (Escritorio · Beta pública · Python · Windows · GPL-3.0+): Una app portable para organizar tarjetas GDEMU con diagnóstico y respaldos. · Plataforma: Aplicación portable para Windows, escrita en Python. · Flujo: Diagnóstico, organización de la SD y respaldos técnicos. · Entrega: Beta v0.2.0-beta.4 con interfaz en español e inglés. OpenMenu GDEMU Manager — Descargar beta OpenMenu GDEMU Manager — Ver código

Tres casos, un proceso

• Diseño, construcción y comprobaciones sobre productos que se pueden explorar o inspeccionar.
• Obsidian Cube. Portafolio bilingüe con seis caras, contenido compartido con el administrador y comprobaciones de arquitectura y diseño. El contenido final y la publicación están en preparación; el repositorio sigue privado.
• Iron Bastion. Tower defense 3D cuyo estándar de modelos y validadores alinean la representación con el disparo. El README documenta un build de 62 MB a unos 13 MB; el simulador aún requiere calibración.
• OpenMenu GDEMU Manager. Aplicación portable para Windows que reúne diagnóstico, organización y reconstrucción del menú con respaldos técnicos. La entrega enlazada es la beta pública v0.2.0-beta.4, no una versión futura de V2.
• Jugar Iron Bastion
• Código de Iron Bastion
• Descargar OpenMenu
• Código de OpenMenu

• GitHub

SISTEMAS — Sistemas en producción

FULL STACK · LÍDER · DBA

Más de 15 años construyendo sistemas que corren en producción: full stack, liderazgo técnico, datos y migración.

Trayectoria — Más de 15 años de sistemas

• Full stack: Más de 15 años construyendo sistemas web de punta a punta.
• Líder técnico: Coordinación técnica y decisiones de arquitectura en equipos.
• DBA: Modelo de datos y migración de casi veinte años de datos.
• Agéntico: Construyo con agentes de IA bajo specs, pruebas y auditorías.

Base

• Más de 15 años full stack
• Sistemas en producción

Hoy

• Modelo de datos y migración
• Desarrollo con agentes de IA

Cómo trabajo

• La IA acelera el código. Los datos, las decisiones, el diseño y los controles siguen pasando por una persona.
• Medir antes de decidir: cada decisión se apoya en los datos reales.
• Separar la migración del rediseño: primero los datos, después el diseño nuevo.
• Probar con el negocio: los reportes reales deben dar lo mismo en ambos sistemas.
• GitHub: Repositorios públicos

• Ver en LinkedIn

SEGURIDAD — Seguridad por decisión

AUTH · CABECERAS · DATOS

Lo que este sitio decide y cumple: sin login propio en producción, cabeceras revisadas, auditorías que corrigen.

• EVIDENCIA PÚBLICA · PANEL — Panel Operativo: amenazas y pruebas: Modelo de amenazas y pruebas de CSRF y roles en una demo técnica con código abierto.
• Auditada y corregida — Un admin enmarcado quedaba abierto: Lo halló una auditoría sin contexto; ahora el marco se rechaza antes de toda ruta, con prueba.

Controles de este sitio

• headers.csp (Verificado): Una política, aplicada durante el chequeo de diseño
• admin.frame (Verificado): El admin no se deja enmarcar; una prueba lo sostiene
• check.privacy (Verificado): Archivos actuales revisados antes de cada push
• content.sanitize (Verificado): Texto enriquecido por una lista de etiquetas en línea
• deploy.oidc (Implementado): Despliegue con OIDC: sin llaves de AWS de larga vida
• contact.captcha (Planificado): El formulario de contacto tras captcha y límites

Seguridad, decidida

• Los controles de Obsidian Cube se revisan localmente y la auditoría final del sitio sigue pendiente. Como evidencia pública adicional, el Panel Operativo ofrece un modelo de amenazas y pruebas inspeccionables de CSRF y roles.
• Obsidian Cube: una configuración de cabeceras alimenta el despliegue y el servidor de pruebas. El chequeo local aplica la política al sitio compilado; esto no acredita un despliegue en producción.
• El admin local, con bcrypt y TOTP, no sale de 127.0.0.1; su atajo de desarrollo se niega a arrancar en producción.
• Una auditoría por un agente sin contexto encontró que una página que lo enmarcara podía usar ese atajo; se reprodujo, se corrigió antes de toda ruta y una prueba lo sostiene.
• El árbol actual se revisa antes de cada push. El historial requiere su revisión antes de abrir este repositorio; el contenido personal se conserva fuera de Git.
• Después, en la etapa de seguridad: una revisión de todo el sitio, y el formulario de contacto tras un captcha y límites de uso.
• El Panel Operativo es una demo técnica pública, no una instalación minera acreditada en producción. Sus pruebas cubren rechazos de tokens CSRF, orígenes y roles no autorizados; aquí se enlaza el código, sin afirmar una auditoría independiente ni una nueva ejecución de su suite.
• Cognito con TOTP es la decisión prevista para el admin en producción. El formulario con captcha, los límites de uso y la auditoría final pertenecen a la etapa de seguridad pendiente.
• Panel Operativo · modelo de amenazas
• Panel Operativo · pruebas de CSRF y roles
• Panel Operativo · política de seguridad

• Ver amenazas: Panel

INVESTIGACIÓN — Experiencia y significado

INVESTIGACIÓN · IA

Experiential Injection: un preprint conceptual sobre experiencia en primera persona y comprensión en IA.

PREGUNTA CENTRAL

• ¿Qué diferencia procesar lenguaje de comprender desde una experiencia propia?

• Tesis propuesta: La comprensión experiencial requiere activar una experiencia propia, según el preprint.
• Discusión: Distingue capacidades del modelo y experiencia en primera persona al discutir el escalamiento.
• Alcance: Es un argumento conceptual en un preprint; no una demostración experimental.

DISTINCIONES

• Procesar: Operar con signos y relaciones formales.
• Experimentar: Tener una vivencia en primera persona.
• Comprender: La tesis vincula sentido y experiencia propia.

PUBLICACIÓN ABIERTA

• Experiential Injection (Preprint · 2026 · DOI)

Experiential Injection

• Investigación independiente de Ricardo Melo. Preprint v1.0 publicado el 2 de mayo de 2026 en Zenodo, con DOI 10.5281/zenodo.19965988 y licencia CC BY 4.0.
• La propuesta se centra en la comprensión experiencial: relacionar signos con experiencias propias en primera persona. No pretende ser una teoría completa de toda forma de comprensión.
• El texto sostiene que el aumento de escala de los modelos de lenguaje no identifica por sí solo un mecanismo de subjetividad. Es la tesis del autor y no un resultado experimental establecido.
• El argumento dialoga con problemas filosóficos de significado, fundamentación de símbolos y conciencia. La lectura requiere distinguir rendimiento lingüístico, experiencia subjetiva y comprensión experiencial.
• Se presenta como preprint conceptual; no se atribuye revisión por pares ni validación empírica. El DOI identifica esta versión de mayo de 2026 y no los manuscritos privados posteriores.
• Preprint · DOI permanente
• Zenodo · ficha y descarga

• Leer el preprint

CONTACTO — Hablemos

CONCEPCIÓN · REMOTO

Para roles, colaboraciones e investigación: el código en GitHub, la trayectoria en LinkedIn.

• Concepción, Chile · remoto · español, inglés técnico
• GitHub: Código y proyectos públicos
• LinkedIn: Trayectoria y contexto

Cómo contactarme

• LinkedIn para roles y colaboraciones; GitHub para el código y los proyectos públicos.
• Roles y colaboraciones: LinkedIn.
• Código y proyectos: GitHub.
• GitHub: Código y proyectos públicos
• LinkedIn: Trayectoria y contexto
• Perfil completo: Los mismos datos en texto plano, para personas y máquinas.

• Ir a LinkedIn
• GitHub