DEV Community: Manswi Pradhan

I built a ghost that haunts my desktop until it can see my work

Manswi Pradhan — Sat, 31 Oct 2026 15:27:55 +0000

My submission for the Hacktoberfest Open-Source AI Challenge: Ghost in the Machine. Gemma 3 4B, Ollama and PySide6. Nothing leaves my laptop.

A reminder asks one thing of you: a tap. Snooze, dismiss, "done". None of them checks anything and I am very good at tapping.

So I built Haunt, a small ghost that appears over whatever I am doing, says something unsettling and does not leave until it can see that the work is done.

What it does

You add a task. Every few minutes the ghost appears on top of your other windows and speaks a line written by Gemma. If you ignore it, it comes back angrier: a whisper first, then eerie, then furious.

When you click I did it, the ghost says "Hold still. Let me look at your screen..." and checks. If it does not see the work, it tells you what it does see and it stays. Something like:

I see a YouTube video of cats. That is not "Finish the report".

If you honestly did the work and the model disagrees, an "I swear I did" button appears after two failed claims. A wrong judgement should never trap you.

How it sees

Here is what happens when you click I did it:

The ghost hides before capturing the screen, so it does not photograph itself.
Haunt captures visual evidence from the desktop.
The screenshot and task context are sent to Gemma 3 4B through Ollama.
The model evaluates whether the screenshot supports the completion claim.
Haunt processes the verdict. If the evidence is insufficient, the ghost responds and remains part of the interacti on.

The model's job is not to read your mind. It evaluates what is visible on the screen.

That distinction matters: a screenshot is evidence of a moment, not proof of everything you have done.

Not everything needs a model

If a task is tied to a file or a repo, Haunt does not need to look at anything:

python haunt.py add "Write tomorrow's notes" --proof file:~/notes.txt
python haunt.py add "Commit the lab work" --proof git:~/lab

The first finishes the moment the file is saved after the task was created. The second finishes when a new commit lands. If a file was saved, I do not need a 4B vision model to tell me. Checking that is cheaper and more reliable than asking a model to interpret pixels, so the model only handles the tasks that really are visual.

Does the judge work?

I tested the judge using 10 screenshots: 5 representing completed tasks and 5 representing incomplete tasks.

This was an initial sanity check to see whether the model could distinguish relevant work from unrelated desktop activity.

I did not retain the individual verdict counts needed to report a reliable confusion matrix, so I am not presenting invented accuracy numbers. Ten screenshots would also be far too small a dataset to establish general reliability.

A more rigorous evaluation would use a larger, labelled dataset and report true positives, false positives, true negatives, false negatives, precision and recall.

What broke

The buttons did nothing. The ghost's buttons looked fine and did not respond to clicks. The tests were green the whole time, because they click by calling button.click() in code, which skips the window system entirely. I isolated it with a minimal Qt button test and then the real window. The culprit was the Qt.Tool window flag. Removing it fixed clicking in my WSLg setup. I only tested that one setup, so other desktops may behave differently.

A newer PySide6 crashed the app. PySide6 6.12.0 crashed Haunt on my machine. I found that 6.8.3 works in a clean environment and pinned it in requirements.txt.

localhost was not where Ollama lived. I develop in WSL while Ollama runs on the Windows host, and localhost inside WSL did not reach it. I point Haunt at the host's address with OLLAMA_HOST. That address is specific to my setup.

The "voice" was a beep. My first version called QApplication.beep() and I was calling that speech. The real fix was Windows' built-in System.Speech, driven from PowerShell on a background thread so the ghost never freezes while it talks.

Why it had to be local

This project exists because of a conflict. A ghost that watches your screen sees your mail, your chats and whatever you would rather not show anyone. That is a reasonable thing to build only if the screenshot goes to your own machine and nowhere else.

Privacy. The screenshot is held in memory and sent to Ollama on my own computer. After the one-time model download, nothing in Haunt calls out to the internet and there is no API key.
Every look is free. A ghost that checks you repeatedly is only affordable when a look costs nothing.
I can swap the model. HAUNT_MODEL or --model picks any vision-capable model from ollama list. I used a 4B model because my laptop has 16 GB of RAM and no GPU, and a bigger one would be impractical. The ghost covers the wait with "Hold still. Let me look."
It degrades instead of dying. If Ollama is not running, the ghost uses built-in lines and says so in the window ("voice: built-in"), rather than pretending.

What it can't do

