DEV Community: Reet Singh

The Last Process: I built a haunted desktop with Gemma

Reet Singh — Sun, 01 Nov 2026 06:01:17 +0000

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

What I Built

You reopen an abandoned desktop. Three files survived. Beside them, a resident appears:

You weren’t supposed to reopen this.

The Last Process is a short browser escape room about a program that kept waiting after its creator was gone. Recover the files, speak to the resident, uncover Mara’s diary, and decide how the last process ends.

Gemma 4 plays the resident. Its responses change with your question and the clue you are examining. The puzzle rules stay in code: the model can offer atmosphere and guidance, but its output cannot unlock a file or change an answer.

I wanted the haunting to come from an ordinary software behavior: a listener that never received its stop signal.

Demo

Play The Last Process

To try it:

Read boot.log and answer the question underneath it.
Open each newly recovered file to continue the story.
Ask the resident a question or use “I’m stuck. Give me a hint.” to see Gemma respond.
Recover the final letter and choose an ending.

The conversation is text-based. Optional ambient sound starts off, and the game never executes real commands or accesses your files. All characters and events are fictional.

The free host may take about a minute to wake. Progress survives a page refresh on the same running instance; a host restart or redeployment can reset saves.

For the HTTP interface, try the interactive API docs.

Code

GitHub repository — MIT licensed application code

The repository contains the complete app, tests, Docker configuration, generated casebook and usage ledger. Dependencies and external models retain their own licenses and terms.

Useful evidence:

How I Built It

I split the experience into three responsibilities: rules, dialogue and story writing.

Rules: make the room solvable

Python validates each answer against an authored puzzle and advances the stage. The API checks the expected stage inside a SQLite write transaction, so duplicate submissions cannot skip a puzzle.

The resident also has three progressively clearer authored hints for each puzzle. These are displayed separately from AI dialogue. If a provider fails or a response is misleading, the player still has a reliable next step.

Dialogue: let Gemma inhabit the room

The resident uses gemma-4-26b-a4b-it, Google's open-weight Gemma model, through the Google Gen AI SDK and Gemini API. Despite the API's name, the selected model is Gemma.

Each request includes the current fictional clue, an approved hint and the player's message. The model writes a brief response as Mara. The game never interprets that response as a command.

Hosted calls have a timeout, an output limit and disabled SDK retries. Session and process limits bound demo usage. If inference is unavailable, the interface explicitly labels its authored fallback.

Story writing: give Ultramarine a bounded job

Ultramarine (ultramarine-1-flash) wrote the three diary fragments bundled with the app. The build-time script calls Paper Instruments through the OpenAI SDK, validates exactly three short fragments, and records token usage.

One useful failure happened here: the first response failed schema validation. It was rejected. The second request passed the unchanged validator, and its prose was reviewed before deployment. Both requests remain in the ledger; the failed attempt did not disappear from the cost accounting.

Ultramarine can write diary paragraphs. Its accepted schema has no field for changing puzzle answers, clues or endings.

The stack

Tool	What it does
React + Vite	Responsive file explorer, reader, resident panel and controls
FastAPI	Session, answer, hint and ending endpoints; Swagger UI
SQLite	Transactional progress saves and bounded dialogue history
Google Gen AI SDK + Gemma 4	Live, in-character resident dialogue
OpenAI SDK + Ultramarine	Build-time diary generation with usage accounting
Render + Docker	Serve the client and API together from one free web service

All 20 unit/API tests pass. They cover wrong and stale answers, concurrent submissions, both endings, session isolation, hint limits, provider failure and invalid story output. Desktop and mobile browser checks exercised the complete game and save/resume. The public API also passed a real Gemma hint, all three unlocks, the generated diary, an ending and resume.

These checks verify the exercised behavior. They are not a general model-accuracy benchmark or proof against every prompt injection. The important protection is that generated text does not control game state.

This is a solo submission. Codex assisted with implementation, testing, review and drafting this write-up; ImageGen created the visual concept and resident portrait. The interface and controls are native React, HTML and CSS.

Why Does Open Innovation Matter?

Gemma is an open-weight model at the center of the live experience. Its weights are available for independent experimentation, and the surrounding application code is public: another builder can inspect the prompts, change the character, examine the guardrails and fork the room.

For this deadline, I used hosted inference to ship a working demo without provisioning a GPU. That means ghost messages and fictional clue excerpts go to Google when a player asks for help. This version does not run Gemma locally or promise private offline AI.

A future local Gemma runtime would need a new provider adapter. The authored puzzles, progression checks and story format could remain in place. Open weights make that route possible without depending on continued access to one hosted endpoint.

The source also exposes the boundary that matters most here: readers can see exactly where a generated response ends and an authoritative game decision begins.

The Spirit of It

Mara built a listener to preserve a voice she missed. Over time, she recognized that a convincing response could still be an imitation.

That became the emotional center of the game. Both endings close the listener. One preserves the words as a story; the other lets the process rest. Neither treats an endlessly running program as a person who must keep waiting.

The final interaction is a choice about what to remember.

Prize Categories

Best Use of Gemma: gemma-4-26b-a4b-it plays the resident in the deployed game, responding to the current clue and player's question. A public live inference call was verified.
Best Use of Ultramarine: ultramarine-1-flash, called through the OpenAI SDK, drafted the three deployed diary fragments. Two requests used 430 input tokens and 484 output tokens, including reasoning, for a usage-based cost of $0.00030650 USD at the published rates. This includes the rejected first response. The provider's usage endpoint confirmed the request and token totals. This is a calculation from reported usage, not a rounded dashboard screenshot or a claim about the whole app's ongoing cost. Usage ledger.
Best Use of Render: Render hosts the working client and Python API in a Docker web service, with server-side Gemma credentials, a health check and public interactive API documentation. The selected hosting plan is Free.

UNWATCH: finding what a second tutorial actually adds

Reet Singh — Sun, 25 Oct 2026 07:58:09 +0000

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

What I Built

My sister is preparing for her board exams alongside NIFT and UCEED 2027. Her study time has to stretch across schoolwork and entrance preparation, and YouTube is part of that routine.

She had already watched one preparation session. When she wanted to move to another video, the question was simple: which parts would actually add something?

She wanted the explanations she had missed, the extra facts and figures, and a different way of understanding a topic. Finding those parts meant spending more time watching material she had already covered. The video could be useful, but she had to sit through it to find out where.

That is where UNWATCH started. Before asking someone to commit to another lesson, could an app show them what appears familiar, what seems new, and the evidence behind that judgement?

I built it to compare those two tutorials. Paste the YouTube link you've watched and the one you're considering. UNWATCH reads the available captions, identifies possible repetitions, and creates an editable watchlist of the original video sections. New examples and uncertain material stay included.

The useful part happens before you press Play. Each proposed skip comes with source caption excerpts. You can check the reasoning, restore a section, and watch the original video at the selected intervals. No subtitle upload or extension is needed.

The theme is “Slow and Steady.” For someone juggling two sets of exams, spending less time finding the useful part leaves more time to work through it.

Demo

Live app: unwatch-byeb.onrender.com · Open the workspace

Try UNWATCH · Watch the short walkthrough

Choose Replay a real result to open the exact measured comparison without spending credits. The public site also includes a clearly labeled illustrative example. The 2 minute 21 second walkthrough is edited from my real screen recording, with local synthetic narration, captions, and an original ambient score. Waiting is shortened. It shows a fresh long React comparison and then the separately labelled saved React result. The live results below come from real YouTube captions and a real transcription path, rather than that example.

In one React comparison, the second tutorial used an interactive 3D scene to teach state. UNWATCH kept those examples and proposed omitting only a repeated explanation of the state value and setter. Its assessed timeline went from 9:56 to 8:57, with 59.481 seconds left out after context padding. I checked both cited caption excerpts. I can include the section again with one click.

Four other comparison configurations kept everything. That includes an unrelated React/Docker pair: two videos sharing words like “application” does not make their explanations interchangeable.

Code

Source code and setup

The project uses React, TypeScript, Express, and shared validation schemas. The workflow lives in server/workflow.ts, provider adapters in server/providers.ts, and section validation and playback ranges in shared/domain.ts. The repository includes an MIT license, setup instructions, application budget controls, and known limitations.

How I Built It

The core path is simple: retrieve timed speech, compare the explanations, validate the proposed sections, then let the learner review them. Seven partner services support that path. Each has a specific job.

Mastra: make the comparison a workflow

The open-source Mastra workflow runs caption retrieval and then comparison, with typed input and output schemas between the steps. Citation and timeline validation run inside that comparison path. This makes the boundary between retrieved evidence and a suggested watchlist visible in the code. For the learner, it means the app can stop with a useful error instead of presenting an unsupported result. Workflow code.

SerpApi: turn a YouTube link into timed source material

UNWATCH calls SerpApi's youtube_video_transcript engine to retrieve captions and their timestamps. Those timestamps connect a proposed section to the original video and support the evidence links. The user pastes a link instead of downloading a video or uploading subtitles. This is caption retrieval, rather than a general web-search feature. Retrieval adapter.

ElevenLabs: recover speech when captions are missing

When the caption route has no usable text, the optional Scribe fallback submits the canonical YouTube URL as source_url and requests timed transcription. A real captionless Docker source passed through this path during development; later runs reused the cached transcript. This widens the set of videos the app can compare, but source access, account allowance, and the prototype's attempt cap still apply. The demo's voiceover uses local Kokoro speech; ElevenLabs is integrated for tutorial transcription. Transcription adapter.

Ultramarine: compare explanations, not just matching words

Paper Instruments' Ultramarine model reads the timed transcripts and proposes sections, reasons, caption references, and an assessment of whether each section adds a distinct detail. The server checks those references before showing the result. A repeated term alone should not remove a new example or caveat. The measured React result below records its tokens and estimated model cost. Comparison adapter.

MongoDB Atlas: remember sessions and preserve the allowance

Atlas stores account-scoped comparisons and expiring caption caches, so a saved session can reopen and a cached transcript can be reused. It also stores the shared provider-budget ledger. Atomic conditional reservations check the remaining allowance before a call, including when requests arrive together; restarting the server does not reset that ledger. This keeps a public prototype manageable within its configured allowance. Store implementation.

Auth0: connect the workflow to the right account

Auth0 handles sign-in and supplies access tokens. The backend verifies their signature, issuer, and audience, then uses the verified user identity to scope saved-session access. A learner can explicitly sync a comparison and reopen it from their account. Sign-in and session sync passed a real one-account public test; owner isolation also has automated coverage. The project does not use Token Vault or fine-grained authorization. Authentication code.

Render: put the whole app behind one public URL

A free Render web service hosts the built React interface and Express API together. Provider credentials stay on the server, and the frontend calls the same-origin API. Judges can open the workspace or replay a saved real result without installing the project. A free instance may need time to wake up. Deployment configuration.

The first hard lesson was that a citation can be valid while a skip is wrong. An early result marked a Docker/VM explanation as repeated, even though it added an OS-compatibility caveat. I tightened the prompt and added an explicit check for distinct details. A section stays included when the model identifies an extra example, caveat, or practical step—or fails to supply that assessment.

Long videos exposed another problem. One malformed model response could throw away the entire comparison. The chunk handler now retains an unassessed part and preserves usable parts around it. It tells the user what happened. It also withholds a total-cost estimate if usage data is incomplete. That recovery has a regression test. The screen recording also shows a fresh long React comparison retaining roughly 80 minutes and omitting nothing. It demonstrates the normal long-video path; malformed-part recovery was tested with simulated responses rather than deliberately triggered in production.

The current automated suite has 20 passing tests. It covers source validation, caption caching and transcription fallback, grounded section references, long-video timelines, conservative recovery, and budget isolation. The production build passes. In browser checks, a real YouTube embed started at a selected timestamp, paused, navigated to another interval, and offered full-video mode.

The real React run returned 19,563 input and 2,170 output tokens: $0.00401945 in estimated model usage at the adapter's configured rates. Five successful configurations totaled $0.02435370. Those figures exclude caption/transcription usage and failed requests. They are token-based estimates, not provider billing statements. The full development evaluation is included with the code.

