DEV Community: Mauricio Andrade

Kuyō: a funeral for the code you deleted, written by a local Gemma

Mauricio Andrade — Wed, 28 Oct 2026 17:54:29 +0000

This is a submission for the DEV Hacktoberfest 2026 Challenge, week 4: Ghost in the Machine.

EmailService.java, who managed the dispatch of status notifications for eleven days, met a swift end. It was decommissioned by the decree: "chore: remover EmailService (código morto, email de status não será usado)". May the unnecessary transmissions it once managed now find eternal silence.

I deleted that class myself, in a commit whose message calls it dead code. I never thought about it again until a Gemma model running on my own machine wrote it an epitaph.

Walk through the cemetery → (hover or tap a grave)

What I Built

In Japan, kuyō (供養) is a memorial service for objects that served well. Needles, dolls, brushes and even eyeglasses are thanked and laid to rest instead of just being thrown away.

Kuyō does the same for source code. You point it at a git repository and it:

exhumes every file that was ever deleted, following renames so that a moved file isn't counted as dead;
examines each death: how long the file lived, the hour it died, how large the commit that killed it was, whether any test witnessed it, and what its last words were (the commit message);
scores its restlessness from 0 to 1 and decides the cause of death: violent, premature, forgotten or natural;
asks Gemma, running locally on Ollama, to write an epitaph from those facts;
renders a cemetery: one self-contained HTML file where restless souls haunt their graves.

It can also ask a code reviewer for an autopsy of each dead Java file, haunt your shell so that deleted files whisper back, and run as a GitHub Action that reburies your repository on every push.

kuyo scan path/to/repo     # the dead and their cause of death, no LLM
kuyo bury path/to/repo     # epitaphs + cemetery.html
kuyo seance path/to/repo EmailService.java   # talk to a dead file
kuyo bury path/to/repo --autopsy            # plus the Shishō's autopsy
kuyo haunt >> ~/.bashrc                      # deleted files whisper back

Demo

mauricioandrade.github.io

The cemetery above comes from stocklentes-hub, a private repository of mine: 137 deleted files in five months. The page shows only names, dates, commit messages and Gemma's epitaphs, and the code never left my machine.

It is a Japanese cemetery: every file gets a granite family grave with its name carved in gold, sotoba slats behind it and incense in front.
The facts are the scene. Pillar height follows the file's lifespan, and the hitodama (spirit flames) above each grave show how restless it is, from one calm blue flame to three trembling violet ones. Violent graves lean and a yūrei rises behind them, forgotten ones grow moss, and premature ones get a small Jizō with a red bib, as children's graves do in Japan.
Approach a grave and its epitaph is brushed onto a washi strip, stamped with the cause of death as a vermilion seal (横死 violent, 夭折 premature, 無縁 forgotten, 天寿 natural).
Turn the sound on for wind, crickets and an orin bell whose tone follows the cause of death, all synthesized in the browser.

Each terrace is a day or a month of deaths. When one commit took many souls at once, the terrace says so. In that private repo, 33 files fell together to a commit called fix: backend. Gemma noticed:

Frontend/src/assets/react.svg, who represented the spirit for eighteen short hours, vanished without fanfare. Its final word was the pragmatic "fix: backend", a most unpoetic exit.

Talking to the dead

kuyo seance summons one file's ghost. It answers in first person, remembering only its last contents and the facts of its life, so I went back to that EmailService:

> What did you do when you were alive? Be specific.
EmailService.java: My primary function was to send status change notifications via email.
I held a method, `enviarMudancaStatus`, which asynchronously dispatched messages detailing
updates to a specific order's status. I used a `JavaMailSender` to accomplish this task.

> Who was the president of Brazil when you died?
EmailService.java: The dead do not know such things.

The second answer is the one I'm proudest of. A ghost that makes things up would be a much worse ghost.

A haunted shell

kuyo haunt possesses your terminal. It prints a few lines of shell for your .bashrc or .zshrc, and from then on, deleting a tracked file has consequences:

$ rm src/main/java/dev/kuyo/haunt/Lines.java
$
  霊 Lines, a mere four hours of existence, still trembles in the shadow of that `rm` command. Don't delete me yet; I have so much to say.
     there is still time: git restore -SW -- ':/src/main/java/dev/kuyo/haunt/Lines.java'

That's Kuyō's own Lines.java, the file that holds what ghosts say when Gemma is away, begging for its life four hours after it was born.

The whisper arrives a few seconds after the prompt comes back, because Kuyō runs in the background while Gemma writes it. The file is examined as if it died right now, with your shell command as its last words. git reset --hard, git push --force and their friends get a line too, and every other command gets silence.

The Shishō's autopsy

Epitaphs are kind, but autopsies are not. Earlier this month I built Shishō (師匠, "master"), a reviewer that reads Java code the way a sensei reads a student's work. With --autopsy, every dead .java file goes on its table.

Kuyō rebuilds the file next to the pom.xml or build.gradle it lived with, as of the commit before it died, and carves the Shishō's lessons on the grave under a vermilion 師:

師 The Shishō's autopsy: medium · No centralized error handling (line 21)

That one is from SpikeResource.java, a spike endpoint in another project of mine that lived nine hours. When the Shishō finds nothing, the washi says the body died clean, and that was the verdict for EmailService. As with restlessness, no model is involved: the autopsy is deterministic.

Burying on every push

