DEV Community: Dev3 ^~^

I built an AI that tells you to leave the leaves alone

Dev3 ^~^ — Thu, 22 Oct 2026 16:27:22 +0000

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

What I Built

Autumn yard work starts with a plan that's mostly habit: rake everything. Some of it is real work, like leaves on the steps you walk down every morning. Some of it you could skip. Penn State Extension notes that leaves in garden beds can stay where they fall to insulate roots, and the National Wildlife Federation describes the leaf layer as foraging ground and nesting material for birds.

RakeLess takes one ground-level photo of a yard and splits it into a 3×3 grid. You mark the patches you were planning to clear. It hands back a chore receipt:

Planned cleanup worth reconsidering: leaves on a bed or under trees, seen clearly, with no site concerns.
Access work to keep: leaves on a path or steps, whether you planned it or not.
Inspect before deciding: lawns (a photo can't show how thick the layer is), mixed or unclear patches, anything outside the rules' scope.
No leaf task observed: nothing on the ground, so it doesn't count as work saved.

Every line shows what the model saw, which rule fired, and any correction you made. The counts are grid cells. RakeLess doesn't turn them into square metres, minutes, or "birds helped".

The lazy part is the point: do the clearing that matters, skip some of the rest, and have a written reason for each patch you skip.

Demo

Live (hosted Gemma): https://rakeless.vercel.app. The landing page replays a saved real run, labelled RECORDED REPLAY · not a new model call. New photos go to Google's Gemini API, and the page says so before you upload.
Local run with the network cut off: eval/results/OFFLINE.md. Ollama and the RakeLess server ran inside a Linux network namespace with only loopback. The page records the network probe, the health check (provider, model digest), the single Ollama request, and the API response: live, uncached, 112.6 s.

I also tried to record a captioned browser video of that local run. It didn't work on a 4-core VM: video capture slowed inference about tenfold, and all four attempts timed out (the first at my own 280 s cap, the rest at Ollama's ~5 minute request limit). The failed runs are in the same folder.

Code

shashank03-dev / RakeLess

RakeLess 🍂

Mark the yard patches you were going to rake. RakeLess shows which of that work is worth reconsidering, which access work to keep, and which patches you need to look at first.

Fallen leaves in garden beds and under trees give shelter to insects and the birds that eat them. Leaves on a path still need clearing. RakeLess splits one ground-level photo into nine patches, has an open-weight Gemma model describe each patch with a few fixed labels, and runs nine plain rules over those labels. You can correct any label; the plan and the chore receipt update without another model call.

Every result is a suggestion from a photo. It cannot see leaf depth, plant disease, or local rules. Walk the patch before you act.

Live demo: https://rakeless.vercel.app (hosted Gemma through the Gemini API, see Privacy)
Local mode: the same app with Gemma 4 in Ollama…

View on GitHub

MIT licensed. npm test covers the rules (including all 1,080 combinations of context and labels), the receipt, the model contract, the request deadline and retries, cache expiry, readiness recovery, and the provider HTTP contracts with mocks. npm run eval reruns the evaluation below.

How I Built It

The model only looks. Plain rules decide.

photo → server: decode, rotate, strip EXIF, 3×3 grid + 9 crops
      → Gemma labels each cell: surface · leaves on ground · visibility · one sentence of evidence
      → Zod: exactly nine valid cells (server and browser)
      → 9 ordered rules → map + chore receipt → you correct → rules re-run, no new model call

Gemma never gives advice. For each cell it picks from fixed labels: surface (bed/tree base, lawn, path/steps, mixed, unknown), fallen leaves (yes, no, unclear), and visibility (clear, unclear). Nine rules in shared/rules.ts turn those labels into leave for now, clear access, review, or no leaf task. The same file runs on the server and in the browser, so a correction is instant.

A bug that shaped the rules. An earlier version checked "is it a path with leaves?" before "is the photo clear?". So a blurry patch the model thought was a path became a confident "clear this". Uncertainty now runs first: unclear, mixed, or unknown patches go to review before any other rule. A test enumerates every combination and asserts that leave, clear, and no task only appear where the rules allow them.

Two providers, one contract. A small provider interface has two implementations:

