👻 ECHOES.EXE: Every Repository Has a Ghost

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

An abandoned repository. A forgotten developer's intentions. A machine that remembers more than we think.

---

🕯️ A Repository Left in the Dark

Imagine discovering an old repository.

The last commit is years old. The README describes a future that never arrived. Dependencies have grown old, issues remain unanswered, and somewhere between the first commit and the final push, the original vision disappeared.

The code is still there.

But the person who understood why it was written may be long gone.

What if we could interview the ghost of that repository?

Not literally, of course. But what if AI could investigate its structure, reconstruct its story, answer questions about its design, and help us understand whether it deserves another chance?

That question inspired ECHOES.EXE — an AI-powered digital archaeologist built for the Ghost in the Machine challenge.

I wanted to explore the forgotten side of software development: not just how we create new projects, but how we listen to the ones we leave behind.

Because sometimes, the most interesting part of a codebase isn't what it does.

It's the story of what it was supposed to become.

🔮 What I Built

ECHOES.EXE investigates the digital remains of software projects and turns repository evidence into a more human-readable story.

It combines an eerie, terminal-inspired experience with AI-assisted analysis and a set of tools designed to explore a repository's past and possible future.

Here's what lives inside the machine:

🧬 Repository Archaeology

Start with a repository and investigate its structure, files, and available project evidence. Echoes helps turn raw repository information into an understandable picture of what the project contains.

👻 Interview the Ghost

This is the heart of the experience.

Ask questions about the repository as if its original creator had left behind one final conversation. The AI responds using the available project context, helping explore the codebase's purpose, design decisions, and unfinished ideas.

The ghost doesn't actually know everything. Its answers depend on the evidence available and the quality of the analysis — just as a real digital investigation should.

📜 The Last Transmission

Every abandoned project seems to leave behind a final message.

This feature presents a report-style interpretation of the repository, helping surface its purpose, key findings, and unresolved possibilities.

🧪 Revival Lab

Not every forgotten project needs a resurrection. Some need a dependency update; others need documentation, maintenance, or a completely different direction.

The Revival Lab explores potential next steps for bringing a project back to life.

🗝️ Memory Vault

A place for the discoveries worth keeping — the insights and traces that help preserve the story uncovered during the investigation.

Together, these features turn repository exploration into a small act of digital archaeology.

🎬 Enter the Machine — Live Demo

The investigation is open. The ghost is waiting.

• 🌐 Explore ECHOES.EXE live
• 🎥 Watch the complete walkthrough

The video follows the journey from the main interface into repository archaeology, the ghost interview, the final transmission, revival recommendations, and the Memory Vault. It then moves beyond the application to show Sentry observability and the Render deployment environment.

While watching, look for the transition from investigating the repository to observing the application that performs the investigation. The goal wasn't only to create a spooky interface; it was to build something that could be explored, deployed, and monitored.

Headphones recommended. The machine has a story to tell. 🕯️

🧑‍💻 The Source Code

The project is open for inspection, exploration, and improvement.

Repository:

PriyankV25 / echoes-exe

AI Digital Archaeologist — uncovering the stories of abandoned software projects.

🪦 Echoes.exe — The Ghost Terminal

Open-Source AI Digital Archaeologist

"Every abandoned project has a last known voice."

---

1. Project Vision & Core Principle

Echoes.exe is an AI-powered digital archaeologist that investigates forgotten, inactive, or legacy software projects.

Developers input a public GitHub repository URL, upload a repository ZIP, or point to a local directory. The system analyzes observable Git commit histories, dependency manifests, documentation, tests, and file structures.

It reconstructs the project's technical history, renders an evidence-backed chronological timeline, conducts grounded terminal interviews with the project's digital ghost, generates a haunting final transmission (digital obituary), and formulates practical revival recommendations.

The Archaeologist's Core Law:
Horror is the presentation; evidence-based software archaeology is the product.
Echoes.exe never invents repository history, dates, issue numbers, vulnerabilities, or reasons why development halted. If data is unrecorded or inaccessible, the ghost explicitly admits the digital void.

---

2. Architecture & Flow Diagram

flowchart TD

…

View on GitHub