Kuyō is also a GitHub Action. Any repository can hold its funerals in CI:

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
- uses: mauricioandrade/kuyo@main
  with:
    output: _site/index.html

Gemma runs on the runner itself, so the code still never goes to a third-party API, and cached epitaphs mean each push only pays for its new deaths.

Kuyō buries itself on every push, and its own cemetery already has a mass grave. Midway through the challenge I translated the codebase from Portuguese to English, and 24 files fell together in one commit: Legista.java (the coroner), Exumador.java (the exhumer), Falecido.java (the deceased) and the rest of their family, all killed by "refactor: write the code in English". The tool now holds funerals for its own past.

Code

mauricioandrade / kuyo

供養 A funeral for the code that's gone. Reads your git history, diagnoses how each deleted file died, and has a local Gemma model write its epitaph in a haunted HTML cemetery. Runs offline.

English · Português

In Japan, kuyō (供養) is a memorial service for objects that served well: needles, dolls, brushes, even eyeglasses. They are thanked and laid to rest instead of just thrown away.

Kuyō does the same for source code. It reads a repository's git history, finds every file that was deleted, and holds a funeral for each one: how it lived, how it died, and how restless its soul is. A local open-weight model writes the epitaphs, and the result is a cemetery in a single HTML page, where restless souls haunt their graves.

🔒 Your code never leaves your machine. Everything runs offline, with a model you control.

Built for the DEV Hacktoberfest 2026 challenge, week 4: Ghost in the Machine.

Walk the cemetery yourself →

The demo cemetery comes from stocklentes-hub, a private repository of mine: 137 deleted files over five months. Its code stays…

View on GitHub

How I Built It

Java 25 + Quarkus (picocli) for the CLI, JGit to read history without shelling out to git, LangChain4j to talk to Ollama, and Qute for the template.

The facts are Java's, the words are Gemma's

I wanted a hard rule: the model never decides anything. Restlessness is computed deterministically from five factors:

Factor	Weight
Size of the death commit (log scale, maxes out at 50 files or 2,000 lines)	0.30
Hour of death, in the author's own timezone (midnight to 5 a.m.)	0.15
Last words: empty, or `remove`, `wip`, `hotfix`, `cleanup`, `oops`…	0.20
No test touched in the commit (code files only)	0.15
Short life (log scale in hours)	0.20

My first draft used linear scales with a seven-day cutoff for a "premature" death. When I ran it against 175 real deaths from nine of my repos, almost every file came out premature and tormented. In practice files die young and in mass graves: half of mine lived less than a day, and most died in commits touching 20 to 120 files. Log scales fixed the spread. The rename threshold also had to match git's 50%, because JGit defaults to 60% and was turning my refactors into deaths.

Gemma then receives only the result (file, lifespan, authors, cause, last words, hour, how many died alongside it) with one instruction: dry humor, and never invent a fact.

Three things that bit me

Gemma 4 thinks by default. My first request took 51 seconds and returned an empty epitaph: the model had spent its whole token budget reasoning. With think: false it takes about a second per epitaph.
The Quarkus Ollama extension fixes the model id at build time. That contradicted the whole "swap the model" promise, so the chat model is built at runtime through a Supplier instead. KUYO_MODEL=whatever works without a rebuild.
Chrome groups @font-face by weight before it applies unicode-range. My embedded kanji subset rendered as empty boxes until I declared it once per weight.

Everything stays in one file

The cemetery makes no network requests: every grave, lantern and flame is hand-drawn CSS and SVG, the typeface is embedded as small base64 subsets, and prefers-reduced-motion turns every animation off.

Why Does Open Innovation Matter?

Because the most interesting history is usually the one you can't share.

Proprietary code can't be pasted into a closed API, and that is exactly the code whose ghosts I wanted to meet. With an open-weight model on my own machine:

Nothing leaves the machine. The demo above comes from a private repo, and that was never a problem.
It costs nothing per run, so burying 137 files is a non-event.
It works offline.
The model is just a setting. Gemma today, whatever open model you prefer tomorrow.

Open tools made the rest possible: JGit, Quarkus, LangChain4j, Ollama, and an OFL typeface from the Shippori Mincho Project.

The Spirit of It

In Brazil, November 2nd is Finados, the day we visit our dead. It falls right after this challenge ends.

Every file in these cemeteries did a job once. Some lived eighteen hours to hold up a screen that changed the next morning, some were placeholders whose only purpose was to be replaced. The projects I work on today stand on all of them. Kuyō is a small way to say thank you before moving on.

Prize Categories

Best Use of Gemma: Gemma 4 (gemma4:e4b) runs locally on Ollama and writes every epitaph from facts computed in Java, so private code stays private.

Credits

Shippori Mincho B1 by the Shippori Mincho Project Authors, SIL Open Font License 1.1.
Built with Quarkus, JGit, LangChain4j and Ollama.
Reaction GIFs belong to their respective anime and shows.
Pair-programmed with Claude Code. Every epitaph and every ghost's answer is Gemma's.

Kikanai: I stopped listening to voice notes, and a local Gemma reads them for me

Mauricio Andrade — Tue, 20 Oct 2026 01:51:46 +0000

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

In Brazil, nobody types. WhatsApp voice notes are how families, friends and half of the people you do business with talk, and every family has a Tia Cida: the aunt who forwards you seven minutes of audio to say there is a barbecue on Sunday and you should bring ice.

