DEV Community: Mario Gutierrez

PISCA: I turned an Andean breakfast soup into an interactive landscape

Mario Gutierrez — Thu, 30 Jul 2026 19:09:35 +0000

This is a submission for Frontend Challenge: Comfort Food Edition, Perfect Landing.

What I built

PISCA is an interactive, bilingual landing page about pisca andina, a family of breakfast soups from the Venezuelan Andes.

I did not want to build a generic food landing page and swap in a regional dish at the end. The page had to feel specific to pisca: a cold mountain morning, a clay bowl, simple ingredients, and the first warmth of the day.

That led to the central image. The soup is the only warm light source in a dark pre-dawn landscape, and its steam becomes the ridgelines of the Andes. The rest of the page follows the same idea: the landscape becomes an ingredient map, then resolves into a practical recipe.

The page is available in English and Spanish. Changing the language preserves the visitor's warmth setting, scroll position, and selected number of portions.

Demo

Open the production build on Cloudflare Pages

One interaction, one purpose

The hero contains a range control called Warm the morning.

It moves through three states:

Mountain mist
First steam
Bowl passed

Moving the control raises the sun, warms the sky, strengthens the light around the bowl, and redraws the steam. Every response belongs to the same cause. I deliberately avoided a collection of unrelated hover effects and reveal animations.

The default state is complete without interaction. Keyboard, touch, and pointer input all reach the same result. When a visitor requests reduced motion, the ambient loop disappears, but the warmth control remains functional.

The design decisions that mattered

I rejected the usual food-site palette

My first direction was too familiar: cream background, serif headline, terracotta accent. It could have described almost any restaurant or recipe.

PISCA instead begins in a high-altitude blue. Warm yellow is reserved for the soup and the dawn it creates. The palette has six named roles: Páramo, Niebla, Caldo, Cilantro, Arcilla, and Leche.

I drew the subject instead of searching for a hero photo

The bowl, ingredients, steam, mountains, and material marks are original SVG and CSS work. There are no remote raster images in the production page.

That choice was not only about originality. A stock photograph would have made one recipe look definitive. Pisca is a family of Andean soups, and published versions differ. The page clearly presents one white, family-style variation rather than claiming a single canonical recipe.

I made the ingredient section spatial, not sequential

An early version placed decorative numbers on ingredient cards. That implied an order the ingredients did not have.

The final version turns them into an annotated contour basin around the bowl. Sequence appears only where it belongs: in the cooking method.

How it works

The canonical project is a small Vite and TypeScript build with no UI framework.

Content lives separately from interaction logic.
The language switch updates the document language and accessible names.
Portion controls scale quantities from two to eight servings.
CSS custom properties carry the warmth state into the illustration.
Fonts are self-hosted and split by Unicode range.
A deterministic build task converts the production artifact into the three files used by the CodePen version.

The CodePen is therefore not a hand-maintained imitation. It is generated from the same implementation deployed to Cloudflare Pages.

Accessibility and verification

I treated accessibility as part of the interaction design, not as a cleanup pass.

The page includes semantic landmarks, a logical heading structure, visible focus, a skip link, bilingual accessible labels, a named illustration, keyboard-operable controls, and a reduced-motion route.

Before this draft, the project passed:

strict TypeScript checking and linting with warnings denied
9/9 contest-specific checks
40/40 Playwright tests across desktop Chrome, mobile Chrome, reduced-motion Chrome, and desktop Firefox
automated Axe checks in English and Spanish with no violations detected in the selected WCAG A/AA rule sets
horizontal-overflow, language-state, portion-boundary, and warmth-state checks

Those results are automation evidence, not a claim of universal accessibility. A manual screen-reader pass and Safari/WebKit verification remain on my checklist.

What I learned

The strongest change came from asking whether the hero interaction could explain the subject instead of merely decorating it.

Once the visitor could warm the morning, several smaller effects became unnecessary. The page became clearer because one metaphor took responsibility for the color, motion, illustration, and status text.

I also found a real mobile grid overflow during visual inspection. Automated checks confirmed the behavior, but looking at the full composition at 390 pixels exposed the layout problem. Both forms of testing mattered.

Originality and AI use

I began this project after the challenge opened. The visual concept, SVG artwork, interface, bilingual content system, and CodePen conversion were created for this submission.

I used AI tools for research assistance, implementation support, and iterative quality review. I made the concept, editorial direction, final selection, verification, and submission decisions, and I reviewed and tested the output before using it.

The cultural and recipe context was checked against:

PISCA is my attempt to make a regional breakfast feel like a place before it reads like a recipe.

I Built a Multilingual Interactive Novel with Rust — ADHD Made Continuity the Hardest Part

Mario Gutierrez — Sun, 26 Jul 2026 02:25:18 +0000

Ideas are not the scarce resource for me.

Returning to an idea without losing its emotional logic, technical decisions, names, dates, and unfinished questions is much harder.

I live with ADHD. Starting an ambitious project can feel natural; holding its entire continuity in working memory for months does not. I can see a flooded city, a biomechanical implant, a character, and a complete scene with painful clarity—and then return days later unable to reconstruct why one small decision mattered.

That is how La Novena Marea stopped being only a manuscript and became a system.

It is a serialized, illustrated hydropunk novel set in 2648. The polar collapse did not cover the whole planet, but it destroyed the old idea of a stable coastline. Humanity survived through floating communities, conservative biomechanical adaptations, distributed intelligence, and uneasy coexistence with nonhuman civilizations that had hidden among us for centuries.

The website currently publishes the story in Spanish, English, and Brazilian Portuguese. It includes a prologue, the first chapter, a glossary, a technical world compendium, and an interactive atlas.

But the most important thing I built was not a page.

It was a way to return.

Iria Salvat receives a signal attributed to an intelligence that has been officially silent for forty-two years.

A novel can become a software architecture problem

The normal advice for publishing fiction online is reasonable: choose a CMS, install a theme, and start posting.

That was not enough for what I wanted.

The prose needed to remain readable without JavaScript. Every language needed its own static routes, metadata, canonical links, and social cards. Illustrations had to participate in the storytelling instead of behaving like decoration. Motion could add atmosphere, but it could never hold the text hostage. The atlas had to explain relationships between a signal, its origin, an altered route, and a community at risk.

I also wanted the technology to reflect the same principle as the world: survival through systems that remain understandable when one layer fails.

So I built the project around two frameworks I have been developing: PliegoRS and PliegoCSS.

The current responsibility boundary looks like this:

