DEV Community: Kushaal Kankane

The Room That Forgot You: A Museum Mystery with an Archivist That Runs in Your Browser

Kushaal Kankane — Sat, 31 Oct 2026 19:10:24 +0000

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

What I Built

The museum knows every donor's name. It cannot tell you who washed the cups.

The Room That Forgot You is a first-person browser mystery set in a railway museum after closing. Its archivist remembers important visitors and celebrated events. Someone else survives only in the margins: an extra cup, repeated return tickets, handwriting beneath an official signature.

You enter with a flashlight and a handheld receiver. Your job is to give that person a place in the record.

The main mechanic is evidence changing the room. Finding a document is only the beginning. Connect it to another record, establish what happened, and confirm the connection. A distorted space regains its sounds, shape, and meaning.

There are three galleries, eighteen records, and nine connections:

Gallery	What the room seems to say	What the records reveal
Departures	Someone abandoned the station.	They kept coming back.
Shelter	Knocking and overturned furniture suggest danger.	The station sheltered people during a flood.
Names	Prominent townspeople did everything worth remembering.	The caretaker's ordinary work kept the doors open.

A presence approaches from blind spots. Hold the flashlight steadily on it to drive it back; wet footprints briefly point toward an unexamined exhibit. Discoveries affect the encounters, and restored galleries become quiet. There is no loss of collected evidence when you make a mistake.

The horror begins with an unexplained absence. The ending is an act of remembrance.

Demo

Enter the museum

The game is public and needs no account. Use a desktop browser with a keyboard and mouse; Chrome or Edge with compatible WebGPU hardware is the intended setup for the live archivist.

WASD / arrows: move; Shift: hurry.
Mouse: look; F: flashlight; E: inspect a nearby object.
J: field notes and connections; R: receiver; Esc: pause.
If mouse capture is unavailable, hold the left mouse button and drag to look.

Enter, approach the return ticket, inspect it, and choose Keep record. Find another supporting record before proposing a connection. Progress is saved in this browser.

To test the AI, open the receiver and explicitly download the models. The first load is substantial and requires internet access. After collecting the relevant records, try: “Did A.V. leave the station forever?” The answer should reference discovered records and offer a connection for confirmation. Asking ahead of the evidence should not unlock anything.

Watch the two-minute captioned walkthrough

That silent recording shows an earlier presentation of the investigation and is labeled AI inactive throughout. It demonstrates authored scenes and transformations; it does not demonstrate live inference or the latest flashlight encounters. The playable link is the current hosted build.

If live inference cannot load, the authored field notes support manual investigation, and the recorded walkthrough remains available. Those are explicitly separate from a generated answer.

Code

Source on GitHub — MIT license

The submission's game snapshot is commit 64ad8d6. The repository includes the evidence graph, model worker, tests, dependency notices, and actual model-evaluation outputs.

To run locally with Node.js 22.21+:

git clone https://github.com/Kushaal-k/the-room-that-forgot-you.git
cd the-room-that-forgot-you
npm ci
npm run build
npm run preview

Open the localhost address printed by the preview server. On Windows, Start Museum.cmd handles installation, building, and opening the production preview.

How I Built It

React 19, React Three Fiber, Three.js, TypeScript, and Vite render a procedural museum. Rain-dark windows and faded exhibits gradually give way to warmer light. A separate worker runs the archivist.

Two open-weight models do different jobs:

MiniLM, quantized and run through Transformers.js, matches a freeform question to discovered evidence and eligible conclusions.
Qwen2.5-1.5B-Instruct, in WebLLM's q4f16_1-MLC format, resolves an ambiguous shortlist of up to three candidates locally through WebGPU.

Both model cards list Apache 2.0 licensing. The app's own code and fictional story are MIT licensed; model weights are separate downloads.

The first small-language-model-only approach missed too many paraphrases. Adding neural retrieval gave the language model a smaller decision to make.