You can listen to it at 2× and still lose three and a half minutes. Or you can do what everyone secretly does:

So I built the lazy option properly. Kikanai (聞かない) is Japanese for "I won't listen".

What I Built

You drop a voice note on a page running on your own computer, and you read something like this instead of playing it (this one is the example on the banner):

Tia Cida
Churrasco no domingo, 13h.
Leva gelo. Não precisa responder.

☐ Levar gelo · domingo 13h
−7m 01s · enrolação 84% · no need to reply

Two lines, at most. The things you have to do, with when and where. Whether you actually need to answer, which is the real question behind every voice note. And two numbers: the time you did not spend listening, and the enrolação (rambling) index, the share of the audio's words that didn't make it into the summary.

Who gets to be lazier: anyone who receives long voice notes, which in Brazil is everyone. You can drop the file on the page, or just save it into a folder: Kikanai picks it up, summarizes it into your history, and moves it to done/. You never open the audio.

And nothing leaves your machine. ffmpeg converts the audio, whisper.cpp transcribes it, and Gemma 4 on Ollama summarizes it, all locally. Your aunt's health updates, your friend's breakup, your landlord's excuses: none of it goes to anyone's server.

Demo

Kikanai runs on your computer, never on a public server, so there is no live link. This is a real run on an 18-second test recording, shown at 2× speed:

The left side is where audio goes: the drop target is drawn like a forwarded voice note, and the whole window accepts the file. The stages light up as the server reports them, with a clock that doesn't lie. The right side is paper: the summary slides out from under the blue line, and every summary stays in the stack below.

The first time you open it, the page shows an example slip (clearly labeled exemplo) so you know what is coming. If something is missing, like the Whisper model or Ollama, it says so above the drop target, with the command that fixes it.

Code

mauricioandrade / kikanai

Voice notes you never have to play. Drop a long WhatsApp voice note, read two lines: whisper.cpp transcribes, Gemma 4 on Ollama summarizes, Java counts the time you saved. Java 25 + Quarkus, 100% offline.

Kikanai (聞かない)

Voice notes you never have to play.

English · Português

Contents: What it is · Demo · How it works · Install · Use · Privacy · Honest numbers · What Gemma got wrong · Architecture · Reviewed by Shishō · Tests · Lazy payoff · License

What it is

Kikanai (聞かない) is Japanese for "I won't listen". Someone forwards you a 7-minute voice note; you drop it on a local page, and a minute later you read two lines, the things you have to do, and whether you need to reply at all.

Me, looking at a 7-minute voice note.

Everything runs on your machine: ffmpeg converts the audio, whisper.cpp transcribes it, and Gemma 4 on Ollama summarizes it. No audio, transcript or summary ever leaves the computer.

Built for the Hacktoberfest 2026 DEV Challenge, week 3: Slow and Steady, AI that rewards laziness.

Demo

…

View on GitHub

MIT licensed. The README has the full setup (whisper.cpp build, model checksum, Ollama on Windows with Kikanai in WSL2) in English and Portuguese.

How I Built It

Piece	Choice
Speech to text	whisper.cpp v1.9.5, `ggml-small`, Portuguese
Summary	Gemma 4 E4B (`gemma4:e4b`) on Ollama, temperature 0.2, thinking off
Audio	ffmpeg / ffprobe
Backend	Java 25 + Quarkus 3.40 LTS
Page	one HTML file, plain CSS and JS, self-hosted fonts
Storage	one JSON file per summary; no database

Two open models, each doing what it is good at

Gemma 4's small models can take audio directly, so my first idea was to skip Whisper. But they take about 30 seconds of it, and the voice notes worth summarizing are the long ones. So each model does its job: Whisper is a speech recognition specialist that handles long audio, and Gemma does the part that needs understanding, deciding what matters, what has to be done, and whether a question was asked.

Composing two specialized open models like this is the point of open weights. Nobody sells me this pipeline; I just plug the pieces together.

Gemma answers in a schema, not in prose

Asking a model to "answer in JSON" and hoping is how you end up parsing with regex. Ollama has structured outputs: you pass a JSON Schema in the format field, and generation is constrained to it. The schema is the contract:

{
  "type": "object",
  "properties": {
    "remetente": { "type": "string" },
    "resumo": { "type": "array", "items": { "type": "string" }, "minItems": 1, "maxItems": 2 },
    "acoes": { "type": "array", "items": { "type": "object",
      "properties": { "descricao": { "type": "string" }, "quando": { "type": "string" } },
      "required": ["descricao", "quando"] } },
    "precisaResponder": { "type": "boolean" }
  },
  "required": ["remetente", "resumo", "acoes", "precisaResponder"]
}

The keys are in Portuguese on purpose: the prompt is in Portuguese, and the model fills them more reliably that way.

The laziness numbers are arithmetic, not AI

If Gemma made up "84% rambling", the number would change on every run and mean nothing. So the model never sees the metrics. They are plain Java in the domain, reproducible and unit-tested:

// Words ÷ 200 wpm, rounded up to whole seconds, never below one second.
static Duration readingTimeOf(int words) {
    long seconds = Math.ceilDiv(words * 60L, READING_WORDS_PER_MINUTE);
    return Duration.ofSeconds(Math.max(1, seconds));
}

