This post is my submission for the DEV Hacktoberfest 2026 Week 4 Challenge — Ghost in the Machine.
Every Repository Has Ghosts 👻
There is a commit in almost every repository that nobody wants to read.
It's the commit that deletes a file.
Not a refactor. Not a rename. Just a removal, buried somewhere in Git history, accompanied by a commit message like cleanup.
But that file had a life before it disappeared.
It was created on a Tuesday, modified eleven times, survived multiple changes, and eventually vanished one afternoon.
Git remembers all of it.
Nobody asks.
For Hacktoberfest Week 4, the theme was Ghost in the Machine.
My first thought was to build something around a haunted AI chatbot. But then I started thinking about something more interesting.
What if the ghost wasn't something we created with AI?
What if it was something the machine had already been carrying all along?
The forgotten history of a Git repository.
That's how RepoRequiem was born.
A Git archaeology tool that uncovers deleted files, forgotten commits, extinct programming languages, and abandoned development timelines — then gives those digital ghosts a voice using locally running open-weight AI models.
🪦 What I Built: RepoRequiem
RepoRequiem explores a Git repository and reconstructs the history of things that are no longer part of its present.
Instead of simply displaying commit logs, it builds a historical record of what existed, what disappeared, and what survived.
Here's what it uncovers:
- The Buried: Files that once existed in Git history but are no longer present in the current tree. Each gets a birth date, death date, lifespan, churn, removal commit, and surviving content.
- Revenants: Files that were deleted and later restored. Some things really do come back.
- The Forgotten: Files that still exist but haven't been touched in years.
-
Cursed Commits: Unusual commits, including late-night changes, Friday the 13th releases, revert spirals, mass deletions, and suspicious messages like
asdf. - Extinct Languages: Programming languages that survive only among deleted files.
-
Unmerged Branches: Alternative development timelines that never became ancestors of
HEAD. - Souls: Historical contributor records, including commit counts, activity periods, and lines added or removed.
On the bundled demo repository, RepoRequiem discovers:
| Discovery | Result |
|---|---|
| Commits | 18 |
| Authors | 3 |
| Buried files | 8 |
| Revenants | 1 |
| Cursed commits | 6 |
| Unmerged branches | 1 |
| Extinct language eras | 1 |
The interesting part?
The scanner doesn't know this story beforehand. It discovers these details directly from Git.
🎬 See It in Action
RepoRequiem is designed to run locally. There is currently no hosted demo because repository history can contain private information, and uploading that history shouldn't be a requirement.
You can explore the bundled demo repository by running the application and opening:
http://127.0.0.1:8000/?demo=1
Here are the main parts of the experience.
1. The Graveyard
Every buried file gets its own headstone.
Open one, and you get a certificate of removal containing its creation date, deletion date, lifespan, changes, removal commit, and the last surviving lines of its content.
A file that lived for 82 days and was removed in a commit titled Retire CoffeeScript, port parser to JavaScript tells a very different story from a file that survived two years before being removed in Final cleanup. Thanks for everything.
2. The Séance
What happened to a particular file?
Who removed it?
What programming language disappeared?
The séance lets you ask questions about the repository's history.
It retrieves relevant evidence from the repository record and gives the model only that evidence to work with.
If the model is unavailable, the system answers using the same facts directly.
And if the record doesn't contain an answer, it says so.
3. The Archive
The archive brings together the repository's historical record — forgotten files, unusual commits, contributors, and alternative development timelines.
It turns what would normally be scattered Git history into something developers can actually explore.
🧠 How I Built It
The technology stack is deliberately small:
- Backend: Python, FastAPI
- Frontend: React, Vite, Tailwind CSS
- AI runtime: Ollama
- Model integration: OpenAI-compatible API
- Version history: Git CLI
But the most important engineering decision wasn't about choosing a framework.
It was about separating facts from AI-generated storytelling.
1. Git is the source of truth
RepoRequiem starts by analyzing the repository using Git commands such as:
git log --numstat --no-renames
git ls-tree
The analysis builds a per-file historical ledger and extracts the information needed to construct the repository's record.
The model doesn't decide what happened to a file.
Git provides the evidence.
2. AI becomes the storyteller
Once the historical record is ready, RepoRequiem converts it into a plain-text collection of facts.
The model receives those facts with strict instructions:
- Never invent file names.
- Never invent contributors.
- Never invent dates or numbers.
- Never invent commits or events.
Its response must follow a JSON schema.
A validation layer checks the response, applies length limits, removes invalid sections, and rejects laments referencing files that were never actually deleted.
The idea is simple:
AI can interpret the evidence, but it cannot rewrite history.
3. The Archivist: When AI isn't available
This is one of the architectural decisions I'm most proud of.
What happens if Ollama isn't running?
Or if the machine doesn't have a suitable model installed?
RepoRequiem doesn't simply display an error.
It switches to a deterministic storyteller called The Archivist.
The Archivist uses the same Git-derived facts to produce a readable historical account without requiring model inference.
The interface clearly identifies this mode:
facts only · no model
The application remains usable even without a GPU or an available model.
I wanted the fallback to feel like a legitimate part of the experience, not a broken version of the application.
4. Local open-weight AI
RepoRequiem uses Ollama to discover locally available models through /api/tags.
It evaluates the available models and selects a suitable instruction-following model, while supporting an explicit OLLAMA_MODEL override.
An OpenAI-compatible endpoint is also available as an alternative.
The inference layer is intentionally simple:
- One request to
/api/chat. - JSON-mode generation.
- A timeout.
- Response validation.
- A deterministic fallback.
No complicated agent framework, orchestration graph, or vector database was necessary.
The hard part was the archaeology, not the plumbing.
🔓 Why Open Innovation Matters
This is where the project's architecture becomes especially important.
A Git repository can contain much more than source code.
It can contain internal architecture, abandoned features, contributor information, and years of development history.
Sending that information to an external AI API introduces another place where private repository data has to travel.
I wanted a different approach.
RepoRequiem keeps repository analysis and AI storytelling on the developer's own machine.
Using open-weight models and local inference gives developers:
- Privacy: Repository history doesn't need to be uploaded to a third-party AI service.
- Control: Developers can choose which locally available model they want to use.
- Flexibility: Models can be replaced without rebuilding the entire application.
- Accessibility: The historical record can still be generated without AI inference.
- Independence: There is no mandatory external AI API or paid inference dependency.
For me, open innovation isn't just about accessing model weights.
It's about having control over how technology works, where data goes, and what happens when a particular service becomes unavailable.
For a tool that explores private repository history, those things matter.
⚙️ What Was Challenging?
Not everything was straightforward.
Detecting deletion without lying
Git doesn't provide a simple event saying, "This file died."
A file can disappear because it was deleted, renamed, moved into a submodule, or because its history was truncated.
RepoRequiem uses a heuristic based on Git's change statistics and cross-checks against the current tree.
It's not perfect, and the README documents that limitation.
I'd rather acknowledge uncertainty than present a guess as historical fact.
Preventing AI hallucinations
Models love adding details.
But a beautiful paragraph about a file that never existed is still wrong.
The validation layer is therefore a critical part of the application, not just an implementation detail.
Making failure feel intentional
Initially, missing Ollama meant an error message.
I changed that behavior and built The Archivist as a proper alternative experience.
A machine without an AI model should still be able to tell the repository's story.
Getting the visual identity right
I didn't want another dark SaaS dashboard with a purple gradient.
I approached the interface as a digital reading room:
- Near-black backgrounds.
- Bone-colored serif typography.
- Candle and ember accents.
- Roman numerals.
- Monospaced typography for historical facts.
- Italic typography for generated storytelling.
The distinction between facts and storytelling is visible in the design itself.
🚀 What's Next?
There are several improvements I'd like to explore:
- Better rename detection instead of treating every rename as a death and birth.
- A comparison view showing what replaced a deleted file.
- Historical obituaries for contributors who left a project.
- A CLI version that can generate repository ghost records during CI runs.
The core idea, however, is already there.
The machine remembers what we deleted.
RepoRequiem just gives those memories a voice.
💻 Try It Yourself
The complete source code is available on GitHub:
You can clone the project and run it locally.
git clone https://github.com/RameezHiro/reporequiem.git
cd reporequiem/frontend
npm install
npm run build
cd ../backend
pip install -r requirements.txt
uvicorn main:app --port 8000
Open:
http://127.0.0.1:8000
Or add ?demo=1 to explore the bundled haunted repository.
The project uses FastAPI, React, Vite, Tailwind CSS, Ollama, and Git.
There is no database, no account system, and no mandatory external AI service. Scans live in memory and expire.
If you explore the project, I'd genuinely appreciate feedback, ideas, and contributions.
👻 One Last Thing
A repository is more than the code currently sitting in its working tree.
It's a record of decisions, experiments, abandoned ideas, failed approaches, and people who contributed along the way.
Some files were removed because they were no longer needed.
Others disappeared because something better replaced them.
Some simply became forgotten.
RepoRequiem doesn't claim to know why every file was deleted. It doesn't invent emotional backstories or pretend to understand decisions that Git never recorded.
It simply preserves what the history can prove.
A ghost that makes things up is a hallucination. A ghost that can only repeat what the record already contains is a witness.
Built for the DEV Hacktoberfest 2026 Week 4 Challenge — Ghost in the Machine.
AI Disclosure: I used an AI coding assistant to pair on the implementation and help draft this article. I checked the technical claims against the running application. The historical facts in the demo are extracted from Git, not invented by the AI model.
Top comments (0)