DEV Community: dipak agrahari

DEADNET: a murder mystery on a dead friend's old computer

dipak agrahari — Thu, 29 Oct 2026 19:07:46 +0000

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

What I Built

DEADNET is a short murder mystery that takes place on a dead woman's computer.

Nora Vale died in her room on Halloween night, 1999. The police called it an accident. You play Adam, her friend. Her neighbour Mara leaves you Nora's old computer with a note asking you to take a look before it's collected.

The computer is a late-90s desktop with ordinary apps: Messenger, Mail, Photos, a Calendar, My Computer, a Trash Bin and a few games. You insert a recovery USB, hear it boot, and start opening things. The clues are in her conversations, emails and photo captions. You learn what happened by noticing where people's stories don't line up.

The day before she died, Nora was making fun of Mara for cooking enough soup for twelve people. “she owns two bowls adam.” Her calendar still has dinner at Mara's in it. Bring bread. Stay for once.

Her last conversation in Messenger is with you. You didn't answer it in time.

Then her account comes back online, in a window called Unknown Signal. You can talk to her and show her what you've found. She's played by an open-weight model, and she only knows what you've shown her, so she can't just tell you the answer.

When you think you've worked it out, you open the Casebook on your recovery USB and answer three questions: who came into the room, why, and how they got in. A wrong answer doesn't end the game. It just tells you something doesn't fit.

Demo

Play it in your browser. It takes about 15 minutes. Each visitor gets their own copy of the case, and progress saves automatically. If nobody has played for a while, the first load can take up to a minute while the server starts.

One thread to pull

Start with Mail → “Home, somehow.”, sent by Len at 03:07 on Halloween morning:

Made the 2:58 by about six seconds. Ticket machine’s broken, so the driver wrote one out by hand. Kept it. First thing I’ve won all week.

I’m home. It’s raining through my kitchen window again. Tell Mara I’ll look at her heater Monday.

It sounds like someone getting home from a miserable shift. Then you read management's statement, which puts Len on the third floor at 03:17. Both accounts can't be right.

Save the email to your USB Casebook, then attach it in Unknown Signal. You can ask Nora what she remembers about Len leaving. Her next reply is generated from the conversation and the evidence she's actually seen; opening an email on your own doesn't give her that knowledge.

The next connection is yours to make. A photo caption records someone borrowing an office spare. Nora's last chat explains what she had found and who wanted to speak to her. Together, the records give you a timeline, a way into the room, and a reason for the visit.

In the Casebook, choose a person, a motive and a way in. If you name the wrong person, the game sends you back to the contradiction:

that doesn’t fit what you found. who asked to come to my room? and who had already gone home?

You can reopen the records and revise your theory without restarting. You don't need to win a mini-game to finish; those are simply games Nora kept on her computer.

Code

sea-deep / deadnet

A murder mystery on a dead friend's 1999 computer. Investigate her messages, confront an AI ghost, and solve Room 317.

DEADNET — Room 317

Mara gives you her dead friend’s computer. You are Adam Moore. The last message Nora sent was to you.

Insert your recovery USB, turn on the computer, and look through Nora’s Messenger, mail, photos and calendar. Get to know the person who lived here. When her account signs in again, show her what you find. Her memory is uncertain; the things she left behind can contradict it.

Play online · The story behind it (DEV) · Source · Scripted static exhibition · Credits and licenses

Run

Node 22.13+ and npm:

npm ci
cp .env.example .env
npm run dev

Open http://127.0.0.1:3000. Insert the USB, then power on. The computer fills the browser; the tray also offers browser fullscreen. Windows drag, resize, minimize and maximize. On phones, a single tap opens an app and each window fills the available space.

For live dialogue, add OPENROUTER_API_KEY to the…

View on GitHub

MIT licensed. Borrowed code, fonts, images and sounds are credited in CREDITS.

How I Built It

The desktop is React with 98.css. A small Node server stores each player's case and talks to the model, so no API keys reach the browser.