Spanish canonical manuscript
          ↓
PliegoRS
content · routes · semantic HTML · metadata · hreflang
          ↓
PliegoCSS
compiled structural CSS · no browser runtime
          ↓
JavaScript adapter
progressive motion · Atlas WebGL · newsletter enhancement
          ↓
Cloudflare Pages + Workers

PliegoRS is the Rust-based publishing layer. It owns the content model, routes, HTML, structured metadata, localized surfaces, and build receipt.

PliegoCSS compiles the structural style contract into standard CSS. The build checks that every emitted pc_* class actually exists in the compiled stylesheet. A matching version string is not considered enough evidence; the HTML and CSS must agree.

JavaScript is an adapter, not the owner of the book. If it fails, the prose, navigation, glossary, and static Atlas records still exist.

That separation became one of the most useful accommodations I made for myself. When I return to the project, I do not have to rediscover which layer is allowed to make a decision.

Responsive images are also narrative direction

One of the first painful mistakes appeared on a 13-inch iPad Pro.

The images were technically responsive. They had srcset, large sources, and fluid dimensions. They were also wrong.

A crop that looked cinematic on a phone could remove the direction of a character's gaze on a tablet. A large illustration could overlap the glossary because its layout context was incorrect. Two characters could appear together without looking at one another, turning an emotional scene into something uncanny.

I learned that image responsiveness is not only resolution selection. It is art direction.

The project now uses separate 16:9, 4:5, and 9:16 compositions where the scene requires them. Narrative illustrations ship with 1920- and 3840-pixel derivatives. Technical plates use object-fit: contain because cutting away a mechanism would also cut away information.

The current QA matrix exercises 21 indexable surfaces across six viewport configurations—126 route and viewport combinations—covering desktop, mobile, short landscape, and both orientations of an emulated 13-inch iPad Pro.

Emulation is not described as hardware proof. That distinction is written into the release criteria.

The nonhuman civilizations are neither saviors nor monsters. They are fallible neighbors responsible for the consequences of their silence.

Three.js needed a reason to exist

The first version of the Atlas looked impressive and communicated almost nothing.

It had depth, a grid, points, and movement. I could interact with it, but I could not explain what the interaction meant.

That is a design failure, even when the shaders work.

The Atlas was rebuilt around four questions:

Where did this signal originate?
Which route did it alter?
Which civilization is exposed?
What is the consequence of acting on incomplete evidence?

Three.js now enhances those relationships. It does not invent them. The same five records remain available as semantic HTML when WebGL, JavaScript, reduced-motion preferences, or data-saving conditions prevent the immersive layer from running.

That rule—the effect must explain something already present in the document—saved the Atlas from becoming a technology demo inside a novel.

You can inspect the current instrument in the Living Atlas.

Translation multiplies decisions, not only words

La Novena Marea is written in Spanish first. Spanish is the canonical narrative source.

English and Brazilian Portuguese are complete static editions, not runtime dictionary substitutions. IDs, dates, relationships, and evidence levels stay fixed. Titles, dialogue, prose, alternative text, navigation, metadata, and email messages are localized.

That means a new sentence can affect:

three manuscripts;
three routes;
three metadata sets;
long-word and diacritic behavior;
headings and image captions;
the glossary and compendium;
newsletter messages;
accessibility text.

The current site has 21 indexable surfaces: seven per language.

More languages are planned, but adding them all at once would be another form of losing continuity. French is the likely next edition; Chinese and Japanese would require a dedicated CJK typography and editorial pass. Spanish will remain the source of truth.

Documentation became an accessibility tool for my own attention

Documentation is often described as something written for another developer.

In this project, I am also that other developer.

I maintain:

a world bible;
a glossary;
a season outline;
a compendium contract;
a visual system;
exact distinctions between facts, official claims, testimony, and unresolved questions;
a continuity audit that refuses to silently accept changed authority files;
a release definition that separates automated validation, visual inspection, and real-device evidence.

These are not attempts to remove spontaneity. They protect it.

When I know that the year is recorded, the meaning of an implant is bounded, and an unresolved mystery has not accidentally become a fact, I can spend my attention writing the next scene instead of rebuilding the previous one.

I also use an AI assistant as a continuity and editorial collaborator. It helps me retrieve decisions, compare localized editions, inspect the implementation, and organize material. It does not get to silently ratify canon. New facts remain proposals until I approve them.

That boundary matters to me.

Every technology in the compendium needs an origin, material, maintenance burden, access cost, failure mode, and social consequence.

The publishing rhythm is part of the experiment

The editorial target is three chapter releases per week.

I am calling it a target, not a proven cadence. A schedule only becomes real after it survives contact with writing, translation, illustration, responsive QA, and ordinary life.

The system is designed to make that rhythm possible:

Spanish first;
continuity and evidence check;
English and Portuguese localization;
image and layout verification;
static build;
SEO and accessibility gates;
production smoke test;
publication notification.

If the process becomes too heavy, the answer is not to publish unreviewed material. The answer is to improve the system or adjust the cadence honestly.

What I would tell another developer building a long creative project

Do not rely on motivation to preserve continuity.

Give every layer a clear owner. Make the canonical source explicit. Record mysteries as mysteries. Test images for meaning, not only dimensions. Treat graceful degradation as part of the design. Separate what a tool verified from what you actually inspected.

Most importantly, build a return path.

A project that welcomes you back after your attention moved elsewhere has a much better chance of becoming real.

La Novena Marea is public and free to read at lanovenamarea.com.

If you want an email only when a new chapter is published, the newsletter is available at the end of the archive. It is optional, uses double opt-in, contains no advertising or commercial email, and deletes unconfirmed requests after a limited reminder cycle.

I am publishing the work as terrizoaguimor.

AI assistance disclosure: I wrote this article from my lived experience, project notes, code, and editorial decisions. I used Codex as a continuity and editing assistant to organize the material, verify technical claims against the working project, compose the draft, and refine the English. I reviewed and remain responsible for every statement before publication.

I Built a Rust Data Engine That Can Prove Its Own Results

Mario Gutierrez — Fri, 17 Jul 2026 00:10:35 +0000

Most data engines can answer a query. I wanted one that could also explain, offline and byte for byte, why that answer belongs to a specific durable state.

That question led me to build Hyphae, an open-source data engine in Rust with a deliberately small operational footprint:

one native binary;
one data directory;
no required database, cache, cloud service, embedding provider, or LLM;
deterministic KV and structured queries;
portable result proofs that can be verified offline.