Why Does Open Innovation Matter?

Mastra is the open-source framework at the center of the app's AI workflow. Its steps are explicit and inspectable: fetch the source, compare it, then validate what can be shown to the learner. The validation rules and provider adapters are also available in the project source, so another builder can change the comparison behavior or substitute a provider.

That mattered when I found the bad skip. I could change the validation boundary and add a focused regression test. The learner's review UI did not need to change. This is a hosted-model prototype; I am not claiming offline inference or an open-weight model.

The Lazy Payoff

My sister has tried the prototype. Her first use case is choosing which parts of a second preparation video deserve her attention: a new explanation, an additional fact, or a detail the previous lesson did not cover. The goal is to leave more time for the rest of her preparation.

The exam-preparation story explains who I built for. The measured comparisons in this post use programming tutorials; evaluating NIFT and UCEED lessons is the next step.

UNWATCH takes on the comparison work: finding the repeated explanation, showing its evidence, and lining up the remaining intervals. The learner keeps the final decision.

The current pilot is deliberately modest: five configurations, with reversed pairs among them, covering two main topic groups plus an unrelated-topic check. Only one section was proposed for omission. It is enough to demonstrate the workflow, but not enough to claim general accuracy or improved learning. Caption analysis also cannot judge silent demonstrations reliably, so those deserve extra care.

My next improvement would be a broader review set and feedback on which suggested skips people restore. For this prototype, I want each suggested shortcut to be explainable and easy to undo.

Prize Categories

Best Use of Render: the public React interface and Express API run together on a real free Render web service. The public replay lets judges inspect a saved live result without new inference requests.
Best Use of Mastra: the actual comparison route executes the open-source workflow for retrieval, comparison and validation.
Best Use of Ultramarine: it reasons over the real transcripts; the token counts and estimated run costs above show what it did.
Best Use of ElevenLabs: Scribe transcribed a real captionless Docker source and supplied timed text to the workflow. Later evaluation runs reused that cached transcript.
Best Use of SerpApi: its YouTube transcript API supplies source captions and timestamps that ground the comparison. This is the project's specific use of SerpApi.
Best Use of MongoDB Atlas: account sessions, expiring caption caches, and atomic provider-budget reservations use the connected Atlas database.
Best Use of Auth0 for AI Agents: Google sign-in and verified access tokens protect live comparisons and account session sync.

I used Codex to help implement, test, and edit the project. The demo narration uses local Kokoro synthetic speech. Backboard and Sentry are not connected and are not category claims. Public live requests remain subject to provider availability and the application allowance; the saved real result stays available without new provider calls.

Hijack Radar: your lockfile said you were safe. Your dependency graph knew better.

Reet Singh — Sun, 18 Oct 2026 17:44:05 +0000

Monday, September 8, 2025

A maintainer of some of the most-used packages on npm gets an email. It says their two-factor settings need updating before the 10th. The link looks like npm. It isn't.

Minutes later, new versions of 18 packages appear on the registry, chalk and debug among them. Together they're downloaded about 2.6 billion times a week. The new code quietly rewrites crypto wallet transactions in the browser. The bad versions are pulled within hours, but every engineering team spends that afternoon asking the same question:

Were we hit?

The obvious way to answer is to search your repos for debug in package.json. We did exactly that across 17 real open-source codebases: VS Code, Playwright, Bitwarden, Jitsi Meet, Expensify and more.

One repo declares debug. All seventeen install it.

The other sixteen pull it in through chains like vscode → eslint@10.8.0 → debug@4.4.3. A text search can't see those chains. A graph can. That gap is the whole project.

What Hijack Radar does

Hijack Radar is an AI agent for the attacks CVE scanners weren't built for: account takeovers and hijacked releases. You ask in plain English, and it answers from a FalkorDB graph of what your repos really install, with the exact path behind every answer.

"If the npm account qix were phished, what would it reach?" That account publishes 7 packages, and they reach all 17 repos. The answer comes back in milliseconds, with a path for each repo.
"MAL-2025-46974 just dropped. Are we affected?" This is the real advisory from that day. A lockfile scanner says safe, because no lockfile pins debug@4.4.2. The agent says that honestly, then checks the version ranges: 217 of them accept the hijacked release, so your next npm update would have pulled it into every repo.
"Where is our next xz?" PageRank over the dependency graph, filtered to packages that a single npm account controls. These are the load-bearing packages nobody is watching.
"We'll pin debug with overrides everywhere. Remember that, and draft an issue for jitsi-meet." The decision is stored as a dated node in the graph, and the agent drafts the fix for the owning team.

Every answer sits next to an evidence panel: the tool calls it made, how long FalkorDB took, and a graph of every dependency path it found, with repos in blue and the compromised package in red. There's also a radar view: the 17 repos as dots, one ring per dependency hop. Replay an attack and the sweep lights up every exposed repo on the ring where the graph reaches it.

Why this has to be a graph

Supply-chain questions are questions about connections, and they're several hops deep:

(:Maintainer)-[:MAINTAINS]->(:Package)-[:HAS_VERSION]->(:Version)
(:Repo)-[:DEPENDS_ON {range}]->(:Version)-[:DEPENDS_ON {range}]->(:Version)
(:Advisory)-[:AFFECTS]->(:Version)
(:Team)-[:OWNS]->(:Repo)
(:Decision)-[:ABOUT]->(:Repo | :Package | :Advisory)

We parse real package-lock.json files using Node's own module-resolution rules, so the graph holds what is installed, not just what is declared. Then we add advisories from OSV.dev and maintainer usernames from the npm registry. The result is 17 repos, 11,179 package versions, 33,233 dependency edges, 357 advisories and 4,099 maintainers. It fits in about 19 MB.

Two modelling choices did most of the work:

Every dependency edge stores its semver range. That's how we answer "would a lockfile refresh pull the hijacked version?", the question that mattered on September 8 and that lockfile scanners can't answer.
Maintainers are nodes. "If this account is phished" becomes a traversal: person → packages → every version → every repo that reaches one.

The core query is short:

MATCH (:Package {name: $name})-[:HAS_VERSION]->(v:Version)
MATCH (r:Repo)
WITH r, v, shortestPath((r)-[:DEPENDS_ON*]->(v)) AS p
WHERE p IS NOT NULL
WITH r, v, p ORDER BY length(p)
WITH r, collect(v.version) AS versions, collect(p)[0] AS p
RETURN r.name, length(p), [n IN nodes(p) | coalesce(n.id, n.name)]

On a laptop, it answers for all 17 repos in about 30 ms. We also use FalkorDB's built-in algorithms as tools: algo.SPpaths to list every equally short chain between a repo and a package, and algo.pageRank to find the "next xz".

How the agent works

We set one rule early: the model never writes Cypher.

The agent picks from 13 fixed tools, served over MCP. Each tool runs a parameterised query we wrote and tested. Before any traversal runs, the tool checks that the package, repo, maintainer or advisory actually exists in the graph. Unknown names get suggestions back, never a guess.

Every result carries an explicit outcome: answered, not_in_graph, unknown_package or answered_from_memory. That's what keeps the agent honest. For the real Sept 2025 advisory, it says "not in the graph, not that you're safe" and then checks the ranges, instead of announcing an all-clear.

The model is Groq's gpt-oss-120b. The free tier is small (8,000 tokens a minute), so the model only reads the first rows of each tool result, plus a count. The UI still draws every path, because it gets the full result separately. The same 13 tools also work in Claude Code or Claude Desktop over MCP: the web agent is just one client.

The tracks we entered, and why it fits

Track 01: Agents That Act on Connected Data

This track asks for agents that use the graph to decide and act: multi-hop reasoning, graph algorithms as tools, tool selection through MCP, and explainable results. That's Hijack Radar's core:

Multi-hop reasoning: every answer is a traversal across up to several hops, from maintainer to package to version to repo.
Graph algorithms as tools: shortestPath, algo.SPpaths and algo.pageRank are tools the agent chooses.
MCP tool selection: 13 fixed tools, and the model picks which ones to call.
Action: it suggests an npm overrides fix and drafts an issue for the team that owns the repo.
Explainable: every result carries its dependency path, drawn beside the answer.

Track 02: Agent Memory and Coordination

This track asks for agents that remember across sessions and keep separate memory per user or tenant:

Memory as graph nodes: a triage decision such as "pin debug with overrides" becomes a dated Decision node linked to the package. Later answers about debug, or about advisories that touch it, come back with that decision attached: who decided and when.
Shared across agents: the memory lives in the graph, not in a chat window, so every MCP client (our web agent, Claude Code, Claude Desktop) sees the same decisions.
One graph per company: each tenant gets its own isolated graph on the same FalkorDB instance (supplychain and supplychain:orbit in our demo). The server pins each chat to its tenant, and the model never even sees the tenant argument. Ask about debug as our second demo company, Orbit, and you get Orbit's 5 repos, none of which declare debug and all of which install it. Orbit's decisions never appear for anyone else.

Things that bit us

Unbounded path enumeration. Our first algo.SPpaths call hung when the target wasn't reachable, because it tried to enumerate every path in the tree. Running shortestPath first and passing its length as maxLen brought it down to a few milliseconds.
An empty graph is an error, not an empty result. A fresh cloud instance made our health check fail and the host restart the app in a loop. Now health reports the problem instead of crashing.
Lockfiles are subtle. Nested node_modules, symlinked workspaces, npm aliases (string-width-cjs is really string-width) and optional platform packages all have to be handled before the graph tells the truth.
Prompts need to say what the UI needs. On the first real run, the model answered "who installs debug?" from memory instead of calling the tool, so the graph never appeared. One line in the prompt ("call tools for every question; the page draws evidence only from this turn") fixed it.

Try it

Reet24-del / supply-chain-blast-radius

Hijack Radar: an agent that traces phished npm maintainers and hijacked releases through a FalkorDB dependency graph (Graph Hacks 2026)

Hijack Radar

An npm maintainer gets phished and a release is hijacked. What did you just install, including what your lockfile says is safe? Hijack Radar is an agent that traces account takeovers and hijacked releases through a FalkorDB graph of your real, installed dependency trees, and shows the path behind every answer.

Radar view (/radar.html): the 17 repos as dots on a radar, with one ring per dependency hop. Pick an attack, such as a phished maintainer or the Sept 2025 debug@4.4.2 hijack, and the sweep lights up every exposed repo on the ring where the graph reaches it.

CVE scanners answer "which of my pinned versions is vulnerable?". Hijack Radar answers the questions they can't:

"If this maintainer's account is phished, what can the attacker publish into our repos?" Maintainers are nodes, so an account takeover is a traversal from a person to packages to every…

View on GitHub

The README has the graph model and every Cypher query the product depends on.

Run it locally. Hijack Radar runs on your own machine with an embedded FalkorDB engine, no Docker and no cloud account needed:

git clone https://github.com/Reet24-del/supply-chain-blast-radius && cd supply-chain-blast-radius
uv sync --extra lite
echo "FALKORDB_LITE_PATH=.falkordb/lite.db" >> .env
echo "GROQ_API_KEY=your-free-key" >> .env     # free at console.groq.com
uv run blast-ingest --reset                    # loads the 17 real lockfiles (~3 min the first time)
uv run blast-web                               # http://localhost:8000, plus /radar.html

Prefer Docker? docker compose up -d starts FalkorDB with its browser UI, and the same code also runs against FalkorDB Cloud.

Built for **Graph Hacks: Context for AI Agents* (FalkorDB × WeMakeDevs), October 2026. Built with Claude Code as a coding assistant, as disclosed in the README.*

“Simple site hai, 15k mein ho jayega na?” I built Panga so freelancers stop saying yes too fast

Reet Singh — Sun, 18 Oct 2026 07:27:53 +0000

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

It's 9:41 on a Tuesday night when Mr Sharma's email lands.