The more important boundary is what happens afterward:

Question + discovered archive
        → local neural retrieval
        → Qwen when ambiguous
        → structured record / connection IDs
        → evidence validation
        → player's confirmation
        → room transformation

The worker never receives undiscovered records. The game rejects nonexistent references and incomplete supporting evidence. It renders factual clue text from the authored archive, rather than treating generated prose as canonical history. The model cannot directly open a door or write a save.

A valid-looking answer can still be wrong. The AI Commit's “Why Forced JSON Output Is Always Valid and Sometimes Wrong” makes the same distinction between parseable output and correct meaning. Here, source validation and an explicit uncertainty response are part of the game rules.

What actually passed

The recorded game snapshot passed 21 unit tests and its production build. Those checks cover evidence validation, save recovery, controls, and encounter logic.

The real-model development evaluation passed 29/30 development paraphrases, four negative cases, and ten additional checks: 43/44 overall.

The mixed pipeline's median response was about 12 ms, mostly from neural retrieval. Ambiguous Qwen decisions took up to 4.59 seconds. Those timings exclude model download and initialization; they are not a claim that Qwen generates answers in 12 ms.

One failure remains in the report: “Who actually opened the station during the flood?” retrieves the general refuge connection rather than the actor-specific credit. These are development checks, not a held-out benchmark.

The verification log records the limits too. A full investigation was exercised before the latest horror pass; that pass received targeted controls checks. Fresh-player pacing, the intended 25–35 minute duration, sustained frame rate, and a complete disconnected model investigation still need verification.

Why Does Open Innovation Matter?

The archivist runs on the visitor's computer. Questions go to a local worker, with no hosted model endpoint, inference account, or API key.

For this project, the benefit over a closed hosted API is control over the experience's continued existence. The model, retrieval catalogue, prompts, and evidence rules can be inspected and changed. A developer can replace the model while keeping the story and saves understandable. The museum need not lose its archivist because an inference provider changes pricing or retires an endpoint.

That fits the subject: preserving someone's place in history should not depend entirely on a service continuing to sell access.

Local inference also avoids a hosted per-question inference charge. It still costs hardware, electricity, storage, and an initial download. WebGPU compatibility and shared graphics memory are real constraints.

The app and model runtimes include caching, but complete offline play has not been verified. I am not claiming that this release already works through a disconnected reload and full investigation. A closed model could perform the reasoning; the open approach makes the reasoning setup and its dependencies available to the person preserving the game.

The Spirit of It

The final reveal is deliberately modest: a workroom, a repaired clock, a kettle, a blue cup, and Ada Vale's name.

The apparent haunting resolves into traces of someone keeping a place safe for other people. The ending asks you to leave a light burning.

That is the intended emotional turn. I do not yet have three fresh-player sessions showing that it lands. The next useful test is watching someone discover the connections without help.

I Built Just Upload Because the Upload Box Shouldn't Be the Final Boss

Kushaal Kankane — Sat, 24 Oct 2026 21:18:37 +0000

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

What I Built

You finished the application.

You found the certificates. You checked the dates. You are one click away from being done.

Then the upload box speaks:

One PDF. Under 1 MB. Application first. Certificates oldest to newest. No instruction pages.

Apparently, the final stage of applying for anything is becoming a part-time PDF technician.

Just Upload is my attempt to make that stage smaller: drop in the paperwork, paste the requirements, review a proposed plan, and take away one PDF.

The local MVP. All documents shown below are fictional samples.

The idea grew out of the Slow and Steady theme: make a tool that handles a chore so someone can get on with their day.

This is for the person assembling an application, a workshop registration, or a bundle of supporting documents. They already have the information. The annoying part is packaging it.

Just Upload brings page selection, ordering, rotation, PDF creation, and file-size checks into one review flow. It accepts static PDFs and JPG, PNG, or WebP images. The output is a PDF.