Hosted: gemma-4-26b-a4b-it through the Gemini API. This is what the Vercel demo uses.
Local: any vision-capable Gemma tag in Ollama. I used gemma4:e4b.

Both receive the same gridded overview plus nine labelled crops. Both are validated by the same Zod schema and feed the same rules. The server picks the provider; the browser can't. There is no silent fallback from local to cloud. Each result records the provider, the model, the version (or the Ollama manifest digest for local runs), the prompt and rules versions, the image hash, model time, server time, the number of upstream calls, and cache status.

Fixing the failure paths:

One deadline covers each request: 52 s on Vercel, inside the 60 s function limit. A retry only happens for invalid JSON or a transient error, and only if at least 10 s remain. Every retry counts against the daily budget.
If the browser goes away, the upstream call is aborted.
The readiness check describes the selected model provider, not just the web server. It retries with backoff and has a "Check again" button, so one slow probe no longer disables analysis until you reload.
The old cache kept whole responses, base64 photos included, with no expiry. Now it keeps only the nine labels for at most 10 minutes. The privacy copy describes exactly that, including where Google's API terms apply.

What the evaluation showed

I wanted a number that couldn't come from one photo and its rotations. So I collected seven distinct, licensed photos from Wikimedia Commons: a New Jersey lawn and sidewalk, a Maryland driveway, English garden steps, woodland leaf litter, an Italian sidewalk, a dark leaf pile, and a woodland floor in January. I aimed for 8–12, but Commons rate-limited the downloads. The coding agent wrote reference labels for every cell before any model saw these photos, and committed them first. These are proxy labels, not expert ground truth.

With local gemma4:e4b on a 4-core CPU:


Valid nine-cell answers	7 / 7, no retries
Time per photo	95–226 s (median 124 s)
Cells sent to review	61 / 63
Reference leave/clear cells reached	1 / 7 (1 / 26 if every photo were treated as in scope)
Wrong leave or wrong no task	0 / 63

That's an honest middle result. The rule layer did its job: a weak model never produced confident bad advice. But a tool that sends almost everything to review is only a little lazier than raking. The failures were specific:

Canopy read as lawn. On the New Jersey photo, the three tree-canopy cells came back as "The grass shows scattered fallen leaves." In the inspector you change "on the ground" to No leaves on ground, and each becomes no leaf task. That's one click per cell and no second model call.
A sharp driveway called "unclear". On the Maryland close-up, all nine cells were unclear. Correcting the surface and confirming you looked turns them into clear access.
Boilerplate. On two scenes the model repeated one sentence for all nine cells, so it clearly wasn't using the per-cell crops.

I couldn't evaluate hosted Gemma because I had no API key in the build environment, so I'm not putting a hosted accuracy or speed number here. The one saved hosted run (16.7 s, one retry) is a single scene.

Why Does Open Innovation Matter?

What open weights changed here is concrete:

I could take the model off the network. The same Gemma family that powers the hosted demo ran on a CPU with external networking disabled, and the API answered with a live, uncached result tagged with the exact weights' digest. For a photo of someone's yard, being able to say "this never left the machine" matters. It isn't free: a 6.6 GB download, two to four minutes per photo on this hardware, and electricity.
I could swap the model without touching the judgement. Moving from hosted 26B to local E4B changed nothing in the rules, the receipt, or the tests. The evaluation then showed exactly what that swap cost.
Every judgement is readable. The prompt, the label schema, the nine rules, and the sources behind them are in the repo. If you think lawns shouldn't always be "review", you can change R7, cite a better source, and rerun npm run eval on the same seven photos.

A proprietary vision API could fill the same "looks" slot. The rule layer doesn't care. What it couldn't give me is the offline run, or the chance to pin and inspect the exact weights.

Scope and limits

The rules were written for temperate North American autumn yards. Anywhere else, every leafy patch becomes review-only. RakeLess can't measure leaf depth, spot disease or pests, know local fire or leaf rules, or judge whether a path is safe. Each cell of the 3×3 grid can mix surfaces, and when it does it's sent to review. A leave for now is a suggestion to walk the patch first, not a certificate.

Credits