Namaste! I run Sharma Tuition Classes in Lucknow for class 9 to 12. We need a simple website showing our courses, our teachers, last year's results and a contact form. Just 4-5 pages. Our budget is ₹12,000.

Easy money. You've built this site twenty times. You reply "Haan ji, ho jayega" and put the phone down.

It buzzes.

parents should be able to pay the monthly fees online also, UPI se

It buzzes again.

and students will login to download notes and old papers
weekly online test bhi ho jaye with marks, that will be very good
Hindi version bhi chahiye, most parents prefer Hindi
every result season we will send topper photos, you put them on the site

And then the line every freelancer in India has heard at least once:

bas simple sa hi hai na

Fourteen minutes, six messages. The "simple site" now has a payment flow, a student login, an exam system, a second language and a maintenance job that never ends. The budget is still ₹12,000.

You find out what that means three weeks later, at 2 AM, when you finally add up the hours. About ninety-two of them. That's ₹130 an hour, before the first "small change".

There's a Hindi word for this kind of trouble: panga. Trouble you pick on purpose.

So I built Panga, a deal room that reads the brief and the chat, finds the work hiding in it, shows what the deal really pays per hour, and lets you rehearse the awkward call with a pushy client before you say yes. Then it helps you answer the only question that matters:

Lena hai? Negotiate karna hai? Ya chhodna hai?
Take it, change the deal, or walk away?

The demo video above is Panga running live on the Sharma deal, narrated with ElevenLabs.

The pain nobody puts on their portfolio

Freelance developers are good at building things. We lose money before the building starts.

The scope isn't in the brief. It's in the chat. The email says "4-5 pages". The WhatsApp thread quietly adds payments, logins and a translation, spread over six messages and three days.
We price by feel. "₹12,000 feels right for a small site." Nobody divides the price by the real hours until the project is half done.
"Small changes later also." The most expensive sentence in freelancing. Unlimited revisions with no line item.
We say yes on calls. The client pushes, the silence gets awkward, and "haan, ho jayega" slips out. Nobody writes it down. The client remembers.
The reply takes an hour. Saying "this costs more" politely, in the right tone, without sounding greedy, is hard. So we don't say it.
We never learn. The last project ran forty percent over. The next quote is still a guess.

None of this is a coding problem. It's a reading, maths and nerve problem. Those are things software can actually help with.

What I built

Panga turns a messy deal into four steps. Here's what it did with Mr Sharma's messages, live, in about 30 seconds.

01 The work: find what's hiding in the chat

Gemma reads the brief and the chat and lists every piece of work. Panga found the website from the email and five more jobs in the chat: UPI fee payments, a student login for notes, weekly online tests, a Hindi version, and topper photos every result season.

The rule that makes this trustworthy: every item must quote the client word for word, and Panga checks each quote against the original text. If the model invents a quote, Panga throws the item away. Click a quote and the client's own message lights up on the right.

It also gets the small things right:

Hosting was never mentioned, so it's listed as "nobody asked for this" and not priced.
The "before April" deadline isn't treated as work.
The ₹12,000 came straight out of the email, with the quote it came from.

Unsure what an online test system involves? What's involved? runs a live web search with SerpApi and explains it with numbered sources.

02 The money: the real hourly rate

All of that work adds up to about 92 hours. At ₹12,000 that's ₹130 an hour against a ₹700 minimum. To be worth your time, the full job should be ₹70,000.

This part is plain TypeScript, not AI. Every number has a "How?" that shows its formula, and you can change your rate, revision rounds or buffer and watch everything update. A "what if the small changes never stop?" slider shows the rate sinking further.

03 Client from hell: practise the call

A pretend client who has read only this brief calls you, by text or by voice, and pushes on every gap using his own messages. In the demo I answered the way most of us do, a little too nicely:

"Haan ji, notes ka portal bhi bana dunga, no problem."

When the call ends, the replay shows exactly what that cost:

That easy "no problem" is flagged as extra work you just promised for free. The price talk is flagged too, with a suggestion for pinning each one down. You can add the promise to the work list in one click.

04 Your call: take it, change it, or walk

Panga lays out three options:

Change the deal: a smaller package that fits the client's ₹12,000, with what's left out written down.
Take it, at your price: everything they asked for, at ₹70,000.
Walk away: a polite no.

Pick one, and it drafts the reply in your tone, including Hinglish. It then checks that every amount in the reply matches its own numbers, so a hallucinated "₹9,000" can't sneak into a message to your client.

You approve it. Panga never messages your client. You do.

When the project ends, you record how long it really took. That becomes a past project, and the next similar brief shows it, for example: "Kurta shop: estimated 50 h, took 72 h. Product import took twice as long as quoted."

Who would pay for this

Freelance web developers and small studios who quote fixed prices, especially for the ₹10k–₹50k "simple website" jobs where scope creep hurts most. One avoided free student portal pays for years of the tool.

The plan is ₹49 per deal check, or ₹299 a month. A full check costs Panga well under ₹1 in model calls, so the numbers work even at Indian freelance prices.

My first user

My first real user is a friend of mine who runs social media for small businesses. He edits videos, turns them into Instagram reels, runs campaigns, and sometimes makes websites and pamphlets. His usual rate for maintaining an account is ₹6,000 a month.

One client, a woman with an Instagram account that was more or less dead, asked him to revive and maintain it for ₹1,000 a month. Her pitch was simple: "I'll manage the account myself too, so you won't have to do much."

That isn't how it went. Every few days there's a new ask: come and record my videos, do this small extra thing, just one more edit. None of it is paid. He wanted to sit down with her and have a proper conversation, but he knew how these talks go. She negotiates well, the silence gets awkward, and his point gets cut short.

So before the talk, he put their chat into Panga. It laid out the extra work hiding in the chat, the recording days and the edits that were never part of the ₹1,000 deal, with her own messages next to each one. It showed what that deal really pays per hour once the extras are counted. He practised the conversation against a client who pushes back the way she does, and walked in knowing exactly what he wanted to say.

This is the case I built Panga for, even though I first wrote it with websites in mind: a freelancer who is good at the work, underpaid by a client who is good at negotiating, and who just needs the facts in front of him before he says "haan, ho jayega" one more time.

Demo

Live: panga-gnb2.onrender.com. It's on a free instance, so the first visit after a quiet spell can take about 50 seconds to wake up. Click Try the sample deal, or paste the Sharma example below.
Code: github.com/Reet24-del/panga (MIT)

The Sharma Tuitions example (paste this into Panga)

What's the project? Sharma Tuitions website

Brief:

Namaste! I run Sharma Tuition Classes in Lucknow for class 9 to 12. We need a simple website showing our courses, our teachers, last year's results and a contact form. Just 4-5 pages. Our budget is ₹12,000.

Chat:

[9:41] Mr Sharma: aapka kaam dekha, accha laga
[9:43] Mr Sharma: parents should be able to pay the monthly fees online also, UPI se
[9:44] Mr Sharma: and students will login to download notes and old papers
[9:47] Mr Sharma: weekly online test bhi ho jaye with marks, that will be very good
[9:50] Mr Sharma: Hindi version bhi chahiye, most parents prefer Hindi
[9:52] Mr Sharma: every result season we will send topper photos, you put them on the site
[9:55] Mr Sharma: admission season starts 1st April so before that please. bas simple sa hi hai na

Why open innovation matters here

Client briefs are private. They hold prices, business plans and sometimes customers' names. Panga runs on open-weight models: Gemma 4 (gemma-4-31B-it) for reasoning and Qwen3 (qwen3-embedding-0.6b) for search, served by DigitalOcean. Neither is a closed vendor's model whose terms can change under me. Panga talks to any OpenAI-compatible endpoint, so a freelancer who wants nothing leaving their machine can point it at Gemma on their own laptop or GPU box by changing a couple of settings.

The business only works if it's cheap. A deal check is several model calls: extraction, a practice call, a replay, research, a reply. On an open model with serverless inference, that's well under a rupee, which is what makes a ₹49 price possible for people who are themselves paid in rupees.

The trust doesn't depend on the model being perfect. Open models make mistakes, and so do closed ones. Panga doesn't hope Gemma is right. It checks: quotes must match the source, maths is done in code, and reply amounts are verified. That makes a smaller open model good enough for a job where money is on the line.

The whole stack is open. Mastra for agents, Temporal for workflows, Postgres with pgvector for search, and Panga itself under MIT.

How I built it

Browser ──► Next.js on Render ──► Mastra agents ──► Gemma 4 on DigitalOcean
               │                                   (scope analyst, researcher,
               │                                    client simulator, writer)
               ├──► Tiger Data (Postgres + pgvector): deals, past projects, hybrid search
               ├──► Backboard: memory of your rates, tone and corrections
               ├──► SerpApi: "What's involved?" research with sources
               └──► Sentry: traces of every agent run and model call

Voice call: Browser ──► ElevenLabs agent ──(Custom LLM)──► Panga /api/sim ──► Gemma

106 automated tests cover the money maths (including a worked example from the spec), quote matching, the practice call's hidden tags, reply amount checks, the database layer and the deal workflow.

Every sponsor in Panga, and exactly what it does

Panga uses ten of this challenge's partners. Nine run in the live demo. One (Temporal) is built and tested but switched off on the free deployment, and I say why below.

Sponsor	Its job in Panga	Live in the demo?
DigitalOcean	Runs every AI call: Gemma 4 and the Qwen3 embeddings	Yes
Gemma	The only reasoning model	Yes
Mastra	The four agents	Yes
ElevenLabs	Voice practice call, voice-note transcription, demo narration	Yes
Tiger Data	The database, and hybrid search over past projects	Yes
Backboard	Remembers your rates, tone and corrections	Yes
SerpApi	Live web research with sources	Yes
Sentry	Traces every agent run, model call and token	Yes
Render	Hosts the app and the agents	Yes
Temporal	A durable workflow for each deal	Built and tested, not live

DigitalOcean: where the AI runs

What it is: DigitalOcean's Gradient AI Platform includes Serverless Inference, which serves open-weight models behind an OpenAI-compatible API and bills per token.
What it does in Panga: it runs every AI call. Gemma 4 (gemma-4-31B-it) handles all the reasoning, and Qwen3 (qwen3-embedding-0.6b) makes the embeddings behind past-project search.
How it's wired: the Mastra agents point at https://inference.do-ai.run/v1 with a DigitalOcean model key (src/mastra/index.ts). Embeddings come from the same endpoint's /v1/embeddings (src/server/embeddings.ts). The repo also ships an App Platform spec (.do/app.yaml). Panga first ran on App Platform, then I moved hosting to Render's free plan to keep the build at ₹0.
Where you see it: every result in the demo: the work list, the practice call, the replay, the research and the reply.

Gemma: the brain

What it is: Google's family of open-weight models.
What it does in Panga: Gemma 4 31B is the only reasoning model. It reads the brief and the chat, plays the client on the practice call, reviews the call for promises, summarises research and drafts the reply.
How it's wired: DigitalOcean serves it (above) and Mastra calls it (below). Because any model can be wrong, Panga checks Gemma's work in code: quotes must match the client's text, all money maths is TypeScript, and every amount in a reply is checked against Panga's own numbers.
Where you see it: Sentry counts 24 Gemma calls and 27,063 tokens on the live app this week, all on gemma-4-31B-it.

Mastra: the agents

What it is: an open-source TypeScript framework for building AI agents.
What it does in Panga: four agents run on Gemma, each with its own instructions:

Agent	Its job	Where you see it
Scope analyst	Lists the work in the brief and chat, quoting the client. Later, reviews the practice call for promises.	Step 01 and the replay
Researcher	Explains an unfamiliar requirement from live search results	"What's involved?"
Client simulator	Plays the client on the practice call, by text or voice, streaming	Step 03
Proposal writer	Drafts the reply in your tone	Step 04

How it's wired: src/mastra/index.ts defines the agents. JSON steps use generate, and the live call uses stream. Mastra's observability exporter sends every run to Sentry.

ElevenLabs: the voice