A screenshot is one moment, not an hour of work. Opening the right window would fool it.
A 4B model can accept irrelevant evidence and reject real work. That is why the honour button exists.
Speech uses the Windows speech engine, which is built in but is not an open-weight model. On other systems the ghost is silent.
Local is not the same as secure. A screenshot can still contain sensitive things.

Try it

git clone https://github.com/newton-lebniz/haunt
cd haunt
pip install -r requirements.txt
ollama pull gemma3:4b
python haunt.py check
python haunt.py add "Finish the report" --expect "The report open with a finished conclusion" --first 0
python haunt.py run

Code: https://github.com/newton-lebniz/haunt
Landing page: https://newton-lebniz.github.io/haunt/

How I built it: I used AI assistants for code and debugging. I ran it, tested it and fixed the real-desktop problems on my own machine.

A ghost that watches your screen should not live on someone else's server. This one lives on mine, and it still will not let me off.

Challenge: Hacktoberfest Open-Source AI Challenge

Week 4 Theme: Ghost in the Machine

Category: Gemma

Inbox Sloth: a local Gemma that reads your inbox so you don’t have to

Manswi Pradhan — Sun, 25 Oct 2026 09:05:10 +0000

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

What I Built

My professor emails on Monday: assignment due Friday. On Tuesday: "correction, because of the holiday it's now Thursday."

An email summariser gives me two accurate summaries and zero help. I still have to notice they're about the same assignment, remember which one wins, and move the date in my head.

Inbox Sloth does that part for me. It reads a mailbox with Gemma running on my own laptop, turns emails into commitments (what, by when, which email said so), and notices when a later email changes an earlier one:

Submit Probability Assignment 3: Thu 22 Oct, 11:59 PM. Changed (was Fri 23 Oct).
Evidence: "Please submit Probability Assignment 3 by Thursday 22 October, 11:59 PM instead."

I open one page and see what to do first, what's due this week, what clashes, and which dates moved and are worth double-checking.

Reads email, extracts commitments: assignments, meetings, exams, replies, with deadlines resolved to real dates.
Tracks them across emails: a correction updates the original task and keeps the history; an older email can never overwrite a newer one.
Plans your day and week: ranked by urgency first, then by what you said matters (a student's exam, a freelancer's client reply). Every ranking shows its reasons, so you can disagree with it.
Flags trouble: overlapping events, overloaded days, moved dates.
Shows its evidence: every task links to the sentence it came from, highlighted in the original email.
Admits what it ignored: informational emails (a mess menu, an instruction tweak) create no task and appear under "Ignored by the sloth" with the reason, so nothing disappears silently.

Demo

Run it yourself in a few minutes (the demo command runs the real model on 18 sample emails and scores it against ground truth):

ollama pull gemma3:1b
cd backend && pip install -r requirements.txt
python -m pytest -q              # 132 tests, no Ollama needed
python -m app.cli demo           # real model run, scored against ground truth
uvicorn app.main:app             # http://localhost:8000

Code

https://github.com/newton-lebniz/inbox-sloth

How I Built It

Stack: gemma3:1b via Ollama (JSON-schema constrained output, temperature 0), FastAPI, SQLite, plain HTML/JS, pytest. It runs on a CPU-only laptop with 16 GB RAM.

The key design decision: the model is a noisy witness. The model reads; code decides.

email -> Gemma (local, JSON-schema output) -> checks in plain code -> commitment tracker -> plan

Dates are never computed by the model. It copies the words ("Thursday 5 PM"); a deterministic resolver turns them into a date relative to when the email was sent.
A date has to be in the email. If the model's date words don't appear there, they're replaced by the email's own date (flagged "Date unsure") or dropped.
A task needs a cue: an action, deadline, meeting or exam word, in a sentence that isn't about the past or a cancellation.
Evidence is chosen by code, not trusted from the model's quote.
Kind and title are normalised from the subject: a quiz is an exam, and a meeting is named after the meeting.
Safety net: if the model returns nothing for an email, rules may propose one task, subject to the same checks, and the UI marks it "found by rules".

Valid model answers are cached by (model, prompt, email), so re-analysing all 18 emails after a code change takes about a second instead of three minutes. That is what made fast iteration possible on a CPU.

The part I almost didn't write

On Day 1, my evaluator said: 10 of 12 commitments found, 6 of 12 dates right.

Then I read the rows. It was comparing "Pay semester fee" with "Submit data structures exam". My matcher accepted the best title match even when the best was bad, so the score looked better than the output. After fixing the evaluator and re-scoring the same real output:

Day 1 (real gemma3:1b run)	reported	actual
Commitments found	10/12	6/12
Dates correct	6/12	5/12
False positives	2	6

What the real run showed: for 4 of the 14 actionable emails, including the deadline correction, no commitment came out. It invented tasks for informational emails ("Khichdi and papad dinner" from a mess-menu notice). It rewrote dates, and a quiz became "Attend class".

So the interesting problem wasn't prompting. It was building something that stays correct when the model doesn't. With the checks above, same prompt:

	Day 1 (re-scored)	After the code checks (real Gemma run)
Found	6/12	12/12
Dates correct	5/12	12/12
Kinds correct	5/12	12/12

An ablation (on recorded Gemma answers) shows where it comes from: without the rule safety net, 10/12 found and 9/12 dates; without the cue check, the false positives come back.

Honest caveats

I wrote the rules after seeing these 18 emails, so this is a development-set score, not a claim that it generalises.
I then wrote 12 differently-worded emails and ran them through the rules alone (all handled), and tried adversarial ones. That found two real flaws ("Thanks for attending the workshop on Monday" became a future task; an email's own subject could act as evidence for a title copied from it). Both are fixed and tested. But I wrote the rules and the tests, so treat this as a smoke test, not proof.
All emails are synthetic. No real mailbox was used.
A 1B model misses things; the rule fallback proposes at most one task per email. A cancellation is ignored rather than applied to an existing task. English only, no Gmail sync yet (imported messages only).

Why Does Open Innovation Matter?

Email is the most private text most people have: grades, client names, medical appointments, offers. I didn't want to ship that to a third-party API just to find out when my lab report is due.

Local inference: after mail is fetched, analysis never leaves the machine.
Free after setup: no per-email bill, so running it over a whole mailbox is a non-event.
Swappable: one environment variable (SLOTH_MODEL=gemma3:4b) changes the model. That mattered, because a 1B model made mistakes and the architecture had to survive them.
Inspectable and reproducible: open weights at temperature 0 let me cache answers and replay them, so I could compare Day 1 and Day 2 on identical model output. A hosted model that changes under you can't give you that.

The Lazy Payoff

The saving is the part I used to do by hand: noticing that Tuesday's email overrides Monday's, and re-checking my own list. The honest limit: I haven't run it on a real mailbox for a week, only on 18 synthetic emails, so I can't claim hours saved. What I can show is that on those emails it found every commitment and applied the date correction, and that for every task it shows the sentence it came from, so checking it takes seconds.

What I learned: (1) a metric you wrote in ten minutes is a hypothesis, and mine flattered me until I read the rows; (2) let the model read and let code decide; (3) make every judgment visible. The evidence sentence, the ranking reasons and the ignored list made the tool trustworthy and also debuggable.

Prize Categories

Best Use of Gemma

I built a WhatsApp shop assistant that runs on a CPU-only laptop. The hard part was getting it to say "I don't know."

Manswi Pradhan — Sun, 18 Oct 2026 07:20:39 +0000

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

What I Built

If you've ever bought jewellery over WhatsApp or Instagram DMs, you know the script. You send "price?" The seller sends photos. You ask what it's made of, what size it is, whether it comes in another colour. Multiply that by every buyer and every item, and a solo seller spends more time retyping answers than making things.

SellMate takes that job off their plate. You drop in a photo and a few keywords, and it writes the listing. Buyers get a chat page where they can ask questions. Anything the assistant can't answer lands in the seller's inbox instead of being guessed. It runs entirely on my laptop (16 GB RAM, no GPU) using two small open models through Ollama.

Photos and keywords in, listing out. Title, description, highlights, tags.
It asks instead of guessing. Material, size and delivery come back as questions for the seller, who types the answers once.
A claim guard. A photo shows colours, not materials. If the model writes "silver" or "hand-tied" and the seller never said so, plain code removes or softens it and asks the seller.
A shop page. Buyers ask questions; the assistant answers only from the listing and the seller's own details.
A seller inbox. Anything it couldn't answer, with a count if several buyers asked.
Ready to post. WhatsApp, Instagram and Reddit versions, one click to copy.

Who would pay for this

A solo seller with a catalogue they keep re-describing in DMs is the person I'd start with. I haven't priced SellMate yet. I want to test two separate sources of value: whether generating listings saves enough time to be worth paying for and whether routing unanswered buyer questions to a seller inbox is useful enough on its own. I'd talk to a few handmade-product sellers, let them try both workflows and ask what they'd actually pay before setting a price.

Demo Usage Example

Drop in a bracelet photo, type "handmade bracelets", a price and a category.
Read the listing. A red box shows what the claim guard removed; a yellow box shows what to check.
Type what's true about the item and press Rewrite.
Copy the WhatsApp, Instagram or Reddit version.
On the shop page, ask the price (instant), then something the listing doesn't cover (it passes the question to the seller instead of guessing).
Back on the seller desk, the question is waiting in the inbox.

Code

Github Repo

You need Python 3.10+ and Ollama:

ollama pull moondream
ollama pull gemma3:1b
pip install -r requirements.txt
uvicorn backend.app.main:app

Then open http://127.0.0.1:8000 (seller desk) and http://127.0.0.1:8000/shop.html (what buyers see).

How I Built It

A 1B-parameter text model writes well but can't see images. A vision model that can see is heavy on a laptop with no GPU. So I used two small open models, each doing one job:

Moondream looks at the photo and describes how it looks.
Gemma 3 1B writes the listing from that description plus what the seller typed. On my machine, one photo took about 22 seconds to look at and 18 seconds to write. That's slow next to a hosted API and I'll come back to that.

Buyers use a separate shop page. Their questions go to Gemma again, but it only sees the one to three products that match the question and it's told to answer only from the seller's facts. If it doesn't know, it says so, tells the buyer the question was passed on and the seller sees it in an inbox. The backend is FastAPI, the frontend is plain HTML, CSS and JavaScript and the catalog is a JSON file, because one seller on one laptop doesn't need a database.

Three things that broke

This is the part I learned the most from.

1. 23 tests passed and the real model still failed. On Day 1 my tests passed. Then I ran SellMate for real and got Ollama returned an error (400). gemma3:1b is text-only and rejects image input. My tests stubbed the model, so they could never have caught it. Worse, the status light said gemma3:1b ready, because the health check only knew the model was downloaded, not that it could see. The fix was the two-model pipeline, a health check that reports each model separately and a test that asserts the text model never receives an image.

2. I asked the model to grade its own homework. For the inbox, I had Gemma return answered_from_catalog: true/false alongside every answer. On the first live test, a buyer asked "What's the price?" and Gemma answered correctly ("The price is 100"), and the question still landed in the seller's inbox, next to repeats of the same material question.

A 1B model can't be trusted to judge its own answer. The fix had two parts: plain price questions no longer go to the model at all (the answer comes from the price field, instantly and always correct), and the "needs the seller" decision now comes from plain code that reads what the answer says. Repeated questions are counted instead of repeated.

My first version of that fix was wrong in the other direction. When I tried it on realistic replies, "You can contact the seller to order it" was treated as "I don't know", which is the original bug again, and "Sorry, I couldn't find that in the details" slipped through, which means a buyer's question never reaches the seller. Both failures cost something: noise teaches the seller to stop checking the inbox, and a missed question is a lost sale. Pointing at the seller now only counts when it's how the reply opens, and "Is the price negotiable?" no longer gets answered with just the price.

3. A colour became a metal. This is the one that matters for a shop. My bracelet photo showed three bracelets: gold, silver and white. Moondream said so, correctly, as colours. Gemma wrote:

Handcrafted Silver Bracelet Trio ... tags: silver bracelet

and a description claiming a "hand-tied design". Meanwhile the seller's own notes said the material was unconfirmed. A buyer reads "silver bracelet" as the metal. Telling the model "don't invent materials" in the prompt didn't stop it.

So I added a claim guard: plain code that runs on every generated listing and compares its claims against what the seller supplied (never the photo notes):

	Before	After
Title	Handcrafted Silver Bracelet Trio	Handcrafted Silver-coloured Bracelet Trio
Tag	`silver bracelet`	`silver-coloured bracelet`
"hand-tied design"	in the description	removed, and the seller is asked
"Handmade"	kept	kept (the seller typed it)

Once the seller confirms "sterling silver, hand-tied with cotton thread" and presses Rewrite, the guard stops removing those claims. The guard is a word list, not understanding, so it won't catch everything, and I say so in the README. But it's the difference between a tool that tries to be honest and one that's checked.

I wrote regression tests for all three problems, using the real bracelet listing as a fixture. The test suite is now 168 tests. A regression test that can't fail isn't one, so python scripts/mutation_check.py puts nine of the bugs back, one at a time, in a scratch copy and checks that the tests fail each time. They do. (My first run missed one, which is how I found a test that wasn't testing what it claimed.)

Where it falls short

Slow. About 40 seconds for one photo on my CPU. Three photos would take longer.
The claim guard is a word list. A claim in words it doesn't know gets through, so read the listing before you post it.
The inbox reads the wording of the answer. An oddly phrased "I don't know" could slip through.
No login. It's a single-seller local tool. Don't put it on the internet as it is.

What I'd do next
A faster vision step. 22 seconds per photo is the biggest wait.
Let sellers teach it their own words, so it learns that "kada" is a bangle.
A login, so it can leave my laptop.

Why Does Open Innovation Matter?
It costs nothing per message. A seller with thin margins can't take a per-token bill on every "what's it made of?"
The photos and chats never leave the laptop. AI inference runs locally through Ollama. Product photos are re-encoded before inference to strip EXIF metadata and a regression test checks a GPS-tagged image.
I could change the architecture when something broke. When I found my text model couldn't read images, the fix was to add a second model and change one environment variable. With a closed API I'd have been choosing between vendors, not designing a pipeline.
Where a closed model would very likely have been better: speed and caption detail. I didn't benchmark one, so that's an expectation, not a measurement. But the failures I hit weren't the kind a bigger model fixes. A colour read as a metal and a model grading its own answer are problems of process, and I could only fix them because I controlled the whole pipeline.

My Agent Session

I built SellMate with Claude as a coding assistant. The bugs described above were found by running it on my own laptop and the commit history in the repo shows each fix.

My First User

My first tester was my roommate. She tried SellMate on a crochet toy she'd made, even though she wasn't planning to sell it. She tested the listing generation, and then I played buyer and asked whether I could request a customization.

The listing didn't mention customization, so SellMate didn't make up an answer. It passed my question to the seller inbox instead. That let us try both sides of the workflow, and she loved it. Her reaction was that this would make things a lot easier.

It was one informal test, not a real sale or proof that sellers will pay for it. My next step is to test SellMate with someone who regularly sells handmade products and find out whether it saves enough time to be worth using.

Prize Categories

Best Use of Gemma: Gemma 3 (1B) runs locally through Ollama, on a CPU-only laptop, and writes every listing and answers every buyer question.

OUTSIDE: a local Gemma picks your next quest and tells you to put the phone away

Manswi Pradhan — Sun, 11 Oct 2026 17:30:30 +0000

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

What I Built

OUTSIDE tells you what to do outside right now.

It reads the time, the weather, how long until sunset, any event nearby and what you have already done today, then gives you one quest. At 5:45 PM on a clear day the quest is "find an open western view and watch the sunset for five minutes." If cloud rolls in, that quest is cancelled and replaced with something that does not need the sky. If a stargazing night is 3 km away then it becomes a special quest worth 500 XP.

When you press Start, the screen says "Put your phone away" and shows a timer. That screen is the whole idea. The app has one job, which is to get you out of the door and then it gets out of your way.

It is for anyone who opens their phone to decide what to do and ends up scrolling instead. There is no feed and no list to choose from, just one concrete thing to do.

Demo

The demo follows one evening:

A live quest for the current weather.
A simulated 5:45 PM with a clear sky: a sunset quest, with the minutes until sunset on the card.
Heavy cloud switched on: the banner reads "The sky isn't cooperating", the sunset quest is struck through and a different quest replaces it.
Demo events switched on: a stargazing night 3.2 km away becomes a gold-outlined special quest, 500 XP, about 38 minutes on foot.
Start the quest, see the "Put your phone away" screen, finish, collect the XP.

The weather and time controls exist only for demos. They let me show a cloudy evening without waiting for one.

Taking it outside

So I majorly had the idea of this app due to my friend,as she always says that she has nothing to do outside and so she just ends up scrolling all day.
So I tried it with her yesterday during the evening and we got the task to watch the sunset. We went and watched the sunset ,talked a bit and she said she enjoyed it, and even felt calm.

Code

Github Repo Link

To run it you need Python 3.10+ and Ollama:

ollama pull gemma3:1b
pip install -r requirements.txt
uvicorn backend.main:app --reload   # then open http://127.0.0.1:8000

How I Built It

The model: Gemma 3 1B, running locally through Ollama. Ollama's format option takes a JSON schema, so the model's reply is forced into the shape the app needs: quest type, title, action, duration and a one-sentence reason.

The stack: a FastAPI backend and a plain HTML, CSS and JavaScript frontend with no build step. Weather and sunset time come from Open-Meteo, which is free and needs no key.

The loop:

location + time + weather + sunset + events + today's history
      -> context engine
      -> local Gemma (JSON schema)
      -> rule check
      -> quest   (or a rule-based quest after two rejections)

The model proposes and the code checks. I did not trust a 1B model with the rules, so there is a validator between the model and the screen. If a quest breaks a rule, the model is asked once more with the reason. If it breaks a rule again, a rule-based generator answers instead and the card says so. The rules are small: no sky quest under heavy cloud or in the rain, no run on a hot day or after you already ran, short quests when it is wet, and an event quest has to name the real event.

My first runs showed why this matters. An event quest came back one minute long. A sunset quest came back as "Observe the evening sky." Neither broke a rule I had written, so I added rules. Actions must be one or two concrete sentences, and an event quest's duration now comes from the walking time, calculated in code.

The next problem was subtler. The model labelled 6 of my 7 test quests "nature", including the sunset one. That mattered because the "no sky quests under cloud" rule only checks quests labelled "sky", so a mislabelled stargazing quest would have walked straight past it. Now the prompt lists the quest types that are allowed right now, and code relabels any quest that mentions a sunset or stars as a sky quest before it is checked.

Testing. I run the same seven situations through the model: a clear morning, a hot afternoon after a run, a clear sunset, a cloudy sunset, a stargazing event nearby, rain, and a cloudy night. Here is Gemma 3 1B before and after that fix:

	Labelled "nature"	Situation checks passed	Answered by the model	Right on first try	Median latency
Before the fix	6 of 7	5 of 6	7 of 7	6 of 7	9.0 s
After the fix	4 of 7	6 of 6	7 of 7	6 of 7	11.7 s

"Situation checks passed" is a low bar, because the validator enforces most of them. It tells me the whole system behaves, not that the model is good by itself. What separates models is how often they need a retry or the fallback, and how good the text is.
I only tested Gemma 3 1B. The code lets you swap models with one environment variable, but I have not compared other models yet, so that is a feature of the design, not a result.

Why Does Open Innovation Matter?

A quest app needs your location, the times you are free and the places you go. I did not want to send that to a hosted API just to be told to go and look at a tree. With an open-weight model the quest generator runs on my own machine, so none of those prompts leave it.

The limit of that claim matters, so here it is: the weather lookup goes to Open-Meteo, which receives my coordinates rounded to about 1 km, and it needs internet. The model does not.

Three other things I got from an open model:

Swapping the model is one environment variable (OUTSIDE_MODEL), with the same prompt, schema and tests for every model.
A quest costs nothing to generate. Nobody has to decide whether a tap is worth a bill.
Constrained output. The reply has to match my schema, and I could test it against fixed situations on my own hardware.

A larger closed model would do some things better than my 1B model, and I would rather say so. Several of my test quests sent people to "the nearby creek" or "a quiet bench near a small green space". The model has no map, so it invents places. At night, my cloudy-night quest told the user to watch "the shadows beneath the trees" even though I had told the model it was dark. A bigger model would likely follow that. The validator catches what I thought to write a rule for, and nothing else.

What Did Not Work

Completion is an honor-system button. Nothing checks that you went outside.
Events are demo data. I did not find a free events API worth using, so events are a list, and the app labels demo events "(demo event)" on the card.
A quest takes about 11 seconds on my laptop with the 1B model, so the loading screen cycles through what the app is doing.
I wanted Jupiter in the sky quests and cut it to finish the core loop. Sky quests use sunset time, cloud cover and time of day.

Prize Categories

Best Use of Gemma. The quest generator is Gemma 3 1B running locally through Ollama with schema-constrained output. I tested it against seven fixed situations and measured how often its first answer passed my rules.

DEV Community: Manswi Pradhan

I built a ghost that haunts my desktop until it can see my work

What it does

How it sees

Not everything needs a model

Does the judge work?

What broke

Why it had to be local

What it can't do

Try it

Inbox Sloth: a local Gemma that reads your inbox so you don’t have to

What I Built

Demo

Code

How I Built It

The part I almost didn't write

Honest caveats

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

I built a WhatsApp shop assistant that runs on a CPU-only laptop. The hard part was getting it to say "I don't know."

What I Built

Who would pay for this

Demo Usage Example

Code

How I Built It

Three things that broke

Where it falls short

What I'd do next

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

OUTSIDE: a local Gemma picks your next quest and tells you to put the phone away

What I Built

Demo

Taking it outside

Code

How I Built It

Why Does Open Innovation Matter?

What Did Not Work

Prize Categories