Ghost of Developers Past: A Way Back Into Unfinished Projects

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

What I Built

I have projects I still want to finish. School, other responsibilities, and new ideas sometimes pull me away long enough that returning becomes a project of its own. What did I finish? Which files matter? Do the startup instructions still match the code?

Project Revival: Ghost of Developers Past is a workbench for recovering that context.

Choose an unfinished project's folder, review the prepared files, and describe what you want to accomplish. Gemma explains what the project does, identifies implemented and unfinished work, and proposes three practical next steps. Its references open the actual file and highlight the cited lines beside the explanation.

You can speak your goal, listen to the response, answer follow-up questions, and save your plan as Markdown or PDF.

For Ghost in the Machine, I wanted to give past work another chance. The ghost and gothic bookshelf set the scene; the useful part is helping a developer return to the ideas sitting in those old folders. This workbench is a new Week 4 build. Older projects are inputs for testing it.

Demo

Open Ghost of Developers Past — no account or login required.

For a quick test:

1. Click Try the example to load Grant Ledger, a fictional unfinished Python project.
2. Inspect its three files in Sources, then return to Project.
3. Keep the example goal or enter your own. Speak your goal provides editable transcription.
4. Click Build my restart plan.
5. Follow a source reference, try Read aloud, or use Answer questions or request changes to create another version.
6. Save the selected plan, then use Clear session when finished.

The example has a useful contradiction to investigate: its README recommends python main.py, while the supplied entry file is app.py. Its CSV export is also unfinished. These give reviewers concrete findings to check against the files.

Code

GitHub repository

The application code is MIT licensed. The repository's artwork notice separately describes the supplied visual assets.

My Agent Session

Part 1: How we work together

This opening exchange comes from earlier in our collaboration, before starting the Week 4 build. We had just downloaded the DevRelay API and was gathering Hacktoberfest information for Week 3. I set the working agreement: we build together. We discuss each component, explain what it does and why it matters, agree on the approach, then build and test it together.

Ghost of Developers Past: we build together, then test the behavior

You

Slow down, I'm not like everyone. When you are working with me and WE are building a project together, that means WE build it. I understand that an agent's purpose and design is to pretty much do everything with minimal assistance from the user, but that's not me. I like working everything step-by-step, in modular components and everything is discussed before executing line or block and explained what it is, what it does, why we need it and how it benefits the user or project. This how I have learned a lot of my programming skills, honestly, more than I learned in half of my college courses. Plus, there is nothing worse than spiting out 100s of lines of code and repeatedly having to rewrite it over and over again because you didn't explain what the code does and what to expect, and the user may not give a clear picture of what they want but there is always something they don't like in each rewrite. That's why I believe in discussing before implementation and asking questions to clarify when there is uncertainty.

Show more

Agent

You’re right—I moved into execution before we had discussed the build. I’m sorry. We’re building this together, and the learning process is part of the project.

From here, we’ll work one small component at a time:

1. Discuss its purpose and what you want it to do.
2. Explain the proposed code or command—what it does, why we need it, and how it benefits the project.
3. Clarify uncertainties and agree on the approach before execution.
4. Build and test that small piece together, discussing what to expect and what happened before moving on.

I won’t treat agreement on the project idea as permission to implement the whole thing.

The tool call you interrupted was intended to inspect files and read guidance; it contained no file edits or installation commands. I haven’t written project code.

Our first discussion should be about the experience itself: when you start a workshop, what would you want the companion to show or do first? We can settle that before choosing tools or writing code.

Show more

2 messages (range 0-1) of 7 total

Part 2: Turning requirements into behavior

The next excerpt jumps forward to this workbench. I specify the Gemma retry limit, the Grok backup, and asking me for missing information. The first check falls short, and we correct the behavior before moving on.

Ghost of Developers Past: we build together, then test the behavior

You

I'm ok with his response and being the backup. We will create a rule that if gemma times out and doesn't work after 2 retries than Grok will be used and shut off after use. Also, it should be included that if the model needs more information to complete the restart plan, like maybe the 3 questions it asks at the bottom, that it gets the missing info from the user and does not fabricate it.

Agent

I’ll make “two retries” mean the first Gemma attempt plus two more attempts, then one Grok fallback. Each new request will start with Gemma again.

I’ll also strengthen the missing-information rule and make the response box clearly support answering follow-up questions. The assistant should ask for essential details, use your answers in the next version, and leave unknown facts unknown.

Agent

The two retries will stay inside the existing three-minute retry window, with shorter Gemma timeouts so there’s time left for Grok to answer.

I’m also opening the answer/feedback box below each response. You’ll be able to answer the assistant’s questions and click Update restart plan; those answers will stay attached to that project and version history.

Agent

The first live check did ask for missing hosting details, but it also jumped ahead with a web-conversion suggestion. I’ve saved that response unchanged.

I’m tightening the rule so changes that depend on unanswered questions stay pending. The assistant can still suggest work supported by the supplied files.

Agent

The updated checks pass: 75 Python tests and 9 JavaScript tests. The timeout test confirms three Gemma attempts, one Grok response, then Gemma again on the next request.