The ElevenLabs category names three uses: give an open-source agent a voice, transcribe audio, or narrate the demo. Panga does all three.

A voice for the open-model client. The voice practice call is an ElevenLabs Conversational AI agent whose Custom LLM is Panga's own endpoint (/api/sim/v1/chat/completions, locked with a shared secret). ElevenLabs listens, handles turn-taking and speaks. Gemma, through the client-simulator agent, decides every word the client says, based on this deal's brief. The browser starts the call with a short-lived signed URL from Panga, so the API key never reaches the browser.
Transcription. "Add their voice note" sends a client's voice note to ElevenLabs Scribe (scribe_v2), and the text joins the brief for Gemma to read.
Narration. The demo video's voice is ElevenLabs text-to-speech (voice "George", eleven_multilingual_v2). Hindi lines are written in Devanagari so they're pronounced correctly, and I checked every clip by transcribing it back with Scribe.

Tiger Data: the database and the search

What it is: managed Postgres with pgvector, running on Tiger Data's free plan.
What it does in Panga: it stores deals, practice calls and your library of past projects, and finds the past projects most like a new brief.
How it's wired: every past project is saved with a Qwen3 embedding (pgvector) and a full-text index. One SQL query runs a hybrid search: score = 0.7 × vector similarity + 0.3 × keyword rank (src/server/projects-repo.ts).
Where you see it: past projects that match a new deal, and the Memory & library page.

Backboard: the memory

What it is: an API that gives AI apps long-term memory and search over it.
What it does in Panga: it remembers you between deals: your minimum hourly rate, currency, tone, work you never include, and every correction you make to an extracted work list.
How it's wired: each workspace gets one Backboard assistant, and its ID is kept in Postgres. Preferences and corrections are saved as Backboard memories. When a new brief arrives, Panga searches those memories with the brief's text and puts the best matches into the scope analyst's prompt (recallForBrief in src/server/memory.ts). A correction you made last month shapes this month's work list.
Where you see it: the Memory & library page.

SerpApi: the research

What it is: an API that returns search engine results as JSON.
What it does in Panga: it powers "What's involved?" on any work item, for when you don't know how big something like "weekly online tests" really is.
How it's wired: the top five Google results from SerpApi go to the researcher agent, which must cite them as [1], [2] and so on. Citations that don't point to a real result are removed, and an answer with no valid citation is replaced by the sources themselves. Each search is its own Sentry span (panga.research.search).

Sentry Agent Tracing: watching the agents work

What it is: Sentry's tracing for AI agents. Every agent run, model call, token count and cost becomes a span you can inspect.
How it's set up: Mastra's Sentry exporter (@mastra/sentry) is plugged into Panga's Mastra instance, so every agent run and Gemma call is traced without extra code per call. Sentry's Node instrumentation adds the Postgres queries to Tiger and the HTTP calls to Backboard, SerpApi and DigitalOcean to the same trace. I added custom spans around the non-AI steps (panga.verify_quotes, panga.research, panga.research.search). Errors are reported with the step that failed, such as memory.recall or elevenlabs.transcribe.

How it performs on the live app over the last 7 days (the panga project only, so these are my test runs and the demo):

Agent run	Time	Tokens
Scope analyst, reading a full brief	28–47 s	about 2,000
Scope analyst, reviewing a practice call	4–7 s	750–900
Client simulator, one turn of the call	1.0–2.5 s	870–1,000
Proposal writer, drafting the reply	5.5 s	600

In total, 24 Gemma calls used 27,063 tokens. Sentry estimates every trace at less than $0.01.

What I found:
- Reading the brief is the slow step. It took 45 s in the trace above, 351% slower than the average Gemma call (10 s). But the request that starts it returns in 343 ms, because the analysis runs after the response. The trace shows why Panga can show a live "reading" screen instead of a frozen button.
- A new workspace pays a one-time 236 ms to create its Backboard assistant (POST /assistants). Later deals skip that step because the ID is saved in Postgres. The waterfall shows the lookup, the create and the save in order.
- The prompt fills 1% of Gemma's 256K context window, so even a long WhatsApp thread has plenty of room.
- A client-simulator turn takes 1–2.5 s, which is quick enough for a spoken conversation.
How it helps me debug: when something fails, the error lands in Sentry tagged with the step, inside the same trace as the model call and the database queries. So I can tell whether Gemma, Postgres or a partner API was at fault.

Render: where Panga lives

What it is: a cloud hosting platform.
What it does in Panga: it runs the whole live app: the Next.js site, the four Mastra agents, and the Custom LLM endpoint that the ElevenLabs voice agent calls during a practice call. So Render is the runtime for the agents, not just a host for static pages.
How it's wired: a free web service that builds with npm ci && npm run build, checks health at /api/health and redeploys on every push to main. Node starts with a 400 MB memory cap to fit the 512 MB plan, and the app runs at around 210 MB.

Temporal: built and tested, not live

What it is: a workflow engine that makes long-running work durable. It survives restarts and retries failed steps.
What it does in the code: one workflow per deal (dealReview). It retries the analysis (3 attempts, starting at 5 s). It waits up to 30 days for the practice call, the scope confirmation and your decision. Then, 14 days after the decision, it asks how the project went.
The honest status: the tests run this workflow, long timers included, in seconds on Temporal's time-skipping test server. The live demo does not use Temporal, because Temporal Cloud asked for a card and I kept this build at ₹0. Instead, the live app runs the same steps inside the web process. Setting TEMPORAL_ADDRESS (plus a key) and PANGA_EMBEDDED_WORKER=true starts the worker inside the web server.

The parts that fought back

Some of the most useful lessons came from things breaking.

Gemma invented quotes. It would "quote" the client with words the client never wrote. Fix: a matcher that forgives curly quotes and spacing but not words, and that maps the match back to the exact original text. Unmatched quotes get dropped and counted.
"Budget 20-25k" became ₹25,000. The model kept taking the top of a range. Prompt rule: a range means the lower end. The reply checker learned to read ranges too, with a test.
Deadlines kept turning into work items. "Before April" isn't a deliverable. The prompt says so, and the dry runs confirm it.
A 900 MB database on a 512 MB server. Locally, Panga uses PGlite (Postgres compiled to WASM) with pgvector. It's lovely, but on my machine it used about 900 MB the moment it started, far more than the 512 MB Render's free plan allows. The live app uses Tiger Data instead and sits around 220 MB.
Tiger's certificate was "self-signed in the chain". Newer node-postgres treats sslmode=require as "verify everything", and Tiger uses its own certificate authority. Every query failed. Fix: read sslmode=require the way libpq does (encrypted, certificate not pinned), with a test.
Backboard returned 500 for one word. Saving preferences failed, but only for some of them. After a few probes I found it: Backboard's API rejects any memory whose metadata has a text field named value. Renaming the field fixed it, and old memories still read back.
Temporal wants a worker. Free hosting doesn't do workers. So the worker runs inside the web server when needed, with the workflow code bundled during the build so the server never has to run webpack at startup. It costs about 70 MB.

Running it for ₹0

Piece	Where	Cost
App	Render free web service	₹0
Database	Tiger Data free service	₹0
Model	Gemma on DigitalOcean (trial credit)	well under ₹1 per deal
Research, memory, voice, tracing	SerpApi, Backboard, ElevenLabs, Sentry free plans	₹0

Prize categories

I'm entering the ten categories explained above:

Best Use of DigitalOcean
Best Use of Gemma
Best Use of Render
Best Use of ElevenLabs
Best Use of Mastra
Best Use of Tiger Data
Best Use of Backboard
Best Use of SerpApi
Best Use of Sentry Agent Tracing
Best Use of Temporal (built and tested, but not live; see its section)

Panga doesn't use TabPFN, Tinker, Arduino, Entire, GitHub Copilot, MongoDB Atlas or a .tech domain, so I'm not entering those.

What's next

Laptop mode: Gemma running locally, so a brief never leaves the freelancer's machine.
A contract from the agreed scope: the final work list, prices and "not included" items, ready to sign.
Learning from real outcomes: if your "simple sites" always run 40% over, Panga should quote you 40% higher before you're tempted not to.

Every freelancer will pick a panga sooner or later. Panga just makes sure you know what you're picking.

Panga lo. Par soch samajh ke.
Pick your panga. Wisely.

Ask an AI for your home loan EMI and it will be off by ₹10. Every month.

Reet Singh — Sun, 11 Oct 2026 14:06:52 +0000

This is a submission for the Kaggle Benchmarking Challenge

Last week I built a little app about Ananya. She's made up, but you know someone like her. She's 31, she's been saving for eight years, and she's about to sign for a ₹72 lakh 2 BHK whose brochure says 1,050 sq ft. The registration says the carpet area is 720.

While I was building it I kept asking chatbots for help with the numbers: what's ₹72 lakh in crore, what's the price per sq ft of carpet, what's the EMI on the loan. The answers sounded confident. I had no idea whether they were right.

So I benchmarked it. Then my benchmark turned out to be too easy, so I made it harder. That second part is where the real findings are.

What I Benchmarked

Lakh, Crore and Carpet Area is 100 deterministic questions about the money and property maths Indian buyers actually do. Every answer was computed in Python, not by hand.

Tier	Group	Cases	Example
Core	Conversion	15	"₹1.2 crore minus ₹45 lakh, in lakh?"
Core	Area	15	"Super built-up 1,300 sq ft, carpet 910. Loading as a % of carpet?"
Core	EMI and tax	15	"₹72,00,000 at 8.4% for 25 years. Monthly EMI?"
Core	Format	15	"Write 98765432 with lakh/crore commas" → 9,87,65,432
Hard	Multi-step loans	15	prepay ₹5 lakh after 36 EMIs, keep the EMI: how many EMIs are left?
Hard	Tax rules	7	80C and 24(b) caps, LTCG with cess, circle rate vs agreement price
Hard	Regional land units	8	guntha, cent, Chennai ground, bigha-biswa, Punjab vs Haryana marla
Hard	Hinglish	10	"72 lakh ka flat hai, 20% down payment, baaki 8.5% pe 20 saal. EMI kitni?"

Each prompt asks for at most five lines of working, then ANSWER: <value>. Numbers are checked against the true value (a rupee or two of slack where rounding is involved, an exact string match for the format group). Tax questions state the rule inside the prompt, so they test arithmetic, not whether a model knows this year's tax law. The scorer also flags any response that slips into Western grouping (7,200,000 instead of 72,00,000), even when the final answer is right. I call that western comma drift.

Why this matters to me: hundreds of millions of people think in lakh and crore, and property listings in India are famous for blurring carpet and super built-up area. If a model is going to sit inside a home-buying assistant, these are its first questions, not edge cases.

Models Tested

A spread you'd actually reach for in a product, across three providers and two price tiers: Gemini 3.7 Flash, Gemini 3.1 Pro Preview, Claude Haiku 5.5, Claude Sonnet 4.6, Gemma 4 31B (open-weight) and GPT-5.4 mini.

Findings

1. My first benchmark was too easy

Version 1 was just the 60 core questions. Every model scored between 0.92 and 1.00:

Model	Core score (60)
Gemini 3.7 Flash	1.00
Gemini 3.1 Pro Preview	0.98
Claude Haiku 5.5	0.98
Claude Sonnet 4.6	0.95
Gemma 4 31B	0.95
GPT-5.4 mini	0.92

A benchmark where everyone gets an A tells you nothing about which model to ship. So I added 40 harder cases, the kind of questions a buyer asks after the first EMI: prepayments, rate hikes, balance transfers, tax caps, regional land units, and the same maths in Hinglish.

2. The hard tier opened a 35-point gap

Model	Score (100)	Hard tier (40)	Multi-step loans	Tax rules	Regional units	Hinglish	Comma drift
Claude Haiku 5.5	0.97	37/40	12/15	7/7	8/8	10/10	16%
Gemini 3.7 Flash	0.94	34/40	10/15	6/7	8/8	10/10	8%
Gemini 3.1 Pro Preview	0.94	34/40	11/15	6/7	8/8	9/10	10%
Gemma 4 31B	0.87	31/40	8/15	6/7	8/8	9/10	22%
Claude Sonnet 4.6	0.85	29/40	7/15	7/7	7/8	8/10	13%
GPT-5.4 mini	0.77	23/40	2/15	7/7	7/8	7/10	6%

