DEV Community: Nayananshu Garai

Phantom Troupe: Ghost in the Machine — Haunted Shell Autopsy

Nayananshu Garai — Sat, 31 Oct 2026 15:52:56 +0000

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

What I Built

I built Phantom Troupe, a command-line tool that treats every failed terminal command like a corpse that deserves an autopsy. When you mistype a command, fat-finger a flag, or hit a permission denied error, Phantom Troupe captures it, files it in a local morgue, and dispatches a small team of AI agents to figure out what killed it and how to bring it back.

The theme — Ghost in the Machine — is literal here. Your shell is haunted by every command that died mid-execution. Phantom Troupe makes those ghosts visible: the Coroner writes cause-of-death reports, the Interpreter explains what a command does and when it's dangerous, the Exorcist guards against destructive commands, the Medium inventories dead scripts, and the Understudy proposes resurrections. It's a séance for your terminal, running entirely on your machine with open-weight models.

It works offline. There's no cloud round-trip for every typo, no account to create, and nothing phones home unless you opt into crash telemetry. You can run it with Gemma 3 through Ollama locally, or point it at the Gemma API if you'd rather not run anything locally. It hooks into zsh, bash, and PowerShell so it catches failures the moment they happen, then keeps a graveyard of dead scripts, aliases, and scheduled tasks you can resurrect or retire later.

The idea came from watching how many commands fail and vanish without a trace. We mistype, we forget, we repeat the same mistake an hour later. Phantom Troupe makes those failures stick around long enough to learn from them.

Demo

The live site is at https://phantom-troupe.onrender.com/. It's a static landing page with a creepy horror theme — dark forests, roaming spirits, bats diving toward the viewer, a pockmarked moon, and a zombie hand clawing out of its grave. It walks through what the tool does, shows the architecture, and lets you try a browser-based simulation of the séance table.

The real tool runs locally on your machine. Install it with one command, and phantom graveyard opens a local UI at http://127.0.0.1:7313 where you can execute real commands and watch the troupe autopsy failures in real time. Failed commands trigger the Coroner automatically; dangerous commands are stopped by the Exorcist before they run; idle brains are released by the Reaper with a spirit ascending from the side of the screen.

Code

https://github.com/N-Garai/Phantom-Troupe

How I Built It

The backbone is a small fleet of specialist agents built with the Mastra framework. Each failure routes to the right agent: the Coroner writes cause-of-death reports, the Interpreter explains what a command does and when it's dangerous, the Exorcist guards against destructive commands, the Medium inventories dead scripts, and the Understudy proposes resurrections. Every response passes through an evaluator that scores it for confidence and safety before it reaches your screen.

For memory, it uses LibSQL to store long-term context about your graveyard, so the troupe remembers what died last week and what cured it. The shell hooks are native — zsh preexec/precmd, bash DEBUG traps, and PowerShell prompt hooks — so capture happens without you thinking about it. Nightly sweeps run through systemd on Linux, launchd on macOS, and schtasks on Windows.

Everything is local-first. If you use Ollama, the model never leaves your machine. If you prefer the Gemma API, you provide your own key and it's stored in your config file, not ours. Sentry telemetry is opt-in only — without a DSN, nothing is sent anywhere. When you do configure a DSN, agent invocations are traced with spans so latency, token cost, failures, and fallback routing are visible in Sentry's trace view.

This is grounded in research on how developers actually use the command line and where they stumble. Work like Fischer et al. on UNIX command use, Potdar and Shihab on developer debt patterns, and Luo et al. on failure recovery informed how we capture and categorize what goes wrong.

Why Does Open Innovation Matter?

Closed APIs turn every failed git push into a data point for someone else's model. Open weights and local inference flip that: your typos stay yours, your command history stays on your disk, and nobody builds a product from your mistakes without asking.

Open innovation made this possible because we could build on open frameworks, open models, and open standards without asking permission. It also means anyone can fork Phantom Troupe, add their own agents, or rewire the hooks for a shell we haven't touched yet. The graveyard format is plain text — you own the bones. And because it runs offline, it works with the lights — and the internet — off.

My Agent Session

The Spirit of It

Día de los Muertos is about the line between past and present feeling a little thinner — about remembering what's gone and keeping it close. That's the spirit of Phantom Troupe. Every failed command, every dead script, every alias that stopped working — they're not just errors. They're moments where something didn't go as expected, and they deserve to be remembered.

I built this because I was tired of watching my own mistakes vanish without a trace. You type the same wrong command three times and realize you've forgotten why it broke the first time. That frustration is a ghost haunting your shell. Phantom Troupe makes those ghosts visible, files them in a morgue, and lets you decide which ones to resurrect and which ones to lay to rest.

The loading screen plays like a rite — a dark forest, smoke everywhere, bats diving toward the screen, the name materializing from mist before dissolving back into it. Then the séance begins. It gives me chills every time, because it turns something ordinary — a typo at the command line — into something worth keeping.

Prize Categories