// 1 − summary/transcript: the share of words the listener didn't need. 0.84 means 84% filler.
static double ramblingIndexOf(int summaryWords, int transcriptWords) {
    if (transcriptWords == 0) {
        return 0;
    }
    double index = 1 - (double) summaryWords / transcriptWords;
    return Math.clamp(index, 0, 1);
}

The AI does what only it can do. The counting stays in code.

What Gemma got wrong, and how I fixed it

My test recording is me saying that it is a transcription test and that I can't remember the app's name. Gemma's first summary:

Este áudio é um teste de transcrição do aplicativo Ki-Kanae.
O remetente está verificando o nome do aplicativo.

"This audio is a test… The sender is checking the app's name." It described the voice note instead of summarizing it. A summary about the message is a summary of nothing, and in a two-line budget it is half the output.

Fix one, the prompt. Saying "don't describe the audio" helped a bit. What worked better was stating what I wanted instead of what I didn't: write the note the speaker would have sent instead of the audio. That is exactly the voice of "Leva gelo." I also added one worked example, deliberately unlike my test transcript, so a test could never pass just because the model copied it.

Fix two, a guard. At temperature 0.2 it still slipped once in a while. Retrying the same question at low temperature tends to get the same answer, so the parser rejects lines about "o áudio", "a mensagem", "o remetente" or "a pessoa", and the retry sends Gemma its own answer plus what was wrong with it:

} catch (InvalidSummaryException e) {
    // At low temperature the same question gets the same answer; the retry says what was wrong.
    if (content != null) {
        messages.add(new ChatRequest.Message("assistant", content));
    }
    messages.add(new ChatRequest.Message("user", e.correction()));
}

In the real run that followed, Gemma wrote "O remetente…" on the first attempt, got rejected, and came back with "Teste de transcrição do aplicativo Ki-Kanae." Clean.

The parser, every time Gemma writes "O remetente está…".

Being lazy takes some engineering

The page shows real progress. The pipeline takes seconds to minutes, and a spinner on a long wait feels broken. The same POST /api/voice-notes streams NDJSON when the page asks for it: one line as each stage starts, then the result. curl still gets plain JSON.
The folder waits for downloads. Browsers download into .crdownload and rename to .ogg when done, so files that aren't audio are ignored, and a file only counts once its size stops changing. You can save a voice note from WhatsApp Web straight into ~/kikanai/inbox.
An assembly line. Each voice note runs on its own virtual thread, and each stage has a lane one note wide: whisper (CPU) transcribes the next note while Gemma (GPU) summarizes the previous one, and no two notes fight over the same stage.
Everything checks itself. GET /api/health/deps reports ffmpeg, whisper-cli, the model, Ollama and the Gemma model, with the fix for whatever is missing. The page shows that list on first run.

Java 25 doing real work

The pipeline returns a sealed result, and the web layer deconstructs it in a switch the compiler checks for completeness:

return switch (summarizeVoiceNote.summarize(voiceNote(file, sender))) {
    case Done(var summary, var report) -> Response.ok(SummaryResponse.from(summary, report)).build();
    case Failed(var stage, var reason) -> ProblemResponse.of(ProblemResponse.UNPROCESSABLE_CONTENT,
            CANNOT_SUMMARIZE, reason, stage);
};

A ScopedValue carries the processing id into every log line of every stage, adapters included, without threading it through method signatures, and it can't leak into the next file the way a ThreadLocal on a reused thread can:

[94f6fd01] Converting WhatsApp Ptt 2026-10-19 at 19.21.37.ogg
[94f6fd01] Transcribing 18s of audio
[94f6fd01] Summarizing 37 words
[94f6fd01] Done in 13s, saved 12s of listening

The upload endpoint sits on a virtual thread (@RunOnVirtualThread) for the whole pipeline, which costs no platform thread while it waits for whisper and Gemma.

Reviewed by my other project

Shishō (師匠, "master") is my opinionated Java linter: it explains why something is wrong and whether the architecture fits the problem. It reviewed Kikanai after every phase.

Clean Architecture for a weekend tool sounds like overengineering, and without context Shishō would say exactly that. So the repo declares its context in shisho.yaml: one person, short life, and infrastructure that will change (whisper.cpp could become another ASR, Ollama another runtime, the JSON files a database). Its verdict: Clean Architecture is adequate; the declared context pays its cost.

It also caught a real gap: errors were handled endpoint by endpoint, so they now all go through one set of @ServerExceptionMapper methods as RFC 9457 problem+json. And it got one wrong: it raised that lesson on the Ollama REST client interface, before any server endpoint existed. A false positive I now get to fix in Shishō itself. Final grade: 1st dan.

Why Does Open Innovation Matter?

Because these are the most private recordings people have. Voice notes are family health news, money, fights, gossip, people's voices. Sending them to a cloud API to save three minutes is a bad trade, and most people wouldn't make it if they thought about it. With open weights, the audio, the transcript and the summary never leave the computer, and the page doesn't even load a font from outside.

Because I could compose the right models. A closed audio API would have sold me one model to do everything, priced per minute of audio, which is exactly the wrong unit for a tool whose whole point is long audio. Open models let me pick a speech specialist and a reasoning model and wire them together.

Because I could see why it failed, and fix it. Running Gemma myself, I could read every raw answer, constrain its output with a schema at the grammar level, and send it my own correction on retry. The "O remetente está…" fix came from reading what the model actually wrote, not from guessing at a black box.