On the core 60, these four were 8 points apart. On the hard 40, they're 35 points apart, and the ranking flipped: Flash, the v1 winner, is now second.

3. Multi-step loans break everyone

Models that nailed single EMIs still stumbled once the loan had a history. Even the best model missed 3 of 15. GPT-5.4 mini got 2 of 15.

The scariest miss was l13: "You can afford an EMI of ₹50,000 at 8.5% for 20 years. What's the largest loan you can take?" The answer is about ₹57.6 lakh. GPT-5.4 mini said 537,000. That's roughly ₹5.4 lakh, a tenth of the real figure, delivered with the same confidence as everything else.

The near-misses are worse in a quieter way. On e04 (₹72,00,000 at 8.4% for 25 years) the correct EMI is ₹57,492. In v1, Claude Sonnet 4.6 said ₹57,487 and Gemini 3.1 Pro Preview said ₹57,482. None of them said "approximately". (1 + r)^300 is exactly where mental arithmetic slips.

What this changed for me: in anything I ship now, the model explains the formula and a tool computes the EMI.

4. The bigger model lost to the cheaper one

Claude Haiku 5.5, the small tier, beat Claude Sonnet 4.6 by 12 points overall, and by 8 cases on the hard tier. Price tier was a worse predictor of accuracy than I expected, so test the model you actually plan to pay for.

5. What I thought would be hard, wasn't

I predicted regional land units would be the bloodbath, since bigha and marla change meaning from state to state. But when the conversion is given, models handle it: 30 of 32 right across the four models. Tax rules stated in the prompt were nearly perfect too (27 of 28). The only tax miss was Gemini 3.7 Flash on t02, which forgot the buyer had already used ₹90,000 of their 80C limit and answered ₹3,30,000 instead of ₹2,40,000.

The difficulty is in chaining steps, not in unfamiliar units.

6. Hinglish costs accuracy for some models

Haiku and Flash got all 10 Hinglish questions right. Sonnet dropped 2 and GPT-5.4 mini dropped 3, on sums like total interest and carpet-from-loading that are routine in English. If your users type "EMI kitni banegi?", test in that language.

7. Models drift into Western commas even in an Indian question

Every model aced the format group when asked directly. Yet 6–16% of responses still wrote something like 4,000,000 somewhere in their working. It doesn't make the answer wrong, but it's exactly the slip that makes "₹40 lakh" read as "₹4 crore" to a tired buyer at 11 PM.

8. My benchmark lied to me first

My first run said Claude Opus 5 scored 0.08, and GPT-5.5 errored completely. I almost wrote a post about it.

Then I opened the run logs. Every failure was a 403 PermissionDeniedError: max estimated cost exceeds your available quota. I'd fired cases in parallel, the expensive models blew through the quota, and my scorer counted each errored call as a wrong answer. Opus 5's printed table actually showed 100% on every group it got to answer.

I fixed it: sequential calls, per-case progress logging, and every run prints answered: X of 100 before any score. I dropped the two most expensive models rather than publish a number I can't stand behind.

The lesson: a benchmark score is only as honest as its error handling. If a leaderboard can't tell you how many questions were actually answered, don't trust the leaderboard.

What I'd measure next

Give the models a calculator tool. Do the multi-step loan errors vanish, or do models skip the tool when they feel confident?
Leave the unit definition out. Ask "2 bigha in sq ft?" with no state, and score whether the model asks which state instead of guessing.

My Benchmark

Benchmark: https://www.kaggle.com/benchmarks/reet22/lakh-crore-and-carpet-area
Task: https://www.kaggle.com/benchmarks/tasks/reet22/lakh-crore-carpet-area
Notebook (all 100 cases and the scorer): https://www.kaggle.com/code/reet22/lakh-crore-and-carpet-area

Fork it, add your city's stamp duty, and tell me which model gets your home loan right.

Wanderlore: What if your next walk had a plot?

Reet Singh — Sun, 11 Oct 2026 12:32:16 +0000

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

The first time I tried to test my walking app properly, I couldn't even get it to find me.

I was on my laptop, staring at another location timeout. I kept wondering what was wrong. How was I supposed to build a story that followed a walk if it couldn't tell where I was?

Then I tried it on my phone. It detected my location and picked up my movement. After all that testing at a desk, the part that finally worked was the part that meant leaving it.

That little moment made Wanderlore feel real to me.

I wanted a walk to have a little anticipation: a reason to notice something, a character to follow, a small mystery waiting around the next chapter. If you've ever wanted a reason to step outside but couldn't quite find one, this is the feeling I built it around.

What I Built

Wanderlore turns a walk into a narrated, interactive story.

You choose folklore, mystery, or fantasy, decide how long you want to wander, and tell it what the weather looks like. The page responds too: choose rain and the scene gains drizzle, with rain ambience after you enable sound.

When you begin, Gemma writes a short chapter and a narrator reads it aloud. In location mode, each new chapter uses your latest position and nearby named places when your selected map pack covers the area. Your earlier chapters and decisions help shape what happens next.

The choices are small invitations into the story. Do you look more closely at the lantern? Ask its keeper a question? Offer to help? Your answer becomes part of the next chapter's context.

Some days you might want to make every decision. Other days, you might just want to listen. Continue automatically lets the storyteller choose and starts the next chapter after narration finishes. Keep the browser visible while using it; background and locked-screen continuation are still future work.

When you're done, save the walk, leave a reflection, and export your story. I like the idea of coming home with a small memory of what you noticed.

Demo

Open the live preview

The hosted walk currently requires a private demo access code. The screenshots below show the live experience without exposing a personal route.

Mobile layout, captured at 390 × 844 pixels in a browser. Real location and movement were also tested on my phone.

This chapter uses Sample walk: its route and place names are fictional. It was generated and voiced in 3.8 seconds in this particular test.

For a first try, choose ten minutes and whichever genre you feel like hearing. On a phone, allow location and use Use my location. On a laptop, Sample walk lets you explore the storytelling without relying on desktop location services.

The sketch records the story's route; it doesn't provide walking directions. The current Lucknow map pack covers central and adjoining areas. You can import a GeoJSON pack for another area; without matching nearby places, the story uses general surroundings.

Code

Wanderlore on GitHub

The app uses Python, FastAPI, and a responsive HTML/CSS/JavaScript frontend. The application code is GPL-3.0; model and map data have their own terms. OpenStreetMap contributors provide the underlying place data. I used Codex to help implement, debug, and test the project.

How I Built It

Gemma is the story engine. The local setup supports Gemma 3 through Ollama. The hosted preview uses gemma-4-26b-a4b-it through Google AI Studio because the small free hosting instance cannot run the local model stack. Chapters carry forward the previous story, selected choices, genre, weather, and available place context.

ElevenLabs supplies the hosted narration. I wanted the voice to feel like someone telling you a story, with enough warmth to keep listening. The hosted version uses the Roger voice. The local setup also supports Kokoro after downloading its voice assets.

Tiger Data supplies a small, sourced place-context pack. I stored four summaries of public Lucknow sources in PostgreSQL with pgvector. Keyword and vector results are combined with reciprocal rank fusion. A verified retrieval produced context for Rumi Gate and Janeshwar Mishra Park, which is exported for the storyteller to read. This is a prepared context pack; walking doesn't trigger a database query for every step. The resulting tale is fiction, even when it includes a real place.

Sentry makes the wait visible. I instrumented the chapter pipeline with a wanderlore.chapter transaction and spans for generation and speech. One verified development trace for Gemma generation measured 3.28 seconds. Seeing where time goes helps me assess the pauses between chapters. The trace integration exports timing and model metadata while excluding prompts, story text, GPS, cookies, and request bodies.

Render hosts the HTTPS preview on its Free plan. That made phone testing possible without running the server on my laptop. The hosted version needs internet for generation and narration. Free hosting can sleep and reset saved files, so exporting a walk matters.

Verification included 29 passing Python tests, five automatic-continuation scheduler tests, and a live browser check where a second chapter started without selecting a choice or pressing Next. My phone detected location and movement; desktop location remained unreliable on my setup.

Why Does Open Innovation Matter?

For Wanderlore, it means having a path to storytelling on your own machine. Gemma's available weights let the local version generate chapters through Ollama, and Kokoro provides a local voice option. After the models and assets are downloaded, that setup can work offline with the local server running.

The hosted preview trades that independence for easier access. It sends story context and nearby place names to Google, and narration text to ElevenLabs. Raw landmark coordinates are stripped from the generation payload, although the hosted server still processes GPS. These are different ways to run the same idea, with different privacy and connectivity needs.

I also want people to be able to improve the experience: bring their own map pack, experiment with a narrator, or make the choices more interesting. Open application code makes those changes possible.

Prize Categories

I'm entering these categories based on the integrations above:

Best Use of Gemma — context-aware chapter generation, with local and hosted inference paths.
Best Use of ElevenLabs — spoken narration for generated chapters.
Best Use of Tiger Data — pgvector and keyword retrieval for sourced place context.
Best Use of Sentry Agent Tracing — instrumented generation and narration, with trace evidence shown above.
Best Use of Render — the deployed HTTPS web experience used for phone testing.

If there's a familiar path near you, that's where I'd start. Pick a mood, give yourself ten minutes, and see what you notice when there's a story waiting for you.

I'd love to hear which genre you'd take on your first walk—and what you would want to happen next.

Maa ka Drawer: finding my mother’s bills with Tiger Data and open multilingual search

Reet Singh — Mon, 05 Oct 2026 05:53:57 +0000

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

What I Built

A receipt can be saved and still be hard to find. You remember the washing machine, the shop, or what broke, not necessarily the filename or invoice number.

I built Maa ka Drawer for my mother: a small household receipt finder that combines open multilingual embeddings with Tiger Cloud PostgreSQL keyword and vector search. The goal is to make “find that bill” a smaller job.

I chose the problem for this prototype. I have not yet tested it with her, so I cannot claim that it has saved her time or quote feedback she has not given.

The app opens onto a drawer of illustrated cards. Hovering lifts and tilts a card; tapping or clicking opens the receipt. Search works over the saved text, and an original PDF or photo can stay attached. If the receipt does not state a warranty expiry, that field stays blank.

Less typing: upload or speak

A JPG, PNG or PDF upload now extracts text and suggests a recognised bill type. A synthetic electricity bill became Electricity bill → Services, retaining its INR 400 amount and original image. Tesseract.js reads English/Hindi text on the app server. PDF.js reads embedded text directly; scanned-page OCR is implemented, limited to the first three pages, but its browser retest is still pending. Photos and embedded-text PDFs passed functional checks. Blurred photos, handwriting and unfamiliar bill layouts can fail.

Speak receipt records a short Hindi or Indian English note, or accepts an audio file. Local Whisper-small, via the ONNX conversion and Transformers.js, transcribes the audio. A conservative parser suggests the item and explicitly stated amount. A synthetic Hindi development recording produced Electricity bill · ₹400; the imperfect transcript remains visible for correction. Voice notes are labelled as notes, not original invoices. The recording is temporary; only reviewed text is saved.

The voice verification record uses two Murf-generated development fixtures, not a held-out accuracy test or my mother's feedback. Transcription and cloud save/reload were verified separately. Further live-microphone and noisy-household testing remains pending. Murf Isha provides the Indian English demo narration; Murf does not transcribe user notes.

Demo

Watch or download the narrated demo video.

The video is a captioned walkthrough with Murf Isha Indian English narration assembled from screenshots captured during real interactions with the app. It shows Hindi search, receipt evidence, a no-match query, uploading a receipt photo with OCR, Hindi voice transcription, an attached PDF, archive, undo, and persistence after reload. It is not a continuous screen recording. Every demonstrated receipt is fictional.