The current app runs on the user's computer. No account is needed in the app, and there is no cloud AI upload step.

Demo

A paced slideshow of actual browser captures, not a real-time performance recording. This demo uses Basic mode, not Gemma inference.

The sample starts in an inconvenient order:

Original position	Page	What should happen
1	Instructions	Leave out
2	Certificate dated 2025-06-18	Put last
3	Application	Put first
4	Certificate dated 2024-03-12	Put second

Paste this requirement:

One PDF under 1 MB. Application first, then certificates
oldest to newest. Exclude instruction pages.

The app proposes application → 2024 certificate → 2025 certificate. The instruction page stays visible in an excluded section, where it can be restored.

That review step matters. A label is a suggestion. You can open the page, move it, rotate it, or change whether it belongs in the output.

Click Create my PDF, and the sample becomes a three-page file displayed as 5.6 KB, below its 1 MB cap. In this run, the original page content was preserved; stronger scan compression was unnecessary.

I haven't measured time saved across users. The concrete payoff demonstrated here is narrower: one interface handles the ordering, exclusion, assembly, and size check that would otherwise require several manual steps.

What happens when the limit is impossible?

I gave the same package a deliberately unrealistic cap: 0.001 MB, or 1 KB.

The output was still 5.6 KB. The app reported it as oversized and changed the download label accordingly.

The check is ordinary code:

passed = body.max_bytes is None or len(data) <= body.max_bytes

A plausible-looking PDF is not evidence that it fits. Measuring the actual output is.

Stronger compression is opt-in because it turns pages into images and can sacrifice selectable text and small-print readability. The user should make that tradeoff knowingly.

Code

The project currently lives in a local Python application; the repository has not been published yet. The stack is FastAPI, PyMuPDF, Pillow, and a plain HTML/CSS/JavaScript interface, with Ollama for the optional local vision path.

The model gets a limited vocabulary. Here is the actual page-finding schema from the app:

class Finding(BaseModel):
    title: str = Field(max_length=120)
    category: Literal["application", "certificate", "instructions", "other"]
    date: str | None = Field(default=None, description="ISO YYYY-MM-DD only if explicitly visible; otherwise null")
    suggested_include: bool = True
    reason: str = Field(max_length=500)
    needs_review: bool = True

The response is validated before it becomes a proposal. That catches malformed output; it cannot prove that a model read a date correctly. Human review remains part of the product.

How I Built It

During planning, a fair objection came up:

Doesn't most of this just need ordinary algorithms?

Yes. Merging PDFs does. Rotating a page does. Counting bytes definitely does.

The useful place for AI is the interpretation before those operations: reading a portal's wording, examining a scanned page, and suggesting what the document is and where it belongs.

So the app has two explicit modes:

Mode	What it does	What it doesn't establish
Basic	Reads selectable PDF text and explicit phrases; uses keyword and date rules to suggest a plan	Understanding of photographed text or arbitrary instructions
Local AI	Calls an installed Ollama vision model to interpret requirements and propose page labels, dates, inclusion decisions, and reasons	Correctness of those suggestions or acceptance by a portal

Both lead to the same human review and deterministic PDF builder.

Files + portal instructions
             |
    Basic rules OR local vision model
             |
       Structured proposal
             |
       Your page-by-page review
             |
    Merge / rotate / compress in code
             |
    Check actual output -> Download

The small details that earned their place

Two early mistakes were surprisingly instructive. An “oldest to newest” instruction could be mishandled by looking for the word “newest” alone. An application mentioning supporting certificates could be mislabeled as a certificate.

Those became reasons to make ordering explicit and prioritize document headings in the Basic classifier. They also reinforced why the review screen should stay.

The current verification run passes 25 tests, covering the sample flow and cases such as ambiguous dates, invalid files, page order, rotations, impossible size limits, session restoration, and the local-model API contract.