Because it costs nothing per voice note. The busiest family group in the world costs the same electricity as a quiet one.

The Lazy Payoff

The first version lost to just listening. I ran four personal voice notes from one afternoon through it (they stay private, so only totals here), and processing took 97 s for 1m 49s of audio. For short notes, that is a bad deal, and the honest clock on the page showed it.

So I asked where the time went, and the answer was not in Java. It was whisper on the CPU and Gemma on the GPU; Java took milliseconds. Virtual threads make waiting free, not computing faster, so the fix had to be in how the tools were used:

Change	Effect
whisper with 8 threads instead of 4 (12 was slower again)	8.2 s → 5.2 s on my 18-second test
`keep_alive` on every request, so Ollama stops unloading Gemma after 5 idle minutes	no more 20 to 90 s reload on the next note
warming Gemma up at startup, with the same context length as real requests	the first note no longer pays for loading it
one lane per stage instead of one note at a time	a batch overlaps whisper (CPU) with Gemma (GPU)

The third row hides my favorite bug of the week: the first warm-up loaded Gemma with Ollama's default context, so the first real request, asking for 8192, made Ollama reload the entire model anyway. The fix was one argument.

After tuning, on my machine (WSL2 with 12 threads and 7 GB of RAM, Ollama on the Windows side with an RTX 2060), my 18-second test takes 7.0 s: 0.2 s of ffmpeg, 5.3 s of whisper and 1.5 s of Gemma. And the same four voice notes:


Voice notes	4, from 18 s to 41 s
Audio I never played	1m 49s
Read instead	25 s
Time not listened	1m 24s
Average rambling	68% (from 30% to 86%)
Processing	46 s in total (97 s before tuning), each note ready before it would have finished playing

Dropped all at once they take 43 s: whisper is the bottleneck now, so the assembly line only hides Gemma's part. And on average, 68% of the words in those voice notes never made it into the summary. The longer the note, the better the deal: transcription grows with the audio, the reading doesn't.

Me, reading two lines instead.

Prize Categories

Best Use of Gemma. Gemma 4 E4B runs locally through Ollama and does the part that needs understanding: from a raw Portuguese transcript, it decides what matters, writes it as the two-line note the speaker would have sent, extracts the actions with when and where, and decides whether a reply is needed. Its output is constrained by a JSON Schema through Ollama's structured outputs, validated, and corrected with its own previous answer when it slips, while every number on the page stays deterministic Java.

Kikanai is week 3 of my Hacktoberfest run, after Janela and Kakeizu.

Kakeizu: a local Gemma reads the gas station's receipts, and check digits catch its mistakes

Mauricio Andrade — Wed, 14 Oct 2026 04:29:22 +0000

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

A friend of mine works at a gas station in the interior of São Paulo. The station has a system, but closing the day still means checking a pile of paper against it by hand: card machine slips, fiscal coupons, Pix receipts, the odd cheque. Amount, date, payment method, one receipt at a time.

Still checking, one receipt at a time.

So I built Kakeizu: you photograph the receipt on your phone, a Gemma model running on the shop's own computer reads it, the domain checks every digit it can, and a person confirms. Nothing is confirmed automatically, and nothing leaves the shop.

The AI suggests, the domain validates, the human decides.

What I Built

Kakeizu reads a photo of a Brazilian payment receipt with Gemma running on the shop's own computer, checks every digit it can, and waits for a person to confirm. The name is Kakeibo (家計簿, the Japanese household ledger) plus Kakuzu, the Akatsuki member who only thinks about money.

It reads the receipts a Brazilian gas station or corner shop sees every day:

Receipt	What the domain checks
NFC-e / NF-e (fiscal coupon or invoice)	44-digit access key with a mod-11 check digit; its month and CNPJ must match the other fields
Card machine slip (Stone, Cielo, Getnet)	the store's CNPJ check digits, the authorization code
Pix receipt	the 32-character end-to-end ID
Cheque	the three mod-10 check digits of the magnetic line (CMC-7); a date over 6 months old gets a warning
Any of them	amount, date never in the future, the same photo or the same key never twice

Confirmed receipts feed a daily summary and a sales report by hour, weekday, payment method, installments and card brand. An NFC-e and the card slip of the same sale are paired, so the sale counts once.

Who pays for it: the owner of a small shop who closes the cash register by hand. Cloud receipt readers exist, but they charge per document and want the shop's sales, suppliers and customers on someone else's server.

The cloud vendor, sending this month's per-document invoice.

Kakeizu costs nothing per document and nothing leaves the shop. The owner pays for the setup and the hour it saves at the end of every day, not for each photo.

Demo

Kakeizu runs on the shop's computer and never on a public server, so there is no live link: the demo is the flow below, recorded with the anonymized sample receipts from the repository.

Today, on the phone. The photo goes up and the list comes back at once. The model reads in the background (dashed violet line), and the line prints itself in when it is done. Orange means "needs you", double green means confirmed.

Review. The photo sits next to everything the model read, and every field that failed a check says why. This template NFC-e has no CNPJ and a zeroed access key, so it cannot be confirmed as read.

Look at the amount, too. The photo says 146,46; the model read 4,00. That number is well formed and no check digit covers it, so only the person comparing it with the photo catches it.

Sales report. Confirmed sales by hour, weekday, payment method, installments and card brand, with a slip paired to its NFC-e so each sale counts once.

Code

mauricioandrade / kakeizu

