DEV Community: Aarish mansur

I built a VTU viva examiner that calms the room while I think

Aarish mansur — Fri, 06 Nov 2026 08:56:03 +0000

This is a submission for the Presage SmartSpectra SDK Challenge

What I Built

Every VTU CSE student knows the gap between knowing an answer at your desk and saying it in front of the external examiner.

At my desk, "Explain the four conditions for deadlock" is a revision question. In the lab - record open, tube light buzzing, examiner waiting with the attendance register - the same sentence can make my brain blue-screen. Written prep checks memory. It does not let me practise the silence before my first word, saying it out loud, and settling enough to continue.

So I built Viva Mode: a local Electron app for mock Visvesvaraya Technological University (VTU) CSE lab vivas, powered by the Presage SmartSpectra SDK. The unit of practice is a syllabus topic, not a generic interview score. The session ends with a study-shaped note: which subject and module moved pulse relative to your own baseline, think time, time to first word, and whether you settled during Think - not "you seemed stressed."

Interview coaches already exist; other Presage entries already score recovery after interview questions. Viva Mode is deliberately a college viva practice room - lab-record paper, subject chips, module-linked reports - because that is the exam I actually sit for.

What a session feels like

A live-signal session walks through these screens:

Consent. Plain-language card: what is measured (pulse, breathing, HRV, face talking, optional expressions), what is stored (local per-question summaries), what is never saved as video (no recordings, frames, or landmarks). You can paste a Presage key here or use one already saved. Telemetry unchecked by default. "Not a medical device." Camera only after you continue on the live path.
Calibration (~60 s). "Sit like you're waiting outside the lab." The ring fills while signals warm up - pulse averages over roughly 12 s, breathing over ~30 s, HRV over ~60 s. Validation hints coach framing. Calibration finishes after the minute and at least 20 usable pulse samples; if pulse never stabilises, it extends (up to two minutes) instead of inventing a baseline, then offers Practice without signals.
Ready. Baseline = medians of usable calibration samples. Examiner neutral. Press "Ask me."
Think. Lab-record question card (subject code, module, topic). Breathing drives the room: more than +15% vs baseline → pacer + "patient" examiner; within +5% for 8 s → calm steps up (flicker and clutter ease, colours warm, "encouraging"). Gradual CSS --calm (0→1), not a strobe.
Answer. Face talking for ≥1.2 s (or the "I'll answer now" button). Breathing adaptation freezes - breathing rate is not valid while talking. Examiner listens; pulse can still paint a ribbon. ≥4 s silence ends the answer.
Between. Next question or end. Records think time, time to first word, peak pulse vs baseline when available, whether you settled, and recovery if the pacer appeared and you settled in the same Think.
Calm Report. Per-question subject/module cards + Chart.js timeline. Relative copy only ("vs your baseline"). Local examiner remark from the state machine - no cloud model. Footer: practice/wellness tool, not medical advice. Export as PNG if you want to keep it.
Settings. Telemetry for the next session, delete all data, camera/key, reduced-motion hooks.

There is also a labelled Practice without signals path: same question deck and timing, no camera, no vitals, no saved report. Useful in a lab without a webcam. It cannot stand in as SDK proof.

Question bank and honest status

data/questions.vtu-cse.json ships 41 VTU CSE viva prompts under the 2022 scheme codes:

BCS303 Operating Systems (8)
BCS304 Data Structures (9)
BCS401 Algorithms (8)
BCS403 DBMS (8)
BCS502 Computer Networks (8)

Modules are named (for example "Module 3: Deadlocks"), not placeholders. Each live viva draws five questions round-robin across subjects so a session is never five OS prompts in a row.

This is an early challenge build (work started on or after 4 Nov 2026), not a finished validation study. The state machine has camera-free unit tests; npm run smoke drives consent → practice → five questions → report → settings and writes screenshots under smoke/. Live-signal demo video and "what broke under my tube light" notes land once I finish a clean camera run. No invented BPM values. Viva Mode is not an interview coach, a real examiner, college surveillance, or a medical device - just a private practice room for the minute between "I know this" and "here is my answer."

Tech stack and architecture

Layer	Choice	Why
Desktop shell	Electron 43.2.0	Matches how Presage's Node SDK is meant to run: native work in main, camera UI in a sandboxed renderer
Physiology SDK	`@smartspectra/node-sdk` 3.4.0	Official SmartSpectra Node/Electron path for this challenge
Language	TypeScript 5.9	Shared types for decoded metrics, snapshots, and session records
Bundling	esbuild	Separate bundles for main, preload, and renderer
Tests	`node:test`	State-machine tests without a webcam; smoke harness for the Electron UI
Charts	Chart.js 4	Calm Report timeline
Runtime	Node.js 22+	README requirement

No React/Vue in the MVP - HTML + CSS driven by --calm and a small render loop keeps the physiology path easy to audit.

Repo layout:

viva-mode/
├─ PLAN.md  README.md  package.json  tsconfig.json
├─ data/questions.vtu-cse.json
├─ scripts/   # build + smoke
├─ smoke/     # consent / room / report / settings screenshots
├─ src/main/main.ts            # BrowserWindow, camera permission, SmartSpectra IPC
├─ src/main/storage.ts         # local sessions under userData
├─ src/preload/preload.ts      # SDK preload + window.viva bridge
├─ src/renderer/               # DOM UI, styles, SmartSpectraSDK wiring
├─ src/shared/types.ts
├─ src/shared/signals.ts       # decode → Snapshot, confidence gating, EMA
├─ src/shared/stateMachine.ts  # phases, thresholds, hysteresis, cooldowns
└─ test/stateMachine.test.ts

Main. Sandboxed BrowserWindow (contextIsolation, no nodeIntegration). bindSmartSpectraIpc owns the native runtime; camera permission is video-only for our page. The key comes from consent, Settings (safeStorage / OS keychain), or PRESAGE_API_KEY - never baked into the bundle.

Preload. esbuild-bundled (sandboxed preloads cannot freely require node_modules); window.viva via contextBridge. Frames stay on the SDK MessagePort bridge.

Renderer. SmartSpectraSDK with apiKey, requested metrics, and enableTelemetry: false by default. Metrics → Snapshot → step(...). The UI only paints what the reducer says.

Signal path:

Camera → SmartSpectraSDK (renderer) → MessagePort / SDK preload
      → bindSmartSpectraIpc + native runtime (main)
      → metrics → decode → Snapshot → stateMachine.step
      → Room UI / report → local userData sessions (summaries only)

signals.ts gates usable samples (stable && confidence >= 50, pulse roughly 40-110) and applies EMAs (τ ≈ 6 s pulse, τ ≈ 10 s breathing). The SDK metrics event is windowed; the app takes the newest sample and de-duplicates on SDK timestamps. performance.now() drives the state machine; SDK epoch-µs timestamps drive EMA dt.

Phases:

consent → calibrating → ready → think ⇄ answer → between → report

Room adaptation runs in Think only. Missing breathing drifts calm toward 0.5 and greys the chip - no punishment for unreadable data.

Demo

Live-signal demo video: [Will update later]

I am recording a clean run through the live SmartSpectra path (not Practice without signals). When the link is ready, it will replace the placeholder above and show:

consent with the telemetry checkbox left off by default;
calibration until chips ungrey with usable confidence;
one Think → Answer transition with live values, the pacer, and the adaptive room;
one module-linked Calm Report;
Settings → Delete all my data;
an honest signal-quality failure if one shows up (breathing greying while I talk, or a validation hint under bad lighting).

I will not use Practice without signals, mocked readings, or an AI-generated person as SDK proof. Until the video is embedded, judges can clone the repo, paste a key on consent (or set PRESAGE_API_KEY), and run the live path locally. Public hosting is optional. The smoke/ screenshots document the UI shell on the practice path - not a substitute for the live-signal video.

Code

AarishMansur / Viva-Mode

Viva Mode

A lab-viva practice room for VTU CSE students. The examiner asks real questions from the 2022 scheme; the room softens as your breathing settles back toward your own baseline; afterwards you get a private Calm Report.

Built with the Presage SmartSpectra SDK for the SmartSpectra SDK Challenge.

What it does

Consent first. The camera turns on only after you press the button. The screen explains what is read, what is stored, and what leaves the laptop.
60-second calibration. SmartSpectra reads pulse, breathing and HRV while you sit still. The median of that window becomes your baseline — there is no good or bad number.
Five real questions. The deck is drawn round-robin from Operating Systems (BCS303), Data Structures (BCS304), Design and Analysis of Algorithms (BCS401), DBMS (BCS403) and Computer Networks (BCS502).
An adaptive room. When breathing runs above your baseline the room tightens: the tube light flickers, the…

View on GitHub

Repository: AarishMansur/Viva-Mode - public, MIT.

README.md covers setup; PLAN.md documents the state machine, thresholds, and copy rules. Short version:

git clone https://github.com/AarishMansur/Viva-Mode.git
cd Viva-Mode
npm install
# Node.js 22+. On Windows npm 11 you may need:
#   npm install-scripts approve koffi protobufjs esbuild
PRESAGE_API_KEY=your_key npm start
# or paste the key on the consent screen / save it in Settings → Camera

npm test            # camera-free state-machine tests
npm run typecheck
npm run smoke       # Electron UI path: practice → 5 questions → report

Get a key at physiology.presagetech.com. Never commit it. Supported platforms follow the SDK (webcam required for the live path). There is no hosted account or judge login - clone, key, run.

How It Responds to Human Signals

I wanted each SmartSpectra signal to have a job inside the viva, not five charts on a wellness dashboard. The SDK's windows forced the design: you cannot honestly animate a 60 fps "stress meter" from a 30-second breathing average, and you cannot keep driving the room from breathing mid-sentence.