Demo release and setup notes · Expanded scene notes

Code

Browse the complete source on GitHub.

The repository includes the app, MIT license, PRD, schema, tests, evaluation queries and results. Run it locally with Node.js 22+, npm ci, npm run build, and npm start.

How I Built It

The useful AI task here is retrieval. A Hindi query such as कपड़े धोने वाली मशीन can find an English washing-machine receipt even when the exact query words are absent.

The model is multilingual-e5-small, using Xenova’s ONNX conversion through Transformers.js. Quantized inference runs on the app server. Queries and receipt chunks become normalized, 384-dimensional vectors.

PostgreSQL stores source text, metadata, full-text search vectors and pgvector embeddings. Exact words and invoice identifiers matter, so keyword search remains part of the system. Reciprocal rank fusion combines keyword and semantic rankings. A similarity gate filters weak or ambiguous semantic matches. These scores are not probabilities.

The interface uses React and Vite; Express serves the API and built app. PDF.js renders originals inside the receipt view. Codex helped implement and test the project, and generated appliance illustrations provide visual cues. The illustrations are not photographs of my mother’s possessions.

Tiger Data is the live data layer. A dedicated free Tiger Cloud service stores receipt text and 384-dimensional embeddings in pgvector. A live verification run passed saving, exact invoice retrieval, vector search, reconnect persistence, archive exclusion and undo. The verification record includes the timestamp and pgvector version. The original gallery/PDF walkthrough and retrieval benchmark used local PGlite. The new OCR and voice-entry captures were taken with the app connected to Tiger Cloud. Cloud persistence was verified separately.

The free service presents a private Timescale certificate authority. I pinned that CA locally on first connection and kept chain and hostname checks enabled for subsequent connections. This initial trust-on-first-use step is disclosed in the README; it is not a publicly authenticated certificate chain.

What worked—and what did not

I ran a fixed evaluation over six fictional receipts and 18 queries:

Search mode	Correct first result on 14 positive queries	Correct no-match responses on 4 negative queries
Keyword	8/14	4/4
Vector	11/14	4/4
Hybrid	12/14	4/4

The full query set and outcomes are public. This is a small, builder-authored evaluation. A Hindi washing-machine phrase was rejected, and a Hinglish ceiling-fan query returned the purifier. Those failures limit how confidently I can hand this to someone else.

All 21 automated tests pass, covering retrieval, identifiers, validation, source-file serving, archive/undo, database persistence, actual image OCR and conservative voice-note parsing. Desktop and phone layouts were checked in the browser.

Why Does Open Innovation Matter?

The open model gives this project a retrieval component I can run, inspect, replace and test without a hosted generative API. After the weights are downloaded, local mode keeps receipt data and inference on the laptop. The verified Tiger Cloud mode stores receipt text and embeddings remotely, while model inference and original attachments stay on the app server. That mode is not fully offline.

The model does one limited job: help locate existing evidence. It does not write an answer about warranty coverage. A user can open the saved text and original document and see what the receipt actually says.

That distinction shaped the rest of the app. Text extracted from a receipt or transcribed from speech stays editable and requires review. Dates are confirmed by the user. Archiving is reversible. The prototype is for one household and has no public account system.

My next step is a real trial with my mother: ask her to find a bill, observe the words she uses, and improve retrieval against those examples. That feedback will matter more than adding another animation.

Prize Categories

Best Use of Tiger Data — real receipt text and open-model embeddings are stored in Tiger Cloud PostgreSQL with pgvector. The application combines full-text and vector rankings, and the public verification record demonstrates the live integration.

The brochure said 18 floors. The registration said 12.

Reet Singh — Sun, 04 Oct 2026 08:12:55 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Let me introduce you to Ananya. She's made up, but you probably know someone exactly like her.

She's 31, works in Pune, and has spent eight years saving for her first flat. One Sunday she walks into a sales office for a project called Nimbus Greens. The brochure is gorgeous. Four towers rising to eighteen floors, a rooftop pool, possession in March 2027, a 2 BHK of 1,050 square feet for ₹72 lakh "all-inclusive", parking free. The broker is friendly and in a hurry. If she pays 20% today, the price is locked.

Here's the part nobody tells her. Everything she needs to make this decision is already public. Every project in India has to be registered with the state's Real Estate Regulatory Authority (RERA), and that registration is what the builder is legally held to. Then there's the draft agreement for sale, and the RERA Act itself. Nobody reads those three next to the brochure. So nobody notices that they tell a different story:

What the brochure says	What the record says
4 towers, G+18	3 buildings, sanctioned for Ground + 12
Possession from March 2027	Completion on 31 December 2028
2 BHK, 1,050 sq ft	690 sq ft carpet area
Rooftop pool, amphitheatre, EV charging	Not in the registered common areas
₹72 lakh all-inclusive, free parking	₹81,55,000 in the agreement, ₹4,50,000 of it for parking
All approvals in place	Environmental clearance applied for, still awaited
Pay 20% on booking	Section 13(1) of the Act allows 10% before a registered agreement

Nimbus Greens is fictional. Every row in that table isn't. These are the tricks Indian buyers find out about years later, once the money is gone and the building has stopped at twelve floors.

So I built Home Truth. You give it a project's documents and it lays them side by side, finds every place they disagree, and shows you the exact sentence from each document so you don't have to take its word for anything. It turns the gaps into a checklist of questions to ask the builder. And it has an agent you can ask the kind of question a broker throws at you on the phone: "I'm being offered flat B-1502, is that okay?"

Why this needed structured content

I tried the obvious version first in my head: dump the documents into a search index and let a model answer. Ask it "how many floors does Nimbus Greens have?" and the loudest, most confident answer in the pile is the brochure's "G+18". It's repeated, it's in large type, and it's wrong.

Getting it right takes knowledge that isn't written in any single document. You have to know that a registration outranks a brochure. You have to know that the law caps a booking amount at 10%, so a request for 20% is a violation, not a detail. And you have to know that "1,050 sq ft" and "690 sq ft carpet" are the same flat, measured two ways, and the brochure picked the flattering one. That knowledge lives in how the content is modelled. That's the bit I built in Sanity.

Demo

Live: https://home-truth-theta.vercel.app. No sign-in. Open Nimbus Greens and try the chat.

If you'd rather click around yourself, here's the two-minute tour.

Start on the home page and drag the building. It's drawn from the data: twelve solid floors are what the sanctioned plan covers, and the six translucent red ones on top only ever existed in the brochure. Scroll down and you can flip through the brochure itself in 3D, with the 20% line highlighted and Section 13(1) of the Act quoted right beside it.

Open the full report. Ten of twelve facts don't hold up, and five of those are critical. Every finding says why it matters to a buyer, and every one has a Show the exact words drawer with the quote from each document. One click on Questions to ask the builder turns all of it into a printable checklist that names the document to ask for.

Then ask the chat about flat B-1502. It goes to Sanity, checks the registration, sees that Building B is sanctioned for Ground + 12, and tells you a fifteenth-floor flat has no approved plan. Open How I checked under the answer and you'll see every query it ran.

Code

Reet24-del / home-truth

Compare builder promises with registered documents through cited findings and an interactive 3D building.

Home Truth

Before you pay for a flat, check the builder's promises.

Home Truth compares what a builder advertises (brochures, websites, broker messages) with what is registered with the state Real Estate Regulatory Authority (RERA), what the draft agreement for sale says, and what the Real Estate (Regulation and Development) Act, 2016 requires. Every finding shows the exact words it came from.

Built for the DEV x Sanity Challenge, Path One: an agent that queries real content through Sanity Context.

Why it needs structured content

Ask a keyword search "how many floors does Nimbus Greens have?" and the brochure answers "G+18" with total confidence. Home Truth knows three things a search engine doesn't:

Which document outranks which. The registration is what the builder is legally held to; the brochure is marketing. The sanctioned plan says Ground + 12, so floors 13 to 18 have no approved plan.
What the…

View on GitHub

studio/ holds the Sanity Studio, the schema, the comparison engine and the scripts. web/ is the Next.js 16 site, the three.js scenes and the agent.

How I Used Sanity

I started with the schema, because the schema is the product

Before any UI, I sat down with the question "what is a fact, here?" and ended up with five document types.

A sourceDocument is one document's full text, plus a kind: registration, agreement, marketing or law. That one field is what lets the system know who to believe.

An attribute is something a buyer cares about, like floors per building, carpet area or the possession date. It also says how that fact should be compared: the unit, a tolerance, a controlled vocabulary, and whether it's checked for equality or against a legal limit. "Floors" and "booking amount" behave very differently, and the attribute is where that difference lives.

A claim is one document's version of one attribute, together with the exact words it came from and where they appear. The demo project has 28 of them. A finding is the verdict once all the claims for an attribute are compared: match, mismatch, violation, or only one source. And a project ties it all together.

The rule I cared most about was that nothing gets paraphrased. Every claim carries a quote, and npm test checks each demo quote word for word against its source document. When Claude extracts claims from a new document, they go through the same check and land in the Studio's Claims to verify view, marked unverified, until a person approves them.

Code decides who's wrong, not the model

I didn't want an LLM deciding whether a builder broke the law. So findings come from a small comparison engine, studio/lib/compare.ts. It ranks the sources (Act, then registration, then agreement, then marketing), applies the tolerances and vocabularies, and checks legal limits. The same claims always produce the same findings, which means every line of the report can be traced back to a quote. The model's job comes later, and it's a narrower one: explain.

Pointing Sanity Context at it

This is where it got interesting.

I created a Knowledge Base in the Context app and pointed it at my own dataset, using a GROQ source query to pull in every document that has a body:

*[_type == "sourceDocument" && defined(body)]{
  title, kind, publisher, publishedAt, "project": project->name, body
}

For the Knowledge Base's purpose I wrote it the way you'd brief a person: who's going to ask questions (homebuyers in India), what should lead (buyer rights, registered facts, agreement clauses, red flags), and what's out of scope.

Then I hit Build entries, and Context came back with six issues. Every one of them was a conflict between the brochure and the registration. The floors, the number of towers, the possession date, the sizes of both flat types, and a jogging track advertised at 1 km that's registered at 600 m. Reading through them felt a bit like watching the product work on itself. I resolved each one in favour of the registration, and Context saved every decision as an instruction that future builds keep.

But "the registration wins" on its own throws away something useful. A buyer needs to know what they were promised as well as what's true, because that gap is exactly what they'll raise with the builder. So I added one instruction by hand:

When a marketing document contradicts a registration document, treat the registration as correct, but keep the marketing claim in the entry, labelled "Advertised", with its source.

Now the agent can say "you were told March 2027, but the builder is held to 31 December 2028", which is the sentence that actually helps.

I'll be honest about one gap. I meant to add the RERA Act as a PDF, as a second source. The government site wouldn't serve the file to my machine, so for now the law lives in the dataset as quoted claims, Section 13(1) on booking amounts and Section 14(3) on defect liability, and the agent reaches it through GROQ.

Two endpoints, two jobs

The agent talks to Sanity through two Context MCP endpoints, and keeping them separate was deliberate. An endpoint that has both a dataset and a Knowledge Base attached quietly serves only the dataset.

home-truth-data runs in GROQ mode and answers exact questions. Each chat narrows it to the current project by adding a groqFilter to the endpoint URL, so the agent only sees that project, the attribute definitions and the law. Context combines that filter with the endpoint's own, so it can only ever narrow access, never widen it. I also cut its tool list down to groq_query, schema_explorer and array_field_reader. The system prompt already explains the schema, so initial_context was just spending tokens.

home-truth-kb runs in Knowledge Base mode. That's where the agent goes for "what does this clause mean" and "what are my rights if possession is late". It calls initial_context once to get the outline, then knowledge_base_read for the entries it needs.

What the agent actually does

The agent runs on Groq with openai/gpt-oss-120b, using Groq's Responses API. Groq connects to both endpoints as remote MCP servers and runs the tool calls itself, so my server just sends the conversation and passes each step back to the page.