If you read my earlier post about provenance over prediction, this is the next and deliberately narrower step. That work began as a cognitive substrate and clarified the provenance thesis. I have since rebuilt Hyphae as a standalone data engine. The research lineage remains, but the current product does not need an AI stack to be useful.

Hyphae 0.1.0 is now available on GitHub, through crates.io, and as signed multiplatform archives in the first public release.

The problem was not another query syntax

The usual path for an application data feature grows surprisingly quickly. A local library becomes a database service. Search adds another service. Caching adds another. Semantic retrieval adds a model provider. Soon, a feature that should be optional controls whether the application can start at all.

There is a second problem hiding underneath that operational stack: a successful response is usually just an assertion from the system that produced it.

If I receive a filtered, sorted, limited result, how do I check that:

the underlying durable state was not corrupted;
the query was executed with the declared semantics;
matching rows were not silently omitted;
the returned result is tied to the state I actually intended to trust?

Checksums help with corruption. Signatures can identify a producer. Neither one, by itself, proves that an arbitrary query result is complete and was reexecuted correctly.

Hyphae is my attempt to make those concerns part of the engine instead of application glue.

What Hyphae is

Hyphae is an autonomous, embeddable, and verifiable Rust data engine. Its durable authority is an append-only, checksummed, digest-chained log. Embedded indexes are rebuildable accelerators, not the source of truth.

The engine currently provides:

atomic structured KV mutations;
durable idempotency through caller-visible UUID transaction IDs;
recovery that fails closed on complete corruption and truncates only an incomplete final frame;
deterministic filters, global sorting, logical cursors, and grouped or global aggregations;
canonical snapshots, anchored compaction, backup, restore, and diagnostics;
exact provider-neutral vector retrieval in the Rust API, with explicit abstention;
proof-bearing reads and complete offline reexecution;
an optional, loopback-first OpenAPI /v1 server;
Rust, TypeScript, Python, CLI, and MCP clients over public versioned contracts.

The base product works with AI completely absent. A host may supply vectors to the Rust retrieval API, but Hyphae does not create embeddings and does not make a provider part of durable authority.

Try the single-binary flow

Install the public CLI from crates.io:

cargo install hyphae-cli --version 0.1.0 --locked
hyphae version --json

Choose a data directory and write two structured records:

export HYPHAE_DATA_DIR="$PWD/hyphae-data"

hyphae put --key alpha --json '{"group":"edge","score":10}'
hyphae put --key beta  --json '{"group":"edge","score":20}'
hyphae get --key alpha

Then run a deterministic query without a server or an AI dependency:

hyphae query \
  --field group --equals '"edge"' \
  --sort score --descending --limit 2

Every command reopens and verifies the same durable directory. A mutation returns its transaction ID and commit digests. An exact retry of the same transaction returns the original receipt; reusing that UUID for different operations is rejected.

From a result to a verifiable result

Add --proof-out to create a portable result proof:

hyphae query \
  --field group --equals '"edge"' \
  --sort score --descending --limit 2 \
  --proof-out result.hyproof

The JSON response identifies three things:

the canonical .hyproof file;
the exact snapshot witness;
the anchor digest for the snapshot and verified log checkpoint.

After pinning that anchor through a channel the verifier trusts, the result can be checked without opening the live data directory or contacting a network:

hyphae verify \
  --proof result.hyproof \
  --snapshot '<proof.snapshot_path>' \
  --anchor '<proof.anchor_digest>'

Verification checks the proof framing, CRC32C and BLAKE3 digests, the caller-supplied anchor, and the complete snapshot. It then reexecutes the embedded operation and requires an exact result match.

That last step matters. Hyphae does not only prove that some bytes were preserved. It checks that the declared query over the complete witness produces the declared answer.

There is also an important limit to state plainly: a self-consistent proof is not an external trust anchor. If an attacker controls the proof, snapshot, and the expected anchor, cryptographic consistency alone cannot establish which historical state should be trusted. The expected anchor must be pinned independently by the verifier.

The architecture in one picture

application
  |-- embedded Rust facade --------------------------|
  |-- local CLI                                      |
  `-- /v1 clients (Rust / TypeScript / Python / MCP) |
                         |                           |
                   optional HTTP server              |
                         `-------------+-------------'
                                       |
                          engine: KV / query / proof
                                       |
                         append-only durable log
                            |                  |
                     canonical snapshots  rebuildable index

The write path acknowledges a mutation only after its canonical frames and commit frame are appended and synchronized. The embedded index is then updated atomically. If that second stage fails, the log still contains the valid commit, the live handle refuses potentially stale reads, and the next open verifies and replays the missing work.

Snapshots serialize logical KV state rather than copying database internals. Compaction first commits the snapshot and next log generation through a new immutable manifest, then retires the previous segment. An interrupted transition therefore has one unambiguous winner.

Four design choices that shaped 0.1.0

1. No partial success disguised as a result

Structured query has hard budgets for scanned records, matches, returned rows, groups, query shape, time, proof size, and response size. If a budget or timeout is exceeded, the operation returns an error and no partial logical result.

For a proof-bearing engine, a plausible-looking prefix is worse than a loud failure.

2. The log is authority; indexes are disposable

Treating the embedded index as rebuildable simplified the recovery contract. A checkpoint is accepted only when its sequence and digest identify the same verified log commit. If the index is missing, Hyphae can reconstruct it. If durable history is corrupt, it fails closed.

3. AI is an optional input, never a prerequisite

KV, structured query, aggregation, recovery, snapshots, backup, and proof verification all work without embeddings or an LLM. Exact cosine retrieval accepts vectors supplied by a Rust host and can abstain when there are no candidates, the score is insufficient, or the top margin is ambiguous.

This keeps semantic providers replaceable and outside the storage trust boundary.

4. Integrations depend on Hyphae, not the reverse

The wire contract is OpenAPI 3.1 plus JSON Schema 2020-12 under a versioned /v1 surface. Framework adapters are optional consumers. Astro, Next, Vite, PliegoRS, or any other host must continue to build and run when Hyphae is absent.

That boundary is less exciting than a feature list, but it is what lets the engine remain autonomous.

What 0.1.0 deliberately does not do

Hyphae is not SQL, a distributed database, a hosted SaaS, or a cognitive runtime. It does not currently ship joins, replication, clustering, built-in TLS, encryption at rest, access-control roles, multitenancy, an embedding model, or an LLM.

The optional HTTP server binds to loopback by default. Applications own remote TLS termination, process supervision, filesystem permissions, and backup-media policy.