There are intentional limits: 12 files, 30 pages, 40 MB per package, and 12 pages per local AI request. Form/signature-widget PDFs and encrypted PDFs are rejected. Photo-dimension rules, form filling, and guaranteed portal acceptance are outside this MVP.

Files stay in the local server's memory. Start over clears the package; inactive sessions expire after an hour; restarting the server clears all sessions. The original files are unchanged.

Why Does Open Innovation Matter?

Documents can contain information you would rather keep on your own machine. That makes the location of inference a product decision.

The local AI path targets Gemma 3 4B through Ollama. A downloaded, compatible vision model can run on the user's machine; the app's AI endpoint is fixed to the local Ollama service. It checks vision capability and rejects cloud model configurations.

That approach gives this project three useful properties:

Control over the data path. Page images go to a local model process rather than a hosted AI API.
Control over the model and behavior. A compatible installed vision model can be selected, and the prompts and validation rules can be changed.
No hosted inference fee per document. Local hardware, electricity, setup, and model downloads still have costs.

Once the app dependencies and model are installed, the design does not require a cloud inference service. That is an architectural advantage here, not a claim that local inference is faster or more accurate than a hosted model.

Current status: the Ollama integration is implemented and tested with simulated model responses. A real Gemma model was not running during these demos. I have not measured its document accuracy or inference latency yet. The working demo above proves the Basic-mode workflow, not the AI path.

The next useful milestone is running the vision path on real, consented document examples: phone photos, rotated scans, faint dates, and confusing headings. I want to record which suggestions people correct, along with latency on actual hardware.

The Lazy Payoff

The fictional sample was exercised in the running app: four input pages became three selected pages in the requested order, with the instruction page excluded and the finished PDF measured at 5.6 KB.

That puts page review, reordering, exclusion, merging, and size checks into one place. The intended payoff is fewer tools to juggle when preparing an application or registration packet. I have not measured time saved with real users, and this is not yet a field-tested AI workflow.

Two DEV reads helped frame the engineering choices: The Hidden Failure Modes of PDF Processing and Building Reliable File Processing Pipelines without Glue Code, both by @iterationlayer. They emphasize early validation, explicit outputs, and visible uncertainty. These are vendor-authored perspectives, not independent validation of this app.

What is the most ridiculous upload requirement you've had to satisfy? A tiny file-size limit? A photo with exact dimensions? Five documents that somehow have to become one?

That last mile is the part I want to make easier.

Prize Categories

Best Use of Gemma: Just Upload integrates Gemma 3 4B through Ollama to interpret upload requirements and suggest document labels, dates, page order, and exclusions locally. Users review the suggestions before ordinary code builds and checks the PDF. The integration has been tested with simulated model responses; real Gemma inference remains to be verified.

ScopeKit: Turn a Messy Client Brief into a Quote with Local Gemma

Kushaal Kankane — Thu, 15 Oct 2026 20:14:27 +0000

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

What I Built

“Just a simple website” can hide a surprisingly long conversation: Which pages? Who supplies the photos? Does “contact form” include email delivery? Are payments part of this phase?

I built ScopeKit, a small local AI workbench for freelancers who need to turn those informal messages into something they can review and quote.

Paste the client's brief, let Gemma suggest a scope, review the deliverables and hours, set your rate, and export a Markdown proposal with a client reply. Source passages sit beside the suggested tasks so you can trace them back to the request.

The intended customer is an independent web designer or small freelance studio. A possible paid offering is installation and customization of a branded proposal workflow. That business idea is still a hypothesis: I have not tested willingness to pay or claimed customers or revenue.

The project is deliberately small. There is no account system or client database. Working content stays in memory; only the appearance preference is saved in the browser.

Demo

Watch the 28-second ScopeKit walkthrough (MP4)

The video is an edited sequence of actual UI steps using a fictional florist brief and real local Gemma inference. Its pauses do not represent inference timings.

