I Built a Coroner for Abandoned GitHub Repos

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

What I Built

Every developer has cloned an abandoned repo, run npm install, and watched it explode. The real question is why. Did the world move out from under it (a breaking dependency release), or was it already broken when the author walked away?

RepoRequiem is a tool that investigates a dead repository and answers that question with evidence, not vibes.

It runs a five-stage pipeline:

1. Evidence Collector: pulls commits, releases, issues, forks, and dependency manifests (from the GitHub API or an offline snapshot) into SQLite. Every fact gets a deterministic evidence_id.
2. Time-Machine Rebuilder: builds the project in a Docker sandbox twice, once with dependencies as they were on the day the project died and once with today's. The result is one of alive, world_moved, born_broken, or cannot_determine.
3. Death Bisector: for world_moved repos, binary-searches dependency release dates between then and now to find the window where it broke, diffs the lockfiles, and isolates the suspect package.
4. Heir Finder: scores forks on divergence, recency, stars, and independent authorship to find a living successor.
5. Verified Resurrection Report: a local Gemma model writes the report and a step-by-step revival checklist.

The Rule of Truth

The part I care most about is that the LLM never decides facts.

Dates, versions, exit codes, and counts all come from deterministic tools and the SQLite evidence store. Gemma only explains them. Every claim it writes has to cite an evidence ID, and a ReportValidator checks each citation and number after generation. Claims that fail validation are flagged or pruned. A small local model is useful here because it is fast and private, and the validator keeps it from making things up.

Safety: Zero Host Execution

Running code from abandoned repos is risky, so target code never runs on the host:

• Install stage: network on, --ignore-scripts
• Build/test stage: --network none
• Non-root user, 1.5 CPU, 2 GB RAM, hard timeouts
• Container destroyed after every run
• If Docker isn't available, the answer is cannot_determine, never a degraded guess

Demo

Try It

Prerequisites: Python 3.11+, Docker (for live rebuilds), and Ollama with a Gemma model (ollama pull gemma2:2b).

git clone https://github.com/AMAN240310/reproequiem.git
cd reproequiem
pip install -e .

# Offline mode (no network or GitHub token needed)
reporequiem inspect tests/fixtures/sample_offline_repo.json --offline

# Live mode
reporequiem inspect https://github.com/owner/dead-repo --token $GITHUB_TOKEN

# Dashboard at http://localhost:8080
reporequiem serve --port 8080

Without Docker, rebuild verdicts come back as cannot_determine, by design.

Code

AMAN240310 / reproequiem

RepoRequiem ⚰️✨

An instrument that measures why an abandoned repository died and whether it can live again.
Built for the Hacktoberfest Open-Source AI Challenge, Week 4 ("Ghost in the Machine").

RepoRequiem investigates dead and abandoned software repositories. It answers the fundamental question: Did this project break because the external world moved under its feet (package drift, API breakages), or was it already broken? Can it be revived?

---

🔮 The Pipeline

1. Stage 1: Evidence Collector (reporequiem.collect)
   • Queries GitHub REST API (or offline cached snapshot).
   • Ingests commits, releases, issues, forks, dependency manifests, and determines last known active date $T$.
   • Stores everything with deterministic evidence_ids in SQLite (store.py).
2. Stage 2: Time-Machine Rebuilder (reporequiem.rebuild)
   • Isolated Docker container execution: install with --ignore-scripts, build/test with --network none.
   • Builds at time $T$ (historical dependencies) vs. today.
   • Determines verdict: alive, world_moved, born_broken, or cannot_determine…

View on GitHub

How I Used Gemma

Gemma runs locally through Ollama (gemma2:2b by default) as an explainer and summarizer. The prompt includes only evidence pulled from the store, the output must be JSON with evidence-ID citations, and the validator is the gatekeeper. The model writes the memorial ("Ofrenda") and the revival checklist, but not the verdict.

## Why Does Open Innovation Matter?

RepoRequiem runs Gemma locally through Ollama, so a repo's code, history, and forks never leave your machine. That matters because the tool analyzes untrusted code and sometimes private forks, and a closed API would mean sending that evidence to a server I don't control.

Open weights also let me swap models without touching the pipeline. The "Rule of Truth" validator works with any model, so a small local one is enough. And the whole thing runs offline, with no API costs and no service that can disappear, which fits a tool built to bring abandoned projects back to life.

Honest Limitations

I documented these in LIMITS.md instead of hiding them:

• Ecosystems: only npm and Python for now; everything else returns cannot_determine.
• Not every death is a dependency death: dead APIs, missing credentials, and rotted system libraries also kill projects. Those cases should land in born_broken or cannot_determine.
• The benchmark is a scoring harness over 7 hand-built fixtures, not a measurement of real-world accuracy. The next step is running the pipeline on real dormant repos with known outcomes.
• Heir scoring is a simple weighted formula, and I haven't validated the weights yet.

Prize Categories

• Best Use of Gemma: Gemma runs locally via Ollama as the report explainer, with every claim checked against stored evidence.

What's Next

• Run the full pipeline on a real dataset of dormant repos
• Pin historical Node/Python runtimes per era in the rebuilder
• Normalize the heir-scoring features
• Add more ecosystems (Rust, Go)

Thanks for reading. If you have a dead repo you'd like to investigate, open an issue. 🕯️