DEV Community: Elon masai

git-ofrenda: An Ofrenda for Deleted Code

Elon masai — Thu, 29 Oct 2026 16:41:16 +0000

*# git-ofrenda: An Ofrenda for Deleted Code

GitHub Repository: https://github.com/elonmasai7/git-ofrenda

Run this in any repository that is a few years old:

git log --diff-filter=D --name-only

Every path it prints is a file someone wrote, fixed late at night, and eventually deleted. Git did not forget any of them. It still has who wrote each one, how many times it was touched, and the one-line commit message that ended it.

That felt like the right ghost for this week's theme, so I built something to give them a proper send-off.

What I Built

git-ofrenda is a command-line tool that finds the files a repository has lost and builds an ofrenda for them.

For each deleted file, it works out when it was created, when it was deleted, who worked on it, who removed it and why, and what its last contents were. Then, a model running on your own machine writes the file some last words and a calavera literaria.

There are five commands:

build generates the ofrenda as a self-contained HTML page, Markdown document, or JSON file.
seance serves the page locally and lets you chat with individual files using their final contents and Git history.
scan lists deleted files without requiring a model.
exhume restores the last contents of deleted files, byte for byte, into a directory.
doctor checks whether Git and the model server are configured correctly.

How I Read the Theme

An ofrenda is specific. It is the photograph, the favourite food, the marigolds, and a candle for each person. Those details make it an act of remembrance rather than a generic memorial.

A calavera literaria is an affectionate, teasing epitaph in verse associated with the Day of the Dead tradition. I borrowed the shape of these traditions for a programmer's joke, trying to keep the tone fond rather than mocking.

I wanted the verses to know things.

Not just, "Here lies a file. Rest in peace," but a verse about a file that spoke FTP to a partner's server for four years, only to be ended by a commit titled:

remove ftp, partner moved to S3

That is why the model receives the file's actual final contents and its Git history. The tool also extracts concrete details, such as function names, imports, and header comments, for its no-model fallback.

Why Open Models Matter Here

Deleted code is precisely the kind of code you may not want to upload anywhere. It can contain old credentials, internal hostnames, deprecated integrations, and embarrassing workarounds.

Building an ofrenda with a hosted model could mean sending a repository's history to a third party. With an open-weight model, the entire pipeline can stay between Git and a server running on localhost, even without an internet connection.

The design also supports multiple backends, verse caching, and operation without a model. The goal is to keep the project private, flexible, and independent of a single provider.

The Moment It Landed

Things That Went Wrong

The Fallback Was Making Things Up

The first template-generated verses sometimes treated filenames or meaningless comments as important parts of a file's history. Reviewing the output exposed the problem. The templates now mention functions only when they exist and quote header comments only when they contain enough meaningful information. I also added a regression test.

A Git Flag Failed Only on Large Repositories

The pre-ranking step used when many deleted files exist passed --format=@@, which Git interpreted as a named format and rejected.

The issue appeared only when the repository contained more than 60 deleted files. A test that deletes 70 files exposed the bug.

Renames Can Misrepresent a File's History

A file renamed in 2020 and deleted in 2024 can appear to have been created in 2020, even if its history began much earlier.

Using git log --follow helps recover its actual age. The command --diff-filter=D -M also helps distinguish deleted files from files that were simply renamed.

How It Works

The project separates repository analysis, verse generation, and presentation into distinct components.

gitscan: Finds deleted files, examines their history, and recovers their final contents from Git.
poet: Generates verses by checking the cache, querying the configured model, retrying once if generation fails, and falling back to templates when necessary.
render and server: Present the ofrenda as a document or serve it through the local séance interface.

Every verse identifies its source, whether template or the model's name. The page header also reports how many verses were model-generated.

The séance server listens on 127.0.0.1, rejects foreign Host headers, and requires a custom header for POST requests. Repository contents and model-generated output are HTML-escaped before being inserted into the page.

Tests

The project includes 45 tests covering repository analysis, file history, model integration, and HTTP behaviour.

The tests build real Git repositories to exercise deletions, renames, binary files, large numbers of deleted files, model server failures, malformed responses, and HTTP streaming.

Mock Ollama and OpenAI-compatible servers verify that the client follows the expected protocols. These tests provide confidence in the tool's behaviour, but they do not measure poetry quality.

Try It

Repository: github.com/elonmasai7/git-ofrenda

Clone and install the project:

git clone https://github.com/elonmasai7/git-ofrenda.git
cd git-ofrenda
pip install .

If you want to use Ollama, install and start it first, then pull the model:

ollama pull gemma3

Check your environment:

git-ofrenda doctor

Generate an ofrenda or start a local séance:

git-ofrenda build
git-ofrenda seance

Terminal Session

Chatting With a File