The test brief asks for a one-page florist website, wedding bouquet gallery, contact form, and phone compatibility. Gemma identifies the website, gallery, and contact form, then proposes questions, assumptions, and exclusions.

It also suggests only two hours of work in total. That is why review is part of the workflow. In the demonstration, the hours are manually changed to 5, 3, and 3. At $50/hour with a 15% contingency, the example estimate becomes $632.50, with a $316.25 deposit. These are illustrative planning numbers, not validated effort predictions.

The model also puts “Mobile Responsiveness beyond basic phone compatibility” in its suggested exclusions. The client explicitly requested phone support, so that wording needs clarification before sharing. The tool does not establish that a scope is complete or that its proposed terms are appropriate.

Try it locally:

git clone https://github.com/Kushaal-k/ScopeKit.git
cd ScopeKit
ollama pull gemma3:1b
python app.py

Install Ollama and Python 3.10+ first. Keep Ollama running, then open http://127.0.0.1:8765. Windows users can use start.cmd. The hand-written Try an example option lets you explore editing and exporting without a model; it is clearly labeled as a sample.

Code

ScopeKit on GitHub

The MIT-licensed repository includes setup instructions, 19 automated tests, a cross-platform CI workflow, the demo video, a real model response, and a reviewed proposal export.

How I Built It

The frontend is plain HTML, CSS, and JavaScript. A Python standard-library server handles validation, quoting, and the local Ollama connection. There are no Python application dependencies or frontend build tools.

Gemma 3 1B performs the core extraction through Ollama's schema-constrained chat API. Instructions and the brief use a user turn, consistent with Gemma's prompt structure.

The most useful lesson came from source evidence. An early approach asked the model to produce supporting quotes. It sometimes invented them. Constraining the available quotes still allowed it to select an unrelated passage.

The final approach gives that mechanical step to code: Gemma proposes tasks, then the server attaches exact passages using task-word overlap and a few aliases, such as phones/mobile. It rejects unmatched task names and duplicate task anchors. One correction attempt is allowed before an error is surfaced.

This is a traceability heuristic. It cannot prove semantic correctness, completeness, or the absence of overlapping work.

The separation continues with money: Python's Decimal arithmetic calculates the quote. The model suggests hours; the user reviews them. Manually edited replies survive price changes, with a reminder to check their numbers.

Client brief → local Gemma → validation and source linking
             → human review → decimal quote → Markdown proposal

The interface has Light, Dark, and System themes, matching dropdowns, keyboard navigation, and responsive layouts. Briefs and proposals clear when the page reloads.

All 19 local validation and HTTP integration tests passed. The adapter tests use a mock Ollama server; separate real Gemma runs verify actual inference. GitHub Actions also passed, running Python checks on Windows and Linux and JavaScript syntax validation.

Why Does Open Innovation Matter?

Local open-weight inference fits the material this tool handles: client messages, project details, and draft commercial terms.

Once the model is downloaded, ScopeKit's inference workflow can work offline. It needs no hosted inference account, API key, or per-request payment. Hardware and electricity still have costs, and a small model still makes mistakes.

Open weights also let the user choose a different local model independently of the application. The model is a replaceable part of a workflow whose validation, calculations, and export format are inspectable.

The application uses the MIT license. Gemma weights have their own Google Gemma Terms; they are a separate download and are not bundled with the source.

Prize Categories

Best Use of Gemma: Gemma 3 1B runs locally through Ollama and extracts the tasks, questions, assumptions, and exclusions at the center of the product. The repository includes real inference evidence and the walkthrough above.
Best Use of GitHub Copilot — through GitHub Actions automation: The challenge explicitly includes GitHub Actions in this category. ScopeKit uses Actions for its Windows/Linux test matrix and JavaScript checks, with a successful run. This entry is based on Actions automation; the app was built with Codex assistance.

Community research

