GHOST//ARCHIVE: The Code Is Gone. Git Remembers.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine There is a strange thing about software: we remove functions, replace implementations, refactor entire systems, and eventually call the old code gone. But Git knows better. A file may disappear from the working tree, yet an earlier version can still be preserved inside repository history, frozen inside a commit and waiting to be discovered. That idea became GHOST//ARCHIVE, a local-first AI archaeologist for forgotten code. It searches Git history for deleted source files, reconstructs the exact version that existed immediately before deletion, and lets a locally running Gemma 3 model investigate what that code once did. The project is built around one important rule: The AI is allowed to interpret the ghost. It is not allowed to rewrite its history. What I Built GHOST//ARCHIVE is a developer tool that turns Git history into a digital archaeology archive. Instead of looking only at the current state of a repository, it searches for source files that once existed, recovers them from historical commits, and presents them as artifacts that can be inspected and investigated. The workflow is: Git repository ↓ Search deletion history ↓ Recover forgotten source ↓ Extract historical evidence ↓ Ask Gemma to investigate ↓ Separate facts from hypotheses The application currently supports: scanning Git history for deleted files; distinguishing real deletions from ordinary renames; restoring the historical source from immediately before deletion; detecting likely Python and JavaScript/TypeScript symbols; showing deletion commit, date, path, and commit message; sending recovered artifacts to a locally running Gemma model; rendering the investigation as Markdown; visually separating verified Git evidence from AI interpretation; generating a synthetic demo archive with one click; testing deletion, edit, rename, empty-repository, AI-failure, and evidence-confidence scenarios. Why “Ghost in the Machine”? I interpreted the theme literally. Every long-lived repository is haunted by software that used to exist. There are functions that once handled production traffic, modules that were replaced years ago, experiments that never survived, architectures that disappeared during refactors, and code written by developers who may no longer be part of the project. A deleted file is no longer visible in the current codebase, but it is not necessarily erased from history. That made Git feel less like a changelog and more like an archaeological site. GHOST//ARCHIVE is my attempt to build an interface for exploring those remains. Demo Live application https://ghost-archive-mvp.onrender.com/ Backend API documentation https://ghost-archive-mvp-backend.vercel.app/docs The hosted version provides a public demonstration of the archive experience. For the complete privacy-first workflow — including scanning arbitrary repositories on your own machine and running Gemma through local Ollama — GHOST//ARCHIVE is designed to run locally. That distinction is intentional. A cloud server cannot access a developer's C:\projects\... directory, and it cannot safely assume access to the Ollama instance running on that developer's laptop. The public deployment is therefore the museum, while the local application is the excavation site. Demo flow Create Demo Archive ↓ Scan Archive ↓ Discover legacy.py ↓ Recover deleted source ↓ Inspect Git evidence ↓ Interrogate with Gemma ↓ Compare VERIFIED evidence with AI HYPOTHESIS Verified archive evidence AI interpretation / hypothesis This separation became the most important design decision in the project. It makes the interface clear about what the repository actually proves and what the AI is merely interpreting. Code The project is fully open source: https://github.com/Njorodev/ghost-archive-mvp The main stack is: Frontend ├── React ├── Vite ├── Lucide React ├── React Markdown └── remark-gfm Backend ├── Python ├── FastAPI ├── Pydantic ├── Requests └── Git CLI AI ├── Gemma 3 └── Ollama Testing ├── Pytest ├── FastAPI TestClient └── HTTPX Deployment ├── Render └── Vercel The repository includes the frontend, backend, automated tests, MIT license, local installation instructions, privacy guidance, and the hosted-demo architecture. How I Built It The project has three main layers: Git archaeology, evidence-first analysis, and local AI investigation. 1. Git archaeology The first job is finding code that no longer exists in the current repository. The backend searches Git history with: git log \ --all \ --find-renames \ --diff-filter=D \ --name-status --diff-filter=D means the archive is intentionally looking for deletions. --find-renames is equally important because renaming a file should not make GHOST//ARCHIVE announce that it has discovered a ghost. Once a deleted artifact is identified, the source that existed immediately before deletion is reconstructed with: git show ^: This gives the application the exact historical source instead of asking an AI model to reconstruct it from memory or inference. The model never has to guess what the deleted code looked like because Git provides the original artifact directly. 2. Evidence before AI My first instinct was to let the model read the deleted code and explain its history. That quickly revealed a problem. Imagine Git contains a commit message like: Commit message: "Cleanup legacy billing code" An LLM might confidently conclude: “The developers removed this module because the new billing architecture made it obsolete.” That sounds plausible, but it may be completely invented. To avoid that, GHOST//ARCHIVE builds an explicit evidence layer before the model is allowed to interpret the artifact. For example: VERIFIED Deletion commit 67dafe3... VERIFIED Historical path legacy.py VERIFIED Deletion date 2026-10-29 SUPPORTED CLUE Commit message Remove legacy billing module after billing refactor Only after that evidence exists does Gemma receive the artifact. The prompt explicitly instructs the model to distinguish between: what the source code proves; what Git history supports; what is only a plausible interpretation; what the archive does not establish. If the evidence is insufficient, the model is instructed to say: “The archive does not establish this.” This changed the project from a simple “AI explains deleted code” tool into something more deliberate: AI investigates deleted code while Git remains the authority. That distinction became one of the defining ideas of GHOST//ARCHIVE. 3. Gemma through Ollama For the AI layer, I used Gemma 3 running locally through Ollama. The local architecture looks like this: React │ ▼ FastAPI │ ├────► Git repository │ └────► Ollama │ ▼ Gemma 3 The recovered source and historical metadata are sent to the local Ollama API at: http://127.0.0.1:11434/api/generate No hosted AI API is required for the full local workflow. When the 4B model humbled my laptop I originally used: gemma3:4b On my machine, Ollama reported: NAME PROCESSOR gemma3:4b 100% CPU The first investigation requests eventually exceeded the backend timeout. Instead of abandoning local inference, I adapted the system around the hardware. I moved the default model to: gemma3:1b and adjusted several runtime settings: output token limits; context size; inference timeout; model keep-alive behavior; temperature. The result was much more practical on a CPU-only Windows machine. It also reinforced one of the strongest advantages of open-weight AI: I could choose the model/runtime tradeoff myself instead of being locked behind a fixed remote endpoint. Testing the Ghosts Git history contains many edge cases, so I added automated tests around the behaviors most likely to create false ghosts. The test suite covers: Deleted files: a committed file that is deleted later should be correctly recovered. Edited files: a normal modification should not appear as a deleted artifact. Renamed files: a move from old_name.py to new_name.py should not be treated as a deletion. Empty repositories: an empty repository should return zero artifacts rather than crash. Ollama failures: if the local model server is unavailable, the API should return a useful error. Evidence confidence: explicit removal/refactor commit messages can be shown as supported clues, while ambiguous messages remain uncertain. For me, this test suite is part of the theme too. If the application falsely declares living code dead, it is not an archaeologist — it is a ghost generator. Privacy Was Part of the Architecture Source repositories can contain some of the most sensitive information in a software organization, including: proprietary algorithms; internal APIs; unreleased functionality; infrastructure details; business rules; security-sensitive implementation logic. I did not want the default GHOST//ARCHIVE workflow to require uploading that source code to a third-party AI endpoint. That is why the complete workflow is local. Git runs locally, FastAPI runs locally, Ollama runs locally, and Gemma runs locally. The source stays on the developer's machine, while recovered historical code is treated as untrusted text and is never executed by GHOST//ARCHIVE. Why Does Open Innovation Matter? For this project, open innovation was not just a competition requirement. It changed what the product could be. If GHOST//ARCHIVE depended entirely on a closed hosted API, the architecture would look like this: private source code ↓ external service ↓ AI model That creates an immediate trust problem. With Gemma and Ollama, the architecture can instead remain local: private repository ↓ local Git archaeology ↓ local Gemma This means the user controls: where inference happens; which Gemma variant runs; how much context is sent; whether the machine needs network access; how the model is configured; what happens to private source code. It also made the project accessible without requiring a paid inference API. My own machine demonstrated why that flexibility matters. When Gemma 4B was too slow on CPU, I switched to Gemma 1B and continued building. There was no account migration, pricing-plan change, or API rewrite — just a different open-weight model better suited to the available hardware. That kind of control is difficult to achieve with a closed black-box endpoint. The Spirit of It The moment the project really clicked for me was not when the AI response appeared. It happened earlier, when the archive recovered a file that no longer existed in the current project. The demo repository contains: legacy.py The file is committed, then deleted. When GHOST//ARCHIVE scans the repository, the current filesystem effectively says: legacy.py does not exist. But Git says: I remember it. The interface then shows the deleted source again, including a function that no longer exists anywhere in the current working tree: def calculate_legacy_total(...): ... There is something slightly eerie about that, not because the code is supernatural, but because it reminds you that deletion in software is often not complete erasure. A repository can contain years of abandoned ideas, old assumptions, forgotten decisions, and implementations written by people who may no longer be part of the project. The current codebase is only the latest layer. Everything beneath it is still part of the story. That is the ghost I wanted this project to capture. What I Would Build Next The current release deliberately focuses on deleted artifacts, but the long-term idea is broader software archaeology. Future improvements could include: function-level edit archaeology; commit-to-commit implementation comparison; AST-based symbol detection; file resurrection timelines; repository-wide historical search; public GitHub repository scanning in hosted mode; exportable investigation reports; richer evidence citations; model presets based on available hardware. The goal is to eventually move beyond the question: “What was deleted?” and toward a larger one: How did this codebase become what it is today? The important constraint would remain the same: AI can help interpret the evidence, but it should not quietly turn speculation into history. Prize Categories I am entering GHOST//ARCHIVE in the following categories. 1. Best Use of Gemma Gemma 3 is the AI investigation layer at the center of the local experience. It runs through Ollama, examines recovered source and Git metadata, and produces evidence-aware explanations while allowing developers to choose different Gemma variants based on their hardware. 2. Best Use of Render The public GHOST//ARCHIVE frontend is deployed on Render: https://ghost-archive-mvp.onrender.com/ Render provides a public demonstration surface, while the privacy-sensitive repository scanning and local inference architecture remain available to developers who run the full project locally. Final Thought We usually think of Git as a version-control system, but building GHOST//ARCHIVE made me think of it as something else too: a memory. Files disappear, functions are replaced, architectures change, and developers move on, but traces remain. If AI is going to help us interpret those traces, it should do so carefully — with evidence visible, uncertainty acknowledged, and history allowed to speak for itself. The code is gone. Git remembers. 👻