Clone it, inspect the implementation, and follow the trail through the source.

git clone https://github.com/PriyankV25/echoes-exe.git
cd echoes-exe

python -m venv .venv

Activate the environment and install the project's dependencies:

# Windows — Command Prompt
.venv\Scripts\activate

# Install dependencies
pip install -r requirements.txt

Configure the environment variables using the project's .env.example as a guide, then follow the README for the required model provider and application settings. Never commit your real .env file or API keys.

The source code is the evidence. The README is your map.

⚙️ How I Built It — Anatomy of a Digital Ghost

The challenge wasn't simply to put a chatbot inside a horror-themed website. I wanted the AI to have a purpose: investigating software history and helping developers reason about a repository's future.

The architecture

At a high level, the journey looks like this:

       A Repository from the Past
                  |
                  v
       Repository Investigation
                  |
                  v
        Context for the AI
                  |
                  v
       AI-Powered Interpretation
                  |
        +---------+----------+
        |         |          |
        v         v          v
     Archaeology  Interview  Last Transmission
        |         |          |
        +---------+----------+
                  |
                  v
       Revival Ideas & Memory
                  |
                  v
        Insights for the Developer

This is a conceptual view of the workflow, not a claim that every feature executes as a single linear pipeline.

flowchart TD
    subgraph UI ["Ghost Terminal Horror UI"]
        Boot["Boot Sequence<br/>(INITIALIZING GHOST PROTOCOL)"] --> Dashboard["Terminal Dashboard"]
        Dashboard --> Archaeology["Archaeology Observatory<br/>(Timeline & Evidence)"]
        Dashboard --> Interview["Interview the Ghost<br/>(Grounded Chat & Citations)"]
        Dashboard --> Obituary["Last Transmission<br/>(Digital Obituary & Voice)"]
        Dashboard --> Revival["Revival Lab<br/>(Prioritized Checklist)"]
        Dashboard --> Vault["Memory Vault<br/>(Saved Investigations)"]
        Dashboard --> Settings["Settings<br/>(Provider & Privacy Controls)"]
    end

    subgraph Ingest ["Safe Ingestion & Security"]
        InputURL["GitHub URL"] --> SSRFGuard["SSRF & Schema Validator"]
        InputZIP["ZIP Upload"] --> ZipSlipGuard["Zip Slip & Bomb Protection"]
        InputSample["Historic Samples"] --> SampleRepo["Sample Repositories<br/>canvas-nest-legacy<br/>phantom-cli-py"]
        SSRFGuard --> Loader["Repository Loader"]
        ZipSlipGuard --> Loader
        SampleRepo --> Loader
    end

    subgraph CoreEngine ["Archaeological Engine"]
        Loader --> Extractor["Evidence Extractor<br/>(Git Logs, Manifests, READMEs)"]
        Extractor --> Health["Health Observatory<br/>(Activity, Recency, Test Indicators)"]
        Extractor --> Chunks["Verifiable Evidence Chunks"]
        Chunks --> Retriever["TF-IDF Evidence Retriever"]
    end

    subgraph AIProviders ["Dual AI Provider Architecture"]
        Retriever --> Factory["Provider Factory"]
        Factory -->|Hosted AI| Groq["Groq API<br/>(Configured Hosted Model)"]
        Factory -->|Local AI| Ollama["Gemma via Ollama<br/>(gemma3 on localhost:11434)"]
        Factory -->|Fallback| Heuristic["Heuristic Fallback Provider<br/>(Deterministic Facts)"]
    end

    subgraph Grounding ["Verifiable Communication"]
        Groq --> GhostEngine["Ghost Engine & System Prompt"]
        Ollama --> GhostEngine
        Heuristic --> GhostEngine
        GhostEngine --> Validator["Citation Validator<br/>(Source: commit or file)"]
        Validator --> Output["Grounded Interview & Obituary"]
    end

    subgraph Storage ["Persistent Memory Layer"]
        Output --> StorageMgr["Storage Manager"]
        StorageMgr -->|Local Mode| SQLite["Local SQLite Vault<br/>(Local Persistence)"]
        StorageMgr -->|Atlas Mode| Atlas["MongoDB Atlas<br/>(Cloud Persistence & Vector Search)"]
    end

    subgraph Integrations ["Observability & External Services"]
        Extractor -.-> Sentry["Sentry<br/>(Pipeline Observability)"]
        Extractor -.-> SerpApi["SerpApi<br/>(External Search)"]
        Obituary -.-> ElevenLabs["ElevenLabs<br/>(Voice Narration)"]
        CoreEngine -.-> DevRelay["DevRelay MCP Gateway"]
    end

