Ricardo Hernan Melo Gallardo

AGENTIC — Building with agents

AGENTS · SPECS · TESTS

This site is the case: built with AI agents under specs, decision records, gates and audits without context.

Featured case

• This site, built with agents (Claude Code · Codex · Specs): Specs and decisions before the code; agents build, gates check, a person looks.

How I work with agents

• Specify: A spec with its problem, decisions and tests.
• Delegate: Agents build inside the rules of AGENTS.md.
• Verify: Gates on every change; a person looks at it.
• Audit: Agents without context judge the drift.

Inspectable evidence — rules → tests → review

• Rules for agents (Iron Bastion · public · AGENTS.md): Architecture boundaries and acceptance rules in AGENTS.md.
• Model validators (Iron Bastion · tests · Tests · JavaScript): Rig contract tests: structure, points and constraints.
• Audits without context (Obsidian Cube · process · Drift): Agents with no prior context judge the work against its goal.

Built with agents

• Obsidian Cube is my agent-assisted workflow case: specs, decisions, tests and visual review. Iron Bastion provides public examples of the same approach; its links are not this site’s repository.
• Specs before the code: problem, decisions, slices and acceptance.
• One constitution, AGENTS.md, that the agents read before every change.
• Gates in CI: types, tests, layout on every screen, first-view weight and privacy.
• Drift audits by agents without prior context, judged against the objective, not the code.
• Green gates are not the experience: every slice closes with a walkthrough a person looks at.
• Public evidence in Iron Bastion: AGENTS.md defines boundaries and acceptance; rig-validator.test.js exposes tests of the model contract. These files are evidence for that project, not for Obsidian Cube’s internal audits.
• Iron Bastion · agent contract
• Iron Bastion · validator tests

• Iron Bastion rules

PRODUCTS — Selected products

FROM IDEA TO PRODUCT

Three products: a 3D portfolio, a browser game, and a desktop tool with inspectable evidence.

Selected products

• Obsidian Cube (3D portfolio · In preparation · React · TypeScript · Three.js): A bilingual portfolio that makes its agent-assisted development inspectable. · Experience: Six faces and two languages in a persistent experience. · Architecture: Testable boundaries for scene, interface, and content. · Verification: 191 tests passed in the November 8, 2026 local review.
• Iron Bastion (3D browser game · Public demo · Three.js · Blender · Validation): A 3D tower defense with verifiable assets and measurable engineering decisions. · Product: A playable 3D tower defense with twenty waves. · Result: The README records a build from 62 MB to about 13 MB. · Contract: Models and projectiles share pivots and geometry. Iron Bastion — Play Iron Bastion — View code
• OpenMenu GDEMU Manager (Desktop app · Public beta · Python · Windows · GPL-3.0+): A portable app for organizing GDEMU cards with diagnostics and backups. · Platform: A portable Windows application written in Python. · Workflow: Diagnostics, SD organization, and technical backups. · Release: Beta v0.2.0-beta.4 with Spanish and English interfaces. OpenMenu GDEMU Manager — Download beta OpenMenu GDEMU Manager — View code

Three cases, one process

• Design, development, and checks behind products that can be explored or inspected.
• Obsidian Cube. A bilingual portfolio with six faces, shared content schemas, and architecture and layout checks. Final content and the public release are in preparation; the repository is still private.
• Iron Bastion. A 3D tower defense whose asset contract and validators align the model with the projectile. The README records a build from 62 MB to about 13 MB; the simulator still needs calibration.
• OpenMenu GDEMU Manager. A portable Windows application that combines diagnostics, organization, and menu rebuilding with technical backups. The linked release is public beta v0.2.0-beta.4, rather than an upcoming V2 release.
• Play Iron Bastion
• Iron Bastion code
• Download OpenMenu
• OpenMenu code

• GitHub

SYSTEMS — Production Systems

FULL STACK · LEAD · DBA

Over 15 years building systems that run in production: full stack, technical lead, data models and migration.

Track record — Over 15 years of systems

• Full stack: Over 15 years building web systems end to end.
• Tech lead: Technical coordination and architecture decisions in the teams.
• DBA: Data model and migration of nearly twenty years of legacy data.
• Agentic: Building with AI agents under specs, gates and audits.

Foundation

• Over 15 years full stack
• Systems in production

Today

• Data models and migration
• Building with AI agents

How I work