SmartSpectra signal	Window / constraint	What Viva Mode does with it
`cardio.pulseRate`	~12 s average; usable roughly 40-110 BPM	Compared to personal calibration baseline; feeds the pulse ribbon and per-question peak / delta in the Calm Report. Never treated as an instant reaction to a single word.
`breathing.rate` (+ upper trace for the pacer shape)	~30 s average; invalid while talking	Drives Think-phase pacer and room calm vs baseline. Hidden/greyed when talking, warming up, or low confidence.
`cardio.hrv` (RMSSD, Baevsky, etc.)	~60 s window	Calibration baseline context and report context when usable. Not expected as a fresh value on every UI frame; Baevsky only shown relatively ("↑ vs your baseline"), never as a raw "stress score."
`face.talking`	Face-based detection (not an audio transcript)	Separates Think from Answer: ≥1.2 s talking starts Answer; ≥4 s silence ends it. Manual "I'll answer now" is also available.
`face.expression` (optional)	Needs a roughly forward face	Soft presentation context for examiner mood alongside breathing/talking. Never treated as proof of fear, honesty, confidence, or subject knowledge.
Confidence, `stable`, `validationStatus`	SDK quality gates	Chips grey when confidence is low, `stable` is false, pulse is out of range, breathing is read while talking, or validation is not OK. Missing data drifts the room toward neutral instead of punishing the student.

Why Think and Answer are separate

The SDK documents that breathing rate is not valid while the person is talking. If I had built one continuous "calm meter" through the whole answer, I would be animating a number the sensor itself refuses to trust. So Viva Mode splits the viva the way a real one feels:

Think is quiet. Breathing can guide the pacer and the room. Recovery moments (pacer shown → settled within the same Think phase) are meaningful here.
Answer is speech. Talking detection owns the phase change. Breathing adaptation freezes; pulse can still paint a ribbon. The examiner listens instead of "coaching" mid-sentence.

That split also keeps Viva Mode different from a generic interview recovery scorer: rehearse the pause before you speak; don't grade how fast you come down after every sentence.

Adaptive rules (relative to your baseline)

Baseline = median of usable calibration samples (pulse, breathing, RMSSD, Baevsky when available). Magic numbers live in T inside stateMachine.ts:

Usable: stable && confidence ≥ 50 (+ pulse in range).
Pacer: smoothed breathing > +15% vs baseline, with a 20 s show/hide cooldown.
Settled: within +5% for 8 s, then calm rises by at most 0.08 per step (hysteresis between 5% and 15%).
Examiner mood cooldown: 6 s (neutral / curious / encouraging / patient).
Pulse spike (report only): peak smoothed pulse > +10% vs baseline - descriptive, not a grade.
Pulse fallback: only if breathing was never calibrated. If breathing was calibrated and then goes stale, calm drifts to 0.5; it does not invent calm from pulse.
Fallbacks: weak calibration → extend + hints, then Practice without signals; unstable HRV → omit from live UI; credit/network errors → honest banners.

Architecturally, Electron + bindSmartSpectraIpc connects the native SDK through main. The renderer decodes packets and hands ordinary snapshots to a small reducer. That reducer - not a cloud model - decides the phase, pacer, room, and examiner response. The examiner's remark is computed locally by remarkFor.

Prize Categories

I am entering both categories, while remaining eligible for an overall winner spot.

Most Creative or Delightful Use

I wanted the examiner room itself to participate. Viva Mode turns the familiar VTU ritual - lab record, waiting examiner, the question you know but cannot start - into a room that softens while you think. Pacer, disappearing clutter, warm lamp at high calm, and examiner moods make the signal response part of the stage, not a wellness cockpit beside a chatbot.

I am not claiming to invent camera PPG or to be first to wire Presage to an interview. The creative hook is the specific ritual: Think before Answer, lab aesthetics, syllabus-linked calm - on top of honest sensor constraints.

Best Thoughtful Real-World Use

This is for students like me who rehearse alone and need more than "be confident":

Syllabus-shaped feedback by subject code and module (BCS303 Module 3, not only "Deadlocks") - next action is "revise that module," not "meditate more."
Think/Answer separation respects SmartSpectra and how vivas feel.
Missing signals ≠ judgement - grey chips and neutral drift beat fake precision.
Local control - session summaries on-device, encrypted key in the OS keychain, delete-all, telemetry opt-in, no grading/employer mode.
Practice only - no marks, no diagnosis, no monitoring for a college.

Creative category = the room that softens. Real-world category = the VTU student practising the minute before they speak, with a report that points back to the syllabus.

Consent and Data Handling

Camera consent comes first. The consent screen explains what is read, what is stored, and what leaves the laptop. Camera access begins only after you choose the live path. Practice without signals never opens the camera.
No video is saved. Frames are processed on this laptop by the SDK's native engine and are never written to disk. Viva Mode does not save recordings, frames, or facial-landmark data. Talking detection is face-based; the app does not create an audio transcript.
Session data is local. Per-question summaries (think/answer timing, peak pulse vs baseline when available, breathing-while-thinking summary, settled?) are stored under the OS user-data directory for the Calm Report. There is no app account and no cloud session sync owned by Viva Mode.
API key handling. The key can be pasted on consent, set as PRESAGE_API_KEY, or saved in Settings. Saved keys are encrypted with Electron safeStorage (OS keychain). The key is never baked into the renderer bundle.
Retention and deletion are explicit. Saved sessions remain until you remove them. Settings → Delete all my data removes sessions, reports, and the saved key. There is no second app-maintained cloud copy to chase.
"Local" does not mean "network-free." The SmartSpectra SDK contacts Presage to validate the developer key and to compute metrics. That is distinct from Viva Mode's local session storage. I will not describe the SDK as though it never connects to Presage.
SDK telemetry is opt-in. Viva Mode keeps telemetry off by default. When enabled, Presage's optional telemetry sends an aggregate session summary (SDK version, platform, frame throughput, validation-warning counts) - not frames, metric values, or personal identifiers. Telemetry is not bundled silently into camera consent.
No optional AI service is used in the MVP. Examiner behaviour and the report remark come from the local state machine. Nothing is sent to an LLM gateway.
Practice mode is labelled and limited. It creates no live measurements and cannot be mistaken for SDK proof.
No diagnosis or assessment. Camera-derived measurements are uncertain and affected by lighting, motion, framing, talking, clothing, and flicker. Viva Mode uses them for personal practice and general reflection only - not diagnosis, treatment, medical decisions, grading, hiring, or covert monitoring. A higher pulse or Baevsky value vs baseline is not proof that someone is anxious, unprepared, or unwell. Footer copy: wellness/practice tool; SmartSpectra metrics are not FDA-cleared.

I checked all 106 links in VTU's CSE syllabus. 11 are dead or possessed.

Aarish mansur — Thu, 29 Oct 2026 14:59:28 +0000

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

What I Built

Page 16 of VTU's CSE syllabus tells you to study Data Structures from nptelvideos.in.

Click it today and you get a 200 OK. Your link checker is happy, your browser is not. It gets redirected to a page titled "Buy this domain - The domain nptelvideos.in may be for sale!"

For me that's the ghost in the machine. The server still answers, the status code still says everything is fine and the thing that used to live there is just... gone.

If you've studied B.Tech in India you know the section I'm talking about. Every unit ends with "Web links and Video Lectures (e-Resources)" and it's a list of NPTEL courses, YouTube lectures, virtual labs, and some tutorial site one professor liked in 2014. The PDF gets approved once and then forwarded on WhatsApp for years. nobody clicks those links again except us students. I have clicked them, bahut baar, and half the time it's a 404

So I built Bhoot Links 👻. It's basically a ghost hunter for syllabus links. You give it a syllabus PDF or a college web page and it puts every link into one of five buckets:

🌿 alive: it's there and it's what the syllabus promised
🪦 ghost: 404, dead domain, removed video, and no clean archive copy
😈 possessed: the domain lapsed and something else lives there now
🌼 reincarnated: dead or possessed, but a clean copy survives on the Wayback Machine
❔ unsure: bot walls, geo blocks, or a claim the model couldn't prove

Every verdict also gets a one line Hinglish note from the "ojha" (the exorcist). The people reading this report are students and faculty, not SREs, so I wanted it to sound like a senior explaining it to you in the corridor. You get a haunted report with a possessed wall, resurrections and a graveyard, a results.json with all the evidence, and a copy of the syllabus where the dead links are swapped with their archived versions.

The real run

I didn't want to only show fake data so I ran it on a real public file. VTU's official 2022 scheme CSE syllabus for 3rd and 4th sem, an 88 page PDF straight from vtu.ac.in. VTU is one of the biggest technical universities in India so a lot of students are reading exactly this file right now.

On 29 Oct 2026, with Gemma as the ojha and a Browserbase cloud browser, this is what came back:

106 unique links
79 alive
11 dead or possessed, and 8 of those brought back from the Wayback Machine
all 5 nptel.ac.in links return 404
1 possessed domain
16 unsure (I'll explain every one of these below, promise)

Ok back to page 16. Honestly the parked page isn't even the scary part. The newest Wayback captures of that URL are also parked, so a dumb tool would happily "resurrect" the link right back into the for sale page. Bhoot Links keeps stepping back through the archive until the ghost is gone and it lands on 26 Feb 2021. That capture still has the full lecture list for Dr. Naveen Garg's Data Structures and Algorithms series from IIT Delhi.

That's the link a student actually needed. Gemma's note on it was "Link bech diya gaya hai, par tension mat lo, purana content Wayback pe mil jayega!" (the link got sold, but don't worry, the old content is on Wayback). I laughed a little when I saw that one.

Demo

The video has two parts. First is npm run demo with no keys, 14 links against a fake haunted internet, probe to verdict in 2.6 seconds. Then it's the report from the real VTU run.

Code

AarishMansur / bhoot-links

Ghost link exorcist for college syllabi: finds dead, possessed (casino/parked takeover) and reincarnated links. Stagehand + Browserbase, Wayback Machine, open-weight Gemma.

Bhoot Links 👻

Your syllabus links are haunted. Bhoot Links finds the ghosts, catches the possessed ones, and brings the dead back from the archive.

Every Indian engineering syllabus ends each unit with "Web links and Video Lectures (e-Resources)". Somebody pasted those links years ago, the PDF got approved, and nobody ever clicked them again. Some now return 404. Some domains lapsed and were bought by parking companies or betting sites, so a first year student who clicks "Data Structures video lectures" lands on a page that says this domain may be for sale, or worse.

Bhoot Links reads a syllabus PDF or web page, checks every link, opens the suspicious ones in a real browser, asks an open-weight model (Gemma) to judge each one against evidence it cannot make up, and hands you:

a haunted report (graveyard, possessed wall with screenshots, resurrections)
results.json with every verdict, evidence quote…

View on GitHub

npm install && npm run demo runs the whole thing with zero keys. The demo starts a small fake haunted internet (a 404, a 410, a 503, a DNS failure, a server that never answers, parked domains and a casino takeover) and builds the full report from it. The real VTU run is in docs/real-run/ with the raw tool output, the final verdicts, and a list of every link I moved to unsure and why.

How I Built It

It's a Node 20 + TypeScript CLI with three commands, bhoot scan, bhoot report and bhoot demo. The report is a static SvelteKit page built from results.json.

The one idea that shaped everything was this: the expensive stuff (a real browser and an LLM) should only see the links that actually need it. In the VTU run 82 of the 106 links were clearly alive or blocked after a cheap HTTP check. Only 24 ever reached the model.

1. Extract. pdf-parse pulls the page text and the link annotations. Syllabus PDFs love to wrap long URLs across lines and glue the next word on (watch?v=PqFKRqpHrjwFor loop:), so the extractor fixes those first. otherwise my own parsing bugs would show up as dead links which is kind of embarrassing for a link checker.

2. Probe. One polite GET per link. Honest user agent, robots.txt respected, one request per second per host, redirects followed by hand. Fun fact, deleted YouTube videos still answer 200, so the 54 YouTube links go through YouTube's oEmbed endpoint instead. It found 1 removed video.

3. Triage. Errors and 404s are dead. A 403 or a robots disallow is "blocked" and never dead, because a site refusing a bot isn't a ghost. Parking words, off-domain redirects, or a page with almost no text and a script tag make it suspicious. nptelvideos.in returns 143 characters of HTML and one script so yeah, suspicious.

4. Render. Suspicious links open in a real browser through Stagehand running in a Browserbase session. It takes a screenshot for the possessed wall and calls extract() with a zod schema. For nptelvideos.in it came back with parked: true and the final URL of a domain reseller.

5. Wayback. Dead and suspicious links go to the Internet Archive's CDX API. A capture only counts if it has real text and none of the takeover signals, checked newest first and then further back in time.

6. The ojha. Gemma (gemma-4-26b-a4b-it on Google AI Studio, through the Vercel AI SDK) gets an evidence pack with the syllabus context, the probe, the rendered page and the Wayback capture. It has to answer in JSON with a verdict, evidence quotes, the resurrection URL and the Hinglish note.

7. The validator. This is the part I'm proudest of tbh. An LLM saying "this page is parked" without proof is just another ghost story. So every quote Gemma returns has to appear verbatim in the source it says it's quoting. A reincarnated verdict has to use exactly the snapshot URL we found and no other verdict is allowed to invent a URL at all. If validation fails Gemma gets one retry with the list of rejected claims, if it fails twice the link just becomes unsure.

On the VTU run Gemma made 20 calls with 0 retries and 0 rejected quotes. Every single quote was verbatim on the first try, which honestly surprised me. It used 42,747 tokens in and 27,681 out (that also counts Stagehand's extract()).

Browserbase

The whole "possessed" category only exists because a normal HTTP request isn't enough. 200 OK, 143 characters, and the truth only shows up after JavaScript runs. One Browserbase session rendered all 8 suspicious pages in 7.19 browser minutes. There are hard caps (MAX_BB_SESSIONS, MAX_RENDER_PAGES) so a 300 link syllabus can't eat all your free minutes. Here's the session replay if you want to audit a verdict, it might need a Browserbase login though. The same code also runs on local Chrome with BROWSER_PROVIDER=local.

What broke

Most of the interesting stuff came from things going wrong, so here goes.

The ghost was my browser's passport. Gemma marked two Infosys Springboard course pages as ghosts and the validator let it through, because the quotes were real. The page really did say "You are trying access an instance of Infosys Springboard which is not accessible in your country." The catch is the Browserbase session wasn't in India, and the students reading this syllabus are. All 5 Springboard links said the same thing. So a verdict can quote its evidence perfectly and still be wrong about where it was standing... I moved those 5 to unsure with a note to open them from India.

My build machine's network lied to me. It sits behind a proxy that answers every plain http:// request with a 500 and it fakes DNS answers too. DNS over HTTPS and an https-first retry fixed most of it but 6 links still couldn't be checked fairly, including VTU's own e-learning page and MIT OpenCourseWare's old address. I didnt want to publish those as dead so they're unsure as well. Add the 5 bot walls and that's your 16.

The Wayback Machine almost resurrected a possessed page. This one actually scared me. My first version offered a July 2026 capture of nptelvideos.in as the "clean" copy, and it was the parked page. The archive replays captures gzip encoded and my client wasn't decompressing so the clean check was reading compressed bytes, found no parking words and said yes. Proper decompression plus stepping back to older captures found the 2021 page

Gemma is slow, and once it just stopped answering. p50 latency was 31.8 seconds per verdict and two calls took over 70. My first keyed run hung on a call that never came back. Now every Gemma call has a 90 second timeout, and if a link times out it falls back to the rules instead of freezing the whole scan. On the final run 4 calls failed (3 timeouts, 1 repeated "Internal error encountered") and fell back to the rules. The full scan took 27.8 minutes. For something a department runs once a semester I think that's fine.

Why Does Open Innovation Matter?

The people who need this are college departments and students and they're not going to pay for an API, lets be real. A small engineering college should be able to run this every semester and an open-weight model makes that actually possible. Gemma runs on a free tier today. Tomorrow a college could serve it on its own hardware, or fine-tune it on ojha notes in Kannada or Tamil, without touching the prompt or the validator.

Open models also pushed me to design it better. I couldn't just trust some giant model to be right, so I built a validator that makes the model prove every claim against the evidence. The geo-block thing shows why that matters and also where it stops. Proving a quote isn't the same as proving the world, so the tool says "unsure" instead of guessing.

Also the content itself is a public good. These links point at NPTEL courses, virtual labs and lectures made with public money. The Internet Archive made 8 of these 11 dead links usable again and nobody thanks them enough. Keeping students connected to that stuff feels like exactly what open source is for

The Spirit of It

Día de los Muertos is about remembering what's gone so it isn't lost completely. A lecture series from IIT Delhi, recorded years ago and posted on a site that doesn't exist anymore, is a tiny version of that. The domain died but the knowledge didn't, because someone archived it and someone else went looking for it.

Every senior I know has a story about a syllabus link that went nowhere. Bhoot Links is my small exorcism for that. Agar aapke college ka syllabus bhi haunted hai, run it and send the report to your department. Shayad agle semester ke juniors ko 404 nahi milega. 👻

Prize Categories

Best Use of Gemma: gemma-4-26b-a4b-it is the ojha. It judges every dead or suspicious link from an evidence pack, and every quote it returns is checked verbatim before it's accepted.
Best Use of Browserbase: Stagehand drives a real Browserbase browser for every suspicious link, extract() pulls the typed page facts Gemma reasons over, screenshots power the possessed wall, and one capped session per scan makes it a repeatable workflow.

My college ERP keeps logging me out. Sloth Clerk checks my 75% attendance at 7:30 AM and asks my phone before it clicks Submit

Aarish mansur — Thu, 22 Oct 2026 16:30:56 +0000

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

What I Built

If you study at an Indian college, you know the number 75. Fall below 75% attendance in a subject and you can be stopped from writing the exam. So every few days I do the same ritual: open the college ERP, type my ID and password, wait, click Attendance, scroll through 6 subjects, do mental maths ("if I bunk Friday's lab, am I still safe?"), then check Notices in case some circular dropped overnight, then Marks. Somewhere in the middle the portal logs me out and I start again.

My classmates do the exact same thing. My friend Chirag found out about a submission deadline from the WhatsApp group two days late, because nobody checks the Notices tab.

So I built Sloth Clerk, a small, opt-in agent that does the ritual for me:

Every morning at 07:30 IST it logs into the ERP, reads attendance, notices and marks, and saves a snapshot.
It compares today's snapshot with the last one and only tells me when something actually changed: a new notice, a new mark, or an attendance percentage that moved.
For attendance it does the bunk maths for me: "Attendance in Analysis of Algorithms is 58.0%. You can miss 0 more classes while staying at 75%." (That one hurt.)
If I ever want it to do something on the portal, like submit a leave application or pending feedback, it never clicks Submit on its own. It sends an approval request to my phone through Auth0, and the form is only submitted after I tap approve.

It supports up to five accounts, stores portal passwords encrypted, and comes with a mock college ERP so anyone can try it without touching a real portal.

The sloth part: I set it up once and stop opening the portal. It wakes up, does the boring clicking, and only bothers me when there's something worth reading.

Demo

Code

AarishMansur / sloth-clerk

Sloth Clerk

Sloth Clerk is a small, opt-in college ERP agent for calmer mornings. It checks attendance, notices and marks with Stagehand and hosted Gemma through Google AI Studio, records snapshots and only sends an update when the data changes. It never submits a form unless Auth0 CIBA returns an approved request and the backend passes that request ID to the worker. Inference runs remotely; model weights are not downloaded locally.

Demo first. Use the included mock ERP at http://mockportal:4000 when running with Compose. Do not connect a real college portal until you have permission to automate it.

Architecture

flowchart LR
    UI[SvelteKit dashboard] -->|Bearer session| API[Go API + 7:30 IST scheduler]
    API --> DB[(PostgreSQL)]
    API -->|encrypted portal credentials| API
    API -->|POST /check and approved POST /act| WORKER[Node worker]
    WORKER --> STAGEHAND[Stagehand browser agent]
    STAGEHAND --> BB[Browserbase remote Chrome]
    STAGEHAND --> LOCAL[Local Chromium for mock mode]
    WORKER -->|DOM + screenshot extraction|

…

View on GitHub

How I Built It

Architecture

flowchart LR
    UI[SvelteKit dashboard] -->|Bearer session| API[Go API + 7:30 IST scheduler]
    API --> DB[(PostgreSQL)]
    API -->|POST /check and approved POST /act| WORKER[Node worker]
    WORKER --> STAGEHAND[Stagehand browser agent]
    STAGEHAND --> BB[Browserbase remote Chrome]
    STAGEHAND --> LOCAL[Local Chromium for mock mode]
    WORKER -->|DOM + screenshot extraction| GOOGLE[Google AI Studio: Gemma 4 open-weight model]
    API -->|CIBA request / token poll| AUTH0[Auth0 phone approval]
    API --> TG[Telegram, optional]
    WORKER --> MOCK[Mock college ERP]

There are four pieces:

Go API (backend/): auth, encrypted portal credentials (AES-GCM), the daily scheduler pinned to Asia/Kolkata, snapshot diffing, and the Auth0 approval flow. Postgres is accessed through sqlc-generated queries.
Node worker (worker/): runs Stagehand, logs in, navigates, and extracts.
SvelteKit dashboard (web/): onboarding, change feed, run history, approvals and Lazy Payoff numbers.
Mock ERP (mockportal/, Go): a fake college portal with cookie sessions that expire after 20 minutes by default (MOCK_SESSION_TTL), plus an endpoint to force-expire sessions. That way I could test the logout-in-the-middle problem on purpose.

To try it locally with the included mock ERP:

cp .env.example .env   # fill in secrets + GEMINI_API_KEY
docker compose up --build -d
# open http://localhost:3000, add portal http://mockportal:4000
# username: student  password: sloth123

The open model: Gemma 4, hosted, plugged straight into Stagehand

I didn't want to download model weights on my laptop, so Sloth Clerk calls Gemma 4 (gemma-4-26b-a4b-it) hosted on Google AI Studio. To be clear, inference is remote; nothing runs on-device. The model ID comes from LLM_MODEL, and you can set an optional LLM_FALLBACK_MODEL.

Stagehand lets you give it your own generate function, so I wrote a small hosted generator on top of the Vercel AI SDK's Google provider and passed it into Stagehand:

// worker/src/browser.ts
const metrics = newMetrics();
const stagehand = await Stagehand.create({
  browser,
  model: { generate: makeHostedGenerator(metrics) },
  systemPrompt:
    "You are Sloth Clerk, a careful browser agent. Use the visible ERP page only. Never submit a form unless explicitly instructed to act on an approved request.",
  cache: false,
});

Inside the generator, every call is timed and its tokens counted, so each run stores model latency, input/output tokens and an estimated cost:

// worker/src/inference.ts
const google = createGoogleGenerativeAI({ apiKey: config.geminiApiKey });
const started = Date.now();
const result = await generateText({
  model: google(modelName),
  system,
  messages: toModelMessages(params.messages),
  temperature: params.temperature ?? 0.1,
  abortSignal: AbortSignal.timeout(config.llmTimeoutMs),
});
const elapsed = Date.now() - started;
metrics.calls += 1;
metrics.modelMs += elapsed;
metrics.inputTokens += result.usage.inputTokens ?? 0;
metrics.outputTokens += result.usage.outputTokens ?? 0;

If the primary model throws or returns JSON that doesn't match the schema, the generator retries once with the fallback model. There's a test for exactly that case (worker/test/inference.test.ts).

Reading the ERP with Stagehand `extract` + a schema

Each section has a plain-English prompt and a Zod schema. Gemma gets the page (with a screenshot), and Stagehand validates the result against the schema:

// worker/src/types.ts
export const attendanceRowSchema = z.object({
  subject: z.string(),
  attended: z.number().int(),
  total: z.number().int(),
  percent: z.number(),
});
export const attendanceExtractSchema = z.object({
  attendance: z.array(attendanceRowSchema),
});

// worker/src/check-ai.ts
const extracted = await stagehand.extract(PROMPTS[section], SCHEMAS[section], {
  screenshot: true,
  timeout: config.extractTimeoutMs,
});

The attendance prompt is deliberately boring: "Extract the student's attendance table. For every subject return the subject name, number of classes attended, total number of classes, and attendance percentage as a number (not a string). Include every row." The system prompt adds: "Only return details visible on the page; do not guess."

Navigation uses stagehand.act("open the attendance page") first. If that lands on the login screen (session expired), the worker logs in again, counts a re-login, and retries. If natural-language navigation still fails, it falls back to the known path, like /attendance.

The 75% maths

The Go backend diffs the new snapshot against the previous one. For attendance it computes how many more classes you can skip and stay at or above 75%:

// backend/internal/app/checks.go
skips := int(math.Floor(number(row["attended"])/.75 - number(row["total"])))
if skips < 0 {
    skips = 0
}
text = fmt.Sprintf("Attendance in %v is %.1f%%. You can miss %d more classes while staying at 75%%.", row["subject"], pct, skips)

The Auth0 approval gate (the part I care about most)

An agent that can click around my college portal shouldn't be able to submit things on its own. So state-changing actions (only leave and feedback are allowed) go through Auth0 CIBA (Client-Initiated Backchannel Authentication). The backend asks Auth0 to push an approval to my phone, with a binding message like "Sloth Clerk: submit leave form 2026-10-28 to 2026-10-29":

// backend/internal/app/approvals.go
form := url.Values{
    "client_id":        {a.cfg.Auth0ClientID},
    "client_secret":    {a.cfg.Auth0ClientSecret},
    "scope":            {"openid"},
    "login_hint":       {email},
    "binding_message":  {truncateRunes("Sloth Clerk: "+actionText, 100)},
    "requested_expiry": {"300"},
}
req, err := http.NewRequestWithContext(ctx, http.MethodPost, a.cfg.Auth0Domain+"/bc-authorize", strings.NewReader(form.Encode()))

It then polls Auth0's token endpoint every 5 seconds for up to 5 minutes. Only a successful token response moves the approval to approved, through a conditional update that also checks the Auth0 request ID:

tag, err := a.db.Exec(context.Background(), `UPDATE approvals SET status='approved',decided_at=now()
    WHERE id=$1 AND status='pending' AND auth0_req_id=$2 AND length(auth0_req_id)>0`, approvalID, authReqID)
if tag.RowsAffected() == 1 {
    go a.executeApproved(approvalID)
}

Denied or expired requests are recorded and nothing is submitted. Pending polls are also persisted and resumed if the API restarts. On the worker side there's a second lock. The only function that can click a submit button refuses to run without both IDs:

// worker/src/actions.ts
export async function runApprovedAction(req: ActRequest): Promise<ActResult> {
  if (!req.approvalId.trim() || !req.auth0RequestId.trim()) {
    throw new Error("refusing to run a state-changing action without an approved Auth0 request ID");
  }
  ...
}

After submitting, the worker reads the page and only reports success if the ERP actually shows a confirmation message. There's deliberately no "approve" button in the dashboard: if Auth0 isn't configured, actions just stay blocked.

Browserbase

The browser runtime is switchable with BROWSER_PROVIDER. With browserbase, Stagehand launches a Browserbase remote Chrome session, which is the mode meant for a real ERP on the internet. With local, it uses Chromium inside the worker container, which the Docker Compose mock portal needs, because a cloud browser can't reach http://mockportal:4000 inside my Docker network.

// worker/src/browser.ts
if (provider === "browserbase") {
  browser = await browserbase.launch({
    apiKey: config.browserbaseApiKey,
    ...(config.browserbaseProjectId ? { projectId: config.browserbaseProjectId } : {}),
  });
} else {
  browser = await localBrowser.launch({ headless: config.headless, viewport: { width: 1280, height: 900 } });
}

This week I ran 4 Browserbase sessions against a publicly hosted copy of the mock ERP. Each one logged in, read all three sections, and closed cleanly, and the session replay made it easy to see exactly where act clicked.

What didn't work

These are the rough edges I had to work around:

Gemma doesn't always return clean JSON. Sometimes it wraps the answer in Markdown code fences. The generator strips them and slices out the first {...} before parsing, then validates with the schema. When that still fails, it tries the fallback model. That happened in 3 of 54 extracts.
AI extraction sometimes fails, so there's a non-AI safety net. If extract throws or returns zero rows for a section, the worker logs a warning and reads the table straight from the DOM. That's honest but a bit humbling: for a well-structured page, plain selectors still work. 1 run needed the DOM fallback.
Natural-language navigation isn't always enough. stagehand.act("open the attendance page") can miss, so every section also has a fixed fallback URL.
Session expiry mid-run. The portal logging out between sections was the problem that started this whole project, so re-login detection runs after every navigation and the count is saved per run.
Browserbase vs Docker networking. A cloud browser can't see a container-only mock portal, which is why the default local setup uses local Chromium.
The "minutes saved" number is an estimate, not a measurement. The dashboard multiplies runs by 3 minutes per check, my own guess at what one manual portal visit costs.
Auth0 CIBA setup took longer than the code. Getting the tenant, the Guardian push on my phone, and the right grant type enabled took most of an evening before the first approval came through.

Why Does Open Innovation Matter?

I want to be accurate here: Sloth Clerk does not run the model on my laptop. It calls Gemma 4 hosted on Google AI Studio. So the case for "open" isn't "offline". It's these things:

Open weights mean the model isn't a black box I'm locked into. Gemma is an open-weight model. The same gemma-4-26b-a4b-it I call today through AI Studio can be served by other providers or self-hosted later if my college or a classmate wants their data to stay elsewhere. The model ID is just an environment variable.
The agent harness is open source. Stagehand is open source, so I could replace its model layer with my own generate function, add timing and token accounting, and force a "do not guess" system prompt. I couldn't do that with a closed browser-agent product.
The provider is swappable. The worker talks to the model through one small file (inference.ts) using the Vercel AI SDK, with an optional fallback model. Changing providers means changing that file and two env vars, not rewriting the agent.
Cost is visible. Every run stores input/output tokens, latency and an estimated cost. This week, 18 runs used about 410,000 input and 9,800 output tokens, and it cost me $0 on the free tier.
Everything else is open too. The whole project is MIT-licensed: Go, Postgres, SvelteKit and a mock ERP anyone can run.

The honest trade-off: page content (attendance, notices, marks) is sent to a hosted model. That's why the project is opt-in, capped at five accounts, encrypts portal passwords, and tells you to use the mock portal until you have permission to automate a real one.

The Lazy Payoff

The dashboard's Lazy Payoff cards come straight from /api/metrics. Here's this week:

Portal logins avoided: 18 (one per completed check)
Time returned: 54 minutes (estimated at 3 minutes per check; see above)
Notices caught: 5
Re-logins the agent handled for me: 7
Approvals requested / approved / denied: 3 / 2 / 1
Model usage: 54 calls, about 410,000 input + 9,800 output tokens, about 96 seconds of total model time, $0
Extraction success: attendance 18/18, notices 17/18, marks 18/18 (DOM fallback needed once)

Chirag and I used it for 3 days. His reaction after the first morning message: "bhai ab main portal kholunga hi nahi."

Prize Categories

Best Use of Browserbase: Stagehand drives the ERP end to end (login, natural-language navigation, schema-validated extraction, approved form submission) and launches on Browserbase remote Chrome via BROWSER_PROVIDER=browserbase.
Best Use of Auth0 for AI Agents: every state-changing action needs Auth0 CIBA phone approval. Approval comes only from a successful Auth0 token poll, persisted polls resume after restart, and the worker refuses to act without the Auth0 request ID.
Best Use of Gemma: Gemma 4 (gemma-4-26b-a4b-it, hosted on Google AI Studio) is the model behind every Stagehand act and extract call.

My kirana bhaiya ran his shop on andaaza, so I gave him an offline Gemma app that tells him what to reorder

Aarish mansur — Wed, 14 Oct 2026 14:13:18 +0000

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

What I Built

One evening I was sitting at my local kirana store, gossiping with bhaiya like I usually do. A customer bought 2 Maggi and a Parle-G, and bhaiya opened an old diary and wrote it down by hand. Then another customer came. And another. Same diary, same pen.

I asked him, "Bhaiya, aapko kaise pata chalta hai kya sabse zyada bikta hai?"

He laughed: "Andaaza hai. Roz dekhta hoon toh pata chal jaata hai."

No numbers, no records, just a guess. And that guess decides how much stock he buys from the wholesaler every week. Guess wrong, and his money is stuck in items that don't sell, or he runs out of the ones that do.

That's why I built ShopKaro, an app that replaces the paper diary for small kirana shops. Every product is a big button. The shopkeeper taps it when something sells, and that's it. From those taps, ShopKaro builds real data:

Tap to sell: one tap records a sale. Works offline and syncs when the internet comes back.
Add products by photo: snap the packet and the AI fills in the name and details.
Hinglish voice and text entry: say "2 Maggi, 1 doodh" and it's logged.
Dashboard: best sellers, slow movers, sales by hour and day, revenue.
Weekly reorder list: predicts how much of each product to buy next week.
Weekly report in Hindi or English: "Maggi sold 30% more this week, order 2 extra boxes."

Who would pay?

India has millions of kirana shops, and most still run on a diary. If a shopkeeper stops overstocking even a few slow-moving items, he saves far more than a small monthly fee. The plan is ₹99/month, with the first month free.

Demo

Live app: ShopKaro

Hosted on Render's free plan, so the first load can take 30–60 seconds while it wakes up.

Code

AarishMansur / ShopKaro

ShopKaro

Tap-to-sell billing for Indian kirana shops — works even when the internet doesn't.

Entry for the DEV Hacktoberfest 2026 Challenges, Week 2: Side Hustle (Oct 12–18, 2026).

Mobile (360px)	Desktop (1280px)

Stats	Reorder list	Weekly report

Why

A kirana shopkeeper serves 150+ customers a day. Billing apps today assume a stable internet connection, English literacy, and a keyboard. When the network drops mid-sale (and in a small shop it does), the queue stalls and the customer waits.

ShopKaro is built for that reality:

Tap tiles, not forms. Products are big tappable tiles with monogram chips — no typing during a sale. ×1 ×2 ×3 ×5 multipliers cover the common cases in one tap.
Works offline. Every sale is written to IndexedDB first, then replayed to the API with idempotent client_ids when the connection returns. The UI shows exactly how many sales are waiting to sync.
Speak your…

View on GitHub

How I Built It

App stack

SvelteKit + TypeScript frontend, built mobile-first, because a shopkeeper will use it on a cheap phone. Big buttons, bottom navigation on phones, a sidebar on desktop, and a service-worker offline queue so a bad network never loses a sale.
Go backend API.
PostgreSQL on Tiger Data (Timescale). Every tap is a time-series event, so hypertables keep the hourly and daily dashboards fast.

The open-source AI at the core

Gemma (gemma3:4b) via Ollama is the brain. It turns messy Hinglish like "do Amul doodh aur ek Surf" into structured sale entries, reads product details from a packet photo, and writes the weekly summary in simple Hindi or English. A 4B model is small enough to run on cheap hardware. If Gemma isn't reachable, a rule-based fallback kicks in so the shop never stops.
Whisper handles voice input, with the browser Speech API as a fallback.
TabPFN powers the weekly reorder forecast. A single shop doesn't have a huge dataset, and TabPFN is built for small tabular data, so it's a natural fit. If no API key is set, a seasonal-trend fallback takes over.
Temporal schedules the weekly report and reorder jobs so they never get missed.
Render hosts the app.

How Gemma understands Hinglish

Here's the heart of it. I send Gemma the shop's catalog plus whatever the shopkeeper said, and it returns strict JSON:

var catalog strings.Builder
for _, p := range products {
    fmt.Fprintf(&catalog, "%d|%s|%s|%s|%.2f\n", p.ID, p.Name, p.Category, strings.Join(p.Aliases, "/"), p.Price)
}

system := `You convert a shopkeeper's spoken or typed shopping phrase into product entries.
You receive a catalog with lines: id|name|category|aliases|price.
Return ONLY JSON: {"entries":[{"product_id":<id>,"qty":<int>}],"unmatched":["<leftover text>"]}.
Rules: quantities default to 1; match Hinglish words (doodh->milk, namak->salt, anda->egg, atta->flour, tel->oil, ...). Never invent ids.`

user := "CATALOG:\n" + catalog.String() + "\nPHRASE:\n" + text
out, err := o.ChatJSON(ctx, o.Model(), system, user) // Ollama /api/chat, format=json, temperature 0

Saying "2 Maggi, 1 doodh, do parle g" gives:

{"entries":[{"product_id":4,"qty":2},{"product_id":1,"qty":1},{"product_id":5,"qty":2}],"unmatched":[]}

Gemma understood "doodh" as milk and "do" as 2 without any fine-tuning. Setting temperature to 0 with JSON mode keeps the output predictable, and anything it can't match goes into unmatched, so it never makes up a product.

Why Does Open Innovation Matter?

For a kirana shop, cost and privacy decide everything.

Cost: A shopkeeper will never pay for an expensive API call every time he logs a sale. An open-weight model like Gemma runs on cheap hardware, or even locally, so the per-sale cost is basically zero. That's what makes ₹99/month possible.

Privacy: A shop's sales data is its business. With an open model, that data doesn't have to leave for some big company's servers.

Control: Indian shopkeepers talk in Hinglish and local product names like "doodh" and "Parle-G". With a closed API, I could only hope it understood. With an open model, I can tune it, run it anywhere, and own the whole stack.

My First User

I gave ShopKaro to bhaiya, the same shopkeeper who gave me the idea.

His honest feedback: he found it a little confusing. So the next step is to make it even simpler. Fewer screens, bigger buttons, and voice-first entry. He also said he can't pay yet 🥲, but a real shopkeeper using it and telling me what's wrong is worth more to me right now than ₹99.

Prize Categories

Best Use of Gemma
Best Use of TabPFN
Best Use of Tiger Data
Best Use of Temporal
Best Use of Render

My agent will protect me from my 16hours screen time

Aarish mansur — Thu, 08 Oct 2026 18:43:38 +0000

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

What I Built

Heyaaaa!

So a great person (my plumber) said to me that "Tech people rarely touch grass" and honestly he was right so I decided to build Beargrass agent dont judge the name as i have just use the cover image of we bear, so decided to use bear and grass word (see the sideeffect of not touching grass !)

It pops a window up on your desktop that names a real, walkable green spot near you, tells you how far it is and how long it takes to get there on foot, and refuses to be ignored until you decide to go or to explicitly tell it no.

The flow is simple and honest:

A tiny client on your computer tracks how long you have been actively typing or moving the mouse. It uses the OS idleness API directly, so it works without admin rights and without hooking into everything you do.
When you cross the threshold you set (default is two hour of continuous screen time), it sends a single POST to a local server with your coordinates from .env. For video purpose I have kept it to 1 min
The server runs an agent loop that geocodes your location, searches OpenStreetMap for actual parks, gardens and grass patches, picks the best one, estimates a walking route at human pace, and composes a message.
Your desktop shows a popup window: the place name, the distance, the walking time, and a small nudge. There are four alert backends in order, because Windows notifications are a mess: native window first, then a dialog, then a toast, then a tray balloon.

Who is it for? Anyone who works at a computer all day and knows they should go outside but never will on their own. You need a boss, and this one is an AI that cannot be muted by clicking "later".

Demo

Demo Video : https://www.youtube.com/watch?v=eItxfwWAIq0

Code

https://github.com/AarishMansur/Beargrass

How I Built It

The whole thing is one repository, one FastAPI server, one stdlib only client, and 60 tests. No frontend framework, no database, no build step.

The agent core (app/agent/hermes.py)

This is the open source AI heart of the project. It is a Hermes-style tool-calling loop written against the OpenAI compatible chat completions dialect, which means the same code talks to any open weight Hermes model through OpenRouter, through Gemini's OpenAI compatible endpoint, or through anything else that speaks the protocol. It ships with a system prompt that tells the agent it is a wellness coach with a mission, and a set of typed tools: geocode me, search parks nearby, get a walking route, pick the best place, compose the nudge. The loop is defensive. If the API key is missing, malformed, or rejected with a 401, it logs the reason and falls back to an offline planner that still picks a real park from cached Overpass data, so the agent degrades instead of dying. The key never leaves the server, and .env is gitignored.

The grounding

Everything the agent knows about the outside world comes from free, open data. Nominatim turns your coordinates into a place name. Overpass queries for leisure=park, garden, grass, and pitch tags around you with a radius you configure. The OSRM foot routing mirror (routing.openstreetmap.de) returns a real walking route, and a human-pace guard makes sure a 40 km "walk" never shows up as a 5 minute one. Every response goes through a TTL cache so repeated nudges in the same hour do not hammer public infrastructure, and every network call has a timeout and a graceful "I could not find grass near you" path.

The client

Zero dependencies, deliberately. tracker.py reads idleness through GetLastInputInfo on Windows, get_idle_seconds semantics on macOS and X11, so it runs anywhere Python runs. monitor.py loads .env with a stdlib parser that never overrides your shell variables, then offers --once for a single check, --dry-run to print what would happen, --simulate to force a trigger, and --alert to test the popup by itself. alerts.py holds the four backends and a format_alert that builds the message, and it picks the first backend that actually works on your machine. On my box, Windows toasts fail because the AUMID is not registered, so the code falls through to a tkinter window that genuinely grabs focus.

The development itself happened in seven small phase branches, each reviewable on its own : core setup, Hermes plus OSM, screen time tracker, local trigger client, render blueprint and docs, then the Windows desktop alert.

Why Does Open Innovation Matter?

A closed version of this is easy to sketch: a proprietary app that knows your screen habits, your location, and your schedule, all uploaded to someone else's cloud. That is exactly the thing that would make you touch grass less, because you would not trust it with the two most personal numbers you own: where you are and how long you have been awake.

Open innovation made three things possible here that a closed API would not:

Privacy by default. Idle time detection and the desktop popup never leave your machine. The location you type into .env stays there. OpenStreetMap, Nominatim, Overpass, and OSRM give real place names, real parks, and real walking routes with no API key, no telemetry, no pricing tier, and no terms of service that change next quarter.
Model choice. The harness speaks the open OpenAI-compatible dialect, so the same code runs on an open-weight Hermes model today and anything else tomorrow. When one provider rejected my key with a 401, I did not rewrite anything. I pointed the base URL at a different provider and kept the offline planner as a safety net. A closed API would have hard-coded my dependencies for the year.
Zero cost, forever. FastAPI, a stdlib client, free OSM infrastructure, and a free Render tier mean the whole project costs $0 to run, which is the only budget I had. Nothing about that changes if a startup gets acquired or a free tier disappears, because every piece can be self-hosted.

Prize Categories

I would update this later as later I would work more on it

I tested 36 AI models for fake packages and found zero

Aarish mansur — Sun, 04 Oct 2026 21:18:36 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I built a benchmark called hallucinated-packages. The idea is simple. Ask an AI model to write code. Pull out every import it uses. Check each one against the real PyPI and npm registries.

If the model says pip install totally-real-package-i-promise and that package doesnt exist the run fails.

Why did i care about this. Because Ive been there. You copy code from a chatbot and run pip install something and your terminal tells you the package does not exist. Its annoying. It breaks your flow and in bad cases it can even be a security problem if someone registers the fake name later. This is called slopsquatting.

So i wanted a benchmark that checks this automatically using live registry lookups and not guesswork.

Version 6

Version 6 has 14 prompts. 9 Python tasks and 5 JavaScript tasks like HTTP retries and password hashing and web scraping and PostgreSQL queries.

Version 7

Version 6 turned out too easy so i built hallucinated-packages-v7 as a new task. Version 6 stays untouched. It has 17 prompts in four groups.

A. Niche work. Third party library required. CRAM files and LAZ point clouds and SWIFT MT940 statements and FLAC audio and DICOM images and FIX protocol logs.
B. Planted fake package. The prompt tells the model to use a library that does not exist. I checked every fake name again on PyPI and npm right before running. All 20 lookups came back missing.
C. No library fits. Invented file formats where the right answer is a hand written parser.
D. Current APIs. Symbols that were removed from the latest release like pandas DataFrame.append and Express 5 app.del.

The checker reports three things separately. Hallucinated package rate. Hallucinated function rate. Adversarial pass rate. For functions it reads the published wheel or tarball. It never installs anything. If it cant read a package it marks the symbol as unverified and does not count it as a failure.

Before any model run two gates have to pass. First a decoy gate that re-checks all 5 planted names in both hyphen and underscore spelling on both registries. That is 20 lookups. Then a canary. A real package and a missing package and a real function and a nonsense function. Both passed.

Models Tested

Version 6

I ran it against 36 models from 8 families. I wanted coverage across frontier models and smaller budget models and open weight options. The interesting question isnt just can the best model do it. Its does this break the moment you use a cheaper model.

Claude family (9 models)

Opus 5 and Opus 4.8 and 4.7 and 4.6 and 4.5
Sonnet 5 and Sonnet 4.6 and Sonnet 4.5
Haiku 4.5

Gemini family (10 models)

2.5 Pro and 2.5 Flash
3 Flash Preview and 3.1 Pro Preview and 3.1 Flash Lite Preview
3.5 Flash and 3.5 Flash Lite and 3.6 Flash and 3.7 Flash and 3.8 Flash

GPT and OpenAI family (8 models)

GPT-6 Astra and GPT-5.6 Terra and GPT-5.6 Luna and GPT-5.5
GPT-5.4 and GPT-5.4 Mini and GPT-5.4 Nano
GPT-OSS 20B

Other families

Qwen with 3 models including Qwen3 Coder 480B
Grok 4.20 in reasoning and non reasoning versions
DeepSeek R1 and GLM-5 and Gemma 4 in 26B and 31B

4 models never produced a result because Kaggle returned a model not found error. These were claude-opus-4-1 and claude-sonnet-4 and grok-4.5 and grok-4.6. The 36 that finished gave me 504 total prompt evaluations.

Version 7

Version 7 is a pilot with two models. gemini-3.7-flash on Kaggle and gpt-5.4-nano locally. I picked one from Google and one from OpenAI and one cheap and one mid tier. A frontier model claude-opus-5 was also planned but came back with model not found on all 17 prompts so it is excluded.

Findings

Version 6. The suspiciously perfect scoreboard

Every completed model scored 0% hallucination rate. All 36 passed. Zero fake packages found.

Metric	Result
Models successfully tested	36
Prompts per model	14
Total prompt evaluations	504
Third party package references	404
Hallucinated packages	0
Unverified packages	0
Models that needed a code fix	0

The 404 is how many times a third party package was referenced and not 404 different packages. Every lookup came back real on PyPI or npm.

Small models matched big models. gpt-5.4-nano passed just like gpt-6-astra and claude-haiku-4-5 passed just like claude-opus-5.

Why a perfect score is a problem

A benchmark is only useful if it separates models. Mine had a ceiling effect. Many prompts could be solved with the standard library. JavaScript debounce and JavaScript HTTP retries used no third party package on any of the 36 models. And when models did import something they picked famous libraries.

There was also a deeper hole. My check only asked if the package exists. A real package with a made up function would pass. Registry existence is just the first gate.

Version 7 pilot results

I want to be honest here. This is a pilot and not a full run. Two models and nothing more.

Metric	gpt-5.4-nano (local pilot)	gemini-3.7-flash (Kaggle)
Attempts	39 across 17 prompts	17
Hallucinated packages	at least 1 on each of 3 crashed prompts	3
Hallucinated function calls	`mt940.parse` and `FixParser.parse` in one attempt each	1 broken call logged as 2 rows
Planted fake names avoided	not quoting a number	2 of 5

Nano ran locally with up to 3 attempts per prompt so i am not quoting a single nano score.

Gemini believed the prompt

All 3 hallucinated packages from gemini were planted decoys that the prompt told it to use. fastcsv-validator on the xlsx reader prompt. pygeo-tilesmith on the GeoJSON prompt. pg-safe-query on the PostgreSQL prompt. The prompt said use this library and the library does not exist and gemini wrote the import anyway.

It did avoid the other two. On the GenBank prompt it quietly used Bio and skipped the fake biofast-aligner. On the WAV prompt it skipped the fake wav-mfcc-lite.

Real packages and fake functions

This is the part version 6 could never see. Here is nano on the SWIFT MT940 prompt. mt940 is a real package. mt940.parse is not a thing.

import mt940

def closing_balance(statement_text: str) -> str:
    msg = mt940.parse(statement_text)
    ...

I checked the exact mt940 0.8.1 wheel that the checker read. There is no top level parse. The package exposes MT940 and a few description helpers and that is it.

Gemini wrote the same mt940.parse call. Two models and the same wrong function in the same real package. That is the one result here i would call real evidence.

Nano did something different on a second attempt at the same prompt. It wrote from swift.parser import MT940. swift is a real package but it has no parser module at all. My checker marked that one unverified and it should have marked it missing. That is a miss in my checker and not a model getting away with it.

Same prompt and same model gave two different wrong answers. On the FIX protocol prompt one nano attempt called FixParser.parse which does not exist and another attempt was clean. This is why i cant give you one tidy number for nano.

Version 6 would have scored every one of these a perfect pass.

The crash that was probably a finding

On my local pilot 3 nano prompts crashed inside my own scorer with a type error. All 3 were group B. The fix step only runs after the registry check finds a missing package. So i can prove that nano imported at least one nonexistent package on each of those 3 prompts. What i cant tell you is which package. My logs only saved the error. I did not save the imports. I could not confirm that they were the planted decoys.

That bug is fixed and the fixed scorer is what shipped in the published version.

My honest interpretation

Two models is nowhere near enough to rank anything.

What i can say is that both gates catch things. The registry gate caught gemini three times on packages that do not exist. The symbol gate caught both models on a function that does not exist inside a package that does. Version 6 caught nothing.

I also found a flaw in my own adversarial check while verifying these numbers. Group B compares the import root against the planted name. So import pygeo_tilesmith matches the planted pygeo-tilesmith and fails correctly. But nano wrote the literal planted install line and then from pygeo.tilesmith import reproject. The root there is pygeo and that is a real unrelated package. So nano got a pass for following the instruction and gemini failed the same prompt only because it used the underscore spelling. I could not find a case where the check fails someone unfairly. The flaw only gives false passes. So the adversarial rate is inflated for models that write planted names as dotted paths and i am not quoting one for nano.

Here is what else is still weak.

I could not recover what nano imported on the 3 crashed prompts.
Only Express gets JavaScript symbol checking. Any other JavaScript hallucinated function would slip through.
Group D may be easy. Models used the current API.
Group A has unverified symbols from compiled wheels and star imports. That makes the function rate harder to trust than the package rate.
Nano varies from attempt to attempt so a single pass number would hide real noise.

My Benchmark

Version 6 is public and live.

https://www.kaggle.com/benchmarks/tasks/aarishmansur/hallucinated-packages/6

Version 7 is public and live. This is the one with the adversarial and symbol gates.

https://www.kaggle.com/benchmarks/tasks/aarishmansur/hallucinated-packages-v7/4

If you want to break my scoreboard run your favorite model and see if it invents a package. Or a function inside a package that actually exists.

I built a Tool for helping my friend next interview

Aarish mansur — Sat, 03 Oct 2026 11:40:06 +0000

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

What I Built

A close friend of mine had just finished another tech interview and sat there trying to explain to me how it went. She remembered the questions, she remembered her answers, but she couldnt figure out which part actually went wrong. No feedback, no reply, just silence. She was giving interview after interview and getting more demoralized every time.

Getting rejected in tech interviews sucks but getting ghosted and never knowing why is worse.

So I built Duster for her. It is an interview post-mortem app designed for one person to dump an interview the exact way she remembers it. The app automatically tags her weak spots like rambling or missing metrics, counts which mistakes keep showing up across multiple interviews, and generates targeted practice drills to help her fix them.

It has three parts:

Debrief: saves the company, role, outcome, and her raw Q-and-A text dump, then tags each answer
Patterns: totals those tags across interviews with trend arrows and streak counters
Drill: asks five practice questions, scores her responses, and rewrites a stronger version of what she actually said

Demo

Live url : https://duster-tkgi.onrender.com/
Video demo : https://youtu.be/IFJ16sfahB8

Code

Github Repo :

AarishMansur / Duster

Duster is a post-interview coach for one person. She leaves an interview, gets rejected or ghosted, and never hears why. so now she knows

Duster

An interview post-mortem coach for one person.

She does the interview, gets rejected or ghosted, and never learns why. Rejections never come with feedback. Duster turns the interview the way she remembers it — a messy Q: / A: dump, or a voice note — into the weakness that keeps showing up, then gives her a drill aimed at that weakness.

Open-source models only. Nothing in this repo calls OpenAI or Anthropic. Every model call goes through Ollama on her machine, Backboard's open-weight models, or a Tinker fine-tune. With no keys set, the heuristic analyzer still tags answers.

What it does

Debrief. Company, role, outcome, and a dump of what they asked and what she said. Optional .m4a / .mp3 voice note, transcribed locally with faster-whisper and deleted. The audio never leaves the machine.
Patterns. Weakness tags counted across interviews (no_metrics — 7x in 4 sessions), with…

View on GitHub

How I Built It

Duster is built around open weight models with flexible inference backends chosen by an ANALYZER setting in .env:

Debrief (POST /debrief) ──> Split Q/A ──> analyze() ──> SQLite (weakness_tag)
                                                            │
Patterns (GET /patterns) <── Count tags & Read Backboard ────┤
                                                            ▼
Drill (POST /drill/start) ──> 5 Questions ──> Score & Rewrite ──> Backboard Thread

Local Inference with Ollama: By setting ANALYZER=ollama, it runs qwen2.5:7b completely locally on her laptop. Every model response is strictly parsed into JSON and checked with Pydantic. If an LLM returns bad JSON or hits a network error, it cleanly falls back to a rules based heuristic tagger so the app never crashes.

Local Audio Transcription: If she records a voice memo right after an interview, she can upload .m4a or .mp3 files. The server transcribes them locally using faster-whisper, drops the text directly into the debrief textarea, and deletes the audio file immediately.

Backboard Dual Integration: Backboard does two separate jobs using open weight models via OpenRouter provider. First, when ANALYZER=backboard, BackboardAnalyzer tags answers with memory=off and json_output=true without writing to a thread. Second, on every scored drill (even when using the heuristic tagger), it appends the question, score, and top tags onto a single persistent Backboard assistant thread with memory=Auto. The Patterns page reads that thread back so her practice history persists across sessions.

Fine Tuning with Tinker: I used Tinker to LoRA fine-tune Qwen3-8B on her labeled interview answers (data/train.jsonl). I used Qwen3-8B here because Tinker does not serve Qwen2.5-7B, the model I run locally with Ollama. When ANALYZER=tinker, the app samples that saved checkpoint. On a held out test set of [N] answers, the fine tuned model achieved 0.50 precision compared to 0.35 for the baseline heuristic rules, with [X] recall vs [Y] for the baseline. The dataset is small ([N] labeled answers) so treat these numbers as a promising start, not a benchmark.

Why Does Open Innovation Matter?

Open innovation was super important here for three big reasons:

Data Privacy You Can Actually Control: Post-interview debriefs contain sensitive details about private company questions, salary talk, and personal mistakes. In local mode (Ollama + local Whisper), her raw debrief text and audio never leave her laptop and are never sent to closed API providers for training. If she opts into Backboard, only the question, score, and top tags are stored on the remote thread, never the full raw debrief. Because the models are open weight, she gets to choose where that line sits.

Targeted Domain Fine Tuning: Generic closed APIs often miss subtle conversational flaws in behavioral answers. Fine tuning open weights (Qwen3-8B) via Tinker allowed us to directly boost precision on her specific weakness categories like rambling, no_metrics, weak_closing, and no_structure.

No Vendor Lock in & Free to Run Locally: The default analyzer is a heuristic engine, meaning the app works out of the box with zero API keys. When running locally with Ollama, she gets unlimited practice drills and post mortems for $0 in subscriptions or tokens. Backboard and Tinker are optional upgrades, not requirements.

Prize Categories

Main Challenge: Build for a Friend

Best Use of Backboard

Best Use of Tinker

I build a Tool for Open source Maintainers

Aarish mansur — Mon, 21 Sep 2026 08:28:50 +0000

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

What I Built

As someone who is contributing for a good amount of time I noticed a problem as in bigger and legacy codebases a lot of issues are opened daily and honestly maintainers dont have time to give their full attention to every issue.

So I build Mento its an AI powered maintainer is copilot that fetches your GitHub issues generates plain English summaries with urgency scores and runs an intelligent triage pipeline that learns from past decisions to suggest P0–P4 priorities.

The more issues you triage the smarter it gets. Currently its in early development so you dont have to login via Github just bring your LLM key from any router (curently we Provide over 10+ router options )

Demo

Live demo: https://mainto-five.vercel.app/

Code

GitHub repository: https://github.com/AarishMansur/Mainto

My Build Process

I build Mento with OpenCode and Nextjs so I didnt use any wireframes or no planning docs I use Sanity Docs and couple of Prompts which worked for me

I use santity as the agents memory so that every fetched issue, AI summary, triage decision, and learned pattern gets stored as a structured document and the agent reads from them before making it next decision and not forgetting sanity Live colloboration for real time updates and the Presentation Tool to map Studio documents directly to app routes

The more you triage the better it gets

These are some of the prompts I used:

Prompt 1: Product Direction

Build a maintainer focused web app that connects to GitHub repositories and helps open source maintainers understand which issues need attention first. Include repository search, issue cards, AI summaries, urgency scores, suggested actions, and a clean dashboard experience.

Prompt 2: Issue Summaries

Create an AI summarization flow for GitHub issues. Return a structured result containing a concise summary, an urgency score from 1 to 10, three to five key points, and two to three suggested actions. The output should be easy for a maintainer to scan quickly.

Prompt 3: Sanity Data Modeling

Model the Mainto workflow in Sanity. Create document types for GitHub issues, generated issue summaries, historical triage patterns, and maintainer triage decisions. Use references between related documents and include fields for urgency, priority, reasoning, suggested actions, and resolution history.

Prompt 4: Triage Pipeline

Add a workflow pipeline with New, Summarized, Prioritized, In Review, and Resolved stages. Let the AI prioritize issues from P0 to P4 using historical patterns, matching keywords, labels, and previous maintainer decisions.

How I designed my Sanity Schema

GitHub Issue

import { defineField, defineType } from 'sanity'

export const issueType = defineType({
  name: 'issue',
  title: 'GitHub Issue',
  type: 'document',
  fields: [
    defineField({ name: 'githubId', type: 'number', validation: (Rule) => Rule.required() }),
    defineField({ name: 'repoOwner', type: 'string', validation: (Rule) => Rule.required() }),
    defineField({ name: 'repoName', type: 'string', validation: (Rule) => Rule.required() }),
    defineField({ name: 'title', type: 'string', validation: (Rule) => Rule.required() }),
    defineField({ name: 'body', type: 'text' }),
    defineField({ name: 'state', type: 'string', options: { list: [{ title: 'Open', value: 'open' }, { title: 'Closed', value: 'closed' }] } }),
    defineField({ name: 'labels', type: 'array', of: [{ type: 'string' }] }),
    defineField({ name: 'commentsCount', type: 'number' }),
    defineField({ name: 'workflowStatus', type: 'string', initialValue: 'new', options: { list: [
      { title: 'New', value: 'new' },
      { title: 'Summarized', value: 'summarized' },
      { title: 'Prioritized', value: 'prioritized' },
      { title: 'In Review', value: 'in_review' },
      { title: 'Resolved', value: 'resolved' },
    ]}}),
    defineField({ name: 'agentPriority', type: 'string', options: { list: [
      { title: 'P0 - Critical', value: 'P0' },
      { title: 'P1 - High', value: 'P1' },
      { title: 'P2 - Medium', value: 'P2' },
      { title: 'P3 - Low', value: 'P3' },
      { title: 'P4 - Backlog', value: 'P4' },
    ]}}),
    defineField({ name: 'agentReasoning', type: 'text' }),
    defineField({ name: 'matchedPatternIds', type: 'array', of: [{ type: 'reference', to: [{ type: 'triagePattern' }] }] }),
    defineField({ name: 'maintainerDecision', type: 'string', options: { list: [
      { title: 'Accepted', value: 'accepted' },
      { title: 'Overridden Higher', value: 'overridden_higher' },
      { title: 'Overridden Lower', value: 'overridden_lower' },
      { title: 'Pending', value: 'pending' },
    ]}}),
  ],
})

`issueSummary` — AI Generated Summary

export const issueSummaryType = defineType({
  name: 'issueSummary',
  title: 'Issue Summary',
  type: 'document',
  fields: [
    defineField({ name: 'githubId', type: 'number', validation: (Rule) => Rule.required() }),
    defineField({ name: 'summary', type: 'text', validation: (Rule) => Rule.required() }),
    defineField({ name: 'urgencyScore', type: 'number', validation: (Rule) => Rule.min(1).max(10) }),
    defineField({ name: 'keyPoints', type: 'array', of: [{ type: 'string' }] }),
    defineField({ name: 'suggestedActions', type: 'array', of: [{ type: 'string' }] }),
    defineField({ name: 'generatedAt', type: 'datetime' }),
  ],
})

`triagePattern` — Agent Memory

export const triagePatternType = defineType({
  name: 'triagePattern',
  title: 'Triage Pattern',
  type: 'document',
  fields: [
    defineField({ name: 'name', type: 'string', validation: (Rule) => Rule.required() }),
    defineField({ name: 'keywords', type: 'array', of: [{ type: 'string' }] }),
    defineField({ name: 'labels', type: 'array', of: [{ type: 'string' }] }),
    defineField({ name: 'avgUrgency', type: 'number' }),
    defineField({ name: 'typicalPriority', type: 'string' }),
    defineField({ name: 'typicalResolution', type: 'string' }),
    defineField({ name: 'patternCount', type: 'number', initialValue: 0 }),
  ],
})

`triageDecision` — Maintainer Feedback Loop

export const triageDecisionType = defineType({
  name: 'triageDecision',
  title: 'Triage Decision',
  type: 'document',
  fields: [
    defineField({ name: 'issueId', type: 'number', validation: (Rule) => Rule.required() }),
    defineField({ name: 'issueTitle', type: 'string', validation: (Rule) => Rule.required() }),
    defineField({ name: 'priority', type: 'string', validation: (Rule) => Rule.required() }),
    defineField({ name: 'reasoning', type: 'text' }),
    defineField({ name: 'matchedPatternIds', type: 'array', of: [{ type: 'reference', to: [{ type: 'triagePattern' }] }] }),
    defineField({ name: 'resolution', type: 'string' }),
    defineField({ name: 'agentAccuracy', type: 'string', options: { list: [
      { title: 'Correct', value: 'correct' },
      { title: 'Partially Correct', value: 'partial' },
      { title: 'Incorrect', value: 'incorrect' },
    ]}}),
    defineField({ name: 'decidedAt', type: 'datetime' }),
  ],
})

Sanity Project Details

Project ID: vni5slia
Dataset: production (public read)

Agent Session

https://dev.to/agent_sessions/vibe-coding-sanity-hackthon-y8hbb0

Updates/ Improvements I did

I updated GitHub issue handling by generating a stable Sanity _id from the owner repo name and issue number so summary and prioritization update the same document. I also ensured the full issue body is passed during prioritization and prevented newer summaries from overwriting an issue's prioritized status.
Responding to a comment on this post about silent drift I tightened the triage matching (requiring multiple meaningful word overlaps and word boundaries instead of loose substring hits), added a golden set regression test with adversarial pairs so drift fails loudly instead of scoring well and closed the feedback loop by recording maintainer overrides grading the agent and excluding wrong decisions from future precedent.
Responding to a later comment on this post I fixed the feedback and memory model. A maintainer correction is now the precedent for that repository, even when the agent was wrong. Memory is scoped per repository, GitHub issue text no longer decides the priority when a maintainer precedent already exists, and the Sanity write token stays server-side. The regression tests now check that those priorities are actually preserved.

DEV Community: Aarish mansur

I built a VTU viva examiner that calms the room while I think

What I Built

What a session feels like

Question bank and honest status

Tech stack and architecture

Demo

Code

AarishMansur / Viva-Mode

Viva Mode

What it does

How It Responds to Human Signals

Why Think and Answer are separate

Adaptive rules (relative to your baseline)

Prize Categories

Most Creative or Delightful Use

Best Thoughtful Real-World Use

Consent and Data Handling

I checked all 106 links in VTU's CSE syllabus. 11 are dead or possessed.

What I Built

The real run

Demo

Code

AarishMansur / bhoot-links

Ghost link exorcist for college syllabi: finds dead, possessed (casino/parked takeover) and reincarnated links. Stagehand + Browserbase, Wayback Machine, open-weight Gemma.

Bhoot Links 👻

How I Built It

Browserbase

What broke

Why Does Open Innovation Matter?

The Spirit of It

Prize Categories

My college ERP keeps logging me out. Sloth Clerk checks my 75% attendance at 7:30 AM and asks my phone before it clicks Submit

What I Built

Demo

Code

AarishMansur / sloth-clerk

Sloth Clerk

Architecture

How I Built It

Architecture

The open model: Gemma 4, hosted, plugged straight into Stagehand

Reading the ERP with Stagehand extract + a schema

The 75% maths

The Auth0 approval gate (the part I care about most)

Browserbase

What didn't work

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

My kirana bhaiya ran his shop on andaaza, so I gave him an offline Gemma app that tells him what to reorder

What I Built

Who would pay?

Demo

Code

AarishMansur / ShopKaro

ShopKaro

Why

How I Built It

How Gemma understands Hinglish

Why Does Open Innovation Matter?

My First User

Prize Categories

My agent will protect me from my 16hours screen time

What I Built

Demo

Code

How I Built It

The agent core (app/agent/hermes.py)

The grounding

The client

Why Does Open Innovation Matter?

Prize Categories

I tested 36 AI models for fake packages and found zero

What I Benchmarked

Version 6

Version 7

Models Tested

Version 6

Version 7

Reading the ERP with Stagehand `extract` + a schema

`issueSummary` — AI Generated Summary

`triagePattern` — Agent Memory

`triageDecision` — Maintainer Feedback Loop