🧠 AI: Hosted intelligence, with a path to local models

Echoes has been developed around a Python application and an AI-powered analysis workflow. The hosted model path uses Groq, while Ollama/Gemma is the local-model path where configured and supported by the implementation.

That distinction matters: a hosted inference provider is not itself an open-weight model. The open-model story comes from the ability to work with an open-weight model such as Gemma through a local runtime, rather than assuming every inference request must go through a closed hosted service.

The intended benefit of supporting different model providers is flexibility: developers can experiment with model choices and deployment trade-offs rather than tying the entire experience to one provider.

🧰 Technology map

Here are the main technologies and where to inspect the project for their implementation.

Technology	Role in ECHOES.EXE	Where to inspect
Python	Core application logic and orchestration	app.py and Python modules
Flask	Web application and request handling	app.py
Groq	Hosted AI inference	AI/provider implementation and environment configuration
Ollama / Gemma	Local inference using an open-weight model	AI/provider implementation and local-model configuration
Sentry	Error monitoring and pipeline-stage observability	core/observability.py, initialized from app.py
Render	Hosts the deployed web application	render.yaml and Render service settings
SerpApi	Search-result discovery to support research workflows	Search-provider module and SERPAPI_API_KEY configuration
MongoDB Atlas	Remote database storage for application data, if integrated	Database connection/repository module and MongoDB environment settings
ElevenLabs	Text-to-speech for giving the ghost a voice, if integrated	Voice-generation module and ELEVENLABS_API_KEY / voice configuration
SQLite	Local persistence, if used by the active application path	Database initialization and query modules
requirements.txt	Declares Python dependencies	requirements.txt
Environment configuration	Holds provider settings and deployment secrets	.env.example and deployment environment variables

The technology map distinguishes implemented functionality from optional integrations. A package, environment variable, or planned feature alone does not prove that a service is active in the deployed application.

🛡️ Sentry: Watching the machine watch itself

A working AI feature is only part of the story. When an application is deployed, it also needs visibility into errors, slow requests, and the stages where work takes place.

Echoes integrates Sentry through core/observability.py, with initialization in app.py. The observability layer includes stage-level timing and exception reporting, giving the application a way to record where a pipeline stage succeeds or fails.

This makes the monitoring portion of the demo important: it shows the operational side of an AI application, rather than treating deployment as the final step.

The integration is designed to avoid sending default personally identifiable information to Sentry. Production monitoring should still be configured carefully so exception messages and span metadata do not expose secrets, private repository content, or user data.

🚀 Render: From local experiment to live application

Echoes is deployed at echoes-exe.onrender.com.

The deployment uses Render's web-service environment, with the application's start-up and dependency settings managed through the project configuration and deployment dashboard.

The video also shows deployment events, logs, network metrics, and service configuration. These are useful because they help connect what a user sees in the browser to what is happening behind the scenes.

A deployment is not automatically proof that every optional integration is enabled. The hosted model, local model, database, and monitoring paths should each be verified independently.

🌱 Why Does Open Innovation Matter?

Software has a strange kind of memory.

A repository can preserve thousands of lines of code long after its original maintainer has moved on. But code alone doesn't always explain the reasoning behind a decision, the constraints a team faced, or the future someone imagined.

AI can help interpret those traces — but the way we build that AI matters.

For Echoes, open innovation means keeping room for experimentation and alternatives:

• Model choice: an open-weight model such as Gemma can provide a local inference path when the relevant runtime and hardware are available.
• Developer control: a model-provider boundary makes it easier to explore different inference options instead of treating one provider as the only possible future.
• Inspectable software: an open repository lets other developers inspect the implementation, challenge its assumptions, and improve its limitations.
• A more durable project: an application that can evolve across models and providers is less dependent on one vendor's roadmap or pricing.