Best Use of Render — the landing page and demo are hosted as a static site on Render
Best Use of Mastra — the agent network, structured outputs, LibSQL memory, and séance workflow are built on Mastra
Best Use of Sentry Agent Tracing — agent invocations are traced with spans in Sentry (opt-in), showing latency, token cost, failures, and fallback routing
Best Use of Gemma — Gemma 3 runs locally through Ollama, with a Gemma API option for remote inference

DocDrift: Your Code Drifted. Your Docs Didn't Have To.

Nayananshu Garai — Mon, 26 Oct 2026 05:06:29 +0000

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

What I Built

DocDrift — a background watcher that keeps your docs honest, powered entirely by open-source AI.

The Problem-----

Here's the loop it breaks. You ship a feature. An env var gets renamed, a default port changes, an endpoint moves to /v2. Your README is now quietly fiction, and somewhere between "I'll update it in the next commit" and "the next commit turned into 40," the docs die. Empirical research backs the feeling — the ICSME 2023 study on outdated documentation references ("Detecting Outdated Code Element References in Software Documentation") found docs routinely pointing at code elements deleted many revisions ago. And notably, string-matching tools can only flag references whose occurrences drop to zero — a changed default like PORT 3000 → 8080 sails straight past them, because the string still exists. DocDrift compares values and shapes, not just string existence.

What it actually does:

Parses the real AST, not vibes. tree-sitter WASM grammars extract exported functions, classes, interfaces, routes and config keys from your TypeScript and Python files, each with line-precise evidence. If a grammar chokes on exotic syntax, a structural fallback extractor takes over and the miss lands in a queryable failure ledger. On the docs side, your README tables, setup guides and .env.example are parsed into typed targets with the same rigor — so both sides of the comparison speak the same language.
Runs a nine-step agent crew with two validation gates. A Mastra workflow (doc-drift-sync) chains intake → extract → docs → synthesize → gate-1 → patch → gate-2 → tone → emit into one typed, inspectable graph. Gemma drafts the findings; Gate 1 then drops every claim the AST can't prove — no phantom links survive — and Gate 2 applies the proposed patch to a shadow copy of your docs, re-parses it, and refuses edits that would break a markdown table.
Gives you a reviewable PR, not a robot merge. The output is a unified diff, a humanized PR title and body, and a full step trace with timings. You review. That is the whole job. PRs open from a docdrift/docs-sync-<timestamp> branch against your default branch — never auto-merged.

There are two ways to use it. The Studio: sign in with GitHub (your own account, your own token — DocDrift never holds an org-wide key), pick a repo, branch and doc file, and watch the whole pipeline run live. Or the autopilot: install a push webhook on your repo, and every push that drifts the docs opens a docs-sync PR without you opening anything. HMAC-SHA256 verified, scoped to the installer's session, one user can't trigger another's webhook.

The three sloth-things baked in: it waits for your push (webhook events, not cron polling), it does the boring comparison work, and it stops before the risky part — merging is your call.

Demo

Try it in about 30 seconds at https://docdrift-rfjj.onrender.com

Code

Repo: https://github.com/N-Garai/DocDrift

DocDrift was built by pair-programming with a rotating cast of AI coding agents — DeepSeek, Kilo Code, GitHub Copilot and opencode — each picked for what it was good at: DeepSeek for heavy reasoning and big-picture design, Kilo Code and opencode for rulebook-driven implementation sprints, and Copilot for inline completions and roadmap development. But the code generation was never the interesting part — the discipline was.

How I Built It

The constraint I set from day one: the open pieces have to be what makes the project work — not a coat of paint over a proprietary core. Everything below is verifiable in the repo, file by file.

Mastra as the agent harness. Four specialized Mastra Agent instances share one job: extraction, validation (Gate 1), patching (Gate 2) and tone. They're wired into a real Mastra workflow via createWorkflow/createStep — nine typed steps chained with .then() and committed as one graph. Every step's input and output is a Zod schema, so an LLM can't sneak a malformed finding past the type system, and every run produces a replayable step trace.
tree-sitter as the compiler for prose. web-tree-sitter with prebuilt grammars from @repomix/tree-sitter-wasms gives line-precise symbol extraction for TypeScript and Python. Parser failures are recorded in an in-memory ledger (last 50, surfaced at GET /api/health) and shipped to Sentry with a redacting beforeSend — cookies, tokens and session IDs never leave the machine.
Gemma as the prose engine, in a provider chain. The reasoning layer resolves per request, with a 15-second cached verdict: local Ollama Gemma (default gemma3:4b at localhost:11434) → the free Gemini API tier serving the open-weight gemma-4-31b-it → and finally a deterministic comparator engine — a rule-based drift detector (changed defaults, missing symbols, rename detection via similarity scoring ≥ 0.62, orphaned doc targets, env keys, stale routes) that produces the same artifact with zero network calls. Temperature 0.2, explicit timeouts and retries — and the chain is one env var to reconfigure.
The two gates are the anti-hallucination core. The design leans on the documentation-drift literature, all annotated in docs/RESEARCH.md: Ratol & Robillard's DOCREF ("Detecting API Documentation Errors", OOPSLA 2014) and the 2025 Concordia LLM traceability study ("Evaluating the Use of LLMs for Documentation-to-Code Traceability") both document how "phantom links" pervade LLM-linked docs. So Gate 1 re-checks every Gemma finding against the extracted symbols and drops anything the AST cannot prove before a patch is built. Gate 2 does the mirror check on the docs side: apply the edit to a snapshot, re-parse it, confirm tables stay well-formed and the symbol is genuinely documented now. Broken edits get repaired once, then flagged — never silently merged.