Those are product boundaries, not omissions hidden behind a roadmap. The complete current capability matrix and limits are documented in the repository.

What ships in the first release

Hyphae 0.1.0 includes:

the hyphae binary for local operations, server, remote client, verifier, and MCP;
ten published Rust crates, including the embeddable hyphae-engine facade;
dependency-free TypeScript and Python HTTP clients;
canonical OpenAPI and JSON Schema contracts;
executable examples and a cross-client conformance suite;
Linux, macOS, and Windows archives with checksums, SBOMs, signatures, and provenance;
documented disk formats, recovery behavior, threat models, ADRs, and release gates.

The source is licensed under Apache-2.0. The current repository is separate from historical research prototypes and the Hyphae Network project; historical sources remain frozen inputs, and only audited pieces with documented provenance may cross that boundary.

Where I would value feedback

This is a first public release, and I am especially interested in three questions:

Where would a proof-bearing local query result materially simplify your system?
Is a complete snapshot witness the right 0.1 tradeoff, or would your workload require authenticated indexes or smaller multiproofs?
Which embedded Rust integration should become the next executable example?

You can explore the project here:

If durable local data and independently checkable results belong in the same engine, I would like to hear what you would build with it.

I Built a Rust-Native Web Framework That Can Explain Every Build

Mario Gutierrez — Fri, 17 Jul 2026 00:10:13 +0000

I kept running into the same uncomfortable gap in modern web tooling.

We are very good at producing interfaces. We are much worse at explaining them.

Which input produced this file? Why did this route rebuild? Can the application replay its state and reach the same result? When a WebGL scene disappears, who owns the cleanup? Can the release I downloaded be tied back to an exact source commit?

Those questions became the starting point for PliegoRS, a Rust-native web framework for verifiable, replayable, durable interfaces.

Today I am releasing PliegoRS 0.0.1 as an Apache-2.0 public preview.

This is not a JavaScript-free purity project

The principle behind PliegoRS is simple:

The framework owns the system. The browser owns the medium.

Rust owns the authored application model: routes, typed views, content, events, folds, reactive state, build artifacts, diagnostics, and the client behavior that benefits from Rust/WASM.

The browser still owns the browser. PliegoRS does not try to reimplement GSAP, Lenis, Three.js, WebGL, or the platform APIs they already use well. Mature JavaScript libraries remain JavaScript, but they run behind an explicit lifecycle boundary instead of becoming invisible global state.

The goal is not fewer technologies at any cost. The goal is clearer ownership.

1. An interface can be a projection, not just a mutable snapshot

The default PliegoRS application starts with typed, versioned events and a fold that projects those events into state.

typed events -> append-only log -> deterministic fold -> interface
                         |                |
                         |                +-> snapshot
                         +-------------------> replay

A reducer must be pure. A replay of the same admitted history must produce the same projected state. Snapshots are bound to the event head, schema set, reducer identity, codec configuration, and canonical state bytes.

That makes features such as history, undo, provenance, audit, and synchronization part of the application model rather than an afterthought bolted onto components.

Static projects do not need a database. When durable synchronization is required, PliegoRS exposes a verified protocol boundary for Hyphae, but the framework does not claim that a production Hyphae gateway exists in this preview.

2. A build should leave evidence

Most build tools tell you whether a build succeeded. PliegoRS also tries to preserve enough evidence to explain what happened.

Every successful build emits a deterministic output ledger and a causal graph. The CLI can answer questions about individual artifacts and rebuild decisions:

pliego inspect
pliego why artifact /journal/index.html
pliego why-rebuilt

The output pipeline guards its namespace, stages changes before publication, hashes emitted artifacts, and records the inputs that influence the result. A content hash is integrity evidence, not authorship, so PliegoRS keeps that distinction explicit.

The 0.0.1 GitHub release goes further: it contains five target archives, SHA-256 files, a two-replica reproducibility record, and an Ed25519-signed exact-set manifest. The release was built from commit e4d0d3d.

This is not a claim of a perfectly hermetic universe. It is a practical attempt to make release claims inspectable instead of implicit.

3. Imperative browser code needs an owner

Visual websites need animation, smooth scrolling, 3D, media, and direct access to browser APIs. Pretending otherwise only pushes those concerns into unmanaged scripts.

PliegoRS adapters have a versioned mount / update / unmount contract. The runtime owns admission, lazy triggers, cancellation, reduced-motion and Save-Data policy, error isolation, and deterministic LIFO cleanup.

An adapter can still use the natural API of its library:

export async function mount(node, context) {
  const scene = createThreeScene(node, context);

  return () => {
    scene.dispose();
  };
}

The difference is that teardown is no longer a convention hidden in a component. It belongs to a framework-owned lifecycle. If a mount is cancelled, fails, or leaves the document, its resources still have an explicit owner.

Useful HTML first, Rust/WASM by intent

PliegoRS emits complete static documents with typed metadata, safe HTML defaults, routes, content, assets, and SEO. A static page does not need a framework runtime to remain useful.

Rust/WASM resumes only the behavior the document needs. External browser libraries are loaded only when their declared policy admits them. Adaptive media plans can account for viewport tier, Save-Data, reduced motion, and transfer budgets before a heavy asset is selected.

That division matters to me: the first response should be a document, not a promise that a document will eventually appear.

Try the public preview

You need Rust 1.85 or newer.

cargo install pliego-cli --version 0.0.1 --locked

pliego new field-notes
cd field-notes
pliego check
pliego dev

The default starter is a small replayable application, not an empty marketing screen. Three additional maintained templates are included:

pliego templates
pliego new my-journal --template editorial
pliego new my-film --template cinematic
pliego new tiny-site --template minimal

Linux production binaries and macOS/Windows development binaries are also available in the signed GitHub release. Download them to disk and verify the release bundle before running them; the project deliberately does not recommend piping an installer from the network into a shell.

What is actually in 0.0.1?

The preview includes:

deterministic static generation with typed routes, heads, assets, and build ledgers;
a typed view macro, signals, memos, effects, ownership scopes, and cleanup;
typed Markdown, JSON, and TOML content collections;
typed/versioned events, transactional folds, snapshots, and exact-tail replay;
Rust/WASM clients and resumable standard browser actions;
lifecycle adapters for external ESM libraries;
adaptive plans for images, video, fonts, and 3D assets;
native-event development, preview, structured diagnostics, causal inspection, and typed HMR;
default, minimal, editorial, and cinematic starters;
fifteen published Rust crates and a cross-platform release pipeline.