• AI speeds up the code. Data, decisions, design and controls still go through a person.
• Measure before deciding: every decision rests on the real data.
• Separate migration from redesign: data first, the new design after.
• Prove it with the business: real reports must match on both systems.
• GitHub: Public repositories

• View on LinkedIn

SECURITY — Security by decision

AUTH · HEADERS · DATA

What this site decides and enforces: no homegrown login in production, checked headers, audits that fix.

• PUBLIC EVIDENCE · PANEL — Operations Panel: threats and tests: Threat model and CSRF and role tests in an open-source technical demo.
• Audit, reproduced, fixed — A framed admin was signed in: An audit without context found it; framing is now refused before any route, and a test holds it.

This site’s controls

• headers.csp (Verified): One policy, enforced while the layout check runs
• admin.frame (Verified): The admin refuses to be framed; a test holds it
• check.privacy (Verified): Current files checked before every push
• content.sanitize (Verified): Rich text through an allowlist of inline tags
• deploy.oidc (Implemented): Deploys with OIDC: no long-lived AWS keys
• contact.captcha (Planned): The contact form behind a captcha and rate limits

Security, decided

• Obsidian Cube’s controls are checked locally and its final site audit remains pending. As additional public evidence, the Operations Panel offers an inspectable threat model and CSRF and role tests.
• Obsidian Cube: one header configuration feeds deployment and the test server. The local check enforces the policy on the built site; this does not establish a production deployment.
• The local admin, with bcrypt and TOTP, never leaves 127.0.0.1; its development bypass refuses to start in production.
• An audit by an agent without context found that a framing page could borrow that bypass; it was reproduced, fixed before any route and kept by a test.
• The current tree is checked before every push. History still requires review before opening this repository; personal content stays outside Git.
• Next, in the security stage: a review of the whole site, and the contact form behind a captcha and rate limits.
• The Operations Panel is a public technical demo, not a verified production mine installation. Its tests cover rejected CSRF tokens, origins and unauthorized roles; the code is linked here without claiming an independent audit or a new run of its suite.
• Cognito with TOTP is the planned production admin decision. The captcha-protected form, rate limits and final audit belong to the pending security stage.
• Operations Panel · threat model
• Operations Panel · CSRF and role tests
• Operations Panel · security policy

• Panel threat model

RESEARCH — Experience and meaning

RESEARCH · AI

Experiential Injection: a conceptual preprint on first-person experience and understanding in AI.

CENTRAL QUESTION

• What separates processing language from understanding through first-person experience?

• Proposed thesis: The preprint argues that experiential understanding requires activating one’s own experience.
• Discussion: It distinguishes model capabilities from first-person experience when discussing scaling.
• Scope: A conceptual argument in a preprint; not an experimental demonstration.

ARGUMENT DISTINCTIONS

• Processing: Operating on signs and formal relations.
• Experiencing: Having a first-person experience.
• Understanding: The thesis connects meaning to one’s own experience.

OPEN PUBLICATION

• Experiential Injection (Preprint · 2026 · DOI)

Experiential Injection

• Independent research by Ricardo Melo. Preprint v1.0 published on May 2, 2026 on Zenodo, DOI 10.5281/zenodo.19965988, licensed CC BY 4.0.
• The proposal focuses on experiential understanding: relating signs to one’s own first-person experiences. It does not claim to be a complete theory of every form of understanding.
• The text argues that scaling language models does not by itself identify a mechanism for subjectivity. This is the author’s thesis, not an established experimental result.
• The argument engages philosophical questions about meaning, symbol grounding and consciousness. Reading it requires distinguishing linguistic performance, subjective experience and experiential understanding.
• Presented as a conceptual preprint, without claiming peer review or empirical validation. The DOI identifies this May 2026 version, not later private manuscripts.
• Preprint · persistent DOI
• Zenodo · record and download

• Read the preprint

CONTACT — Let's talk

CONCEPCIÓN · REMOTE

For roles, collaborations and research: the code on GitHub, the track record on LinkedIn.

• Concepción, Chile · remote · Spanish, technical English
• GitHub: Code and public projects
• LinkedIn: Track record and context

How to reach me

• LinkedIn for roles and collaborations; GitHub for the code and the public projects.
• Roles and collaborations: LinkedIn.
• Code and projects: GitHub.
• GitHub: Code and public projects
• LinkedIn: Track record and context
• Full profile: The same facts in plain text, for people and machines.

• Go to LinkedIn
• GitHub