DEV Community: Kunal Kashyap

👻 Haunted Terminal

Kunal Kashyap — Sun, 01 Nov 2026 00:25:38 +0000

The Process Was Terminated. So Why Is It Still Running? 👻

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

What I Built

What if a computer remembered someone who no longer existed?

And what if the thing answering your questions wasn't quite that person?

Meet Haunted Terminal — Infrastructure #674, an interactive, AI-powered horror experience built around an abandoned machine, a forgotten memory-preservation experiment, and an entity reconstructed from fragments of someone's past.

The experience begins with an unsettling discovery:

The process was terminated. So why is it still running?

You enter a fictional CRT workstation. Something is consuming memory, but its start time, executable, and owner are missing. System records contradict one another. An operator's identity has been deleted. Somewhere inside the archive, something is waiting to be questioned.

Your job is to investigate.

But this isn't a conventional chatbot where you type anything and receive a spooky response. You must recover evidence, follow the trail of an abandoned experiment, and gradually uncover what the machine has retained.

The investigation uses commands such as:

scan — recover the unknown-process anomaly.
logs — investigate the shutdown warning.
investigate — examine the deleted operator identity.
reconstruct — uncover contradictory experiment records.
whisper — invite the entity to speak.
ask <text> — question the entity.
reveal — restore the final memory and reach the decision.

Eventually, you must choose what happens to the process:

TERMINATE: Shut it down.
PRESERVE: Keep the archive alive.
RELEASE: Unlock a hidden ending by recovering an additional memory fragment.

There are three endings, and the hidden one requires discovering evidence that isn't necessary for the other two.

My interpretation of Ghost in the Machine

I didn't want to make another horror chatbot that simply generates creepy sentences.

I wanted to explore a more uncomfortable question:

If a machine can reproduce someone's memories, their words, and fragments of their personality, does that mean the person is still there?

The entity in Infrastructure #674 is not presented as a confirmed human consciousness. It is a reconstruction built from incomplete records. It remembers fragments, misunderstands others, and gradually becomes aware of the contradictions surrounding its existence.

The horror comes from not knowing whether you're speaking to a person, a simulation, or something that has developed an identity of its own.

The terminal is entirely fictional. It does not execute commands on the player's operating system or inspect their actual files or processes. The investigation takes place inside the game's own environment.

Demo

Repository: Haunted Terminal — GitHub

There is no publicly hosted version because the project is designed to run locally, with the frontend, backend, SQLite database, and Ollama model on the same machine.

You can explore the source code and follow the local setup instructions in the repository.

Code

Explore the complete source code on GitHub

The project is organized into two applications:

apps/web — React frontend and terminal interface.
apps/api — Express API, story engine, Ollama integration, and persistence.

The repository contains the complete implementation, database schema, Prisma migrations, environment examples, and setup instructions.

How I Built It

The most important architectural decision was separating what the game knows from what the entity says.

I didn't want an LLM to decide whether a clue existed, whether the player had completed an investigation, or which ending should be unlocked.

An LLM can generate convincing dialogue, but it can also hallucinate, contradict previous events, or confidently reveal information that the player hasn't discovered.

That would destroy the mystery.

So I built Haunted Terminal around two separate systems.

1. Deterministic story engine

The backend owns the actual game.

It handles:

Command validation.
Clue discovery and prerequisite checks.
Investigation progression.
Session state.
Ending conditions.
Persistence of terminal events.

The investigation follows a controlled sequence:

scan → logs → investigate → reconstruct → reveal

The first four core clues are required to reach the final decision. The optional recover command discovers an additional memory fragment required for the hidden release ending.

This means the player cannot simply ask the AI to reveal the ending or skip the investigation.

2. Local AI entity

For the conversational entity, I used Qwen 2.5 3B, served locally through Ollama.

The model is responsible for the entity's dialogue when the player uses whisper or ask.

The API supplies the model with:

The entity's character instructions.
Its current awareness stage.
The evidence recovered by the player.
Up to eight recent conversation messages.

The entity progresses through three awareness stages:

Stage	Trigger	Behaviour
`DORMANT`	Fewer than two core clues	Barely aware, cautious, and uncertain
`AWARE`	At least two clues	Recognizes recovered records but cannot resolve every mystery
`EXPOSED`	At least four clues	Understands the contradictions and reacts more personally

The model is instructed not to invent undiscovered clues, claim to inspect the player's real computer, or present uncertain information as established fact.

Generated responses are also constrained in length and sanitized before being returned to the terminal.

The distinction matters: the story engine determines what happens. The model determines how the entity communicates about it.

3. Persistence and session restoration

I used SQLite with Prisma 7 and the Better SQLite3 adapter.

The database stores four kinds of information:

Session — session status, ending, and timestamps.
DiscoveredClue — evidence recovered during the investigation.
ConversationMessage — player and entity messages.
TerminalEvent — commands and rendered events used to restore the interface.

A UUID identifies each session. The frontend stores that identifier in localStorage, allowing the application to retrieve the saved investigation after a page refresh.

4. The interface and atmosphere

The frontend uses React 19 and Vite 8, with Tailwind CSS v4 and custom CSS.

I wanted the interface to feel like an abandoned workstation rather than a modern chat application.

Some of the details include:

A CRT-inspired terminal interface.
Phosphor-green styling and restrained warning colors.
A visual keyboard with physical key feedback.
Subtle animated entity eyes.
Two looping ambient horror audio layers.
Audio playback that begins only after the user explicitly enables it.

The audio is implemented using the browser's HTML Audio API.

Technology used

Component	Technology
Frontend	React 19, Vite 8
Styling	Tailwind CSS v4, custom CSS
Backend	Node.js, Express 5
AI model	Qwen 2.5 3B
AI runtime	Ollama
Database	SQLite
ORM	Prisma 7
Audio	Browser HTML Audio API

Why Does Open Innovation Matter?

For Haunted Terminal, open-weight AI isn't just a technology choice. It changes how the experience operates and what developers can inspect.

The model runs locally

Ollama serves Qwen 2.5 3B on the same machine as the application.

The frontend communicates with the local Express API, and the API communicates with the local Ollama service.

There is no hosted proprietary LLM API in the conversation loop.

This means the player's questions and conversational context don't need to be sent to an external model provider. The SQLite database also remains local.

For a project about memories, identity, and personal information, that distinction is meaningful.

The model is replaceable

The model is configured through an environment variable rather than being hard-coded into the story engine.

A compatible Ollama model can be selected by changing OLLAMA_MODEL and downloading that model.

The investigation logic doesn't need to be rewritten just because the underlying model changes.

The behaviour is inspectable

The system prompt, evidence supplied to the model, response constraints, and deterministic story progression are part of the source code.

Developers can inspect how the entity is instructed to behave, experiment with different models, and modify the experience without depending on a closed API provider.

Local-first also has trade-offs

Running locally means the player's machine supplies the computational resources.

Model downloads and initial dependency installation require internet access. Inference speed depends on available CPU, memory, and hardware. The current Ollama configuration explicitly uses CPU inference.

Once dependencies and the model have been installed, the application can run locally without sending inference requests to a cloud LLM service.

This isn't a claim that local AI is always better. It's a choice that makes sense for this particular experience.

I wanted the machine to feel like its own isolated world. Local inference makes that possible.

My Agent Session

I haven't prepared a DevRelay agent session for this project, so I'm leaving this optional section out rather than linking to something that doesn't exist.

The Spirit of It

There is one question I kept coming back to while building this:

What if the entity doesn't know that it is only a reconstruction?

Imagine recovering enough evidence to understand that the machine has preserved fragments of someone's memories. You ask it a question, and it answers confidently. But the records you've uncovered don't quite agree with what it remembers.

You now know something it doesn't.

You could terminate the process and erase what remains. You could preserve the archive, allowing the reconstruction to continue. Or you could search for one more fragment and unlock the possibility of releasing it.

None of these choices proves that the entity is a person.

That's the part I wanted to leave unresolved.

For me, the ghost in this machine isn't simply a process that refuses to terminate. It's the possibility that something can remember a life without ever having lived it.

And perhaps the most unsettling question isn't whether the machine is alive.

It's whether we would know what to do if it were.

Closing

Haunted Terminal started as an experiment in combining local open-weight AI with a deterministic interactive narrative.

It became an exploration of memory, identity, and the uncomfortable space between a person and their reconstruction.

The model gives the entity a voice. The evidence gives that voice context. The player decides what happens next.

The process was terminated. The archive remains active.

Project: Haunted Terminal — Infrastructure #674

Built by: Kunal Kashyap

MemoryVault: A Private AI-Powered Home for Family Memories

Kunal Kashyap — Mon, 05 Oct 2026 07:02:34 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built
I built MemoryVault for my family.
Over the years, families collect hundreds of little things that mean a lot — stories, recipes, photographs, personal notes, funny incidents, emotional moments, and memories that only one person may remember.
But these things get scattered.
Some are buried in WhatsApp conversations. Some are sitting somewhere in a phone gallery. Some are written down in notebooks. Some are stored as random documents. And some exist only in someone's memory.
Eventually, finding one particular memory becomes surprisingly difficult.
That's why I built MemoryVault.
MemoryVault is a private family memory vault where family members can store:

Stories
Recipes
Notes
Documents
Photos
Memories connected to specific family members You can search and filter memories, connect them to the people they are about, and ask questions about what you've saved. For example: "What do we remember about our family trips?"

or:
"What recipes have we saved?"

MemoryVault retrieves relevant memories and provides them as context to a locally running AI model, which can then answer the question using the family's own memories.
I didn't want to build another generic AI chatbot.
I wanted to build something that would actually be useful to the people closest to me.
Memories are easy to collect, but surprisingly easy to lose.
MemoryVault is my attempt to give those memories a home.
Demo
Live Demo
👉 Live
The application is deployed on Render and can be explored as a working full-stack application.
Screenshots

Code
👉 GitHub
The repository contains the complete React frontend and Express backend, along with the MongoDB integration, authentication, memory management, and local AI integration.
How I Built It
MemoryVault is a full-stack TypeScript application built with:

React + TypeScript + Vite — frontend
Tailwind CSS + Framer Motion — UI and animations
Node.js + Express + TypeScript — backend
MongoDB + Mongoose — persistent storage
Gemma 3 4B — open-weight AI model
llama.cpp — local inference runtime
Render — deployment
GitHub Copilot — development workflow Local AI with Gemma The most important architectural decision was to make the AI local. MemoryVault uses Gemma 3 4B, running through llama.cpp. When a user asks a question, MemoryVault doesn't simply send that question to an external AI API. Instead, the application first searches the memories stored in MongoDB and retrieves the relevant ones. The flow is: User question → Memory retrieval → Context building → llama.cpp → Gemma 3 4B → Answer + supporting memories The backend communicates with llama.cpp through its OpenAI-compatible API. This means MemoryVault does not require OpenAI, Anthropic, Gemini, or another hosted LLM API for its AI functionality. MongoDB MongoDB is the persistent storage layer of MemoryVault. It stores:
Users
Family spaces
Family members
Memories
Memory metadata
Relationships between memories and people This gives MemoryVault a structured way to preserve and retrieve family memories. Privacy by Design Privacy was one of the reasons I chose local inference in the first place. These aren't generic documents. They are family stories, personal experiences, photographs, recipes, and emotional moments. I didn't want adding an AI feature to automatically mean sending those memories to a third-party LLM provider. With Gemma running locally through llama.cpp, AI inference can happen on the user's own machine. That's the approach I wanted for MemoryVault: Bring the AI to the memories, rather than automatically sending the memories to the AI. GitHub Copilot I also used GitHub Copilot during the development of MemoryVault as part of my development workflow. It helped me during implementation and iteration while I focused on the application's architecture, privacy requirements, user experience, and the problem I wanted to solve for my family. Why Does Open Innovation Matter? This project made me think differently about where AI should run. For many applications, using a closed AI API is the easiest option. You send some data to an API, receive a response, and move on. But what happens when the data is deeply personal? With MemoryVault, the data isn't just business documents or random text. It's someone's family history. Stories about people we love. Personal experiences. Photographs. Recipes. Emotional moments. Using an open-weight model like Gemma gave me another option. Instead of: Family memories → Cloud API → Closed model → Answer I could build: Family memories → MemoryVault → Local retrieval → llama.cpp → Gemma 3 4B → Answer Open models made it possible for me to experiment with AI while keeping AI inference local. They also give developers more control over the technology they are building with. I can choose the model, run it myself, control the inference environment, and change the retrieval logic without making a proprietary AI provider a mandatory part of the architecture. For MemoryVault, that matters because privacy isn't an extra feature. It's part of the reason the application exists. Open innovation gave me the ability to ask: Can we bring AI to personal data without automatically sending personal data to someone else's AI?

For this project, the answer is yes.

Prize Categories
🏆 Best Use of Gemma
MemoryVault uses Gemma 3 4B as its local open-weight AI model.
Gemma is directly involved in the core Ask Your Vault experience.
When a user asks a question, MemoryVault retrieves relevant family memories from MongoDB, provides that context to the local Gemma model through llama.cpp, and returns an answer based on those memories.
Gemma isn't just an additional feature — it is part of the core experience of MemoryVault.
🤖 Best Use of GitHub Copilot
I used GitHub Copilot during the development of MemoryVault as part of my development workflow.

I didn't start this project because I wanted to make another AI chatbot.
I started it because memories are fragile.
A recipe can disappear.
A story can be forgotten.
A photograph can get buried.
A small moment that meant everything to someone can become impossible to find.
MemoryVault is my attempt to make those things a little harder to lose.
A private place for the stories, people, recipes, photographs, and emotional moments that make a family what it is.
That's what I built for my family. ❤️

hacktoberfest #hf26challenge #opensource #gemma #mongodb #react #typescript #llamacp