Photos: Michael Gil (CC BY 2.0), Famartin, Mark Schellhase, Acabashi (CC BY-SA 4.0), Anna.Massini (CC BY 4.0), McKay Savage (CC BY 2.0), and Bob Embleton (CC BY-SA 2.0), via Wikimedia Commons. Rule sources: Penn State Extension, National Wildlife Federation, University of Minnesota Extension, and Joan Nassauer's work on cues to care. They inform a prototype and don't endorse it. Built with Gemma 4, Ollama, React, Vite, Zod, and sharp, with help from an AI coding agent.

Prize Categories

Best Use of Gemma. Gemma does all of the vision work, hosted through the Gemini API on the public demo, and locally through Ollama, including a run with the network cut off.

Paper Trail: Gemma writes my neighbourhood into a paper zine, so my phone can stay home

Dev3 ^~^ — Sun, 11 Oct 2026 02:37:56 +0000

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

Most "go outside" apps want to come with you. They want a photo of the tree to prove you saw it, a check-in at the bench, a notification after ten minutes outside. You end up in the park looking at the same screen you left on your desk.

I wanted an app you use for two minutes before a walk and two minutes after, and that stays at home in between.

When I was thinking about it I kept coming back to the old I-Spy spotter books. Kids carried a little paper book, ticked off what they saw, and posted the finished book back for a reward. No battery, no signal, and the fun part happened outside.

So I built Paper Trail: an open model writes your real neighbourhood into an 8-page paper zine, you walk with paper and a pencil, and when you're back it reads your pencil marks from one photo.

What I Built

You pick a starting point, how long you want to walk and who's coming. Paper Trail pulls the real streets and places around you from OpenStreetMap, plans a loop, and Gemma writes the zine. It prints on one sheet of US Letter or A4. One cut, a few folds, and it's a pocket booklet.

The eight pages:

Cover: a title written for your spot, today's weather and a PHONE STAYS HOME stamp
Map: your real streets, hand-drawn in code, with the loop and numbered stops
Route: directions by landmark, not turn-by-turn
I-Spy: 8 to 10 things to tick off, at least six of them real mapped places on your route
Listen: stand still for a minute and write down the loudest, the quietest and a new sound
Riddle: the answer is a real stop on your route
Sketch: a drawing prompt tied to something you'll pass
Bring me home: a QR code and a note on which model wrote it

This is the zine Gemma wrote tonight for Dolores Park in San Francisco, exactly as it prints. The top row is upside down on purpose: that's how a one-sheet zine folds.

Then you leave. When you come back, you unfold the sheet and take one photo. The browser finds the four black corner squares, flattens the photo and checks every box for pencil. Gemma reads your handwriting, judges your riddle answer and describes your sketch. You get a Field Report with a postmark, a Trail Book of every walk, and a counter of time on the screen against time outside.

It's for anyone who wants a reason to go outside without bringing the feed along: kids, families, someone walking a dog, or a teacher who wants thirty different trails starting at the school gate.

Demo

Try it live: paper-trail-t6mp.onrender.com. No sign-up. If you'd rather not share your location, pick one of the example parks.

15-second launch video: watch it here

While Gemma writes, the sheet prints itself page by page, so you're not staring at a spinner:

The read-back, on the live site

To test the return trip end to end, I took that Dolores Park sheet and added the kind of marks you'd make on a walk: six ticks out of nine, three sounds, the riddle answer and a quick tree. I drew the marks in code and tilted and shadowed the sheet like a phone photo. That's the photo I uploaded:

The browser found the corners on its own:

28 seconds later, the Field Report:

It got all six ticks and all three untouched boxes right. It read "golden fire hydrant" and marked the riddle Right!. It described the sketch as "a simple tree with a straight trunk and two overlapping circles for its leafy canopy", which is exactly what I drew. The Trail Office note even quoted my sounds back to me.

Code

shashank03-dev / Paper-Trail-WEEK-1

Every touch-grass app wants to come with you. This one stays home.

Paper Trail

Every touch-grass app wants to come with you. This one stays home.

Paper Trail turns your real neighbourhood into a one-sheet, 8-page paper zine written by an open model (Gemma 4 — on your own machine, or through Ollama Cloud or the Gemini API), so your phone can stay home. When you get back, Gemma reads your pencil ticks, handwriting and sketches from one photo and stamps your Trail Book.