The documentation site is built with PliegoRS itself and covers the framework contracts, security boundaries, release verification, starters, content, lifecycle adapters, and the Hyphae protocol boundary.

What it does not claim yet

0.0.1 is pre-1.0 software. APIs may evolve between minor releases.

PliegoRS does not yet claim broad server-framework parity, production-verified Hyphae synchronization, signed production support for the macOS and Windows artifacts, or 1.0 stability. The current strongest path is deterministic static generation with focused Rust/WASM interaction and explicit adapters for browser-native libraries.

I would rather publish a narrow, testable boundary than hide unfinished systems behind a large version number.

Why release it now?

A framework cannot become useful in isolation. It needs projects that stress its assumptions, developers who dislike its ergonomics, and bug reports that its own test suite did not imagine.

So the first public preview is an invitation to challenge the model:

Create a project.
Build it twice.
Inspect the ledger.
Add a small Rust/WASM interaction or a JavaScript lifecycle adapter.
Tell us where the framework stops helping.

Start with the source on GitHub, read the documentation, or inspect the pliego-cli API docs.

If the web framework you want is one that can explain its state, its artifacts, and its ownership boundaries, I would genuinely like to hear what you build with PliegoRS.

PliegoRS is an Apache-2.0 project by Celiums Solutions LLC.

EL RELATOR - your life, narrated like a World Cup goal (in two languages)

Mario Gutierrez — Sat, 11 Jul 2026 16:51:24 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

EL RELATOR takes any moment of your life — "my test finally passed after three hours of debugging", "I found parking on a Friday at 6pm", "my daughter took her first steps" — and narrates it as an over-the-top radio football commentary, complete with the legendary elongated ¡GOOOOOOOL!, delivered as real audio.

You type the moment, pick a language (Spanish or English — the whole UI and the narration switch), pick an intensity, and a relator loses his mind over your small victory like it's stoppage time in the World Cup final.

Three intensity levels:

Radio 🎙️ — classic radio call, emotional but controlled
Final 🏆 — championship final energy
Infarto / Cardiac 🔥 — minute 93, World Cup final, on the verge of happy tears

The goal: with the World Cup ongoing, everyone deserves their own personal commentator. Because passion doesn't distinguish between a stoppage-time final and a green test suite on a Friday deploy.

Demo

🎬 Watch the 60-second promo (with sound — the voice IS the demo)

The promo itself was narrated with the same ElevenLabs voice the app uses — including a live "GOOOOOOOAL!" over a passing test suite.

Here's what it produced for "I found parking right in front of the building, on a Friday at 6pm" on Cardiac mode (English):

It is ninety-three minutes on the clock. Friday evening. The rain is pouring, the traffic is a wall of steel, and the hope is fading. […] He cuts inside, he cuts back, he guides the vehicle into the tightest of corridors, AND HE HAS DONE IT! GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOAL! THE PARKING SPACE IS HIS! […] I am weeping, ladies and gentlemen, we are witnessing absolute perfection!

And in Spanish, for "after three hours of debugging, my test finally passed" on Infarto:

[…] le da play a la consola y el cursor empieza a correr, corre, corre, busca el destino de gloria, se enciende la pantalla y se pone, se pone, ¡SÍ, SE PONE VERDE! ¡GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL! ¡GOL DE LA VIDA! ¡PASÓ EL TEST! […] ¡y el alma que vuelve al cuerpo en un grito sagrado que lo escucha todo el barrio!

Run it locally in under a minute (both APIs have free tiers):

git clone https://github.com/terrizoaguimor/el-relator
cd el-relator
cp .env.example .env         # add your Gemini + ElevenLabs keys
npm install && npm run dev   # open http://localhost:4321

Code

terrizoaguimor / el-relator

Any moment of your life, narrated like a World Cup-winning goal. Gemini writes, ElevenLabs screams. DEV Weekend Challenge: Passion

EL RELATOR ⚽📻

Any moment of your life, narrated like a World Cup–winning goal. In Spanish or English.

Passion doesn't distinguish between a stoppage-time final and a green test suite on a Friday deploy. EL RELATOR takes any moment you give it — "my test finally passed", "I found parking", "my daughter took her first steps" — and turns it into an over-the-top radio football commentary, complete with the legendary elongated ¡GOOOOOOOL! / GOOOOOOOAL!, delivered as real audio.

Built for the DEV Weekend Challenge: Passion ❤️‍🔥

Example output (input: "I found parking right in front of the building, on a Friday at 6pm", intensity: Cardiac):

It is ninety-three minutes on the clock. Friday evening. The rain is pouring, the traffic is a wall of steel, and the hope is fading. […] He cuts inside, he cuts back, he guides the vehicle into the tightest of corridors, AND HE…

View on GitHub

How I Built It

If there is one universal language of passion, it's the voice of a football relator. That voice doesn't distinguish between a Champions League final and a green test suite — passion is passion.

Tech stack

Layer	Technology
Script generation	Google Gemini (`gemini-flash-latest`, Google AI Studio API)
Voice	ElevenLabs (`eleven_multilingual_v2`)
Framework	Astro 5 — SSR with the Node adapter; the page and the API route live in one project
Frontend	Vanilla HTML/CSS/JS: floodlight sweeps, LED ticker, scoreboard, audio equalizer, confetti on every goal

Your moment + language + intensity
        │
        ▼
  Astro API route (/api/relato)
        ├─► Gemini ──► writes the commentary script
        └─► ElevenLabs ──► gives it the voice
        ▼
  MP3 + script back to the browser

Google AI (Gemini) — the writer 🖋️

Gemini runs with an in-character system prompt per language: it IS the relator. The prompt encodes the craft of radio commentary — short phrases that build tension, accelerate, and EXPLODE at the climax with elongated vowels, then land on a poetic closer ("y lo grita todo el barrio" / "and the whole neighborhood is screaming"). Each intensity level changes the writing brief, and sad moments are narrated too — with the epic dignity of a lost final.

A detail that mattered: the prompt treats the output as a radio performance, not text — no emojis, no markdown, elongated vowels, punctuation as pacing, 60–110 words (~30–45s of audio). I also set thinkingBudget: 0 so tokens go to the script, not reasoning.

ElevenLabs — the voice 🎙️

The script goes to ElevenLabs, and this is where the project comes alive. Two tricks:

One multilingual voice (eleven_multilingual_v2) performs both Spanish and English — same commentator, two languages.
Voice settings are tuned per intensity level:

Intensity	stability	style
Radio	0.45	0.55
Final	0.30	0.80
Infarto	0.15	1.00

Lower stability + maxed style = a genuinely unhinged, cracking, emotional delivery. On Infarto, the voice actually sounds like it's about to lose it during the ¡GOOOOOL! — which is exactly the point. The elongated vowels Gemini writes give the TTS something real to scream.

The same intensity knob drives both the writing brief and the voice settings — writer and performer are directed together, which is what makes the output feel coherent.

What I learned

ElevenLabs' stability/style settings are a legit performance direction tool, not just quality knobs.
Writing FOR text-to-speech is its own discipline: the system prompt treats the script as a radio performance, not text.
Astro's SSR mode makes this kind of project trivial: src/pages/api/relato.ts keeps both API keys server-side, and the page ships almost zero framework JS.

Prize Categories

This submission is for Best Use of Google AI and Best Use of ElevenLabs:

Google AI: Gemini (gemini-flash-latest) is the writer — bilingual in-character system prompts turn any life moment into a 60–110 word radio goal call, with the intensity level shaping the writing brief.
ElevenLabs: eleven_multilingual_v2 is the performer — one voice speaks both languages, and per-intensity stability/style settings direct the emotional delivery, from controlled radio call to full minute-93 meltdown.

Passion doesn't need a stadium. Sometimes it's just you, a green test, and a voice screaming ¡GOOOOOOOL! at 2am. ❤️‍🔥

Six failures, a 32-minute TPU lie, and the moment a language model ignored my prompt on purpose

Mario Gutierrez — Wed, 03 Jun 2026 17:28:05 +0000

Every language model you've ever used is a single-channel machine: text goes in, text comes out, and the prompt is the only force acting on the network. Our entire toolbox for evaluating LLMs quietly assumes that.

I couldn't stop poking at a different question: what if a model also had a sense of its own internal state — not what's in the prompt, but what it is carrying — and that sense shaped how it answered, at every layer?

Six signals. I call them proprioceptive channels — by analogy to how your body knows where your arm is without looking. Not perception of the world; perception of itself. What's salient in memory right now. Its mood. The time. Its caution posture. Which "self" is active. Which thread of the conversation it's on. I called the architecture MARS.

This is the honest story of trying to prove it works — including the part where I failed six times in a row, the day my TPU lied to me for half an hour, and the test result that made me put the coffee down.

Repo + everything below: 👉 github.com/terrizoaguimor/tinymars

Act 1: six iterations, six negatives

For six rounds, I trained the channels to carry content — a fact, a persona — and asked an LLM to judge whether the output reflected it. Six times, basically nothing. Flat. The kind of clean, repeated negative that whispers "your idea is wrong, friend."

I almost shelved it. What saved it wasn't optimism — it was getting specific about why it failed. The bug wasn't the architecture. It was me. I was asking the channel to do the prompt's job: cram a whole fact into a pooled vector and have the model decode it back out. That's close to impossible, and it's not what the design is for. (The LLM judges, unreliable on tone, hid the mistake under noise.)

The fix was almost embarrassing in hindsight: put the content in the prompt (like RAG), and let the channel carry only state — which memory is salient, what posture to take. Re-ran with objective metrics and no LLM judges. Six capabilities, all positive. The one that had been flattest (identity) gave the biggest signal once I stopped testing it wrong.

Lesson tattooed on me now: a flat negative often means a broken experiment, not a broken idea. Measure the thing you actually built.

Act 2: "wait — this test can't even see what I care about"

Even with 6/6, something nagged. The standard test asks: does the channel say X better than a text prompt would? And honestly — for a simple instruction, a good instruction-tuned model follows text near-perfectly. So text is a strong baseline, and on that axis the channel ties it.

But that's the wrong axis. It's measuring a river current with a speedometer. The real claim isn't "the channel is a nicer way to write a prompt." It's that internal state is a second, perpendicular force — one that can override the text.

So I built the test a single-channel model literally cannot be given: set the channel to say one thing, write the prompt to say the opposite, and measure who wins.

capability	times the internal state beat the contradicting prompt
affect	85/86 (98%)
time	80/80 (100%)
ethics	99/99 (100%)
total	264/265 (99.6%)

The model followed its internal state over the explicit text, 264 times out of 265. And the part that made me stare: I never trained it to do that. It was only ever trained to read the channel. That the channel would win a fight with the prompt was never an objective — it emerged. I'd pre-registered the result that would've killed the claim (text wins) before running it. It didn't happen.

That's the moment the project stopped feeling like "fine-tuning with extra steps" and started feeling like a new kind of control.

Act 3: the day the TPU lied to me

dev.to is for builders, so here's the trench story. I spun up a fresh Cloud TPU, kicked off the eval, and watched the log sit there. And sit. Thirty-two minutes, one CPU core pinned at 94%, zero output. Not crashed — "running." Lying to my face.

The culprit: a fresh install pulled transformers 5.x, which fires torch.compile/inductor inside the forward pass — pathological under torch_xla. The model wasn't generating; it was stuck compiling on CPU forever. Then the VM got so saturated SSH wouldn't even let me in to kill it.

The fix was a maze: downgrade to 4.x? — that version can't even load the tokenizer (different bug). The actual answer was transformers 5.x with TORCHDYNAMO_DISABLE=1 — verified with a tiny "does it generate at all" smoke test before trusting it again. When SSH was locked out, a stop/start (not delete — never delete) freed the box. If you train Gemma-class models on TPU: write that env var on your hand.

Act 4: the honest part (this is why you can trust the 264)

If a research project reports everything as a win, be suspicious — somebody leaned on the scale. So here's the stuff that didn't go my way, on the record:

It's an adapter on a frozen base, at smoke scale (~186M trained params on a frozen Gemma E2B). Not a from-scratch architecture yet.
I predicted wrong, repeatedly. I bet the "register" channels would just tie text. Two of them (time, ethics) the channel won decisively. My calibration was off — in the architecture's favor, but off.
One whole test came back null, and I kept it. I expected the channel to persist better than text across long context. At the scale I can test (the model trains at 256 tokens), there was nothing to measure — the text didn't decay either. Untested, not refuted. It's in the report as a flat line, because hiding it would make the 264 a lie too.

Act 5: what's next

What I proved is a functional category: internal state as a control force, measured under adversarial conflict. To make it an architectural category, the channels have to be there from layer 1, trained from scratch — not bolted onto a model that already knew how to talk.