The main design decision was splitting what's fixed from what's live:

Fixed: the evidence and the solution. Every player gets the same messages, timestamps and photos, and the same answer.
Live: the characters. The model decides what Nora remembers, how sure she is and what she asks you.

I did this because language models are good at sounding unsure and bad at keeping facts straight. If the model could change the evidence, it could also accidentally solve the case for you, or make it unsolvable.

So each character only sees what they've actually been shown. Replies come back in a fixed format and get checked before they're saved. A reply that cites an invented or unwitnessed evidence ID is rejected. Dialogue can still be mistaken, but it cannot create a collectable clue, change the evidence or decide whether your theory wins.

The clue Nora shouldn't know yet

One bug made that distinction concrete. The photograph looked harmless in the UI, but its model-facing description also explained the motive from a different conversation. Show Nora the key photo, and the prompt had already handed her an answer you hadn't discovered together.

The fix was in the information I gave her:

Before: the photograph's description established access and explained why someone wanted to silence Nora.
After: the photograph establishes access. The motive has to come from the separate conversation.

I also removed a later memory hint that named the key's owner before Nora had seen the photo caption. The tests now check all eight combinations of the three items she can have seen. Showing her one item must not quietly give her the other two.

That changed how I thought about the ghost. Her uncertainty needs a reason. She is piecing the night together with you, and each thing you show her changes what she can say.

The model. The browser version now uses Gemma 4 31B through OpenRouter, pinned to google/gemma-4-31b-it:free. It runs on a hosted provider, not inside your browser. The local option is Gemma 4 E2B through Ollama. Both use the same character prompts and evidence rules; System Monitor records the actual model and request trace.

Making it feel like someone's computer

My first version was a file hunt: log files, a damaged backup you had to unlock, and at one point you had to play mini-games to recover it. It worked, but it felt like an escape room rather than someone's computer. I rebuilt it around chats with friends, emails, a photo album and a calendar.

That gave the ordinary messages a job, too. An earlier chat has Nora complaining that Adam's bat game ate her evening when she was supposed to be packing. She says she's finally moving in November, somewhere with a window that opens. Later, you're reading that conversation knowing she never got to move.

The same desktop can tell you she was funny, she was planning a future, and somebody's account of her last night is wrong. I wanted the player to notice all three.

Hosting. It runs on Render. Each browser gets its own private case, so players never see each other's conversations. The game autosaves, and you can save to a file, load it back or start over from the Start menu. If the free model is busy, it tells you and lets you explicitly switch to labelled scripted replies. It never silently replaces a failed live response. Requests are capped at eight per visitor and thirty globally per day, with burst limits and cooldowns; resetting the case doesn't reset the allowance.

There's also one voice clip: Nora's last voicemail, recorded with ElevenLabs' premade Lily voice, hushed and hurried. She warns Adam not to come through the lobby and says Len wasn't in the building. It's something to compare with the email and management's statement, rather than a narrator explaining the solution.

The clip is cached, so replaying it doesn't generate more audio. There's a transcript next to it. Voice, model, transcript and delivery settings identify the cache entry; concurrent playback requests share a single render. The existing render record documents one generation taking 1.927 seconds; replay used the saved audio.

Following Nora's reply with Sentry. After finding the premature clue, I wanted to see the boundary around a whole turn: which evidence is available, when the model runs, whether the reply passes validation, and what gets saved. Each turn now has a Sentry agent trace with those steps underneath it. Live model spans record the provider, model and token counts. Players' messages, prompts and replies stay out of the telemetry.

One verification gives Nora an invalid reply that tries to contact Mara from the private signal. The validator rejects it and the root trace is marked rejected; Nora's private message never reaches another resident. Here is the actual Sentry trace, captured in Safari:

This capture uses a deterministic fixture in Sentry's verification environment. It checks the guard and the tracing, rather than measuring hosted Gemma's speed. Trace record and screenshots.