AI Explore's “Structured Output Gives You Syntax. It Doesn't Give You Semantics” informed the distinction between parseable output and trustworthy suggestions. ScopeKit's invented-quote failures made that distinction concrete.

I Built a Pokédex for Real Nature -Take Photos Offline, Identify Them on Your Laptop

Kushaal Kankane — Thu, 08 Oct 2026 11:22:03 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I built NatureDex, a pocket field guide for the things you notice outside.

You don’t need a planned hike or a rare discovery. Start with the tree beside your house, a flower along your usual route, or an unfamiliar leaf. Take a picture, keep walking, and learn about it when you get back.

NatureDex is for curious beginners, casual walkers, and anyone who wants a reason to look more closely at their surroundings.

The experience follows a simple rhythm:

Capture: photograph something that catches your eye.
Keep walking: save photos and notes in Walk mode, even without internet.
Reconnect: when your laptop is available, the open phone app automatically sends waiting photos for identification.
Discover: review possible matches and save sightings to your personal Field Guide.
Explore again: choose easy, medium, or hard expeditions and earn achievements along the way.

Your Field Guide grows from your discoveries, with photos, notes, a sighting timeline, and optional map locations.

I gave the app a retro, pixel-art look to make collecting discoveries feel playful. The goal is to make the screen a small part of the outing.

Take a photo. Pocket the phone. Keep walking.

Demo

Open NatureDex

NatureDex has an installable mobile web interface. Set up the laptop companion and scan its private QR code once to pair your phone. After that, you keep using the same app address.

Load the app before heading outside so offline Walk mode is ready. Identification uses your own laptop; the hosted site provides the interface.

The sample collection shows NatureDex’s pixel illustrations. Your own Field Guide grows from the sightings you save.

Code

NatureDex on GitHub

The repository includes the app, model setup, and phone-to-laptop connection instructions.

How I Built It

NatureDex’s identification engine uses Imageomics’ open-weight BioCLIP 2 through pybioclip. A model built for biological images gives the app its core recognition capability.

The frontend uses React, TypeScript, and Vite, hosted on Render. A FastAPI backend runs on the laptop, with SQLite storing saved sightings. Offline captures stay in browser storage on the phone until they can be processed.

The most important design decision was separating taking a photo from identifying it.

You can walk somewhere with no signal and collect photos without waiting for the model. Later, when your phone and laptop are connected, reopen NatureDex and the queued photos transfer to the laptop. Results come back to the phone for review.

No signal needed to collect a discovery. Identification happens when you reconnect.

The laptop companion starts at Windows sign-in. Tailscale Funnel provides its HTTPS connection without requiring a custom domain, so pairing doesn’t mean entering a new link every session. Photos travel to the laptop through that connection; there is no cloud photo queue.

My GPU has gone bad, so I ran BioCLIP on my laptop’s CPU. To avoid holding several gigabytes of RAM all day, the model runs in a separate worker that exits after three idle minutes. The connection stays available, and the next photo automatically reloads the model.

NatureDex also treats identification as a suggestion. It shows alternative matches, makes uncertainty visible, and provides photo-quality hints. Walk results need review before joining the Field Guide.

Why Does Open Innovation Matter?

Open weights let me build the experience around a model I can run myself.

I don’t need a third-party AI API for every photograph or a per-identification payment. Once the weights are downloaded, inference can run locally without internet access. The remote phone connection still needs internet, but capturing photos outside does not.

That freedom shaped NatureDex: the phone handles the outdoor moment, while a laptop handles the large model. I can choose where inference happens, experiment with other models, and change how predictions are presented.

It also meant a broken GPU didn’t end the project. I could keep building with the CPU I already had.

For NatureDex, open innovation made this workflow possible: go outside without a connection, collect what catches your eye, and come home to learn about it using a model you control.

A little less scrolling. A little more exploring.

Prize Categories

Best Use of Render: Render hosts NatureDex’s mobile web interface, while the open-weight identification model runs on the user’s own laptop.