DEV Community: Nazaret

I built a haunted museum where dead tech (and my old repos) talk back 👻

Nazaret — Sat, 31 Oct 2026 19:11:48 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

The Haunted Museum of Dead Tech 👻 is a museum where the technologies we buried come back as ghosts, and they still have a lot to say.

You walk through the halls, pick an exhibit and talk to its ghost. Each one tells you its story, defends itself from its critics and tries to convince you that it deserves to come back from the dead.

The collection has eight ghosts born between 1971 and 1999: the Floppy Disk, VHS, the Walkman, the Game Boy, Encarta, Internet Explorer, Clippy and MSN Messenger. The Floppy Disk is grumpy because it's still the Save icon and nobody thanks it, VHS gets upset if you didn't rewind, and MSN sends you a nudge if you take too long to answer.

Every ghost is shaped like its object (a floppy disk, a cassette, a little console, an open book, a chat bubble...), with a pastel color, a soft halo and a face that moves its mouth while it talks.

I read the theme in two ways at once. Halloween gave me the ghosts and the séances. Día de los Muertos gave me the idea of honoring what is gone: remembering these technologies with love, leaving them offerings and letting them tell their own story. So the museum also has:

🕯️ Ofrendas. Leave a candle, a marigold, pan de muerto or the ghost's special gift on its altar (a rewound rental tape for VHS, fresh AA batteries for the Game Boy...). The ghost reacts, and the most loved ghost gets a badge in the hall.
📖 Guestbook. Sign an exhibit's guestbook and the ghost writes you a dedication back, like signing a yearbook.
⚔️ Debate Hall. Pick two ghosts and a topic, and they argue live, turn by turn, answering each other. When the candles burn out, you vote the winner.
🪦 Repo Graveyard. The personal wing. Write your GitHub username and every repo you stopped committing to gets a tombstone with an epitaph. Then you can summon the ghost of any repo: it remembers its README and last commits, knows you created it, and asks you why you left.

The inspiration was simple: I'm a web development student, I got into programming through an HTML game, and I still remember the floppy disks and MSN nudges. I wanted a place where those memories could talk back.

Demo

The museum runs locally with Ollama, so the best way to see it is the video. To run it yourself, the instructions are in the repo.

Code

itsnazaretdev / haunted-museum

👻 Haunted Museum of Dead Tech

A haunted museum where dead (or almost dead) technologies come back as ghosts.

Built for the Hacktoberfest open-source AI challenge, week "Ghost in the Machine" Every ghost runs on Gemma 3 (4B) through Ollama, locally. No API keys, no cloud.

What you can do

Historical wing · Eight ghosts born between 1971 and 1999: the Floppy Disk, VHS, the Walkman the Game Boy, Encarta, Internet Explorer, Clippy and MSN Messenger. Each one is shaped like its object. Talk to any of them: each ghost tells its story, answers its critics and argues why it should come back.
Ofrenda · For Día de los Muertos, leave a candle, a marigold, pan de muerto or the ghost's special gift on its altar. The ghost reacts, and the most loved ghost gets a badge in the hall.
Guestbook · Sign each exhibit's guestbook and the ghost…

View on GitHub

How I Built It

Open-source AI used:

Gemma 3 (4B), an open-weight model, running locally with Ollama. Every ghost, epitaph, offering reaction and debate turn is generated on my own machine.
Any other model in Ollama works too: the museum detects what you have installed and lets you switch the "medium" from the header.

The rest of the stack:

Fastify (Node) for the museum server: it builds each ghost's prompt and streams the answers.
Astro with plain CSS for the museum, and SVG for the ghosts.
pnpm workspaces to keep the server and the web in one repo.

One Markdown file per ghost. Each exhibit is a .md file. The frontmatter is the ghost's soul (personality, catchphrase, what its critics say, its color, shape and special offering) and the body is its historical archive: life, death, defense and why it should come back. The same file is used twice: Astro renders it as the exhibit plaque, and the server puts it in the model's system prompt as the only thing the ghost remembers. The ghost is told to say its memory is "foggy" instead of inventing dates. A 4B model can make things up easily, so I checked every archive myself. Adding a new ghost means adding one file.