Checking the case. There are 40 Node tests for knowledge boundaries, invented evidence, wrong theories, the ending, saves, request limits, the audio cache and telemetry privacy. Another 38 browser scenarios cover desktop and phone layouts, including a complete investigation with a wrong accusation and recovery. They use fixtures, so these checks don't spend model or voice credits. Verification.

The GitHub Actions checks run the tests, typecheck, both builds and the browser scenarios on every push. A second workflow deploys the scripted exhibition to GitHub Pages. That makes a broken desktop or ending a failing build, rather than something a judge has to find.

Why Does Open Innovation Matter?

It keeps the game playable. The story is about a computer that keeps answering after its owner is gone. With open-weight models, Nora doesn't depend on one company keeping one model available. The prompts and rules are in the repo, and any compatible open model can play her.

It can run privately. You can run the whole thing locally with Gemma through Ollama, so your conversations never leave your machine.

It's free to play. The hosted version uses a free Gemma route with a small daily request budget to protect the account. Running Gemma locally removes that shared API allowance; there is no per-message provider charge.

The most useful lesson was learning where to put the model. It brings a voice to the conversation; the code keeps track of what happened and what each character has seen. That division is small enough to inspect, test and change with another open model.

The Spirit of It

Mara keeps writing to Nora after she's gone. There's a scarf on her chair, a dinner in the calendar, and a deleted letter in which Nora almost says yes to a new flat. Before you have a suspect, you have the shape of a life that was supposed to continue.

Halloween is the night that life stops. On November 2, you're sitting at the computer with everything she left behind. You can put a name on what happened. You can't get back to 03:14 and answer her in time.

The ending, if you'd like to see where the investigation leads

After a supported report, Mara writes: “i printed her name properly this time. NORA VALE. not ‘the woman in 317’.” Nora hears the rain again, and the line goes quiet.

My Agent Session

I used Entire to capture the actual Codex session behind the evidence fix. The checkpoint links the conversation and tool work to the implementation commit.

The session excerpt includes the edit that removed the premature clue and the test results that followed. It was exported from checkpoint 01M682MCRY0YFDMAADPPK7ETN8; private setup and internal reasoning are omitted. The native checkpoint stays local, and the public excerpt can be read without an account. Entire setup and capture details.

DEADNET: the clue Nora should not know yet

You

make sure to integrate the entire sponsor category hahaha since i have used codex u should be able to do it all yourself

Agent

I’ll integrate Entire and check that it captures a real Codex session linked to a commit. I’ll also review the new brief and update the submission materials, without spending AI or voice credits.

Agent

The README already describes the murder mystery. The main gap is that the hosted app uses a generic free-model router, which doesn’t guarantee Gemma. I’ll pin it to a free Gemma route and add tests for the evidence boundaries.

I’m using the challenge rules skills to check the submission requirements. Entire’s category specifically asks for agent work shared in the write-up, so I’ll produce a linked session alongside the setup.

Agent

Entire is installed and configured for Codex. I’ll attach this existing session to the changes using Entire’s supported command, since the session started before its hooks were installed. Raw transcripts will stay local; the submission will link to a reviewed excerpt.

I also found a spoiler leak: the spare-key evidence described the motive even before Nora had seen the final chat. I’m separating those facts and adding a regression test.

Agent

▸ apply_patch *** Begin Patch *** Update File: server/seed.ts @@ - fact: "Nora’s October...

Input

*** Begin Patch
*** Update File: server/seed.ts
@@
-    fact: "Nora’s October 28 photo caption says she borrowed Owen Keene’s office spare to get back into her room after locking herself out. The pictured brass key and the caption establish that the manager had a way into her room. Combined with Nora’s final conversation, this establishes Owen’s access and motive to silence her about the forged fire inspections. The image alone does not identify an owner; the ownership is in Nora’s caption.",
+    fact: "Nora’s October 28 photo caption says she borrowed Owen Keene’s office spare to get back into her room after locking herself out. The pictured brass key and the caption establish that the manager had a way into her room. The image alone does not identify an owner; the ownership is in Nora’s caption. This photograph does not establish a motive or what happened on Halloween night.",
*** Update File: server/model.ts
@@
-                      "A brass key scraping your desk. You did not open the door. Once shown the photo caption, you recognize the spare from Owen’s office, not Len’s red staff key.",
+                      "A key scraping your desk. You did not open the door. You cannot place its owner or connect it to a photograph you have not been shown.",
*** End Patch