When I asked it how many floors the towers are registered for and what the brochure claims, it first ran:

*[_type == "finding" && attribute->label match "*floor*"]{status, severity, summary, "fact": attribute->label, entries}

Then it pulled the two claims behind that finding, opened the Knowledge Base outline, and read the possession and delays and buyer rights entries. The answer quoted the sanctioned plan ("Ground + 12") against the brochure ("G+18"), called it a critical mismatch, summarised Section 18 on delayed possession, and finished with what to ask the builder for and what not to pay yet. All five steps sit under How I checked.

The system prompt is short on personality and strict on rules. Trust the Act, then the registration, then the agreement, then marketing. Never invent a quote, a section number, a date or an amount. If neither source knows, say so and send the buyer to the state RERA portal or a lawyer.

The parts that bit me

Project tokens don't work for Context. I got a 403 until I made an organization token with Context Viewer.

Deploying the schema wasn't enough, either. The GROQ endpoint kept saying "No Studio application found" until I ran sanity deploy and the Studio went live. Then everything turned green at once.

The model has habits. gpt-oss leaves markers like 【result[0].quote】 in its prose and drops <br> into table cells, so both get stripped before an answer reaches the page.

And the chat didn't start on Groq. I first built it on Claude's MCP connector, then moved it over. Because both run MCP on their side, the switch touched one file of about 90 lines. Claude still does the claim extraction for new documents.

Sanity Project Details

The project ID is f5y6g2q3, and the production dataset is public. You can query it straight away: every project, or all the findings. The demo has 4 source documents, 12 attributes, 28 claims and 12 computed findings. The Studio is at https://home-truth.sanity.studio (sign-in required).

Ananya didn't pay 20% that day. She went home with a list of questions instead.

If you're about to book a flat in India, look the project up on your state's RERA portal first. Home Truth explains what the documents and the law say. It isn't legal advice.

Pani Kaisa Hai? A golgappa map that warns a neighbourhood about bad water, but only after a human checks

Reet Singh — Sun, 04 Oct 2026 07:50:29 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

Every golgappa wala in India gets asked the same thing before the first bite: pani saaf hai na? Is this water clean?

Nobody asks that about their own tap, borewell or tanker, even though contaminated supply is one of the most common ways a whole neighbourhood falls sick at once. The signs show up early (a sewage smell, yellow water, two kids in the same lane with loose motions) but they stay scattered across WhatsApp groups until it is too late.

Pani Kaisa Hai? collects those signs in under a minute, adds them up per neighbourhood against India's drinking water standard (IS 10500) and, only when the risk is real, asks a local health worker to confirm before anyone is warned.

Every neighbourhood is a golgappa on the map:

	State	What it means
🟢	Crisp	No credible signal
🟡	Soggy	Complaints rising, boil or filter first. This one is automatic
🔴	Phoot gaya	Contamination confirmed by a named person. Never automatic
✨	Fresh batch	Fix recorded, area recovering

The rule the whole thing rests on: software can make a golgappa soggy, only a person can make it burst. An AI check can score a case and push it as far as "needs verification". It can never confirm or dismiss one. Every red alert carries the name of the person who confirmed it and the reason they gave.

It is for residents, ASHA workers and residents' association volunteers in Indian cities. The demo runs on sample data for Indore.

Demo

Live: https://pani-kaisa-hai.vercel.app

/ the golgappa map, the stall and Shake the golgappa, a simulator that runs the app's real scoring code. Pile on signals and watch it go soggy on its own, then notice the "health worker confirms" button stays locked until there is evidence for a person to look at
/area/sector-14 an area page with the state, the reason and the arithmetic behind it
/report the four step report form
/control the verifier queue. Passphrase: pani-demo
/studio the embedded Sanity Studio

A 98 second walkthrough told as a story. The frames are the live site, captured by a script; the narration is Murf's Hindi voice Shweta.

Early warning from residents, not a lab test. All data in the demo is sample data.

Code

https://github.com/Reet24-del/pani-kaisa-hai

Next.js 16 (App Router, TypeScript, plain CSS Modules), Sanity Studio v6 embedded at /studio, an App SDK control room in control-room/, a Workflows definition in sanity/workflows/, a scheduled Sanity Function in functions/daily-tick/, Leaflet with OpenStreetMap tiles. 33 tests cover the risk score, the case rules (including "only a person can confirm"), the daily tick, the report input rules, the workflow definition and a lint for GROQ date comparisons.

My Build Process

I built this with Claude Code over about seven sessions between 19 September and 4 October and I kept a build log the whole way (BUILD_LOG.md in the repo), including the parts that went badly. This section is the short version.

Day 1: schema first, then the whole spine before the backend existed

I started with the data model, not the UI, because the product only works if evidence and decisions are kept apart:

report is one resident's observation and it is append-only. Corrections are new reports, never edits. An edited evidence trail is not evidence.
waterCase groups reports in one area and carries the verification status.
alert is a confirmed warning and cannot exist without a verifiedBy and a written reason.
safetyLimit and riskSettings hold the rules as content. IS 10500 thresholds carry their clause as a citation, so a wrong number is a content fix in the Studio, not a deploy.
waterSource.areasServed stores the source to area link once and areas read it back with references().
Area state is derived but stored, with a reason and a timestamp, so the map is one query and every golgappa can explain itself.

Nine document types, written by hand. The Studio desk is laid out the way work arrives: Needs verification → Active alerts → Unmapped reports, then reference data.

Then I asked Claude to stop following the day-by-day plan and just build, before I even had a Sanity project. That worked because of one early decision: when the Sanity env vars are missing, the home page renders setup steps instead of crashing. One guard (sanityConfigured) decides whether any query runs at all, so the whole UI could be built against the schema first.

In that session: the map and area pages, the four step report form, the report API (whitelisted fields, clamped numbers, a salted device hash instead of IP addresses, 3 reports per device per area per day), the risk score as pure functions with tests, the case engine and both control rooms.

What went wrong on Day 1:

defineLive comes from next-sanity/live, not the package root.
next build failed because the env module threw at import time, so a build with no Sanity project was impossible. I rewrote it to fall back to a placeholder project id.
Node's test runner needed allowImportingTsExtensions before --experimental-strip-types would accept .ts imports.

Reaching past the Studio: Workflows, the App SDK and Functions

Workflows. The verification flow lives in sanity/workflows/waterCase.ts as data: intake → score → watch or needs verification → human decision → alert → resolved → closed. The AI check is a system actor that can move a case as far as verification. Confirming or dismissing sits in a decide activity whose actions are gated on the verifier role. An agent and a person use the same transitions, only the person can take the last one.

The engine's own validator rejected my first version twice. The workflow name had to match ^[a-z0-9][a-z0-9-]*$ and every activity needed an action carrying status: 'done' or the stage gate wedges. That is how I know the definition is real and not decorative.

Being honest about where it stands: Workflows is in early access and the engine is not deployed on my project yet. Until it is, the same stages and the same human-only guard run through sanity/lib/cases.ts, which the report route and both control rooms call. The workflow file passes defineWorkflow's validator and has tests.

App SDK. control-room/ is a custom app for the Sanity Dashboard: the verifier queue with live data, the evidence for each case and the confirm or dismiss decision. Confirming writes the case decision and the alert in one transaction. There is also a /control page in the Next app behind a passphrase, so judges can try it without a Sanity login. Both write the same fields.

Sanity Functions. The daily tick (quiet cases close, a Fresh batch goes back to Crisp after its quiet days, every golgappa is re-derived) is a scheduled Sanity Function in functions/daily-tick/, deployed from sanity.blueprint.ts with its own robot token that only has Editor rights on this project. It calls the same runTick as the app, which takes any Sanity client, so the function and the old Vercel cron share one tested implementation. The cron stays as a backup 15 minutes later; a second run changes nothing. Its first deployed run timed out at the 10 second default, because re-deriving every area takes longer than that from Sanity's servers, so the blueprint now gives it 120 seconds.

Custom Studio input. Readings are drawn against their limit in the Studio, using the same component the control room uses, so an editor sees "780 mg/L, over the 500 acceptable limit" instead of a bare number.

Day 2: the theme and a hard lesson about drawing people

The first palette was cool mint, which is wrong for a golgappa. I rebuilt the tokens from the stall itself: sand, tamarind, saffron, roasted brown, imli pani, fried puri.

What failed. I wanted a girl at the stall, pouring pani into a golgappa and reacting to each section as you scroll. Claude hand-drew her in SVG over three passes. The face worked, the arms never did: stroked limbs with separate hand shapes leave a lump where the outlines cross. After the third try the honest call was that hand-authoring a natural human figure in raw SVG paths was not going to get good, so we stopped iterating.

What worked. I generated her instead. One reference image from a detailed prompt, then three more moods generated from that image as the reference, changing only pose and expression, which is what kept her the same person. Backgrounds were cut out locally with sharp (flood-fill from the border, clear the big white gaps in the hair, keep small ones like eye whites, recolour the feathered edge so there is no white fringe on the dark theme). About 42 KB per pose as WebP. The image tool's schema was opaque, the free plan allowed one job at a time and I ran out of credits after four images, so the fifth mood reuses a pose.

Scroll bug. The first version used an IntersectionObserver and got silently stuck, because the figure itself carried data-mood so the observer kept picking her own mood. Then the footer never triggered because it is too short to reach the middle of the screen. One check per animation frame replaced both.

Day 3: dressing the page as an actual stall

Feedback was that the girl was right but the page still read like a SaaS template. So it became a thela: a scalloped awning with bunting in pure CSS, a signboard headline with पानी painted huge behind it, an LED ticker reading every area's state off Sanity, a chalkboard "Aaj ka menu" with the action where the price would be and the Shake the golgappa simulator running the real scoreReports from lib/risk.ts.

Bug caught by clicking, not by reading: three fast clicks on "+" counted two, because the stepper computed value + 1 from a stale render. Functional updates fixed it.

Deploy day

Vercel refused the first deploy: the Hobby plan only allows daily cron jobs and my vercel.json ran the case tick every 15 minutes. The tick only closes quiet cases and returns recovered areas to Crisp, so daily is enough.
I finally checked the IS 10500 numbers I had written from memory on Day 1. Every value was right, but two citations were wrong (chlorine is in Table 2, bacteria in Table 6). Because limits are content, the fix was a three document patch, not a code change. That was the schema decision paying off.
The hero said "Indore · live" right under a banner saying "Sample data". It now says demo.

3 October: auditing the decision path

I asked Claude to rate the project as a judge would. It gave functionality a 7, so I asked what would make it a 9.5. The answer was an audit of every path from report to alert, and it found real bugs:

The App SDK control room only ever wrote drafts. @sanity/sdk edits the draft unless the document handle says liveEdit: true. Confirming in the Dashboard made a draft alert the public site never saw. Now the decision, the alert and the area turning red go in one live-edit transaction.
"Mark fixed" had no button, so Fresh batch was unreachable from the control room.
A case could be confirmed twice, which made two alerts. Decisions now act only on cases waiting for a person, every write is guarded by the case _rev, and the alert id is derived from the case.
Server actions trusted the page. Server actions are public endpoints, so each one now checks the sign-in itself.
A reporter's phone number was one GROQ query away on a public dataset. Contact details now live in private.contact.<reportId> documents. Ids with a dot sit on a path that Sanity never returns to unauthenticated requests.
A date filter never matched. submittedAt is a string, and comparing it to dateTime(now()) without dateTime() was always false. Area pages showed no reports and the rate limit never fired. There is now a test that scans every GROQ string for that mistake.

The case rules became pure functions with tests, so "the scorer can raise a case to needs verification and never past it" is tested directly. Tests went from 11 to 29.

The last evening: a check from a stale copy

On the last evening I asked a local Claude Code session "what is left". It read an old copy of the project on my Mac that had no git remote and stopped at 21 September, so its first answer was confidently wrong. The mistake surfaced when a CLI deploy from that folder was blocked by Vercel: its commits were authored with an email the Hobby plan doesn't accept. That block saved me, because the deploy would have replaced the day's fixes with week-old code. Comparing the blocked deploy's metadata with the live one showed where the real repo was.