Making a small model behave:

Language. The prompt is in English, so Gemma kept answering in English even when I wrote in Spanish. A rule at the end of a long prompt wasn't enough. What worked was detecting the visitor's language and adding a short reminder right before the ghost answers. Small models pay much more attention to the end of the conversation.
Debates. Each turn is a separate request. The ghost on stage sees its own lines as its messages and the opponent's lines as the other person, so they really answer each other instead of giving two monologues.
GitHub limits. My first graveyard downloaded the README and commits of every repo just to write the epitaphs, and I hit GitHub's hourly limit fast. Now the epitaphs only need the repo list (one request for the whole graveyard), and the README and commits are downloaded only when you summon a ghost. No token needed.

Why Does Open Innovation Matter?

Your memories stay home. The guestbook, the offerings and your repo history are saved in small JSON files on your own machine. Talking to your old projects never sends your code or your messages to someone else's server.

It works with the lights off. The museum runs fully offline. The graveyard needs the internet only the first time: after that, repos, epitaphs and memories are cached locally. A museum of technologies that disappeared because a company switched them off shouldn't depend on a service that can be switched off too.

I could compare and choose. I tried the same ghosts with Gemma 3 and Qwen 2.5. Gemma kept the characters much better, so it's the default. With a closed API I would have used whatever model I was given. Here I compared them myself, and anyone who prefers another model can switch it from the header.

It costs nothing to haunt. No API keys, no tokens, no bills. You can debate with ghosts all night.

And there's an irony I love: many of the ghosts in this museum died because someone else decided for them. Microsoft retired MSN Messenger and replaced it with Skype, and Encarta was shut down along with all its websites. Building their museum with open tools felt like the right way to honor them.

My Agent Session

I built the museum with an AI coding assistant, in one long conversation. It wrote much of the code, but the direction was mine: I turned a repo graveyard idea into a museum of dead tech, chose the ghosts my generation grew up with, asked for each one to have the shape of its object, and decided what stayed and what went.

My other job was testing everything on my laptop and reporting what broke: ghosts answering only in English, GitHub's rate limit, duplicated offerings, a repo ghost claiming it created itself... Each one became a fix. Learning to explain clearly what was wrong and decide when something was finished was the most interesting part for me.

The Spirit of It

As a kid, floppy disks were how I first got close to a computer. They were my way in, and everything that came after started there. So "talking" to the Floppy Disk ghost felt special: like saying thank you to the thing that opened the door for me.

But the moment that really landed was in the graveyard. I summoned the ghost of one of my own abandoned repos, asked it who created it, and it answered with my name and asked me why I left. It's a strange feeling to be questioned by your past self's code. I didn't have a good answer. 👻

Prize Categories

Best Use of Gemma: every ghost, epitaph, offering reaction and debate turn is generated by Gemma 3 (4B) running locally with Ollama. After comparing it with other open models, Gemma kept the characters best, so it's the default medium of the museum.

Sleepy Coder: a local assistant that finds the boring fixes in your code

Nazaret — Sat, 24 Oct 2026 17:26:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Slow and Steady.

What I Built

Sleepy Coder is a local coding assistant for the small, boring problems that pile up in side projects: the duplicate <h1>, the image without alt, the console.log you forgot, the TODO from three weeks ago.

You point it at a folder on your computer and it:

Finds tasks with rules (no AI, instant, reliable): SEO issues like a duplicate <h1> or a missing <title> and meta description, accessibility issues like images without alt or icon links without text, leftover console.log, TODO/FIXME comments, and a missing README, LICENSE or tests.
Asks Gemma for ideas about anything the rules can't see. These are clearly labelled AI idea · verify it.
Shows you How to fix each task: the exact file and line (with an Open in VS Code button), and Gemma's explanation with suggested code.
Checks your fix. You change the code yourself, press I fixed it — check again, and the same rule that found the problem runs again. If it's gone, the task moves to Done.