Output

{}

Agent

The 39 offline tests pass, including the new evidence checks and pinned Gemma request. I’ve corrected the GitHub description and drafted the stronger DEV entry with a complete investigation walkthrough, voicemail explanation and Entire section. The full desktop and phone checks are still running.

Agent

▸ exec_command npm run test:e2e

Input

$ npm run test:e2e

Output

38 passed (1.6m)

Agent

▸ exec_command npm test

Input

$ npm test

Output

✔ every Nora evidence subset scopes both prompt records and decoding to witnessed items (1.29525ms)
✔ a late ungrounded memory does not reveal whose key Nora heard (0.715958ms)
✔ invented prose cannot create case evidence, change the solution, or satisfy report prerequisites (0.40825ms)
✔ hosted default is a pinned free Gemma route, with no router or paid fallback (13.893458ms)
ℹ tests 39
ℹ pass 39
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0

Agent

All 38 desktop and phone scenarios pass, including finding evidence, showing it to Nora, revising a wrong theory and reaching the ending. Both builds pass too.

I’m now linking the real Codex session to the implementation commit and preparing the public excerpt for the Entire category.

Prize Categories

Best Use of Render: the game is hosted on Render as a web service, with a private case per visitor, automatic saving, and API keys kept on the server.
Best Use of Gemma: Gemma drives the characters through the pinned OpenRouter route online, or through Ollama for private local play.
Best Use of ElevenLabs: Nora's last voicemail, an important clue, is an ElevenLabs recording, cached and shown with a transcript.
Best Use of Entire: the actual Codex development session is linked to its commit, with the debugging edit and test output shared above.
Best Use of Sentry Agent Tracing: evidence scoping, model execution, reply validation and persistence are traced together; the verification capture shows a rejected private reply, and tests check that telemetry excludes conversation text and credentials.
Best Use of GitHub Copilot: entered through the challenge's GitHub Actions route. The existing workflows test and build the game, check the complete browser investigation, and deploy the scripted exhibition.

All characters and events are fictional. I used AI coding assistants while building DEADNET and while writing this post.

The answer was already in another thread, so I built ThreadSherpa

dipak agrahari — Fri, 23 Oct 2026 18:10:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I got the idea from the MLH Discord.

People kept asking about account names, missing offer codes and student benefits. Different people, same questions. The useful answer was usually already there, buried in another thread, and a moderator had to go find it and type it out again.

ThreadSherpa is a Discord support bot that remembers the answer so the moderator doesn't have to. A moderator replies normally, right-clicks their message and picks Apps → Save this answer. That one click is the approval. The next time someone asks the same thing in different words, ThreadSherpa writes a fresh reply for that person from the saved facts and links back to the original.

The part I care about most: when the saved answers don't cover a question, ThreadSherpa says nothing. No "I'm not sure, maybe try…", no guessing. The question goes into a quiet moderator queue instead. A small open model is only as good as what you give it, so ThreadSherpa only gives it facts a human already approved, and stays out of the way otherwise.

Demo

Try it in your browser · Website and walkthrough · Setup guide

The /try/ sandbox is a fictional community where you can save a moderator's reply, ask a new question and watch it answered, all in your browser with no Discord server needed.

Below is a real run in my test server, with separate moderator and participant accounts, on a Minecraft support question: which version can join the server?

The moderator answers and saves the reply:

Later, a participant describes the same problem in completely different words, an "Outdated client" error. ThreadSherpa answers on its own, tells them which version to pick, and links to the moderator's original guidance:

Paper Instruments' Ultramarine wrote this reply and MongoDB Atlas stored the saved answer. The exact same flow also runs fully local on Gemma 4 through Ollama.

Code

sea-deep / threadsherpa

A Discord support bot that saves moderator answers and writes short, sourced replies for repeat questions.

Built solo, Apache-2.0 licensed. There's also a GitLab mirror.

How I Built It

TypeScript and discord.js. Saved answers, versions, support cases and evidence live in MongoDB Atlas. Models plug in through one provider interface, with two first-class options: Gemma 4 (gemma4:e4b-it-qat) running locally through Ollama, or Paper Instruments' Ultramarine through its API. EmbeddingGemma handles embeddings locally either way.

Moderator saves a reply
  → keep their exact wording, check for duplicates, store it in Atlas

New forum question + thread context
  → retrieve this server's current answers (exact, keyword and vector match)
  → give only that evidence to the model
  → check every citation and link in the draft
  → reply in the thread, or queue it quietly for a moderator

Retrieval combines exact matching, keyword search and embeddings, ranked with Atlas Vector Search. Every server has its own memory, so one community's answers never leak into another's.

Saving keeps the human's words; answering is a separate job

My first version stuffed titles, review details, versions and labels around a two-line answer, and pasted old messages back almost verbatim. It felt like a filing cabinet, not a helper.

So I split the two jobs. Saving stores the moderator's wording exactly as written. In the learning pipeline that's simply:

canonical_answer: options.adminMessage,

Generation happens later, with the new question and its thread in front of the model, so each reply fits the person asking. Saving the same answer twice reuses the existing entry.

Staying quiet is a feature

During testing the bot posted "I couldn't check this. A moderator can help." under a question a moderator had already answered. It added noise and helped nobody.

Now a queued result sends nothing. The Discord handler only posts when it has something useful:

if (result.policyResult.action !== 'queue') {
  await thread.send(await this.card(c.case_id));
}

A few other guardrails sit around that:

Narrow answers ask first. If a saved answer only applies under certain conditions, ThreadSherpa asks a clarifying question instead of guessing.
Account actions go to humans. Sensitive requests are routed to moderators, never answered by the model.
No open web search. Besides saved answers, the bot can only read documentation URLs a moderator explicitly adds with /sources, fetched through an SSRF-safe fetcher.

It learns from how the conversation ends

Each reply comes with Solved and Need help buttons, and the bot also reads plain follow-ups. "That worked" closes the case. "That didn't help" hands it to a moderator and adds the failed advice to the context, so the bot doesn't keep suggesting the same fix.

Moderators stay in control

Three autonomy modes, picked in /setup:

Quiet: record new posts, no replies. Good for a trial week.
On request: reply only to /ask and follow-ups.
Automatic: answer new support questions on its own.

And a set of moderator tools:

Command	What it does
`/memory`	Private panel to search, add, edit, expire or remove saved answers, and import FAQs
`/teach`	Save knowledge when there's no existing message to save
`/answers`	Find or remove saved guidance
`/queue`	See waiting questions, grouped so repeated gaps stand out
`/sources`	Manage the documentation URLs the bot is allowed to read
`/stats`	Questions, confirmed solves and handoffs
`/ask`	Ask explicitly instead of waiting for an automatic reply

The /memory panel is visible only to the moderator using it:

Already have a FAQ? Import FAQs takes pasted Markdown, shows a preview, and saves it in one go, skipping duplicates:

## Can I submit by myself?
Yes, solo projects are fine.

## Do I need a video?
A video is optional.

Answers can have a source, conditions and an expiry date. Expired answers stay visible in the panel for review but stop being used in replies, so last month's deadline never gets quoted as this month's.

/queue is also where the lazy loop closes: if the same unanswered question shows up five times, the moderator sees it grouped together, answers once, saves it, and it's handled from then on.

Testing