The whole stack is Bun + TypeScript, Express on the engine, Next.js front end, a zero-dependency JSON store for sessions and webhook registrations (no database required — swap in Postgres later behind the same interface), node:test for the test suite, and a multi-stage Dockerfile whose single Node process serves the API and the static-exported frontend on one port. On the building side, I pair-programmed the codebase with agentic coding tools — DeepSeek, Kilo Code, GitHub Copilot and opencode — under a rulebook the whole team (human included) had to follow.

Why Does Open Innovation Matter?

DocDrift reads code, docs and env files from your repository — the payload a closed tool would demand you upload somewhere. Open makes the trust question easy to answer:

Your repos stay local. The default inference path is Ollama on localhost; the deterministic engine doesn't even open a socket. Anyone can verify that by reading core/llm/provider.ts — which is exactly the point. Closed-source doc tools ask you to trust the pipeline; open-source lets you audit the pipeline.
It costs nothing to run, forever. Every component — Mastra, tree-sitter, Gemma weights, the Ollama runtime — is free, and the free Gemini tier is a fallback, not a crutch. The landing page's live demo runs with zero providers configured (the deterministic engine powers it). There's no paid plan to outgrow, no credit card, no trial clock.
The brain is swappable by config, not migration. Set OLLAMA_MODEL, point at another local model, or drop the key and use the deterministic engine. Fine-tuning how your agent behaves is an env edit.
Honest intelligence. The similarity thresholds, the evidence rules, the gate behavior — it's all in plain TypeScript with 36 tests over it rather than a marketing page. That transparency is only possible when the core is open.

My Agent Session

The build was pair-programmed with a rotating cast of AI coding agents — DeepSeek Harness, Kilo Code, GitHub Copilot and opencode — different tools for different jobs, and the interesting part was the discipline, not the code generation.

The Lazy Payoff

The honest math: every time you ship anything, keeping your own backlog of docs consistent is a 20–30 minute guilt-tax — reread the README, scan your config keys against .env.example, and see if the endpoints match. Most weeks, the honest answer is that nobody does it, and the tables fall behind. DocDrift does not ask you to remember anything.

Studio path: click through the repo picker, hit "Run drift analysis," get the diff. The demo runs on the landing page in a browser with no API key of any kind, so the price of admission to "my docs are freshly audited" is one click.
Webhook path: install once, forget. Every push lands a review PR whenever your docs fall out of date with the code. You review and merge whenever you want — DocDrift will never merge for you, which is exactly the design decision you want from a tool handling your README.
When it's wrong, it fails loudly: the mandatory evidence rules mean the diff is a real diff with real files, and the failure ledger at /api/health shows you exactly what the parser missed instead of hiding it.

The sloth wins because I only do the part that needs a human: deciding whether the new table row reads well.

Prize Categories

Best Use of Gemma — Gemma's open weights are the reasoning engine at the center of the synthesize step, with a provider chain covering both real deployment modes: local via Ollama (default gemma3:4b) on the laptop path and the open-weight gemma-4-31b-it on the hosted free tier (temperature 0.2, explicit timeouts, structured Zod outputs), plus a deterministic fallback so the pipeline never stalls without a provider.
Best Use of Mastra — the entire brain runs on the open Mastra harness: four specialized Agent instances wired into one production createWorkflow graph (doc-drift-sync) of nine typed createSteps (intake → extract → docs → synthesize → gate-1 → patch → gate-2 → tone → emit), all with Zod-typed step boundaries and per-step traces replayable in the Studio.
Best Use of Render — DocDrift is deployed on Render's free tier (render.yaml, Docker service): health check on /api/health, auto-deploy, production env wiring for the GitHub OAuth app and webhook secret — and a custom keep-warm service that self-pings only in production (every 13.5 minutes, cancellable with KEEP_WARM=off) so the free instance doesn't nap through its own ~15-minute idle window.
Best Use of Sentry Agent Tracing — the engine instruments its failure paths with @sentry/node (captureParserFailure, captureWorkflowError in core/sentry.ts): every tree-sitter grammar failure and workflow error is captured with a redacting beforeSend that scrubs cookies, GitHub tokens and session IDs before anything leaves, and the same failures surface live in GET /api/health's parser-failure ledger — the observability story includes what you can see without an account.

Git-Voice: Twenty Seconds of Client Voice into One Filed GitHub Issue

Nayananshu Garai — Sun, 18 Oct 2026 15:16:28 +0000

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

What I Built