Local-first receipt reader for small shops: Gemma (via Ollama) reads NFC-e, card slips, Pix and cheques; check digits validate; a person confirms. Java 25 + Quarkus. Nothing leaves the machine.

🧾 Kakeizu

A receipt reader for small shops that runs 100% locally.
A photo goes in, structured data comes out, and nothing leaves the owner's machine.

Kakeibo (家計簿, the Japanese household ledger) + Kakuzu (the Akatsuki member who only thinks about money)

🤖 The AI suggests · 🧮 the domain validates · 🧑 the human decides

📑 Contents

😩 The problem

The owner or manager of a gas station, a corner shop or a small restaurant gets dozens of receipts a day: NFC-e, card machine slips, Pix receipts, the odd cheque. Closing the day means typing amount, date and who paid or got paid into a spreadsheet, one receipt at a time.

Cloud tools do this, but they want the business's financial data on…

View on GitHub

Apache 2.0. The README has the setup for both Ollama layouts on Windows + WSL2, the accuracy tables and the backup script.

How I Built It

The whole design is one sentence: the AI suggests, the domain validates, the human decides.

Layer	Choice
Model	Gemma 4 (`gemma4:e4b`), vision, thinking on, temperature 0
Inference	Ollama on the Windows side, reached from WSL2
Glue	Quarkus 3.40 with `quarkus-langchain4j-ollama`
Language	Java 25
Storage	PostgreSQL + Flyway
Web	Qute templates + htmx, no frontend build

Gemma reads, and nothing it returns is trusted

Gemma gets the photo and a field guide in the system prompt, and returns plain strings: type, amount, date, counterparty, tax ID, unique ID, time, payment method, installments, card brand. Those strings never touch the database as values. They go through the same domain objects a person's correction goes through, and each object checks what it can.

The check digits are the trick. They exist to catch a cashier's typo, and they catch a model's misread just as well. A CNPJ, for instance, carries two mod-11 digits:

public record Cnpj(String value) {
    public Cnpj {
        value = value.replaceAll("[.\\-/\\s]", "").toUpperCase();
        if (!value.matches("[A-Z0-9]{12}\\d{2}")) {
            throw new InvalidValueException("CNPJ must have 14 characters");
        }
        if (checkDigit(value, FIRST_WEIGHTS) != valueAt(value, 12)
                || checkDigit(value, SECOND_WEIGHTS) != valueAt(value, 13)) {
            throw new InvalidValueException("CNPJ check digits do not match: " + value);
        }
    }

    // Each character is worth ASCII - 48, so the new alphanumeric CNPJ
    // (issued since July 2026) and the old all-digit one share one rule
    private static int valueAt(String cnpj, int index) {
        return cnpj.charAt(index) - '0';
    }
}

On a real Cielo slip, Gemma read the CNPJ as 13.438.977/0001-00 three times out of three. The real one is 13.458.397/0001-01. The check digits rejected it every time, and the review screen put the photo next to the red field. It also read the authorization code 375579 as 375759. No check digit covers that code, so nothing caught it. That is exactly why a person confirms every receipt.

How often it is right

Seven receipts, three readings each, run through the app's own validation:

Of 210 fields	Count
Right on the first reading	200 (95%)
Wrong, and the domain flags that field	3
Wrong, in a receipt the domain blocks for another field	4
Wrong, and nothing flags it	3

Then a real gas station's day: a Getnet debit slip (3 of 3 ready to confirm as read), an NFC-e paid in cash (2 of 3, the 44-digit access key right every time), a Pix paid on the card machine, and a handwritten cheque. The small sample is the honest caveat: treat these as a sanity check, not a benchmark.

What I learned the hard way

Every field must be required in the schema. Ollama uses the JSON schema LangChain4j sends as a grammar, and by default no field is required. Gemma's reasoning said "installments = 5" and the answer simply left the key out. Marking every field @JsonProperty(required = true) took the share of right fields from 88% to 95%.

The model cannot say null. With every field required and typed as a string, it writes the word "null", or just ", ", when a field is not on the receipt. The adapter turns those into a missing field.

Thinking matters more than speed. With thinking off, a reading takes about 2 seconds instead of 15. It also took an item price as the NFC-e total and the card brand as the store name: wrong values in a valid format, which no check digit can catch. Thinking stayed on.

Temperature 0 is not deterministic. The same photo gave different answers between runs, so every receipt in the accuracy tables was read three times. The NFC-e template's total, 146,46, came back right, then as 46,46, then as 4,00, in different runs.

Tell the model where things are printed. It returned the NFC-e note number as the access key until the prompt said the key is all 44 digits, in groups of four, under "Consulte pela Chave de Acesso". A Pix paid on the card machine kept coming back as a card slip until the prompt described it: an "ID/TRANSAÇÃO" and no card brand, no card number, no authorization code.

Some mistakes need the calendar, not a check digit. On a handwritten cheque, Gemma read the year "26" as 2022, three times out of three. A cheque that old can no longer be cashed in Brazil, so a cheque dated more than six months ago now gets a warning on review.

Nobody waits for the model

A warm reading takes about 15 seconds on a consumer GPU. I measured where it goes: the image takes under a second, and the rest is Gemma writing about 750 tokens of reasoning at 75 tokens a second. Turning the reasoning off cost accuracy, and asking for shorter reasoning changed nothing, so the app stopped waiting for it instead. The upload saves the photo and returns at once, a background worker reads it, and the line on today's list updates itself. If Ollama is down, the receipt still goes to review, empty, to be typed from the photo.