An entry for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass. MIT licensed.

How it works

 Setup ─► OpenStreetMap features + streets ─► route.ts picks a 5–6 stop loop (no AI)
   │      Open-Meteo weather                         │
   │                                                 ▼
   │                       Gemma writer: plan  ─►  cover · route · listen · back
   │                       (JSON schema → zod → grounding check → retry → template)
   ▼                                                 │
 IndexedDB  ◄──── the trail ◄──── one SVG sheet, mm-exact, drawn with rough.js

…

View on GitHub

MIT licensed. Next.js 15, TypeScript, Tailwind 4, rough.js for every wobbly line, three.js for the folding sheet on the landing page, and Dexie for storage in the browser. There are 90 unit tests and 12 browser tests that run the whole flow, setup to stamp, against a mock model.

How I Built It

 setup ─► OpenStreetMap places + streets ─► planner picks a 5–6 stop loop (no AI)
                                                  │
                         Gemma: plan ─► cover · route · listen · back
                         (JSON schema → zod → grounding check → retry → template)
                                                  │
                         one SVG sheet in millimetres ─► print, cut, fold, walk
                                                  │
 Field Report ◄─ combine ◄─ Gemma reads 4 page crops ◄─ warp ◄─ corner markers ◄─ one photo
                    ▲
                    └── ink count inside every printed checkbox (no AI)

Gemma writes, but it doesn't navigate

A plain planner picks the loop: the most interesting nearby places that fit your time at walking pace. Gemma gets that route plus a short list of real places, each with an id, and writes in two steps: first a plan (title, I-Spy list, riddle, sketch prompt), then the text for each page.

Every answer goes through a JSON schema, then zod, then checks that the model can't talk its way past. Every place has to exist. At least six I-Spy items have to be real places. The riddle's answer has to be a stop on the route. Here's the riddle check, trimmed:

export function riddleProblems(r: Riddle, ctx: WriterContext): string[] {
  const wp = new Set(ctx.route.waypoints.map((w) => w.featureId));
  const p: string[] = [];
  if (!wp.has(r.targetFeatureId))
    p.push(`riddle targetFeatureId "${r.targetFeatureId}" must be one of the WAYPOINT ids: ...`);
  p.push(...idLeaks([r.text]));
  if (!fitsEverywhere("riddleText", r.text))
    p.push("riddle text is too long for its panel; make it shorter");
  return p;
}

The text also has to fit the page, and a page is 67 mm wide. SVG doesn't wrap text, so I generated width tables from the actual font files and measure every line before it's accepted. If any check fails, Gemma gets the exact problem back and another try. If it keeps failing, a template built from the same real places takes over, so you always get a zine.

The checks earned their place tonight. Writing the Dolores Park zine took 5 calls, and 2 of them (the route page and the listen page) failed a check the first time and passed on the retry:

Live run, Dolores Park, 20 minutes
Model	Gemma 4 26B A4B, on the Gemini API
Time to write the whole zine	41.5 s
Speed	13.8 tokens/s
Calls that needed a retry	2 of 5 (route, listen)
I-Spy items tied to real mapped places	7 of 9
Time to read the photo back	28.5 s
Ticks read correctly	9 of 9 boxes

The paper is one SVG, in millimetres

Everything on the sheet is drawn in code: the map, the weather icon, the stamp, the QR code. There are no stock images and no generated images. One layout file holds every measurement, so the preview on screen is the print, and the reader knows exactly where every checkbox was printed.

Reading is where the open model earns its keep

One photo of a whole sheet is a lot to ask of a model, so the browser does the geometry first, in plain TypeScript with no OpenCV: find the four corner markers, solve a homography, warp the photo flat and cut out the pages. Gemma then gets four small crops (I-Spy, Listen, Riddle, Sketch), each with a prompt saying what should be on it.

For the ticks there's a second opinion that needs no model at all. Because I know where every box was printed, I measure how much pencil is inside it. When Gemma and the ink count agree, the answer stands. When they don't, the report marks the row in amber and you tap to fix it.

