The Last Commit: An AI Archaeologist That Exhumes Your Dead Repos

Ashwin — Sat, 31 Oct 2026 16:59:35 +0000

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

What I Built

Every abandoned repository is a ghost story. The author moved on, the issues
went quiet, the README promised features that never shipped — and somewhere in
the commit history, the exact moment the project died is still recorded. The
challenge theme said Ghost in the Machine, and to me the reading was literal:
the machine is the git history, and the ghost is the maintainer's memory,
reconstructable from it.

So I built The Last Commit — an AI archaeologist for abandoned
repositories. You give it a GitHub link to something dead, and it does two
things:

First, it performs an autopsy. A deterministic forensic engine reads the
full commit graph, the final source tree through tree-sitter, and the
documentation, and produces a report: a Timeline of Decline (who stopped
committing, and when), The Autopsy (stub functions, TODO clusters, branches
with stranded work), Anomalies & Suspicious Regressions (reverted commits
paired with what they undid, disabled tests, high-churn files that fell silent),
Decisions Nobody Wrote Down (large refactors with no documentation traffic),
and a Revival Roadmap.

Second — the part the theme is really about — you interrogate the ghost.
Under every report there's a séance panel where you chat with the former
maintainer, in character, first person, with a fallible human memory: "honestly,
I don't remember… but the log shows we reverted the cache layer because it
doubled latency." The persona pulls real evidence live — commits with diffs,
file revisions, branch states — and every single answer ends with a
Receipts block. If the record is silent, the ghost says so instead of
inventing something.

The design rule that makes this trustworthy: deterministic first, LLM
second. Every fact in the report is computed by code. The open-weight model
writes the story, but it may only cite finding IDs, and a machine verifier
strips any commit hash or reference it can't match against real evidence.
Claims that fail verification are removed, not trusted.

Demo

The app is deployed and live (no sign-in — rate limits are 5 exhumations and
20 whispers per visitor per day):

🔗 https://lastcommit-app.azurewebsites.net

Paste a dead repo's GitHub link, watch the exhumation ("Reading the bones…"),
read the report, scroll down to Summon the Maintainer, and ask it why the
project died. There's also a full CLI (lastcommit analyze / lastcommit interview) for local repos, private ones included.

Code

ashxris / the-last-commit

An AI archaeologist for abandoned open-source repositories.

The Last Commit

An AI archaeologist for abandoned open-source repositories.

Give it a dead repo. It excavates the git history, the final source tree, and the documentation; reconstructs what the original developers were trying to build; and produces a forensic report — unfinished features, suspicious regressions undocumented design decisions — plus a ranked roadmap for reviving the project.

Then it does the part you actually came for: you interrogate the repository as if interviewing its former maintainer. The persona answers in first person with a fallible human memory, but every claim is grounded in real commits, files, and branches pulled live from the history — and every answer ends with a receipts block.

Install

Get the code, then install — this creates a private environment with every dependency the project needs, including the lastcommit command:

git clone https://github.com/ashxris/the-last-commit.git
cd the-last-commit
uv sync          # or: pip install -e .

No git…

View on GitHub

The architecture, in one picture:

repo ──▶ ingest ──▶ forensic detectors ──▶ findings (typed evidence)
             │            │                      │
             │            └─ pygit2 · tree-sitter · doc parsing
             ▼                                   ▼
       chunk index (SQLite + FTS5 + local vectors) ──▶ verified report
             │
             ▼
    interview: maintainer persona + agentic git tools (show_commit,
    blame, file_at_rev, search, timeline) + receipts

Python, pygit2 for full-history walks, tree-sitter for AST-level code
understanding, SQLite FTS5 + local embeddings for hybrid retrieval, and an
OpenAI-compatible client for the model layer.

How I Built It

The open-source AI core. The persona runs on Qwen, an open-weight
model (qwen/qwen3.8-27b served through Groq's OpenAI-compatible endpoint —
one config line swaps in a locally hosted model via vLLM, Ollama, or
llama.cpp). Embeddings for the retrieval index are fully local: fastembed
running BGE-small on CPU via ONNX — no embedding API, no cloud, no data
leaving the machine.

Deterministic forensics. The detectors never call a model. Revert
detection pairs a revert commit with the change it undid by inverting diff
statistics. Author dropout order comes from per-author commit cadence. Stub
detection reads the AST: raise NotImplementedError bodies, ..., docstring-
only functions, and symbols with zero remaining call sites. Test-disabling
commits, CHANGELOG promises that never shipped, undocumented refactors — all
pure code, all with typed evidence attached.

Constrained generation with machine verification. The LLM sees the
findings as facts and writes narrative, but it may only reference finding IDs;
a verifier then re-checks every cited ID and every commit hash in the prose
against the evidence set and strips what doesn't match. The interview works
the same way: an agentic loop with five real git tools, a persona prompt that
requires receipts, and "the record doesn't show that" as the mandated answer
when evidence runs out.

The build itself was agentic too. The entire project — detectors, retrieval
index, verifier, spooky crimson web UI, and the Azure infrastructure — was
built in an agent session on ZCode running GLM, an open-weight model, over
about a day of iterating.

Deployment. Azure App Service (B1, Always On) via the Azure Developer CLI
and Bicep, with GitHub Actions deploying on every push using OIDC federated
credentials — no cloud secrets stored anywhere.

Why Does Open Innovation Matter?

Because the whole product is a claim about trust, and open weights are what
make the claim auditable. The app tells you "this ghost only says what the
record supports." That's only meaningful if you can inspect everything the
ghost can see: the deterministic detectors, the exact system prompts, the
verifier's rules. With a closed API, "trust me" would be the actual architecture.

Swappability made the project survive its own deployment. The model layer
is one config file. When the first hosted model hit a token-per-minute wall,
the failure taught us to slim the prompts and pace requests — and the same code
ran unchanged on a different model and host. If a vendor changes pricing or
disappears, the ghost moves; the séance stays.

Local inference matters for the private case. The CLI works on your own
repos, and the embedding model runs on your CPU. Nothing about the core needs
a vendor at all — point base_url at your own vLLM box and the whole thing is
offline.

And it's a reusable pattern. Deterministic evidence → constrained
generation → machine-verified citations is the part I most wanted to give
away. It's MIT-licensed, pinned with a lockfile, and commented so the next
person building an "AI that must not hallucinate" can start from the spine,
not from scratch.

My Agent Session

The project was built end-to-end in one agentic session on ZCode, powered by
GLM (open-weight): architecture, all 25+ source files, the Bicep
infrastructure, the GitHub Actions pipeline, and the debugging along the way
(including Azure for Students blocking ACR remote builds — the build moved to
Actions runners, and the Bicep was fixed to match).

🔗 Session: https://zcode.z.ai/share/a6l1cJwHUcOQhGkyvmTYDWtBstMISbvh

Prize Categories

GitHub Copilot — the project's delivery is GitHub Actions automation: an OIDC-federated pipeline (no stored cloud secrets) that provisions Azure infrastructure with Bicep, builds the container, and rolls it out to App Service on every push to main.

DEV Community: Ashwin