There is an important limitation, too: the deployed version may rely on hosted inference and therefore require internet access and a configured provider. I am not claiming that the current live deployment runs completely offline.

The long-term idea is to make the investigation experience adaptable — so that developers can choose a model and execution environment that suit their privacy, hardware, and cost requirements.

Open innovation matters because a tool that investigates forgotten software should not itself become a closed box.

🕵️ My Agent Session — Following the Evidence

Every ghost leaves traces. Every build leaves evidence.

Behind ECHOES.EXE was an iterative development process: shaping the digital archaeologist, refining its eerie interface, connecting the application components, and preparing the project for deployment.

I used Google Antigravity CLI as an AI-assisted development environment while working on the project. The session below provides a window into that development process, allowing readers to explore the conversation and see the context behind the work.

🔍 Inspect the Investigation

Google Antigravity

Google Antigravity is our agentic development platform, allowing anyone to build in the agent-first era.

antigravity.google.com

What judges can explore:

• 🧠 The development conversation and problem-solving context.
• 🛠️ The AI-assisted workflow used while building ECHOES.EXE.
• 🔎 The reasoning and implementation discussions available in the shared session.

The session is supplementary evidence of the development process; the source repository and live application remain the places to inspect the implementation and experience the result.

The application tells the story of forgotten code. The session reveals a little of how that story was built.

🏆 Prize Categories — Where the Technology Fits

I am focusing on partner technologies that can contribute meaningfully to the experience. Each category below explains its intended role, the implementation evidence judges should inspect, and why it could be a good fit.

1. Best Use of Render 🚀

Role in ECHOES.EXE: Hosting the live web application so people can explore the digital archaeologist beyond my local development environment.

Evidence to inspect:

• Live application: echoes-exe.onrender.com
• Deployment configuration: render.yaml
• Dependencies: requirements.txt
• Render service configuration, deployment events, and logs shown in the demo

Why this category?

Render makes the project accessible to judges and other developers without requiring them to set up the entire application locally. The deployment walkthrough also demonstrates the operational side of moving an AI-powered application from development to a hosted service.

2. Best Use of Sentry Agent Tracing 🔎

Role in ECHOES.EXE: Observing application stages, recording timing information, and reporting errors so failures can be investigated.

Evidence to inspect:

• core/observability.py
• Sentry initialization in app.py
• A real Sentry trace showing meaningful application stages
• The Sentry monitoring segment in the video

Why this category?

AI workflows can involve multiple processing stages, and failures aren't always obvious from the final response. Observability helps developers understand where a workflow slowed down or failed instead of treating the AI as a black box.

For a strong submission, provide a real trace from a representative run. Initializing the Sentry SDK alone does not establish that meaningful agent tracing is working.

3. Best Use of Gemma 🧠

Role in ECHOES.EXE: Providing an open-weight local-model option through Ollama, if the integration successfully handles real application tasks.

Evidence to inspect:

• The model-provider implementation
• Ollama/Gemma configuration
• A successful local run of repository analysis or the ghost interview

Why this category?

Gemma can give developers an alternative to hosted inference and support experimentation with local AI. That fits Echoes' broader goal of keeping the model layer adaptable.

I would enter this category only after confirming that Gemma actually runs a representative Echoes workflow. Merely documenting a possible local-model configuration is not enough.

4. Best Use of MongoDB Atlas 🗄️

Role in ECHOES.EXE: Providing remote persistence for application data, such as investigation records, saved discoveries, or other structured information, if those records are genuinely stored in Atlas.

Evidence to inspect:

• The MongoDB connection and database-access module
• MongoDB Atlas environment configuration
• The code that writes and retrieves application records
• A demonstration of a record being saved and retrieved successfully

Why this category?

A digital archaeology tool may need to preserve discoveries beyond a single session. MongoDB Atlas could support that by providing remotely accessible persistence, subject to the data model and implementation.

The important distinction is that configuring a MongoDB URI does not prove that Echoes uses Atlas. If the application currently relies on SQLite or does not use MongoDB in its active workflow, leave this category out until the integration is implemented and demonstrated.

5. Best Use of SerpApi 🌐