That experiment is specified. The trick (an epiphany I'm still smiling about): I don't reinvent the language part — I stand on a proven small-LM recipe (nanochat) for "learn to speak," so the channels are the only new variable. Param-matched control. A stop-loss, written down in advance: three iterations with no signal vs baseline and I downgrade the claim, in public.

If you want to poke holes

Everything's open — code, the technical report, every per-iteration metric, the objective scorers, and the pre-registration of the conflict test:

👉 github.com/terrizoaguimor/tinymars

Archived + citable: DOI 10.5281/zenodo.20531347 · GPL-3.0 (code) / CC BY-SA 4.0 (docs).

If you work on representation steering, control-theoretic alignment, or you just respect an honest negative result — come break it. The conflict test is the one I'd attack first. I'd genuinely love to be wrong in an interesting way.

Why I'm building Hyphae: provenance over prediction (and the 3-line baseline that tied it)

Mario Gutierrez — Fri, 29 May 2026 14:55:20 +0000

A few months ago I set out to build a cognitive substrate without a large language model in the answering path. I had a thesis I liked, a Rust workspace, and a lot of conviction.

Then I wrote a three-line baseline that tied it on every metric I cared about.

This is the story of why that was the best thing that happened to the project — and why I'm still building it, just pointed at a sharper target.

The problem I actually care about

When a language model answers a grounded question, it paraphrases its sources. That paraphrase is fluent, often correct, and — this is the part that bothers me — impossible to bind back to its source byte-for-byte. You can cite a document. You cannot prove, after the fact, that the words in the answer are the words that were stored, unaltered, at a known position.

For a chatbot that doesn't matter. For anything that has to be audited — a compliance trail, a medical or legal memory, an agent acting on your behalf over months — it matters a lot. "Trust me, I read the docs" is not a property you can verify.

So I started building Hyphae: a substrate that answers by emitting byte-identical quotations of stored memory fragments, over a SHA-256 hash-chained journal, with no LLM in the cognition path. Rust, CPU-only, a single binary.

The shape of it is simple:

// Every stored fragment is appended verbatim to a hash chain.
let (seq, head) = journal.append("memory_op", fragment.bytes())?;

// An answer span is a byte-identical quotation of a stored fragment.
// Tamper with any historical entry and the recomputed chain breaks
// at the next link — verify() localises exactly where.
journal.verify()?;

Nothing here is cryptographically novel. Hash-chained logs are old and well understood — Haber & Stornetta in 1991, Merkle before that, Certificate Transparency, git. I want to be honest about that up front, because the interesting part isn't the chain.

The day a three-line baseline tied me

I wanted to show Hyphae was better than an LLM+RAG pipeline at grounded answering. So I built the comparison properly: a real retriever, reranking, six models across three retrieval modes, two corpora, twelve metrics.

Then a reviewer asked the obvious question: what does a trivial baseline score?

So I wrote echo — a few lines that just print the retrieved fragment back. It tied Hyphae on every correctness and grounding metric. So did echo + journal.

That stings for about a day. Then it becomes the whole point.

The measured correctness and grounding were never properties of my system. They are properties of verbatim quotation itself. If you emit a stored span unchanged, of course it's "grounded" — it is the source. Hyphae's seventeen subsystems weren't what made the answers auditable. The verbatim-emission-over-a-journal layer was. And that layer is addable to any extractive retrieval system — it isn't Hyphae-specific at all.

So I stopped claiming Hyphae was a better brain and started claiming something narrower and, I think, truer:

Verifiable provenance is a property you can add to grounded retrieval. A paraphrase destroys byte-level bindability to its source; a verbatim quotation preserves it, and a hash chain makes that binding independently auditable.

The contribution isn't the hash chain. It's the observation, and the measurement of it against eighteen LLM configurations and a tamper-detection benchmark.

Closing the gaps, honestly

Once you claim "tamper-evident," people who know what they're doing immediately ask where it breaks. Good. The threat model is the product.

A bare hash chain catches a store-only attacker who edits a record in place. It does not catch a chain-aware attacker who recomputes every hash forward and rewrites the head — because the head lives in the same store. So I anchor the head with an Ed25519 signature held outside the store (the attacker can't re-sign). That closes it.

But a single signature pins a valid head, not the latest one. Every head the journal ever had was, at its time, legitimately signed. An attacker can roll back to an earlier state and replay its genuine-but-stale anchor — and a lone signature check accepts it. So the heads get published to an append-only, hash-chained ledger, and an auditor checks the current head against the ledger's tail:

// A single signature pins *a* valid head.
// An append-only ledger pins *the latest* one.
verify_fresh_head(&current_head, &ledger, &verifying_key); // rollback rejected

That's the pattern from Certificate Transparency and git, applied to memory provenance: the value isn't the chain, it's publishing the head to a monotonic log that third parties can compare.

And I keep a column for what I haven't closed: a store that withholds later ledger entries is only caught once an auditor gets the true tail from an external witness (a timestamp authority, a gossiped tree head). That's deployment work, and I'd rather write it down than pretend it's solved.

Where this is going

The direction got clearer the moment the echo baseline humbled me. I'm not building a better answer engine. I'm building provenance as a first-class, measurable property of grounded AI, in the open. Concretely:

A provenance benchmark. Correctness benchmarks compare RAG systems on answer quality. There's no standard way to compare verifiable-generation systems on whether tampering is detectable and localisable. So I built one: a tampering taxonomy, an adversary-capability matrix, and a scoring protocol any system can plug into. That's the axis I think actually matters for AI you have to trust over time.
Provenance as an addable layer. The realizer-independence is the feature, not a caveat. The goal is for any extractive retriever to be able to adopt the layer.
External witnessing and key rotation to harden the ledger for real deployments.
The bigger picture — this is one piece of Celiums, where the bet is that memory is the foundation for AI agents you can actually audit, not an afterthought bolted onto a model.

It's all open

The substrate, the LLM+RAG comparator, every result envelope, the tamper-detection experiment, the provenance benchmark, and the full preprint are public. Code is Apache-2.0; the docs, corpora, and preprint are CC-BY-4.0.

Code: https://github.com/terrizoaguimor/hyphae-v2
Preprint (Zenodo DOI): https://doi.org/10.5281/zenodo.20436643

I'm a solo, self-taught founder building this in public, which means the dead ends are public too — the echo baseline being the best example. If you work on retrieval, tamper-evident logs, or grounded generation, I'd genuinely like to hear where you think this breaks. The threat model only gets better when someone smarter than me attacks it.

I Have ADHD and I Keep Losing Context — So I Taught My AI to Remember for Me

Mario Gutierrez — Fri, 17 Apr 2026 13:38:29 +0000

I'm going to be honest about something that most people in tech don't talk about openly.

I have ADHD. I'm 40. I'm a self-taught developer with no CS degree. And I lose context constantly.

Not in the "oh I forgot where I put my keys" way. In the "I just spent 3 hours deep in a codebase, got interrupted by a Slack message, and now I genuinely cannot remember what I was doing or why" way.

If you have ADHD, you know exactly what I'm talking about. If you don't — imagine your browser crashing and losing 47 tabs. That panic? That's every Tuesday for me.

The AI Paradox for ADHD Brains

Here's the thing nobody warned me about: AI coding tools made my ADHD worse.

Not better. Worse.

Why? Because they're stateless. Every session is a blank slate. And for someone who already struggles with working memory, having to rebuild context from scratch every time I open Claude Code or ChatGPT is genuinely exhausting.

Me at 9am: "I'm working on a Next.js app with Supabase auth, 
           JWT refresh tokens, the user table has these columns..."

Me at 2pm: "I'm working on a Next.js app with Supabase auth,
           JWT refresh tokens, the user table has these columns..."

Me at 9pm: "I'm working on a Next.js app with Supabase auth..."

I type the same context paragraph 5-8 times a day. Every. Single. Day.

For a neurotypical developer, this is annoying. For me, each repetition drains the limited executive function I have. By the third time, I'm frustrated. By the fifth, I'm done for the day.

The tool that's supposed to help me think is making me spend my mental energy on remembering what to tell it.

The Breaking Point

It happened on a Thursday at midnight. I was debugging a race condition. I'd been at it for two hours. Claude gave me a suggestion I'd already tried — because it didn't know I'd already tried it. Because it doesn't remember anything.

I typed (and I'm not proud of this):

"I ALREADY TRIED THAT. WE DISCUSSED THIS 20 MINUTES AGO IN THE PREVIOUS SESSION."

Then I realized: I was yelling at a machine for not having memory. And the machine was right to not remember — it was designed that way. Every AI tool is designed that way.

That's when something clicked. Not the bug (that took another hour). Something else:

The problem isn't AI intelligence. It's AI amnesia.

What I Actually Needed

I sat down and wrote a list of what would actually help my ADHD brain:

Don't make me repeat context. Ever. If I told you once, you should know it forever.
Remember what worked AND what didn't. So you don't suggest the thing I already tried and rejected.
Know when I'm frustrated. If I've been debugging the same thing for 2 hours at midnight, maybe don't give me a 500-word explanation. Just give me the fix.
Carry context across projects. My coding style doesn't change when I switch repos. My preferences don't reset.
Forget things naturally. Not everything is worth remembering forever. That random CSS hack from 6 months ago? Let it fade.

I looked for tools that did this. I found vector databases pretending to be memory. I found RAG pipelines that retrieve documents but don't understand context. I found "memory" features that are just conversation logs with a search bar.

Nothing actually modeled how memory works. How my brain works (when it works).

So I Started Building

I'm not going to pitch you anything. But I will tell you what I learned, because maybe it's useful to someone else.

I started reading neuroscience papers. Real ones. Not Medium articles — actual research on how human memory works:

The Ebbinghaus forgetting curve — memories decay exponentially unless reinforced. Your brain doesn't delete things; they just fade. This is the opposite of how databases work (store forever, delete explicitly).
The PAD emotional model — Pleasure, Arousal, Dominance. Psychologists use three dimensions to map any emotional state. Turns out, emotions are not decorations on memory — they're part of the retrieval mechanism. You remember emotional events better. Your brain literally prioritizes them.
Circadian rhythms affect cognition — you're not the same developer at 9am and 11pm. Your ability to focus, recall, and make decisions fluctuates. Any system that treats you the same at all times is ignoring biology.

I started modeling these concepts in code. Not as a product — as a personal tool. Something that would sit between me and my AI tools and just... remember things for me.

The first version was ugly. 200 lines of JavaScript and a JSON file. But it worked. I told it my preferences once, and the next day, they were still there. I told it about a debugging approach that failed, and it remembered that too.

For the first time in years, I felt like my tools were adapting to me instead of the other way around.

What I Learned About Memory (and ADHD)

Building this taught me things about my own brain:

1. Context is not content. There's a difference between "what was said" and "what matters." Most AI memory solutions store conversations. But what I need is context — the decisions, the preferences, the patterns. Not the 400 lines of chat where we discussed them.

2. Forgetting is a feature, not a bug. My ADHD brain forgets things constantly, and yes, it's frustrating. But it also means I don't carry stale assumptions. I approach problems fresh. The best memory system isn't one that remembers everything — it's one that remembers the right things and lets the rest fade.

3. Emotions are metadata. When I'm frustrated with a solution, that frustration is information. It means "this approach has a problem, even if the code technically works." Any memory system that strips emotional context is throwing away signal.

4. My ADHD is a design constraint, not a disability. When I design for my own limitations — short working memory, need for external structure, sensitivity to context switches — I end up building things that work better for everyone. Turns out, neurotypical developers also hate re-explaining context to their AI tools. They're just more patient about it.

The Uncomfortable Truth

Here's what I think about late at night:

Every major AI company is racing to build bigger models, longer context windows, better reasoning. And that's great. But none of them are building memory.

Not real memory. Not the kind that persists, decays, carries emotion, and adapts to you over time.

They're building incredibly smart assistants with permanent amnesia. And we've all just... accepted that?

I didn't accept it. I couldn't. My brain wouldn't let me.

Where I Am Now

I'm a solo founder. Venezuelan, living in Medellín, Colombia. Zero employees. I run the company with AI agents (which is a whole other post).

I've been working on this problem for months. Some days I feel like I'm building something important. Other days I feel like I'm a guy with ADHD who got hyperfocused on a niche problem and can't stop.

Both are probably true.

If you're a developer with ADHD — or honestly, any developer who's tired of being the memory system for your AI tools — I'd love to hear how you deal with it. What workarounds have you found? What do you wish your tools remembered?

And if you're building AI tools: please, for the love of everything, add persistent memory. Your ADHD users will thank you. Your neurotypical users will thank you too, they just won't know why.

This is my first post here. I'm Mario. I'll probably write about building things alone, neurodivergent entrepreneurship, and why AI tools should be designed for how brains actually work — not how we wish they worked.