140 automated tests cover routing, approval, duplicate saves, expiry, source checks, FAQ import and panel permissions, and run on every push through GitHub Actions.
12 support scenarios (paraphrases, a different event with a similar name, expired guidance and a correction) passed on both local Gemma and Ultramarine. Reproduce them with npm run eval:local or npm run eval:paper.
Atlas was checked for persistence across processes, real vector queries and per-server isolation with npm run verify:atlas.
npm run demo runs the whole flow on fixtures, with no Discord and no paid inference.

The Ultramarine eval made 10 generation calls (5,408 input and 1,109 output tokens) for about $0.0014 at the 23 October rates, roughly a hundredth of a cent per generated reply.

Tracing every answer with Sentry

Every answer runs inside a Sentry agent trace. Each support.answer agent span contains the tool.search_knowledge tool call that finds the saved answers, then the GroundedAnswerDraft model call and the HTTP request behind it. Embedding calls get their own spans too. Model spans record the model name and input and output token counts; message text and prompts are never sent, only numbers.

On a traced Ultramarine eval run, each reply used 506–588 input and 50–176 output tokens, and the model call took 1.1–3.2 seconds. Knowledge search took under a millisecond and local embeddings a few milliseconds, so almost all of the answer time is the model writing. The trace showed something else useful: some questions the bot shouldn't answer stop right after the search, without calling the model at all, so those declines cost no tokens.

Set SENTRY_DSN and both the bot and npm run eval send these traces.

Why Does Open Innovation Matter?

A community's support knowledge stays with the community. Moderator answers often touch account names, offer codes and other things members don't want shared. With Gemma running through Ollama, generation and embeddings happen on the machine the operator controls, and no third-party model provider ever sees them.

It's cheap enough for volunteers. Most Discord communities are run by volunteers, and a support bot with a big bill is a bot nobody keeps switched on. On local Gemma, one more answer costs nothing extra. On Ultramarine, the whole eval run cost about a seventh of a cent.

Moderators can see and change everything. The prompts, retrieval and policy rules are all in the repo. If a community wants a stricter bot, a friendlier tone or a different model, they change a config value or a prompt, not a vendor contract.

Open models make the choice the community's. Because both Gemma and Ultramarine are open models (Paper has announced Ultramarine's weights), a community isn't locked in. Run Gemma on a spare laptop for full privacy, use Ultramarine through the API for stronger writing at a tiny cost, or self-host Ultramarine once its weights are out. I swapped between the two without touching any of the saving, retrieval or Discord code. The community owns its knowledge and picks where its model runs.

The Lazy Payoff

Before: a moderator sees a question, remembers answering it last week, scrolls through old threads, finds it, and types it out again. Then does the same thing tomorrow.

After: the moderator answers once and clicks Save this answer. Every future version of that question, in whatever words, gets a tailored reply with a source, while the moderator is asleep. Questions the bot can't answer wait quietly in /queue until someone has time.

That's the sloth approach: do the work once, properly, and let it keep paying off.

Prize Categories

Best Use of Gemma: Gemma 4 through Ollama is the default reply model and handles duplicate comparisons, with EmbeddingGemma for local retrieval embeddings. It passed the full scenario suite locally.
Best Use of MongoDB Atlas: Atlas holds saved answers, versions, cases and evidence, scoped per server, with Atlas Vector Search ranking retrieval candidates. Persistence and real vector queries are verified by npm run verify:atlas.
Best Use of Ultramarine: Ultramarine wrote the replies in the Discord demo above, working only from the moderator-approved evidence, and passed the full scenario suite. The eval run cost about $0.0014 for 10 generations, broken down above.
Best Use of Render: Render hosts ThreadSherpa's front end at threadsherpa.onrender.com, including the interactive /try/ sandbox where anyone can run the save → ask → reply loop, deployed from the repo's render.yaml Blueprint. The repo also ships a background-worker Blueprint that runs the Discord bot itself on Render, preconfigured for Ultramarine or a Gemma endpoint.
Best Use of Sentry Agent Tracing: every answer is a Sentry agent trace with tool, model and HTTP spans, plus token counts and latency per model call. The trace screenshot and the numbers are in the tracing section above.
Best Use of GitHub Copilot: the Checks workflow in GitHub Actions type-checks, tests and builds the bot, verifies the fixture flow, and checks and builds the website on every push.