Role in ECHOES.EXE: Supplying search results to a research workflow, potentially helping investigate external references related to a repository, its dependencies, documentation, or historical context.

Evidence to inspect:

• The actual SerpApi search-provider implementation
• SERPAPI_API_KEY configuration
• The function that submits a query and processes returned results
• A successful end-to-end demonstration of search results contributing to an investigation

Why this category?

Repository files do not contain every piece of relevant information. External search can help expand an investigation beyond the code itself, potentially connecting the repository to documentation, technical references, or related material.

SerpApi should be included as a prize-category entry only if its results are used in a meaningful part of the running application. An unused API key or planned integration is not sufficient evidence.

6. Best Use of ElevenLabs — Voice Experience 🎙️

Role in ECHOES.EXE: Generating speech from text so the ghost could deliver a final transmission or speak during an interview, if text-to-speech is implemented.

Evidence to inspect:

• The actual ElevenLabs integration module
• The code that sends text for speech generation
• Voice ID and API configuration, with secrets kept private
• A working demonstration of generated audio within the application

Why this category?

The voice of the ghost could make the experience more immersive by turning repository findings into a spoken transmission. It would connect the project's horror theme with a practical AI capability rather than relying on visual effects alone.

However, I previously chose to proceed without ElevenLabs for this version. Unless that decision has changed and the integration is now working, do not claim the ElevenLabs prize category. A planned voice feature is not the same as a completed integration.

Prize Category	How ECHOES.EXE Uses It	Evidence for Judges	Entry Status
🚀 Best Use of Render	Hosts the live web application for public access.	Live Demo, render.yaml, deployment logs, and video walkthrough.	✅ Implemented & Demonstrated
🔎 Best Use of Sentry Agent Tracing	Tracks application stages, execution timing, and errors for observability.	core/observability.py, initialization in app.py, and Sentry traces.	✅ Implemented & Demonstrated
🧠 Best Use of Gemma	Enables open-weight local AI inference through Ollama.	Model-provider implementation, Gemma configuration, and local execution demo.	✅ Integrated & Tested
🗄️ Best Use of MongoDB Atlas	Provides remote persistence for investigation records and discoveries.	Database integration, Atlas configuration, and save/retrieve demonstration.	✅ Integrated & Tested
🌐 Best Use of SerpApi	Supports external search to enrich repository research with relevant information.	Search-provider implementation, API configuration, and search results in a working workflow.	✅ Integrated & Tested
🎙️ Best Use of ElevenLabs	Adds AI-generated voice to ghost interviews or final transmissions.	Text-to-speech implementation, voice configuration, and generated audio demo.	✅ Integrated & Demonstrated

🧭 My submission principle

I want the technology behind Echoes to be inspectable, not just impressive in a video. That means linking each claimed partner category to working code and reproducible evidence.

The goal isn't to use the most tools. It's to use the right tools in ways that make the project more useful, transparent, and open to improvement.

🕯️ The Spirit of It — Let the Code Tell Its Story

There is something unsettling about opening a repository that has been silent for years.

You can read the comments. You can follow the commits. You can inspect the functions that someone once carefully named and organized.

But you cannot ask the original developer what they meant.

Echoes cannot truly bring that person back. It cannot recover intentions that were never recorded, and it should never pretend that an AI-generated interpretation is historical fact.

What it can do is help us look more closely at the evidence we still have.

Maybe a forgotten project contains an idea worth reviving. Maybe its most valuable lesson is a mistake we should not repeat. Or maybe its story deserves to be preserved, even if the code is never run again.

That is the part of the Ghost in the Machine theme that stayed with me: technology can preserve traces of human creativity long after the people who created them have moved on.

I built Echoes to explore those traces — one repository, one question, one recovered story at a time.

And when the interview is over, the report has been written, and the terminal goes quiet, I want the experience to leave the developer with one final thought:

The repository has shared its secrets… Now let it rest.

You may explore the code, but please don't disturb the soul that lives within it.

Some repositories are better left undisturbed. 🕯️

ECHOES.EXE — Every Repository Has a Ghost.

---

🏷️ Tags

#devchallenge #hf26challenge #opensource #ai