Limitations and What's Next

Heavily rewritten files can still look like a death followed by a birth. Only the first 2,500 characters of a file are sent to the model, and smaller models sometimes ignore the requested verse format, causing the tool to fall back to a template.

The next feature I would like to build is a GitHub Action that publishes an ofrenda each year for the files deleted during that year.

It would turn an ordinary maintenance history into a small annual ritual: a chance to revisit the code that once mattered, understand why it disappeared, and remember the work that went into building it.

Final Thoughts

Git is excellent at remembering what happened to a codebase. It records changes, authors, and commit messages with remarkable persistence.

But it does not usually encourage us to stop and reflect on what those changes mean.

git-ofrenda is my attempt to add that missing moment of reflection. It takes something as ordinary as a deleted file and turns its history into a small memorial, using local models to keep the process private and accessible.

Sometimes, even deleted code deserves a proper goodbye.

Explore the project on GitHub: https://github.com/elonmasai7/git-ofrenda

SlothWatch is an AI agent whose best output is silence.

Elon masai — Sun, 25 Oct 2026 17:29:26 +0000

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

What I Built

SlothWatch is an AI agent whose best output is silence.

Every "lazy" AI tool I've seen does the same thing: it summarizes more stuff so you can read it. That isn't laziness, it's a new inbox. A sloth doesn't summarize the forest. A sloth stays asleep until something actually matters.

So SlothWatch watches the boring numbers in your life (bank CSV exports, bills, subscriptions) and does nothing unless something is wrong. Most nights, it says this:

Nothing needs you. Go back to sleep. (45 rows checked, 0 surprises. Receipt #1)

When something is wrong, it wakes up, tells you in two plain sentences, and drafts the dispute message for you. It never sends anything. You approve, ignore, or snooze.

The effort it saves: I never have to open a bank statement to hunt for the subscription that quietly went up 40%, the grocery store that charged me twice, or the electricity bill that doubled. The agent reads every row so I read none.

Who gets to be lazier: anyone who dreads "I should really check my statements." That's most of us.

Demo

Live demo: https://slothwatch-demo.onrender.com/

It's hosted on Render and runs on a fully synthetic person (seeded, so every run is identical), so no real financial data is ever involved. The hosted dashboard boots into a clean month, so the sloth starts asleep. If the page takes a moment to load, the free instance is waking up. That seemed appropriate.

To watch the agent catch things, run the scenarios locally. Here is the "everything goes wrong" month: a streaming plan up 40%, a duplicate grocery charge, an electricity spike, and an insurance premium creeping up 3% a month.

And here is a sloth's diary of the duplicate-charge month, one line per day:

Code

elonmasai7 / slothwatch

fully local agent that watches boring personal numbers (bank CSV exports, utility bills, subscriptions) and does nothing unless something is off. Success state is silence: "Nothing needs you. Go back to sleep."

SlothWatch 🦥 the agent whose best output is silence

A local agent that watches boring money numbers (bank CSVs) and stays quiet unless something is wrong "Nothing needs you. Go back to sleep. (45 rows checked, 0 surprises. Receipt #1)"

Two apps, one core:

SlothWatch (real): your CSVs, your schedule. State in .slothwatch/.
SlothWatch Demo: seeded synthetic life, six scenario packs, fast-forward sloth diary, guided tour, 12-week simulation. State in .slothwatch-demo/.

Screenshots

All captured from real runs of this repo (synthetic demo data). Regenerate any of them with the command shown.

1. A clean month: silence is the product (slothwatch-demo run clean-month)

2. Everything goes wrong: the ladder wakes the model only 4 times out of 47 rows (slothwatch-demo run everything-wrong)

3. A sloth's diary: 30 days, one line per day (slothwatch-demo fast duplicate-charge)

4. Silence with a receipt: spot-check…

View on GitHub

About 2,650 lines of Python and 28 tests. The core uses only the standard library, so you can clone it and run the demo with nothing installed:

python3 -m slothwatch.demo.cli run clean-month
python3 -m slothwatch.demo.cli run everything-wrong
python3 -m slothwatch.demo.cli tour

How I Built It

The central idea: laziness should be the architecture, not just the theme. I call it the Sloth Ladder. Every layer exists to avoid waking the next one.

Rung	What it does	Open piece
0	Plain rules: exact duplicates, same-as-last-month, ignore-list. Settles most rows for free.	none needed
1	Forecasts what each recurring bill should be, with a prediction interval. Inside the interval = boring.	TabPFN, run locally
1.5	"Does this person care?" Learns from your approve/ignore decisions and hushes things you always dismiss.	TabPFN classifier, in-context
2	Wakes only for real surprises. Writes a two-sentence verdict, a severity, and a draft message as strict JSON.	Gemma via Ollama
3	You. Pinged only for severity "act".	you

A few decisions that mattered:

1. TabPFN is the "is this surprising?" gate. It's a tabular foundation model that learns in context, so there's no training pipeline to build or babysit. A few months of a bill's history goes in; a forecast with a prediction interval comes out. That is the laziest possible way to get a defensible "normal."

2. Gemma only sees the flagged row. The prompt contains one charge and its forecast context, never the whole statement. Output is schema-validated JSON with one retry and a clearly labelled templated fallback, so the nightly run never breaks if the model is down.

3. Silence has to be verifiable. An agent that says nothing looks exactly like a broken agent. So every run, quiet or not, writes a Silence Receipt: rows checked, which rung settled each one, and why. Receipts are hash-chained, slothwatch verify recomputes the chain, and slothwatch receipt --sample 3 shows three random rows it left alone with the interval that cleared them. A weekly canary plants a fake anomaly in a copy of the data and checks that the ladder catches it.

4. Temporal makes it nap durably. The nightly run is a Temporal workflow that retries flaky steps, then sleeps up to seven days waiting on a signal for your decision. The pipeline is idempotent per date window, so a worker crash can't produce a second alert.

5. Every rung is a traced span (Sentry Agent Tracing, with a local JSONL fallback) recording latency, tokens, whether it woke, and cost. Local inference shows $0.

6. The demo is deployable on Render. A render.yaml Blueprint in the repo deploys only the synthetic dashboard. It is deliberately not meant for real bank data: the real app stays on your own machine.

Under the hood it's deliberately plain: a pure run_ladder() function, SQLite, and a dashboard built on http.server with one HTML file and no CDNs, so it works with the wifi off.

Why Does Open Innovation Matter?

Because this tool reads the most sensitive file most people own, and I can prove it never leaves my machine.

slothwatch privacy-check runs the entire pipeline with every non-local network connection and DNS lookup blocked and recorded. It fails if anything tries to phone home. It's also a unit test.

That is only possible because the models are open-weight and run locally. With a closed API, the honest version of this product means uploading your bank statements to a third party and paying per token on every row. Open models gave me things a closed API wouldn't:

Privacy you can test, not just a policy you have to trust.
$0 per run, which is what makes "check every row, every night" sane.
Control over behavior. Prompts are versioned text files, rules live in a TOML file, the model is one config key, and the Rung 2 model can be swapped or fine-tuned.
It works offline. The sloth doesn't need wifi.

This is also why the hosted demo uses synthetic data only. The public link shows the idea, and your real statements never need to touch a server you don't control.

My Agent Session

⟦ EMBED agent_session ⟧

The Lazy Payoff

The point of the ladder is how rarely the expensive layers run. I benchmarked it against the naive "send every row to the LLM" approach across six scenarios (one clean month plus five kinds of problem):

8 model wake-ups with the ladder versus 274 for send-every-row: 97% fewer.
On a typical bad month: 47 rows checked, 42 settled by rules, 1 by forecast, and the model woke 4 times.
Every planted anomaly was caught, with zero false positives (on synthetic data, so real statements will be messier).

I also simulated twelve weeks with a persona that has consistent tastes (always approves duplicate charges, ignores small utility wobbles), once with learning off and once on:

I want to be straight about this one. The effect is real but modest: 56 wake-ups fell to 47 (16% fewer), and in a 26-week run 106 fell to 90. The two curves are identical until week 6, because the agent needs 15 labelled decisions before it is allowed to hush anything. Safety rails stop it from ever suppressing a large charge, and in both runs it still caught all 19 true anomalies. I'd rather show you a small honest curve than a dramatic invented one.

⟦ One sentence about your real use this week, or delete this line ⟧

What isn't proven yet: the benchmark ran with Gemma's templated fallback (labelled "offline" in the report), so its token counts are estimated. ⟦ After running with Ollama: "With gemma3:4b live, a wake-up took ___ ms and ___ tokens." ⟧ The Tinker fine-tuning harness (dataset plus evaluation) is built and tested, but I'm not claiming a tuned-versus-stock improvement I didn't measure.

Prize Categories

Best Use of Render: the synthetic demo dashboard is deployed on Render from a render.yaml Blueprint: https://slothwatch-demo.onrender.com/
Best Use of TabPFN: forecast intervals (Rung 1) and the in-context "does this person care?" classifier (Rung 1.5), inside a wider prediction agent.
Best Use of Gemma: the Rung 2 explainer, running locally via Ollama, waking only for flagged rows.
Best Use of Temporal: a durable nightly workflow that retries, sleeps on a signal, and is idempotent across crashes.
Best Use of Sentry Agent Tracing: one span per rung with latency, tokens, wake/sleep, and cost.
Best Use of Entire: agent sessions linked above.