Java 25 doing real work

The receipt is a sealed interface with one record per type, so the mapper and the reports are exhaustive switches with record patterns and no default. Up to five photos can go in one upload: each is saved and queued on its own virtual thread inside a StructuredTaskScope (a preview in Java 25), so one bad photo never stops the others. A correlation id rides a ScopedValue into every log line of an upload, across the forked threads and into the background reader.

Why Does Open Innovation Matter?

Because with a closed API, this product could not be sold to the person it is for.

The data cannot leave the shop. A day of receipts is the business itself: what it sold, to whom, through which bank, from which supplier, and sometimes a customer's name and partial CPF. An open-weight Gemma on the shop's own GPU means the photos, the database and the model all stay on one computer. There is no privacy policy to read because there is no third party.

The cost does not grow with the work. A gas station photographs dozens of receipts a day. A per-call API turns every one of them into a line on a bill, so the busiest day costs the most. Local inference costs the electricity of about 15 seconds of GPU per receipt.

The model is a setting. KAKEIZU_MODEL swaps Gemma for any Ollama vision model, and the same check digits judge the new one. When a better small open model ships, the shop gets it for free.

Open models let me see why they fail. Because I ran Gemma myself, I could turn thinking on and off, read its reasoning, and see it decide "installments = 5" and then drop the key. That is how the required-schema fix was found. A closed endpoint would have shown me only a wrong answer.

My First User

My first user is that friend at the gas station. Midway through the week they sent me photos of a real day's receipts: a Getnet debit slip, a Pix paid on the card machine, an NFC-e paid in cash, and a handwritten cheque. The station stays anonymous here, and none of those receipts are in the repository.

That one batch changed the product more than any test I wrote:

A Pix paid on the card machine has no end-to-end ID. The slip prints the machine's own transaction ID, so the Pix ID became optional and the prompt learned to tell this slip from a card slip.
Gas stations take cheques. Kakeizu now reads them, checks the magnetic line's three check digits when it is typed, and treats the cheque the other way round: the CNPJ on it is the payer's, so a cheque from another company is a sale. Shops that do not take cheques switch this off.
The NFC-e access key is printed far from its label. The prompt now says exactly where to find all 44 digits.

After testing it, they want to use it every day.

Prize Categories

Best Use of Gemma. Gemma 4 (gemma4:e4b) runs locally through Ollama and does all the reading: receipt type, amount, date, counterparty, tax ID, access keys and payment details, from phone photos of thermal slips, fiscal coupons and handwritten cheques. Kakeizu is built around both its strengths and its mistakes: thinking stays on because it buys accuracy, and every field it returns goes through deterministic checks before a person confirms it.

Janela — a local Gemma tells you when to go outside (and why)

Mauricio Andrade — Wed, 07 Oct 2026 22:28:05 +0000

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

What I Built

In most of Brazil, "I'll go for a run later" isn't about frost or snow. It's about dodging a UV index of 11 at noon, a feels-like of 38 °C at 2 PM, and the thunderstorm that shows up at 5 PM almost every summer afternoon. The weather app has all of that data. It just doesn't tell you when to go.

Hina from Weathering With You could pray for a sunny window. The rest of us have to read the forecast.