The recurring pain behind client work isn't the bugs — it's the dispatch cost. A client sees something broken on their staging site, describes it in one emotional sentence ("the checkout is broken, fix it ASAP"), and the freelancer spends the next unpaid hour reverse-engineering the sentence: which browser, which route, what console said, whether the coupon even reached the server. Neither side is having a good time. I've been on both sides of that email.

Git-Voice is a small embeddable widget that replaces the sentence with twenty seconds of speech. The developer drops one <script> tag on the staging site. The client clicks a floating mic button, talks while clicking around the broken page, and the system:

captures the audio plus real browser telemetry (console output, route, viewport, clicks),
locates the suspicious files by searching an architecture index built from the client's repo,
drafts an engineering-grade GitHub issue — title, severity, expected vs. actual, numbered reproduction steps, suspected file — and files it, labels included,
reads a short spoken confirmation back to the client in their own browser, so they finish feeling heard instead of handed a form.

No forms, no severity dropdowns, no "which browser are you using?" — the telemetry already answers that.

Who would pay for it: freelance developers and tiny agencies juggling 2–10 client staging sites. The pricing is honest about its audience: Hobby (free, public repos, one project — the whole pipeline still runs), Freelancer at $15/mo (private repos, hosted drafting and premium voice, auto-reindex), Agency at $60/mo (ten projects). One recovered debugging hour a month pays for it.

One thing I refused to fake: the billing. Checkout is a clearly-labelled simulation (card digits pass a Luhn check, invoices are issued, nothing touches a real processor). The pricing page says exactly which capabilities the server enforces, and the server actually enforces them — the plan gates in this post are code, not copy.

Demo

The deployed app (Render-web service with docker):

Live app: https://git-voice-sh7k.onrender.com — try the landing-page demo store widget, sign in with GitHub, create a project from your own repos, watch a report end-to-end.
Video walkthrough: Demo

Code

Node + Hono backend, React dashboard, one install-anywhere site widget built as a separate ~21 KB bundle, and a Postgres/pgvector-backed index. Apache-2.0 licensed, no payment processor and no stored card data — the simulated checkout says so plainly in its own UI — and 145 backend tests across 18 files.

Repo:- Git-Voice

How I Built It

The brain is Gemma (gemma-4-26b-a4b-it on the Gemini API, open-weight). Every issue that leaves the pipeline is drafted by it — but deliberately at temperature 0, with a hand-rolled JSON extraction step instead of prompt-and-pray parsing. Transcription of uploaded audio uses the free gemini tier, and embeddings (gemini-embedding-001, 768 dims, batched with exponential backoff) build the retrieval layer. I chose Gemini's free tier for the model side and kept every piece I could running locally so the whole thing costs $0 to operate.