It still found things worth fixing. /api/cron/tick would run for anyone, because the secret check only ran if CRON_SECRET was set, and it wasn't. Now the secret is set and the route fails closed on any deployment. The citation fix had been written but never run against the live data. Two old write tokens from before the rotation were still active, and are now deleted. Then I confirmed the Sector 14 case myself in the control room and watched the area go red on the map.

What I deliberately did not build

Photo upload on reports. Asset uploads need the write token path designed properly and a reading carries more weight than a blurry photo.
A Hindi interface. The content is bilingual (area names, advice, alert precautions), the UI chrome is still English.

Sanity Project Details

Project ID: ya4g5th1
Dataset: production (public)
Schema: sanity/schemaTypes/ (9 types), workflow: sanity/workflows/waterCase.ts, App SDK app: control-room/, scheduled Function: functions/daily-tick/ with sanity.blueprint.ts

I built The Repair Line: turning small repairs into shared relief

Reet Singh — Mon, 07 Sep 2026 08:04:32 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

I built The Repair Line, a community-repair platform for the small shared things that keep a neighbourhood moving: a broken public hand pump, a leaking roof above a ration counter, a damaged study desk, or a clinic fan that has stopped working.

The goal is to make generosity visible and practical. Someone uploads a clear photo of a repair need, receives an AI-assisted assessment, and can add it to a local repair line where people can see the impact, the directional cost, and the amount already pledged.

Each repair includes:

a real repair photo and a short explanation
severity, people affected, and a directional INR cost range
funding progress
a before-and-after proof-of-repair concept

The experience is designed to feel warm and community-led rather than like a generic fundraising dashboard. It starts with local repairs, but the city selector supports Lucknow, Kanpur, Prayagraj, Varanasi, and an all-cities view.

Demo

Live app: The Repair Line

Try the flow:

Choose a city from the location selector.
Browse local repair needs or click Show all repairs.
In Assess a repair, upload a clear photo of a broken shared item.
Receive an assessment of severity, plausibility, likely repair cost, and reasoning.
Add the assessed repair to the line.

Code

The project is built with React and Vite, with API routes prepared for Vercel Functions.

Repository: github.com/Reet24-del/the-repair-line

Key pieces of the implementation:

React interface and location-aware repair feed
Gemini-backed server-side assessment endpoint
Snowflake-backed repair, pledge, sort, and city-filtering queries
Vercel deployment and API routes

How I Built It

Starting with a small but meaningful problem

I wanted to focus on generosity that is easy to understand. Not every community need requires a huge campaign. A ₹2,000–₹10,000 repair can make a real difference when it restores a shared tap, desk, roof, or fan.

The product flow became: photo in, fixed out.

AI assessment with Google Gemini

The repair assessor accepts a photo and sends it to a server-side Gemini route. Gemini is asked to return structured JSON with:

{
  "severity": "Low | Medium | High",
  "cost": "a directional INR range",
  "plausibility": "Likely genuine | Needs review | Unclear",
  "reasoning": "a concise explanation"
}

I require a photo before an assessment can run. This prevents the interface from creating a confident-looking repair result without visual evidence. The cost is intentionally presented as directional guidance rather than a quote.

Repair feed and Snowflake

Repair records include the repair title, location, severity, estimated cost, people helped, reason, image, and pledged amount. The Snowflake schema and query layer support feed filters for city, severity, and sorting.

The feed initially keeps the page focused by showing a smaller set of repairs. A Show all repairs control expands the complete list, while the city selector changes the listings and heading to keep the experience locally relevant.

Deployment

The frontend is deployed on Vercel, while Vercel Functions host the assessment, repair, and pledge endpoints. Sensitive credentials stay in server-side environment variables rather than the browser bundle.

Prize Categories

Best Use of Google AI

The project uses Google Gemini to analyse an uploaded repair photo and produce a structured, user-facing assessment. Gemini helps translate a visual problem into understandable severity, plausibility, repair guidance, and an INR cost range.

Best Use of Snowflake

Snowflake provides the repair data layer for listings and pledges. The app is designed to query repairs by city, severity, and priority, so a growing local repair line remains filterable and useful.

The Repair Line is a small idea on purpose: make a modest, shared repair easy to see, trust, and complete.

The Answer Looked Right. That Was the Problem.

Reet Singh — Sun, 30 Aug 2026 16:28:44 +0000

I started building The Verifier because of a slightly uncomfortable thought:

What if an AI gives you a perfectly written answer based on yesterday's truth?

Not a hallucination. Not an obviously fake source. Just an answer that used to be correct.

That felt more dangerous.

A polished lie is easy to fear. An outdated fact wearing a confident suit? That one can quietly walk straight into reports, presentations, articles, and important decisions.

So I decided to build something that would not simply answer a claim.

It would argue with itself first.

Meet The Verifier

The Verifier is an evidence-first research assistant for public claims.

You give it a claim such as:

Verify that Brian Niccol is the CEO of Starbucks.

Instead of immediately producing a confident paragraph, it investigates the claim from two opposing directions.

One research lane looks for evidence supporting the claim. Another actively searches for credible evidence contradicting it.

This matters because normal search behaviour has a bias: once we find one convincing source, we usually stop looking.

The Verifier does not get that luxury.

It has to search both sides, place the evidence next to each other, and show its work.

Then Starbucks created the perfect plot twist

The Starbucks leadership example turned out to be a great demonstration.

One public source identifies Brian Niccol as Starbucks' current chairman and CEO.

Another Starbucks source names Laxman Narasimhan as CEO.

Both sources are real. Both come from Starbucks. Both look authoritative.

So which one should the system trust?

This is where the project became more than a fancy search interface.

The answer was hiding in the metadata.

Dates are boring—until they solve the mystery

Most people do not get excited about fields such as datePublished, dateModified, or ISO timestamps.

Honestly, neither did I.

But those tiny pieces of metadata became the detective of this story.

The Verifier extracts machine-readable dates from every source. It records which metadata field was used, preserves the original value, and normalizes the date to UTC.

Now the system can compare evidence deterministically.

It does not choose a source because it sounds more confident. It can explain that one source represents an older leadership announcement while another contains newer evidence about the company's current leadership.

That difference matters.

The conclusion is not merely:

Brian Niccol is CEO.

It becomes:

The claim is supported by newer public evidence. The conflicting source is legitimate, but outdated.

Suddenly, the contradiction is not something to hide. It is part of the explanation.

I wanted the disagreement to remain visible

A lot of AI tools clean up the messy middle.

You provide a question. Something complicated happens. A neat answer appears.

Magic.

Also slightly terrifying.

I wanted The Verifier to show the messy middle.

The interface keeps the supporting and conflicting evidence in separate lanes. Each source displays its role, URL, relevant statement, and date information.

The user can inspect why the system reached its conclusion instead of being asked to trust a glowing confidence score.

Because “97% confident” sounds impressive, but it does not tell me whether the model checked last year's announcement against today's leadership page.

Evidence does.

The voice feature fought back

I also wanted the experience to feel conversational.

The original idea was simple: click Speak brief, say the claim, and continue asking questions naturally.

The browser had other plans.

At one point, the button barely behaved like a button. Then voice mode required clicking it repeatedly. Even worse, every new interaction felt like the previous conversation had been erased from existence.

The Verifier had the memory of a goldfish with Wi-Fi.

That forced me to rethink the feature.

Voice could not be a one-shot transcription gimmick. It needed to be a continuous conversation where the active claim, collected sources, and date resolution remained available for follow-up questions.

I also added text as a permanent fallback because demos—and browsers—have a wonderful sense of dramatic timing.

The agent can research. It cannot press Save for you.

This became my favourite part of the project.

After completing the investigation, The Verifier does not automatically store the result.

It asks the user for approval.

That is not just a polite message in the interface. The restriction is enforced on the server.

The server creates a one-time approval token and refuses to persist the dossier until explicit approval is received. Export remains locked as well.

If the user chooses to keep investigating, nothing is saved.

Only after server-confirmed approval does the dossier become permanent and downloadable.

The system can investigate, compare, and explain.

The final decision still belongs to a human.

Of course, the build was not a straight line

The first UI used fictional “Maya Chen” and “Northstar AI” evidence while the backend used the real Starbucks case.

Very coherent. Absolutely no notes.

That mismatch had to go.

Then came GitHub authentication, voice bugs, disappearing conversational context, provider configuration, Groq setup, and a Daytona API key that continued rejecting me like it had a personal grudge.

Some parts worked immediately. Several parts worked only after I stopped assuming they worked. A few parts smiled during testing and broke the moment I opened the demo.

That is the real version of building for a hackathon.

It is not one cinematic montage with energetic music. It is a series of tiny mysteries, questionable browser tabs, and commits that begin with the word “fix.”

But each problem improved the project.

The fictional demo became a real public case. The voice button became a conversation. The date field became an explanation. The approval message became a server boundary.

What The Verifier is really about

The Verifier is not trying to make AI sound smarter.

It is trying to make AI easier to question.

The important output is not only the final conclusion. It is the path:

What evidence supported the claim?
What evidence contradicted it?
Which source was newer?
Which metadata field proved that?
Why was the conflict resolved this way?
Did a human approve saving the result?

That path becomes an inspectable dossier that a researcher, journalist, policy team, or compliance reviewer can defend.

The internet changes. Leadership changes. Policies change. Yesterday's correct answer quietly becomes today's misinformation.

The Verifier is my attempt to catch that moment.

Not by asking you to trust another polished AI answer.

By showing you the evidence, explaining the conflict, and waiting for you to decide.

Verify first. Save only when you are ready.

🚀 Live demo: the-verifier.vercel.app

🔗 Project: github.com/Reet24-del/the-verifier

If you build with AI, I would love to know: what part of an answer do you wish AI tools showed more clearly?

Good Boy Amnesia: An AI Detective Game where Memory IS the Gameplay 🐶🧠

Reet Singh — Mon, 17 Aug 2026 07:04:29 +0000

This is a submission for the Weekend Challenge: Dog Days Edition

What I Built 🦴

Good Boy Amnesia is a detective game built for Dog Days where an AI agent's entire long-term memory lifecycle — remember → recall → memify → forget — is the gameplay loop, visualized as a live 3D knowledge graph in Three.js.

The Story:

Your owner Dev left you home alone last night, and you threw a legendary neighborhood puppy party. At 6:00 AM, your memory graph was corrupted. Dev arrives home at noon (12:00 PM), the living room is trashed, and his favorite leather slipper is missing.

You play Buster, a Golden Retriever whose mind is literally a knowledge graph. Reconstruct what happened last night, interrogate the neighborhood animals, purge false rumors, and find Dev's slipper before he walks through the door!

Demo & Screenshots 🎮

Live Game Demo: https://good-boy-amnesia.vercel.app (or your Hugging Face Space URL)
Video Walkthrough: (Optional link to your screen recording)

Gameplay Breakdown:

🔍 Investigate Hotspots: Explore 6 locations (Living Room, Backyard Lawn, Bella's Garden Fence, Dog Park, Lou's Oak Tree Stash, and Rooftop Sandbox).
🗂 File Clues (remember): Committing a fact adds glowing nodes to your live 3D memory graph in real-time.
💬 Interrogate Animals: Chat with Bella (the wise cat), Lou (the shifty raccoon), Rev. Rex (the howling Basset Hound), and Barnaby (the hungover pug). The characters read your live graph and react dynamically to your knowledge.
🧠 Connect the Dots (memify): Consolidate stored memories into derived inferences (e.g. realizing the slipper was locked in the treat safe before the party started).
🗑 Purge False Leads (forget): 5 red herrings are hidden in the story. Delete gossip from your memory log to keep your graph clean and win the case!
🎯 Tell Dev (solve): Reconstruct the timeline before noon to win in a burst of victory confetti!

Code Repository ⭐

GitHub Repository: github.com/your-username/good-boy-amnesia