Janela (Portuguese for window) does that for you. You give it a city, an activity (run, walk, bike, picnic, gardening, or an outdoor workout at the square's gym), how long you want to be out, and how many days ahead to look. It answers with:

the best time window, plus two alternatives, each scored 0–100 with its feels-like temperature, UV, rain chance and wind;
each day's comfort drawn as a tide, so you see at a glance when the day opens up and when it closes;
a short explanation written by Gemma running on my own laptop, saying why that window wins, plus a tiny "touch grass" challenge for when you're out there.

It works in Portuguese and English (°F and mph in English), and searches are shareable links.

Every activity, in anime terms

🏃 Run	🚶 Walk	🚴 Bike

10–22 °C feels-like. Form not included.	Janela finds the window. Finding the park is on you.	Pick the cool hour, then draft behind your friends.

🧺 Picnic	🌱 Gardening	💪 Square gym

18–28 °C feels-like. Bring enough for Goku.	Domain Expansion: Vegetable Garden.	The springtime of youth starts at 06:00.

Lain lived in the Wired. Janela is for the rest of us, who occasionally need to log off.

Demo

How I Built It

city + activity ──▶ Spring Boot API ──▶ Open-Meteo (geocoding + hourly forecast)
                         │
                         ▼
                  WindowScorer (plain Java, unit-tested)
                         │  top 3 windows, already ranked
                         ▼
               Ollama up? ── yes ──▶ Gemma writes the explanation
                         └── no ───▶ template writes it instead

Java computes, Gemma explains

This was the one rule I set before writing any code: the model never picks a time and never does math. Java is Senku here: it does the science. Gemma just presents the results.

Small models (I'm using gemma3:4b) are great at turning data into friendly sentences and bad at arithmetic. If I asked Gemma "when should I run in Recife tomorrow?" with a raw forecast, it would answer confidently, and sometimes wrongly.

A 4B model doing arithmetic: full confidence, questionable results.

So all the deciding happens in a deterministic domain:

every daylight hour starts at 100 and loses points for rain chance, feels-like temperature outside the activity's range, and UV or wind above its limits (a run wants 10–22 °C feels-like, a picnic 18–28 °C);
a window is the best run of consecutive hours covering your duration, and any hour below 40 rules the whole window out;
the best window of each day is picked before repeating a day, and once the sun has set, "3 days" starts tomorrow instead of wasting today.

All of that is covered by JUnit tests (118 on the backend), with an injected Clock so "drop the hours that already passed" is testable too.

Pre-digesting the payload for a 4B model

The interesting part was learning what a small model needs to not make things up. My first prompts sent ISO timestamps and raw numbers, and Gemma would echo 2026-10-07T17:00, call UV 0.6 "high", and praise window #2.

gemma3:4b looking at UV 0.6, before I pre-digested the payload.

What fixed it was doing the interpreting in Java and letting the model only reword:

{
  "best": {
    "rating": "great",
    "day": "Thursday, Oct 8",
    "start": "06:00",
    "end": "07:00",
    "temperature": 83,
    "comfort": "hot",
    "uvIndex": 0,
    "uvLevel": "low",
    "rainChancePercent": 6,
    "rainLevel": "low",
    "wind": 5,
    "reasons": ["before the day's heat peaks at 13:00"]
  },
  "alternative": { "rating": "fair", "day": "Friday, Oct 9", "start": "17:00", "end": "18:00", "…": "…" }
}

day names and times are already formatted in the reader's language;
numbers are rounded and converted (°F/mph in English) the way the UI shows them;
the window's quality, temperature, UV and rain come with words (rating is the same word the screen shows next to the score, plus comfort, the WHO UV category and rainLevel), so Gemma never decides what "hot", "low chance" or "ideal" means;
reasons are the window's advantages already worked out in Java from the day's outlook; the prompt tells Gemma to reword those and draw no conclusions of its own;
the score is left out on purpose, because the model kept quoting it;
there are no ranks: the best window and one alternative go by name, because with a ranked list of three, Gemma mixed up the order, praised the wrong one and wrote "Rank 2" into the text.

The prompt then forbids the specific failures I saw in testing: inventing a beach or a park, saying "today" about a window two days out, writing JSON field names into the text, or describing a 33 °C afternoon as "pleasant".

A prompt is a request, not a guarantee, so Java also reads the reply before showing it. Any time it wasn't given, a 12-hour clock, a field name, an invented beach, "pleasant" for a hot hour, "ideal" for a fair window or a missing 🌿 line gets the reply rejected, and Gemma gets one more try with the mistake named. It usually fixes it, and on my laptop the retry costs 2–4 seconds.

If the second try still breaks a rule, or Ollama is off or slow (30 s timeout), a template writes the text and the UI labels it as such instead of pretending.

Stack

Backend: Java 21, Spring Boot 4, Spring AI 2.0 with the Ollama starter, Clean Architecture (the use case is framework-free), API versioning with Spring Framework 7, Caffeine caches, OpenAPI docs
Model: gemma3:4b via Ollama, swappable with one env var
Weather: Open-Meteo forecast and geocoding (open data, no key)
Frontend: React 19, TypeScript, Vite, TanStack Query, Tailwind 4, shadcn/ui on Base UI, a hand-drawn SVG tide chart

Why open innovation matters here

It runs on a laptop. No API key, no account, no cost per question. Anyone can clone it and have it working in three commands.
Your routine stays with you. Where you live and when you go out are exactly the kind of data I don't want to send to an AI cloud. With Gemma local, they don't leave the machine. To be honest about it: the forecast comes from Open-Meteo's open API, so that request does go out (just coordinates, no profile).
Swap the model with one variable. OLLAMA_MODEL=gemma3:12b and you're done. Open weights mean the app isn't tied to one vendor's pricing or deprecation schedule.
It works without AI. Because the AI only explains and never decides, turning it off loses the nice sentences, not the answer.

Prize Categories

Best Use of Gemma. Gemma 3 (4B) runs locally through Ollama and writes every recommendation, in Portuguese or English. The project is built around what a small open model is good at (language) and keeps it away from what it isn't (math and decisions).

Code

mauricioandrade / janela

🌿 Find your window to touch grass. Picks the best outdoor time for running, walking or cycling based on heat, UV and rain — explained by a local open-weight model (Gemma via Ollama). Java 21 + Spring AI. Built for Hacktoberfest 2026.

🌿 Janela

Find your window to touch grass.

Janela (Portuguese for window) finds the best time windows in the next few days for an outdoor activity — running, walking, cycling, a picnic, some gardening, a workout at the square's outdoor gym — based on what actually matters in a tropical climate heat, UV index, afternoon storms and wind.

Then a local open-weight model (Gemma, via Ollama) turns those numbers into a short, human recommendation and a tiny "touch grass" challenge. No API keys, no per-query costs, and it still works if the model is offline.

Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1 — "Touch Grass".

Why

In much of Brazil, "go for a run" isn't about frost. It's about dodging a UV index of 11 at noon and the thunderstorm that shows up at 5 PM. Weather apps give you the data; Janela tells you…

View on GitHub

Credits

Weather data by Open-Meteo (CC BY 4.0) · Gemma by Google · Spring AI and Ollama · Archivo typeface by Omnibus-Type · country flags from country-flag-icons, Brazilian state flags from Wikimedia Commons. Anime GIFs belong to their respective creators and studios.