The pipeline is a seven-station engine I wrote myself — ingest → transcribe → locate → correlate → draft → publish → confirm — instead of pulling in a workflow framework, because the failure behavior matters more than the orchestration syntax: each station holds its own typed result, the whole run is bounded by a 90-second timeout, and (this is the part I'm most attached to) a deterministic offline triage engine runs first and stays as the final draft. If the model is unreachable, rate-limited, or not configured, a working, honest issue still gets drafted and filed from a rule-based synthesizer. The spoken confirmation reads through the browser's own speech synthesis on every plan — nothing to configure — and spaces out to a server-rendered voice on paid tiers when the deployment carries a speech API key. Every station's state ends up visible in the dashboard; nothing disappears into a spinner.

Retrieval is hybrid on purpose: keyword scoring over a curated "signature" per file — path, exports, error strings, class names — fused with cosine-similarity over their embeddings using Reciprocal Rank Fusion (Cormack et al. 2009, SIGIR), with BM25 weighting underneath (Robertson & Zaragoza 2009). The index itself comes from the repo tarball (public via codeload, private via the owner's own OAuth token), capped at 800 files, chunked into signatures, and stored in Postgres with pgvector.

For agent observability I wired @sentry/node with OpenInference's gen_ai semantic conventions — one span per pipeline station (gen_ai.execute_tool), one for the model call (gen_ai.chat with real token usage), one per agent run — enabled by nothing more than a SENTRY_DSN environment variable, with a strict gate that strips report content from spans by default. Reports belong to the client; telemetry should collect clicks, not conversations.

Why Does Open Innovation Matter?

Three concrete reasons this is an open-weights project and not a wrapper on some closed API's free credits:

It survives without the vendor. The offline triage engine plus the browser's Web Speech APIs mean the $0 Hobby tier is a complete product, not a teaser. When the model quota runs dry, drafts and file matching keep working; when a paid feature is missing, the UI says so — the plan gates are server-side checks. A closed-API-first product would have been a demo that dies in a cold aisle.

It costs exactly nothing to run honestly. Gemma via the free Gemini tier, Render's free Docker web service, browser TTS/STT, open-source pgvector. Being able to build a purchasable product (the actual "side hustle" test) on top of open infrastructure is the difference between a hobby and a hustle.

Users keep their data and their identity. Issues are filed into the developer's own repo under their own GitHub OAuth token — the deployment's credentials never write to a client repo. The embeddings layer searches a curated signature index, not raw source code, so a client's project is never shipped wholesale to a third-party service. Open stores (plain GitHub issues, Postgres + pgvector) mean no lock-in: stop using Git-Voice and your issues, your repo, and your index stay right where they are.

My First User

The first real user was my freelancer friend — someone who has lived through exactly the "client sends one angry sentence" scenario Git-Voice is built for. He got no instructions beyond a link. What he did in his first session: signed in with GitHub, picked a repository from the picker, upgraded the plan to Agency through the simulated checkout (no money moves, by design), created a project, filed reports through the widget, and replayed the spoken confirmations.

He reported back with screenshots and three bugs (which I'd have shipped to production) saying "It was so helpful for me to save time,I've attached the link my client sent me to my copilot but it didn't understand the proper issue and mangled the whole code,took too much time,with your app it creates a cited issue and my coding agent easily patched the bug,now i am just reviewing the changes". Would he pay? Not yet, and I won't pretend otherwise: the checkout is simulated, so no money has moved. What the session did settle is the value pitch — a twenty-second voice report that lands as a labelled, reproducible issue beats the "which browser is this on?" email every week. I'll take the bug list as the more honest compliment.

Prize Categories

Best Use of Gemma (featured) — the open-weight gemma-4-26b-a4b-it model drafts every single issue at temperature 0, with a deterministic offline synthesizer underneath it so the product never dead-ends.
Best Use of Render — the whole thing is one Dockerfile: Hono serves the React dashboard, the widget bundle, the API, and the Postgres/pgvector index from a single free-tier web service, deployed from main with health checks and keep-warm.
Best Use of Sentry Agent Tracing — the pipeline's work is inspectable, not a spinner: @sentry/node emits gen_ai spans for every station run, for the Gemma call (real token usage and finish reasons), and for the agent run itself, with a content gate that keeps report text out of spans by default. Enabling it is one SENTRY_DSN environment variable, and the trace reads like the dashboard's run log.
Best Use of ElevenLabs — the confirmation voice is plan-aware: paid tiers render an ElevenLabs mp3 server-side when the deployment carries a key, Hobby always speaks through the browser's native speech synthesis, and any failure falls back gracefully — the client always hears their confirmation.
Best Use of GitHub Copilot — Copilot handled editor-side work (completions, small refactors, test scaffolding) alongside the milestone-driven agent sessions described above; the odd pairing of a fast autocomplete brain and a slow milestone brain turned out to fit how I actually work.Also github cron jobs plays a significant role of my site(preventing render site getting idle after 15min).

Sky-Whisper

Nayananshu Garai — Sun, 11 Oct 2026 14:49:34 +0000

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

What I Built

SkyWhisper turns stargazing from a looking activity into a listening one. You open the app at home, it computes exactly what's over your sky tonight, writes you a ~90-second narrated guide, and synthesizes it into audio you download. Then you go outside, put the phone face-down, lock the screen — and just listen through your earbuds, with lock-screen controls handling the rest.

It's for everyone who has ever held a glowing phone up to the night sky and ruined the very thing they went out to see: your eyes need 20–30 minutes of darkness to fully adapt, and one glance at a bright screen resets that clock to zero. Every other stargazing app is the screen. SkyWhisper's entire thesis is that in the field, the screen's only job is to stay off — if you never unlock your phone, you used the product perfectly. That's about as "touch grass" as software gets: the output isn't content to consume, it's instructions to look up.

Demo

Live: https://sky-whisper.onrender.com (free tier — first load after idle takes ~30–60s while the container wakes)

The 60-second try-it script:

Allow location (or type coordinates) → Prepare My Sky → watch the ritual stages light up with real server progress, not a fake timer.
Press play on the countdown → flip your phone face-down → control it from the lock screen.
Tap the 🎙 button and say "describe the sky" — or "where can I find Vega?" — and hear the agent answer from live data.
Open any pack's "Tonight's Narration" card: it tells you exactly which model narrated it — or precisely why the template did instead. No black boxes.

Code

https://github.com/N-Garai/Sky-Whisper

How I Built It

The one architectural decision everything hangs on: coordinates are computed, never generated. A deterministic ephemeris stack (Skyfield + JPL data, CelesTrak + SGP4 for satellites) calculates Sun, Moon, 5 planets, 18 named stars, and 12 constellations for your exact spot and second. The language model only ever receives those finished facts — and every number it utters is checked against them before audio renders. A closed model guessing "what's above you" would be unfalsifiable and occasionally confidently wrong; open math can be diffed against Stellarium by anyone.

The model chain is built for a world where model IDs die. During this build, Groq retired one default ID and NIM returned 410 Gone on another — I watched it happen in the logs. So each rung carries a fallback ID (switched only on 404/410-class errors), each rung gets 55 seconds, the whole walk gets 150, every failure is recorded with its reason, and the deterministic template always answers. The pack JSON — and the UI badge on it — names the winning rung or explains exactly why the template did. Model rot can't silently break this product.

Mastra (@mastra/core, Apache-2.0) orchestrates narration: a docent agent with real tools (get-sky-snapshot over localhost, get-body-direction for any named body), a facts → narrate → validate workflow, per-rung endpoint pinning, and a zod narration envelope — with the Python validator re-gating everything as the final word. Voice questions ride the same chain with conversation memory, answered as speech.

Free-tier engineering: the whole serving footprint peaks around ~320MB of 512MB; the Node harness spawns only when a model rung actually runs and is kill-guarded so hung runs can't orphan processes into an OOM; packs cache on 15-minute sky buckets so retries serve instantly; the kernel and satellite data warm at boot.

The frontend: (React 19, Vite, Tailwind v4, Framer Motion, Three.js living starfield, installable PWA with offline pack cache) also ships two things I'm proud of: a drag-to-turn 360° sky map with a live facing readout, and a blackout pointer mode — pure-black OLED overlay where compass, vibration, and rising pitch guide your aim onto a star without emitting a photon that matters.

Testing: 136 automated tests, hermetic (no network, no keys) — ephemeris math, anti-hallucination rejection (including a test pinned from a real production failure where a model emitted raw altitudes), chain fallthrough, kill-on-timeout, and full HTTP integration.

Why Does Open Innovation Matter?

Four concrete ways, all demonstrated in code rather than claimed in prose:

Open coordinates are a correctness feature. My cross-check table (in docs/accuracy.md) diffs Skyfield against astropy's independent implementation: 0.00° across the board except a 0.64° lunar-elongation residual I document and explain. Try auditing a closed API's sky positions that way.
Swap-ability is a one-line demo. Hosted Gemma via free key → local Ollama via one variable. A closed-API product cannot offer "run my narrator on your laptop with zero code changes"; the open-weight one does, and location history ("where you stargaze") never has to leave your machine.
It costs nothing to run. Free Render + free model tiers + free TTS tier + free data sources = $0/month, every line auditable. Open is what makes the hobby budget possible.
It survives the real world. When providers retired model IDs mid-build, the open, inspectable stack meant I could see exactly what broke (HTTP 404/410 in plain text) and route around it in the open — instead of a black-box outage I couldn't diagnose.

Prize Categories

Best Use of Render — single free web service serving API + PWA; cold-start honesty, ephemeral-by-design storage, measured 320MB footprint on 512MB.
Best Use of Gemma — open-weight Gemma narrates from computed facts only (never coordinates), hosted free-tier path plus one-variable local Ollama swap, model recorded per pack.
Best Use of ElevenLabs — pre-trip TTS rendering with an honest transcript-only mode when unkeyed; short voice replies synthesized on demand.
Best Use of Mastra — docent agent with snapshot/direction tools, facts→narrate→validate workflow, per-rung orchestration, memory-carrying voice loop.

Bill-Bhasa

Nayananshu Garai — Sun, 04 Oct 2026 14:54:36 +0000

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

What I Built

BillBhasha — a privacy-first bill scanner that reads any paper receipt, prescription, or invoice out loud in my parents' own language.

My mother is 62, hindi-first, and has low vision. She still handles every household bill, medicine strip, and ration document by hand. Right now that means either squinting at faded paper or asking someone else to read it for her — and neither option lets her stay independent.

BillBhasha lets her simply take a photo of any document. The app cleans the image, reads the text with open-source OCR, understands it with an open-weight language model, and then speaks the explanation back in warm, simple Hindi or Bengali. It also watches her spending history and speaks a gentle warning when an amount jumps unusually.

Everything runs inside a single free-tier web service. No app store, no login, no credit card. She opens the site, snaps a photo, and listens.

Demo

Live link: https://billbhasha.onrender.com (first visit may take ~40s to wake the free service)
How it feels for her: open the page → tap the camera → snap a bill → hear a 30-second Hindi explanation → see a plain ₹ amount and a simple "check this" warning if something looks off

Code

GitHub repo: https://github.com/N-Garai/Bill-Bhasa
Stack: FastAPI backend · Tesseract OCR · SmolLM2-360M (GGUF, Apache-2.0) · Piper Hindi/Bengali voice · Neon Postgres · vanilla JS frontend with GSAP + Three.js

How I Built It

BillBhasha is not a wrapper around a closed API.

Open-weight model at the core

The default brain is SmolLM2-360M in GGUF format (LLM_MODEL env var). It turns raw OCR text into a simple Hindi/Bengali explanation with amount, date, and action items.
It runs locally inside the same container via llama.cpp subprocess isolation, so there is no external inference bill and no data leaves the box.
The model is swappable in one config line: Qwen2.5-0.5B, Phi-3, or any GGUF-compatible model. I started with Phi-3 Mini but it OOM'd on the 0.1 CPU free tier, which is why SmolLM2-360M became the default.

Open harness + local inference

FastAPI + Uvicorn serve the app. Tesseract (pytesseract) does the OCR. Both are open source.
Heavy work runs in subprocesses with a sequential in-process lock, keeping peak memory under 512 MB on a single CPU.
Piper provides an offline Hindi/Bengali voice on-device, so the app still speaks when the network is down.

Open vision fallback

When Tesseract returns nothing (faded print, bad light), Gemma (gemma-4-26b-a4b-it) reads the photo directly through the free Google AI Studio API and returns structured JSON.
The vision prompt is locked to the user's chosen language, and the response is schema-validated before it reaches the TTS stage.

Why this architecture

My parents' data never needs to leave the server. On the SQLite profile, the app runs fully offline.
Every behavior swaps via environment variables: LLM_PROVIDER, LLM_MODEL, TESS_LANG, ELEVENLABS_API_KEY, GEMINI_API_KEY. No code changes required.
The monthly receipt is $0: Render free web service + Neon free Postgres + zero closed-API spend. ## Why Does Open Innovation Matter?  For my parents, "open" is not a buzzword — it is the only reason this exists at all.

Privacy without trust in a closed server

My parents' prescriptions, bank statements, and hospital bills never leave our infrastructure. With SQLite + local inference, the app works with the cable pulled. A closed API would require sending those papers to someone else's server, with no guarantee they won't train on them.

Model swap = accessibility swap

Hindi-first, Bengali-first, and English-first users all need the same app, but different voices and different LLMs. Open-weight GGUF models let me swap the brain in one line. Closed APIs would lock me into their pricing, their accents, and their privacy policy.

Cost = access

My parents are retired. A $20/month closed-API bill is not a viable long-term plan. SmolLM2-360M, Tesseract, Piper, Render free tier, and Neon free tier together cost $0. Open innovation made this project actually sustainable for the person it was built for.

What failed and what open alternatives made possible

Phi-3 Mini: 2.5 GB, OOM on 0.1 CPU. SmolLM2-360M: 360 MB, runs comfortably.
EasyOCR: pulled from the box for memory. Tesseract with sparse passes stayed under budget.
Render Postgres 30-day reset trap → Neon free Postgres, no reset.
Closed TTS APIs sounded robotic in Hindi/Bengali. ElevenLabs multilingual v2 + Piper on-device gave us a warm, female voice that sounds like home.

Prize Categories

Best Use of Render — deployed on Render free web service with Neon Postgres
Best Use of Gemma — Gemma 4 vision fallback via Google AI Studio free API (gemma-4-26b-a4b-it) with schema-locked JSON output
Best Use of ElevenLabs — ElevenLabs multilingual v2 TTS for Bengali/Hindi with Piper offline fallback

Cifrasync

Nayananshu Garai — Sun, 07 Jun 2026 14:12:41 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

CifraSync — a zero-dependency encrypted incremental backup tool written in C from scratch (200 KB binary, 31 source files, ~5000 lines). No Python, no Go, no npm. Just a single binary with chunk-based deduplication, RLE compression, HMAC stream cipher v2 (key separation, CSPRNG, 600K PBKDF2), incremental snapshots, remote sync, file-based mutual exclusion locks, and a colored interactive TUI.

The project started as a partially-built C backup scaffold with stubs and unfinished wiring. I completed all 7 commands (init, backup, restore, list, verify, prune, sync), added a server mode, wired compression and encryption end-to-end with key separation and cryptographically secure randomness, built an interactive menu, added file-based locking, and wrote a comprehensive README and docs. All 14 tests pass with zero compiler warnings.

Key technical features

Chunk-level deduplication — identical data across files/snapshots stored once
RLE compression — per-chunk, auto-decompressed on restore/verify
HMAC stream cipher v2 — Blob version 2 with key separation (enc_key ≠ mac_key), cryptographically random salt/nonce (CryptGenRandom / /dev/urandom), 600K PBKDF2 iterations, constant-time tag verification
Key cache — In-memory PBKDF2 cache eliminating redundant per-chunk derivation
Masked passphrase input — No echo on terminal (SetConsoleMode / getpass)
File-based mutual exclusion — flock/LockFileEx locks (EXCLUSIVE for writes, SHARED for reads)
Atomic manifest writes — .tmp + rename() crash safety
Journal replay — interrupted backups auto-resume
Cross-platform — same codebase compiles on Windows (MinGW), Linux, macOS
Interactive TUI — colored numbered menu, no flags needed for daily use
wake up cifra — one-command launcher after one-time setup.ps1

Demo

Build & Test

git clone https://github.com/N-Garai/CifraSync.git
cd CifraSync
mingw32-make release    # builds bin/cifrasync.exe (200 KB)
mingw32-make test       # 14/14 tests pass

Quick Demo (interactive mode)

# Create test data
mkdir C:\demo\source C:\demo\repo C:\demo\restored
"Hello world" > C:\demo\source\file1.txt
"Another file" > C:\demo\source\file2.txt
mkdir C:\demo\source\sub
"Deep file" > C:\demo\source\sub\deep.txt

# Launch interactive menu
cifrasync

CLI Usage

cifrasync init --repo PATH
cifrasync backup --source PATH --repo PATH [--compress] [--encrypt] [--label TEXT]
cifrasync list --repo PATH
cifrasync restore --repo PATH --snapshot ID --out PATH [--source-file PATH]
cifrasync verify --repo PATH
cifrasync prune --repo PATH [--keep-last N] [--older-than DAYS]
cifrasync sync --repo PATH --remote HOST:PORT   # pushes manifests + chunks to remote
cifrasync serve --bind HOST:PORT [--repo PATH]   # receives & stores sync data

The Comeback Story

Before : The project had the CLI scaffold, core storage and chunking layers, basic tests, and tools. But 3 of 7 commands were stubs (verify, prune, sync returned "unsupported"). Compression and encryption were logged but not applied. Snapshot listing showed bare filenames only. No journal replay, no atomic writes, no config auto-load, no single-file restore, no interactive mode, no launcher. The project needed documentation, polish, and a clear demo path.

After : Every command is fully implemented. Compression and encryption are wired end-to-end (RLE before store, HMAC seal v2 with key separation, auto-decompress on restore/verify). Encryption uses cryptographically random salt+nonce, 600K PBKDF2 iterations, masked passphrase input, and key separation (enc_key ≠ mac_key). File-based mutual exclusion locks prevent concurrent corrupting writes. Journal replay resumes interrupted backups. Atomic .tmp + rename() prevents partial snapshots. Config auto-loads on startup. The snapshot list shows rich details (ID, timestamp, file count, size, label). There's a colored interactive TUI, a serve command for remote sync, and a wake up cifra one-command launcher. The README is comprehensive with a full interactive mode reference table. All 14 tests pass with zero warnings.

Sync Protocol (full data transfer)

The sync now implements bidirectional chunk transfer via a custom TCP frame protocol:

HELLO — client announces itself, server responds with repo path
MANIFEST — client sends full snapshot metadata + serialized manifest file (all file/chunk references)
Missing chunk negotiation — server compares manifest chunk hashes against its local chunk store, returns list of only the missing hashes
CHUNK — client reads each missing chunk from local store and sends it as binary frame (64-byte SHA-256 hash + raw data)
BYE — clean disconnect

Only chunks the server doesn't already have are transferred, making re-syncs incremental. The server writes .snapshot metadata files, .manifest files, and stores chunks using the existing repository format. The client reads manifests from its local repo and sends chunk data on demand.

Key changes made:

Implemented verify (chunk re-hash), prune (snapshot deletion + orphan GC), sync (full manifest + chunk data transfer), serve (server mode with --repo for storage)
Wired RLE compression and HMAC encryption into the backup pipeline
Blob v2 with key separation — enc_key/mac_key derived via HMAC-SHA256 from master key; authentication tag computed with mac_key, stream cipher uses enc_key
Cryptographically secure randomness — replaced time()+clock() salt/nonce with CryptGenRandom (Windows) / /dev/urandom (POSIX)
PBKDF2 iterations: 10K → 600K — OWASP 2023 recommendation for SHA-256
Wired in key cache — per-session static cache avoids recomputing PBKDF2 per chunk
Masked passphrase input — SetConsoleMode disables echo on Windows; getpass on POSIX
Passphrase zeroization — passphrase buffer cleared in backup cleanup path
Wrong-passphrase now fails loudly — restore/verify previously silently produced garbage; now they return errors with log messages
File-based mutual exclusion — EXCLUSIVE lock for backup/prune/server-sync, SHARED lock for restore/verify/client-sync; cross-platform via flock / LockFileEx
Fixed Windows shared lock — LockFileEx now called for shared mode too (was a no-op)
Added journal replay on backup start
Added atomic manifest writes
Added rich snapshot listing with formatted columns
Added single-file restore (--source-file)
Added config auto-load
Built interactive TUI with colored ASCII menu
Created wake up cifra launcher (wake_up_cifra.cmd + setup.ps1)
Fixed platform detection (dynamic #ifdef instead of hardcoded)
Fixed verify with compressed chunks (decompress before hash check)
Added POSIX fallbacks for cross-platform support
Deduplicated 5 copies of path_join into shared cs_path_join
Fixed \r carriage return bug in interactive input (was corrupting paths on Windows)
Fixed NULL callback crash in journal.c
Wrote comprehensive README, after.md, and submission docs

My Experience with GitHub Copilot

I used GitHub Copilot throughout the completion process. Copilot was most helpful for:

Boilerplate code generation — writing repetitive CLI option parsing, path joining, and error handling patterns
Test writing — generating test cases and edge cases for unit tests
Documentation — drafting README sections, the submission post, and code comments
Bug finding — suggesting fixes for the \r carriage return issue and the verify decompression logic
Refactoring — suggesting how to deduplicate the path_join functions across 5 files into a single shared implementation

Every suggestion was reviewed, adjusted for the project's coding style and safety constraints, and validated against the test suite before being committed.

Demo Video

Watch the full walkthrough: https://youtu.be/IqonIOfXhFs

Repository: N-Garai/CifraSync