The live question check now leaves hosting decisions pending and asks for the platform, runtime restrictions, and budget. I’m starting the local workbench with the approved backup enabled.

5 messages (range 2-6) of 7 total

These are selected original messages; intervening conversation is omitted. The test counts in the excerpt reflect that stage of development.

How I Built It

I built the workbench with Python, Flask, browser JavaScript, Gemma, ElevenLabs, and Render. I worked with Codex one component at a time, discussing the behavior, testing it, and reviewing model responses before deciding on feedback.

The responsibilities are deliberately clear:

Component	What it does
Python file reader	Prepares a bounded, read-only snapshot, excludes common credential/generated files, and numbers source lines.
Gemma	Interprets the supplied project evidence and the developer's goal, then writes the explanation and restart plan.
Source viewer	Connects references to files and exact line ranges so the developer can inspect the evidence.
ElevenLabs	Transcribes spoken goals and generates narration of the selected response.
Render	Hosts the Flask application and browser interface over HTTPS.

The primary model is Gemma 4 26B A4B IT, served through Google Cloud's managed API. The shared model-rules file requires evidence-backed findings, setup/startup cross-checks, and questions when essential information is missing. The developer's answers remain in context for later revisions, and previous response versions stay available.

For temporary service failures, the app allows an initial Gemma attempt and two retries. An enabled Grok backup gets one attempt within the same overall time budget. Its use is identified in the interface, and the next operation starts with Gemma again.

The application checks whether reference locations exist. A person still needs to judge whether those lines support the model's claim. That distinction is part of why the source viewer matters.

Testing beyond the small example

The small example was useful, but I also tested a past project where I knew what was and was not finished. I spoke my goal, the transcription needed no editing, and Gemma's response was on point for that project.

That larger test also exposed an export bug. Some files ended with extra blank lines. When the export code reconstructed the numbered source, it lost a final empty line and rejected its own line count. Preserving that line fixed both download formats:

content_lines = [line.split(": ", 1)[1] for line in lines]
text = "\n".join(content_lines)
if content_lines and content_lines[-1] == "":
    text += "\n"

The current automated suite has 106 passing checks, with Linux verification through GitHub Actions. Live tests covered Gemma generation, source highlighting, ElevenLabs narration, Markdown/PDF exports, and clearing a test workspace. I also verified spoken-goal transcription in my browser.

Keeping the workspace temporary

Users review their selection before cloud analysis. Common credential files and generated folders are excluded, and recognizable credential-like values are redacted. That filtering needs human review; it cannot identify every possible secret.

The snapshot is limited to 40 text files, so larger projects receive a partial review. Project text, response versions, and cached narration stay in server memory. Clear session removes the current workspace and returns the browser to the starting screen. It leaves original files and downloaded plans untouched.

The demo uses cloud services. Clearing our app's session does not recall requests already sent to those providers. Saved plans also matter because a server restart clears temporary workspaces.

Why Does Open Innovation Matter?

Gemma is the model doing the project interpretation and writing at the core of this tool. Its open weights give this project a path to hosting the model elsewhere, including exploring local deployment, as the workbench develops.

For this version, I chose managed cloud inference so the demo could run without requiring visitors to download a model or my laptop to serve one. I have not fine-tuned Gemma, and this deployed version requires an internet connection.

What matters to me is being able to inspect and change how the assistant works: the evidence it receives, the rules it follows, how feedback is incorporated, and how its conclusions connect back to source files. The application code is open, the shared instructions are in the repository, and the original project stays under the developer's control.

Open weights provide deployment options beyond one hosted model API. Open application code makes the workbench itself something another developer can inspect, adapt, and continue.

The Spirit of It

The moment this project landed for me was recognizing my own unfinished project in the response. I knew that code, so I could judge whether the explanation helped.

Being able to speak my goal and then follow the source links made returning feel manageable. I could take one step, check the evidence, and decide what came next.

That is the experience I wanted to build around this week's theme: recovering the context behind past work and giving it a practical next chapter.

Recover the context. Follow the evidence. Move forward at your own pace.

Prize Categories

• Best Use of Gemma: Gemma is the primary model interpreting the reviewed project snapshot and writing source-linked restart plans through Google Cloud.
• Best Use of ElevenLabs: Speech-to-text turns spoken goals into editable text; text-to-speech reads the selected response aloud.
• Best Use of Render: The deployed Flask application, interactive workbench, exports, and voice endpoints are hosted on Render.

Two useful DEV discussions during development were System Prompts Define Instructions. Factual Evaluation Needs Evidence. by Shashank Agarwal, and The logout loop nobody tests: treating session cleanup as a security feature by @kamrankhandev. They reinforced checking the evidence and testing cleanup across the server and browser.

AI assistance disclosure: I built this project step by step with Codex as a coding collaborator. I used DevRelay to research challenge requirements and relevant DEV discussions, manage this submission draft, and save the curated agent-session excerpts embedded in this post. This write-up was prepared with AI assistance and reviewed by me.