On 30 synthetic phone photos (tilted, rotated, shadowed, blurred), the corner markers were found every time, and the ink count alone got every tick right. Real crumpled paper in bad light is harder than that, which is why every result can be fixed with one tap.

Bugs I hit along the way

My first sheet didn't fold right. I'd offset the page grid by the print margin, so the real folds landed 3 mm off the page edges. Pages are now exact quarters of the sheet, with the margins inside each page. There's a /fold-test page with giant page numbers to check a printer before printing the real thing.
Gemma on the Gemini API thinks before it answers. It spent its token budget on a hidden thought block and sometimes ran out before the JSON. Requests now ask for minimal reasoning, and any thought text that still arrives is stripped before parsing.
Real output leaked internal ids. The prompt gives places ids like n9000024, and Gemma sometimes printed them in the text ("the fountain n9000024"). Now every piece of text is checked for ids and sent back for a retry.
The same API takes no system prompt and no JSON schema for Gemma. The client folds the system prompt into the request and puts the schema in the prompt, and the zod checks do the rest.

Running it

Locally it runs on Ollama with gemma4:e4b, or gemma4:e2b on smaller machines. The live site runs on Render as one Docker web service in Singapore, and it uses Gemma 4 26B A4B through the Gemini API, with Gemma on Ollama Cloud as the fallback. Every default in the config is a Gemma model. Render redeploys on every push to main. My last change went live 2 minutes 48 seconds after the push.

Since the site is public, it has guard rails: a daily cap on model calls, at most four model calls at once with a queue, a health check that's cached so the model badge doesn't spend quota, and a block on other sites calling the API.

Even the launch video is open source end to end. It's drawn in code from the same zine renderer and the landing page's fold model, and the voice is Kokoro-82M, an Apache-2.0 text-to-speech model that runs on a CPU.

I built Paper Trail with an AI coding agent doing a lot of the typing while I made the calls.

Why Does Open Innovation Matter?

Paper Trail works with two things I don't want to hand out lightly: a map of where I live, and a photo of my handwriting.

It can run entirely on my own machine. With Gemma in Ollama next to the app, my location and my notes never leave my computer. There are no accounts and no analytics, and trails live in the browser. On the hosted site, the zine prints which provider wrote it, and the "your location never left this machine" line only appears when that's true.
I can swap the model with one environment variable. E2B for a small machine, E4B on a laptop, 26B or 31B hosted. Same prompts, same checks, same zine.
There's always a way to run it yourself. If a hosted provider rate-limits, the next one serves the same open model. If you don't trust any provider, you run it on your own hardware. A school, a library or a scout group can run it for free.
I could make a small model reliable instead of hoping a big one is. Because I control the whole loop, I could split the photo into four focused crops, add an ink count as a second opinion, and check every answer against the real map. A closed API would give me one big answer back and my fingers crossed.

Where closed is better: a big hosted model writes a little more colourful copy, and it's faster than a small model on a CPU. For an app you open for two minutes before a walk, that's a fine trade.

And once it's printed, it works with no signal and no battery. It's paper.

What it can't do (yet)

OpenStreetMap coverage varies. Where a place is thinly mapped, the I-Spy list leans on things like "a passing dog" or "a leaf that's two colours".
Hard light hurts. A shadow across the checkboxes can fool both the ink count and the model, which is why every row is one tap to fix.
Small models still misread handwriting sometimes. The report never hides that.
The screen-versus-outside counter only times the outside part if you print from the app.

Prize Categories

Best Use of Gemma: Gemma 4 does both halves of the app. It writes every zine (grounded in real places, schema-checked, fitted to the page) and reads every sheet that comes back (handwriting, riddle answers and sketch descriptions from four focused crops). It runs as E2B or E4B on Ollama locally, and as 26B A4B on the Gemini API with 31B on Ollama Cloud as the fallback for the live site.
Best Use of Render: the live site is a Docker web service on Render that redeploys on every push to main, with a daily model budget, a concurrency gate and a cached health check so a public demo can't run up the bill. The repo also includes a Render Blueprint that runs Gemma itself in an Ollama private service with a persistent model disk, next to the web app.

Built solo.

Print one this weekend, leave your phone at home, and tell me in the comments what you spotted.