I used AI coding assistants while building ThreadSherpa and while writing this post.

GitQuest: Visual Interactive Git DAG Simulator & Adventure Game

dipak agrahari — Mon, 12 Oct 2026 20:27:53 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Git can be overwhelming when you're just starting out. You run commands like git commit, git branch, or git merge, but what actually happens behind the scenes remains invisible. What is HEAD? How do branches point to commits? Why do merge conflicts happen?

I built GitQuest, an interactive visual simulator and puzzle adventure that teaches version control from absolute zero.

Instead of throwing users into an abstract command line, GitQuest pairs a live Git repository directly with a tactile 2D arcade world. Players configure files, stage changes (git add), save checkpoints (git commit), create branches, resolve 3-way merge conflicts, and push to remotes. Every single operation immediately updates the live commit graph, file staging areas, .git internals, and physically powers conduits and bridges for a runner to reach the goal.

Who Would Pay For It?

Engineering Bootcamps & CS Universities: Onboarding cohorts onto Git is notoriously painful and consumes hours of mentor time. A structured, self-paced visual simulator replaces static slide decks with interactive verification.
Developer Training & Corporate Onboarding: Engineering teams onboarding junior developers or career switchers can license interactive sandboxes to evaluate practical Git proficiency without breaking company repos.
Individual Developers (Freemium/Pro): Self-paced learners who want guided interactive mastery of advanced Git scenarios (interactive rebasing, cherry-picking, complex merge conflict triage).

Demo

Play Live in Browser: https://gitquest-five.vercel.app
Local Run: Run GitQuest locally in seconds:

git clone https://gitlab.com/wdipak/gitquest.git
cd gitquest
npm install
npm run dev

Visual Preview

Code

GitLab: https://gitlab.com/wdipak/gitquest

The project is fully open source under the MIT License, built with React, TypeScript, Vite, Tailwind CSS, and Web Audio API for interactive audio feedback.

How I Built It

GitQuest is built around a custom client-side Git virtual machine and world engine:

From-Scratch Virtual Workspace: Implements a sandboxed virtual filesystem supporting mkdir, cd, touch, echo, and file inspection.
Pure JavaScript Git State Engine: Models Git's true object model (blobs, trees, commits) along with references (refs/heads/*, refs/remotes/*, and HEAD).
3 Dynamic Views:
1. Commit Map: Real-time visual graph of all commits, branch pointers, and HEAD movements.
2. File Stages: Visualizes file flow across Working Directory -> Staging Area -> Local Repo -> Remotes.
3. Behind the Scenes (.git): Interactive inspection of .git/HEAD, .git/refs, and simulated object trees.
Tactile Puzzle Progression: A 2D interactive arcade scene where versioned configuration files directly power bridges, gates, and runner routes, paired with multi-level hint systems and fair move-budget scoring.
6 Campaign Missions + Free Play Sandbox: From basic commits to branching, 3-way merging, remote synchronization, conflict resolution, and an open sandbox.

Why Does Open Innovation Matter?

Open innovation is what made Git the foundation of modern software engineering, and it is essential for developer education tools:

Zero Walled Gardens: Anyone can run GitQuest locally, fork it, and add custom curricula or level packs without recurring subscription lock-in or proprietary cloud dependencies.
Transparent Learning: Because the entire simulation engine is open source and client-side, learners can open developer tools to inspect exactly how the virtual Git engine computes graph nodes and commits.
Multi-Forge Neutrality: Real-world software happens across open platforms. Open tooling ensures learners aren't locked into a single proprietary vendor.

Prize Categories

Best Use of a .tech Domain