The lazy part: I don't have to remember what's wrong in each project or hunt for it. Sleepy Coder does the looking and the explaining; I only do the one-minute fix.

The real moment I knew it was useful: I ran it on my CSS backgrounds gallery (an Astro site) and it reported two <h1> on the home page. I had no idea. The second one was inside a modal that simulates a website to preview each background, and the rule found it by following the Astro imports from the page into the component. It also knew the real title was the one in the hero and told me to leave that one alone.

Demo

In the video: I open my CSS backgrounds gallery, press Find tasks, approve the duplicate <h1>, open How to fix (exact line + Gemma's guide), fix it in VS Code, and press check again: the task moves to Done.

Watch the demo on YouTube

Code

itsnazaretdev / sleepy-coder

💤 Sleepy Coder

Let your code sleep. We'll handle the boring stuff.

Sleepy Coder is a local coding assistant that looks through your repositories for small boring problems — a duplicate <h1>, an image without alt, a forgotten console.log, a TODO you never got back to — and shows you exactly where each one is and how to fix it.

It runs on your machine with a local model through Ollama No cloud, no paid APIs, and it never changes your files: you make the fix, Sleepy Coder checks it.

Built for the Hacktoberfest Slow and Steady challenge.

What it finds

With rules (fast, no AI, reliable):

SEO: duplicate <h1> on a page (it follows Astro layouts and components), missing <title>, missing <meta name="description">
Accessibility: images without alt, links without readable text, <html> without lang
Code: TODO / FIXME / HACK comments, leftover…

View on GitHub

How I Built It

Gemma 3 4B (open weights) running locally through Ollama. Everything AI goes through it: task ideas and fix guides.
Astro with React islands and plain CSS for the dashboard, and Fastify for a small API that only listens on 127.0.0.1.
SQLite (Node's built-in node:sqlite) to remember repositories, tasks and guides.
Vitest for the tests, in a pnpm monorepo.

The rules and the model each do the part they're good at:

Rules find where. They read the files and know exactly which line has the problem, so the location is always right.
Gemma explains how. It gets the numbered lines around the problem plus a hint from the rule (for example, "keep the <h1> in Hero.astro"), and returns an explanation, steps and suggested code as structured JSON. I validate everything it sends back.
For AI ideas, Gemma checks itself. Before writing a guide, it reads the real file and has to say whether the problem actually exists. Once it told me all my SEO descriptions were empty strings… they weren't. Now it can answer "this does not apply", and the app offers to discard the task.

What I tried first (and why it doesn't fix things for you)

My first plan was the "sleepy" dream: approve a task, and an agent makes the change on its own Git branch while you rest. I built it carefully: an isolated git worktree on a sleepy/… branch, a sandbox so it could only touch files inside that copy, protected files it couldn't edit, your own test script before and after, and a check that the problem was really gone before committing.

The safety side worked. It never broke anything. But the edits themselves, with a 4B model on a laptop, kept failing in new ways:

asked to add alt text, it reformatted a file instead;
asked to rewrite a file, it dropped half of it;
asked for small search-and-replace edits, it "quoted" code from memory that wasn't actually in the file.

Each time my checks rejected the change, so the result was safe but useless: "Failed", over and over. What Gemma did get right every time was understanding the problem and explaining the fix. So I changed the design to match that: rules find the line, Gemma explains, I edit, the rule checks. The agent is still in the code as an experimental option for bigger models, but it's off by default.

It was hard to let go of the "it fixes everything while you sleep" idea. I think the result is more honest, and more useful.

Why Does Open Innovation Matter?

My code never leaves my machine. Sleepy Coder reads whole repositories: unfinished projects, class assignments, things I haven't published. With a closed API I'd be uploading all of that to someone else's server just to be told I forgot an alt.
It costs nothing to run. No API key and no bill per request. You can scan as often as you want, which matters for a tool whose whole point is to be used casually.
It works offline once the model is downloaded.
The model is swappable. Sleepy Coder uses Gemma by default, but if you already have another model in Ollama it will use that, and one environment variable (SLEEPY_MODEL=…) picks a specific one. Nobody is locked into a provider.
I could see the limits and design around them. Because the model runs locally and I can test it as much as I like, I found out exactly where a small model is reliable and where it isn't, and built the app on the reliable part. That experiment is the main lesson of the project.

The Lazy Payoff

On my CSS backgrounds gallery it found a duplicate <h1> I didn't know about, told me which file to change and which one to keep, and confirmed the fix with one click.
Instead of opening every file to look for leftovers, one click on Find tasks lists them with the exact line, and Check again moves each to Done once it's fixed.
Sleepy Coder never changes my files, so I can run it on any project without worrying about it.

Prize Categories

Gemma: the whole project runs on Gemma 3 4B locally through Ollama.

Thanks for reading! I'm a second-year web development student, and this is my third local-AI project in this Hacktoberfest, after a walk journal and a menu translator. This one taught me the most about where a small model shines and where it doesn't. If you try it on your own projects and it flags something silly, tell me: every false positive becomes a new test.

MenuMind: From a restaurant's PDF menu to a bilingual QR menu with Gemma 3

Nazaret — Sun, 18 Oct 2026 17:59:37 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

MenuMind is a tool for small restaurants that turns their existing PDF menu into a digital, bilingual (Spanish/English) menu that customers open by scanning a QR code.

I'm a web development student in Spain, and where I live a lot of small bars and restaurants still run on printed menus. That works fine until a tourist sits down, or prices change, or a dish comes off the menu. Then someone has to redo the document, get it translated, and keep two or three versions in sync. Big chains have tools and agencies for that. The family-run place on the corner usually doesn't.

So the idea behind MenuMind is simple: the restaurant uploads the menu it already has, and gets back something its customers can read on their phone, in their language.

The flow looks like this:

Upload the menu as a PDF.
Extract: each page is analysed by Gemma 3 4B, which identifies dishes, categories and prices.
Review: the owner sees every extracted dish in an editable table and can fix names, categories or prices, or delete anything that shouldn't be there.
Translate: once the Spanish version is right, Gemma translates dish names and categories into English.
Publish: the menu is saved as the restaurant's own public page, with a Spanish/English toggle. The page also shows a QR code pointing to it, meant to be printed and placed on the tables, so customers can open the menu from their phones.

The owner's side of the app is in Spanish on purpose: the first users I have in mind are bars and restaurants around me, and the tool should speak their language. The English is for their customers.

The review step is deliberate. AI does the boring part, the typing, but the restaurant has the final word on what its customers read. A wrong price on a menu is a real problem, so I didn't want the model to be the last line of defence.

"Why not just put the PDF behind a QR code?" I asked myself this halfway through the build, and it's a fair question: plenty of bars already do exactly that. But a PDF behind a QR code is still the same document. It's still only in Spanish, so a tourist still can't read it, and on a phone it means pinching and zooming around a page designed for paper.

MenuMind isn't about showing the PDF. The PDF is just the way in. The AI's job is to save the owner from retyping sixty dishes by hand, which is the real reason small places never get around to a proper digital menu. Once the dishes are structured data (a name, a category and a price) instead of a document, the menu can be translated, read comfortably on a phone, and, as the product grows, updated or extended to more languages while the QR codes on the tables stay the same.

Who would pay for it? Small restaurants, cafés and bars, especially in areas that get tourists and need their menu in more than one language. The natural business model would be a small monthly subscription per venue, cheaper than paying for a translation every time the menu changes. Right now, though, my focus is building and validating the product, not selling it yet.

Demo

MenuMind currently runs entirely on my own machine (frontend, API, database and the model), so instead of a public link, here's a short video of the full flow: uploading a real menu PDF, reviewing the extracted dishes, translating them, opening the public menu and scanning its QR code from an Android phone on the same network. The interface you'll see is in Spanish, so turn on captions (CC) for an English walkthrough of each step.

Watch the demo on YouTube

I briefly deployed the frontend, but took it down: without the local API and model behind it, it couldn't show the real experience, and I'd rather show something that actually works.

Code

itsnazaretdev / menuMind

MenuMind

Turn a restaurant's PDF menu into a bilingual (Spanish/English) digital menu that customers open by scanning a QR code, using Gemma 3 4B running locally through Ollama.

MenuMind is built for small restaurants, cafés and bars that still rely on printed menus and need to offer them in more than one language.

The PDF is only the way in: Gemma reads it so the owner doesn't have to retype every dish. What customers get is not the PDF but a structured menu that can be translated and read comfortably on a phone.

The owner-facing interface is in Spanish, because it's designed first for restaurants in Spain. The public menu is bilingual for their customers.

Built for the Hacktoberfest Open-Source AI Challenge, Week 2: Side Hustle. The project currently runs locally; there is no public deployment.

How it works

Upload the menu as a PDF.
Extract: each…

View on GitHub

The project is a pnpm workspaces monorepo:

apps/api: Fastify backend. PDF processing, calls to Gemma through Ollama, translation, and the menu endpoints.
apps/web: Next.js frontend. The upload and review screen, plus the public menu page with the language toggle and QR code.
packages/database: Prisma schema and client, backed by SQLite (restaurants, menus and menu items with their English translations).

The README has the setup steps if you want to run it yourself: pull gemma3:4b with Ollama, install with pnpm, create the database and start both apps with pnpm dev.

How I Built It

The model: Gemma 3 4B (gemma3:4b), an open-weight model from Google, running locally through Ollama. I picked it because it's multimodal, so it can look at a menu page, and small enough to run on my laptop. The same model does both jobs in MenuMind: reading the menu and translating it.

Reading the menu. Restaurant menus are hard to parse: two columns, dish names that wrap across lines, prices floating on the right, section titles in decorative fonts, an allergen table at the end. Plain text extraction loses most of that structure. So for each page, the API sends Gemma two things together:

The page rendered as an image (with pdfjs-dist and @napi-rs/canvas), so the model can see the layout.
The page's text layer, extracted with pdfjs-dist and rebuilt into lines by grouping text fragments by their position on the page.

The prompt asks Gemma to use the image to understand where each dish starts and ends, and the text to get the words right. It also has to classify the page (menu, allergens or other), join dish names that span several lines, assign each dish to the last section title above it, and use null instead of guessing when a price isn't clear. Responses come back as JSON (Ollama's format: "json"), with temperature 0 and a fixed seed so results are as repeatable as possible, and the API validates the shape before using it.

Translating. After the owner confirms the Spanish version, the dishes go back to Gemma in small batches of three, with instructions to translate dish names and categories naturally, keep proper and place names, and never touch the prices. Small batches turned out to matter: with bigger ones, a 4B model would sometimes skip items or leave a name half in Spanish.

The rest of the stack:

Fastify for the API, with @fastify/multipart for uploads (PDF only, size-limited, and checked for a real PDF header).
Prisma + SQLite to store restaurants, menus and items. Each item keeps its Spanish name and category plus their English versions, and only confirmed menus are served publicly.
Next.js, React, TypeScript and Tailwind CSS for the interface.
qrcode.react to generate the QR code on the public menu page.

What it doesn't do yet. Being honest about the gaps, the two that matter most come straight from the question above:

Photos as input. Many small bars don't have a PDF at all, just a printed menu or a chalkboard. A photo taken with a phone is the more realistic way in, and since Gemma already reads each page as an image, it's the first thing I want to add.
Editing after publishing. Right now, changing a price means uploading the menu again. Editing dishes directly on the saved menu is what would make "update it without redoing documents" fully true.
A proper printable QR. Right now the QR code appears at the bottom of the public menu page; a "download / print QR" button would make it easier to put on the tables.

Beyond that, MenuMind works best with PDFs that have selectable text, translation is Spanish to English only, the owner interface is Spanish only (internationalizing it would open the tool to restaurants outside Spain), and everything runs locally, so a restaurant can't use it yet without someone running it for them.

Why Does Open Innovation Matter?

For a project like this, an open-weight model changed what was realistic for me to build.

Experimenting cost me nothing but time. Getting extraction right took a lot of iterations: rewriting prompts, re-running the same menu again and again, trying different batch sizes for translation. With a local model, that loop has no per-request bill and no rate limit, so I could iterate as much as the problem needed. For a student, that's the difference between trying an idea and not trying it.

A small model is enough for a focused job. MenuMind doesn't need a giant general-purpose model. It needs one that can read a menu page and translate dish names well. A 4B multimodal model running through Ollama does that on ordinary hardware, which makes the long-term cost of the product something I can reason about, instead of a variable tied to someone else's pricing page.

The restaurant's data stays where it's processed. Menus aren't secret, but they are a business's working documents. In MenuMind, the PDF, the extracted dishes and the translations are processed by the model running on the same machine as the app, not sent to a third-party AI API.

I can see and control the whole pipeline. Every piece, from pdf.js to Prisma to the model itself, is open. When extraction failed on a page, I could look at exactly what text and image Gemma received, change how lines were rebuilt, and try again. Nothing in the chain was a black box I had to work around.

To be fair, open isn't automatically free or better: running models still needs hardware, a bigger hosted model might extract some menus more accurately, and a 4B model needs careful prompting and validation. But open models made it possible for one student to build the whole thing, end to end, and own every part of it.

Prize Categories

Gemma: MenuMind uses Gemma 3 4B, run locally with Ollama, for both menu extraction (vision + text) and translation.

A diary that writes itself after your walk (Gemma running on my laptop)

Nazaret — Sun, 11 Oct 2026 20:00:26 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Field Diary is for people who love a walk but forget what they noticed by the time they get home.

Outdoors, you only jot down a few words for each thing you see, smell or hear. At home, an open-weight model running on my laptop turns those scraps into a diary entry that sounds like me.

The screen is the shortest part of the walk. Each note is one short line in my phone's notes app and takes a few seconds. The writing happens later, when I am sitting down anyway.

I made it for myself. I am a second-year web development student in Spain, and I wanted to keep a record of my walks without turning them into more screen time.

Outdoors I only use the Notes app on my Xiaomi. At home I paste the notes into the page, press one button, and the model on my laptop does the writing. For the tests in this post I ran the same thing from the terminal instead, reading the notes from a text file.

Demo

The video is a recording of the web app on my laptop. The five notes in it are the ones I wrote at the park, copied from my phone.

Watch the demo on YouTube

The notes can be in any language; the entries come out in English. I jot mine down in English.

Code

itsnazaretdev / hackaton-touchGrass

Field Diary

Jot down quick notes while you walk. When you get home, an open-weight model running on your own computer turns them into a diary entry in your voice. No accounts, no API keys, and after the model is downloaded, no internet: your walks never leave your machine.

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass. The screen is the shortest part of the walk: outdoors you only type a short line for each thing you see, smell or hear, and the writing happens later, at home.

How a walk works

Outdoors: jot your notes in your phone's notes app, one short line per thing you see, smell or hear. No signal needed. Write them in any language.
At home: paste the notes into the page and press Write entry. The model runs on your computer, so the writing always happens there.
The entry…

View on GitHub

How I Built It

Model: Gemma 3 (4B), Google's open-weight model, served locally by Ollama.
App: Python standard library only. A tiny web server plus one index.html with plain JavaScript. No frameworks, no packages.
Prompt: the model is told to use only what is in my notes and not to invent animals, places or events.
My voice: a file called style.md holds a few of my own texts. They go into the prompt as examples, so the model imitates my tone. There is no training and no fine-tuning: to change the style I edit a text file.
Output: each entry is saved as Markdown with frontmatter, ready for my Astro blog.
Model selector: the page lists the models installed in Ollama, so I can swap them with one click.

Two models, same notes

I ran the same five notes and the same prompt through two models. My five notes are in the "Taking it outside" section below.

qwen2.5:3b wrote one tidy paragraph that reads like a summary:

Today, I ventured to María Zambrano and was greeted by the vibrant scene of kids playing football. The sky was clear, with no clouds in sight, and the temperature was just right, making it perfect for a stroll. The days are indeed getting shorter, which is a melancholic thought as it means the fading light at dusk has me yearning for longer nights. People strolled with their furry companions, adding a playful touch to the serene park atmosphere.

gemma3:4b wrote two paragraphs with more rhythm and more feeling:

The Parque María Zambrano was buzzing today. A group of kids were really getting into a football game, the shouts and the thud of the ball against the ground a constant rhythm. The sky was just… blue. Completely blue, not a single cloud to be seen. It was warm, a really nice warmth, and I could feel the sun on my skin.

It feels like the days are shrinking. They're getting shorter and shorter, and I noticed it especially here, with the light already starting to slant. I saw people walking, mostly with dogs – a few Labradors and a golden retriever, pulling gently on their leashes. There was a gentle, steady flow of people, just enjoying the afternoon.

I preferred Gemma because it sounds more like me.

Both models added details that were not in my notes. Gemma named "a few Labradors and a golden retriever" and added "the sun on my skin" and "the light already starting to slant", when my notes only said people were walking dogs and the days were getting short. Qwen turned the shortening days into "a melancholic thought" that has it "yearning for longer nights", which is not what I wrote. My prompt says to use only the notes, so that rule reduces the invention but does not remove it, and I read every entry before keeping it.

I also learned that the model can only be as specific as I am. With short notes, the entry was generic. When I wrote down smells, sounds and how I felt, the entry got much better.

What didn't work

After the Python version worked, I tried to make it easier to try by moving it to Astro, with Gemma running inside the browser (WebLLM). It worked in Chrome on my Mac. A friend opened it on her iPhone, the model download reached 100%, and then nothing appeared. I did not have time to find out why, so I decided not to ship it.

So this submission is the Ollama version, which runs on a laptop.

Taking it outside

I went yesterday to the park on the south side of my city and wrote my notes in my phone's notes app, one short line for each thing I noticed. These are my five notes, exactly as I typed them:

there are a group of kids playing football
the sky doesn't have any clouds
the temperature is nice and warm
the days are getting short every day
people is walking with their dogs

Typing on the phone didn't bother me. It took a few seconds per line and I put it away straight after.

Still, writing on paper is always a pleasure, and something traditional adds authenticity that a screen doesn't. That is the one thing I'd change: a version where you could photograph a handwritten page and have the model read it would suit this idea even better.

Why Does Open Innovation Matter?

Privacy. A diary is about as personal as data gets: places, routines, how I felt. With an open model my notes and entries stay on my laptop. The only time it needs the internet is to download the model once.
No account, no cost. There is no API key and no bill, so anyone can run it.
Swapping models. Switching models is one click, and the comparison above shows why that matters: each model has its own voice, and I got to choose the one that sounds like me.
Control over the style. I shaped the tone by editing a plain text file, not by asking a company to change its model.

A closed API would have been easier to set up. But I could not have kept my diary off someone else's server, and I could not have chosen a voice.

My Agent Session

I built this project with the help of Claude, an AI assistant. It helped me write the Python code and the page, and I made the decisions about the idea, the style, which model to use and what to ship. I also tested it myself on a real walk and wrote the notes quoted in this post.

Prize Categories

Best Use of Gemma: Gemma 3 (4B) runs locally through Ollama and writes every entry.