DEV Community: Linh Pham

Shade Ledger: A Local AI That Sends You Outside to Notice Neighborhood Shade

Linh Pham — Mon, 12 Oct 2026 05:32:34 +0000

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

What I Built

Shade Ledger is a small fieldwork companion that tries to get out of your way. Most outdoor apps turn a walk into more screen time: step counts, GPS trails, notifications. Shade Ledger does the opposite. It asks a locally running open-weight model to design a short, personalized outdoor mission, tells you to close your laptop, and then waits for you to come back with a few observations about your neighborhood.

You pick how long you have (5–30 minutes), where you can go, how you'll explore (walking, a slow stroll, a wheelchair-friendly route, or seated observation), what you want to notice (shade and urban heat, trees and biodiversity, rainwater and drainage, urban nature, or public-space care), your pace, and a rough climate context. The model returns a mission with three steps, three things to notice, and one question to think about later.

When you get back, you fill in a 60-second field receipt: how many stops you made, how many felt shaded, how many planted or permeable surfaces and drainage features you spotted, and how being outside felt. It's saved to a local ledger so you can compare visits over time.

It's for anyone who wants a gentle reason to step outside and pay attention, and especially for people curious about how city design shapes everyday comfort. Shade and greenery aren't just nice to look at; they're worth noticing. To be clear about what it isn't: the "shade share" is a simple count of the stops you chose, not a measurement of temperature, canopy cover, or environmental impact.

Demo

Shade Ledger is designed for local inference and local storage, so there's no hosted version. These screenshots are from the app running on my machine against the local Qwen2.5 model:

A mission generated locally by Qwen2.5 1.5B via Ollama:

The field receipt you fill in when you come back (shown with example values):

To run it yourself, setup takes a few minutes and is described in the README.

Code

ryuuseiwa / shade-ledger

Local open-weight AI that turns neighborhood walks into environmental fieldwork

🌿 Shade Ledger — Less scrolling. More noticing.

An outdoor-first, privacy-first neighborhood fieldwork app powered by an open-weight model running on your laptop. Designed for the Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.

What makes it different

Most outdoors apps turn a walk into more screen time, tracking, and GPS. Shade Ledger uses a local LLM to design a 5–30 minute mini field mission, then sends you outside to notice shade, plantings, storm drains, and other neighborhood details. On return, make a 60-second field receipt and learn how to compare your own observations over time. No GPS, login, paid API, location history, server database, or image upload.

A city-planning / environmental-justice-inspired field journal, not a scientific instrument. The app does not infer measured temperatures, carbon capture, canopy cover, or safety from observations.

How open-source AI powers it

Model: qwen2.5:1.5b-instruct (open-weight, Apache 2.0) running through Ollama.
Inference: locally…

View on GitHub

How I Built It

Model: Qwen2.5 1.5B Instruct, an Apache-2.0 open-weight model, running locally through Ollama.
Inference: a plain HTTP call to Ollama's local /api/generate endpoint at 127.0.0.1:11434, using Ollama's JSON mode for structured output. On my desktop (AMD RX 7900 GRE), a mission comes back in about 3 seconds.
Prompting: engine.py builds a safety-constrained, mobility-aware prompt from your choices. It tells the model to keep you in public, accessible areas, never to suggest entering roads, trespassing, touching unknown plants or animals, or going out in unsafe weather, and not to invent routes, species, temperatures, or safety conditions.
Validation: the response is parsed and checked against a strict schema (a title, a mission, exactly three steps, exactly three things to notice, and a reflection question). Anything malformed is rejected with a clear error.
No fake fallback: if the model isn't available, the app says so. There's no hardcoded list of canned missions pretending to be AI.
UI and storage: Streamlit for the interface; field receipts are appended to a local JSONL file that's git-ignored, viewable in the app, and exportable as JSON.
Tests: unit tests cover the schema validation, the scoring, and the prompt builder.

The whole flow is: your preferences → prompt → local Qwen model → validated mission → go outside → local field receipt. No account, GPS, paid API, or cloud database.

Why Does Open Innovation Matter?

Where you walk and what you notice about your own neighborhood is personal. With an open-weight model running on my own machine, none of that leaves my computer. Once the model is downloaded, mission generation works with Wi-Fi off.

Open weights also make the project adaptable. Anyone can swap in a different Ollama model from the sidebar, rewrite the prompt, or run it on smaller hardware, without asking a vendor or paying per request. Because the prompt, validation, and scoring are all plain, inspectable Python, the same idea could be reshaped into a campus accessibility walk, a stormwater observation log, or a neighborhood green-space journal.

A closed API would have meant an account, a key, a per-mission cost, and sending people's reflections about their surroundings to a third party. For an app whose whole point is less screen and more attention, keeping the AI small, local, and open felt like the right fit.

Barista Buddy: A Little More Confident, One Shift at a Time

Linh Pham — Mon, 05 Oct 2026 04:08:57 +0000

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

I built Barista Buddy during the challenge window; the project was not developed before the contest period.

What I Built

My friend recently moved to a new country and is training to become a barista. He’s learning drink recipes, customer phrases, and a new work environment at the same time. I wanted to give him somewhere to put all of that instead of trying to remember everything after a shift.

So I built Barista Buddy, a personal shift notebook and practice coach.

He can log what he made, the steps his café taught him, what felt tricky, and advice from his trainer. Those entries become his own drink handbook. Before the next shift, he can review recall cards made from his latest saved notes, revisit workplace phrases, or ask the local AI coach what to focus on.

The recipes come from what he records. That matters because I wanted him to learn his café’s routine, rather than memorize a random recipe from the internet.

There’s also a small progress view showing what he has practiced and his own confidence ratings. Sample entries are clearly labeled, and he can remove them when he starts his real notebook.

I have not handed the app to my friend yet, so this submission does not include user feedback.

Demo

Open Barista Buddy

Browse the source on GitHub

A quick walkthrough:

Open Today and load the sample notebook, or save a drink of your own.
Open Drink notebook to see the latest recipe notes and earlier shift entries.
Try Practice → Drink recall, reveal your saved notes, and mark what you want to review.
Open Settings & backup → Prepare AI coach while online to download the open model. The initial model download is several hundred MB and may be slow or fail on some connections; sample recall practice works without it.
Try Practice → AI coach with a question such as “What should I focus on before my next shift?”
In a drink draft, try Organize my steps with AI, then review the suggested steps before applying them.

The source repository includes a local launcher so the app can also be handed over as a laptop app served on localhost.

Code

Browse the MIT-licensed source project

The application code is MIT licensed. The included runtime libraries retain their own licenses, and model weights are downloaded separately.

How I Built It

I built the interface with HTML, CSS, and JavaScript. Drink notes and practice records are stored in IndexedDB on the user’s own browser. JSON export and import make it possible to back up the notebook or move it to another device.

For the AI, I used SmolLM2-360M-Instruct, an Apache-2.0 open-weight model, through Transformers.js and ONNX Runtime Web. The app uses a pinned model revision and quantized q4 weights. Generation runs in a browser worker, using the device’s CPU through WebAssembly.

The model has two jobs: tidy up steps the user already wrote and respond to questions using recent saved training notes. It is instructed to avoid inventing recipes, quantities, or café rules. Since a small model can still make mistakes, its suggestions are labeled and kept separate from the notebook until the user reviews them.

Recall practice uses the saved notes directly. It does not treat an AI-generated recipe as the correct answer. Cards marked for review are prioritized, alongside drinks with lower self-rated confidence.

A service worker caches the app and bundled inference runtime. Transformers.js caches downloaded model files. There is no API key and no remote model endpoint receiving the user’s notes.

In local browser checks, the interface rendered at desktop (1280x900) and narrow (390x844) sizes without horizontal overflow. A sample recall answer and self-rating updated the progress view, and sample records were removed afterward. The browser worker attempted to download the pinned model twice, but the Hugging Face CDN failed with an HTTP/2 protocol error (around 72% on the first try and 64% on retry). I could not verify a browser-generated AI response or offline AI inference in this test. The model did generate from sample trainer notes using local ONNX inference in Node on the original build machine; that is not a browser inference test. I have not yet tested the app with my friend, so I have no user feedback to report.

Why Does Open Innovation Matter?

My friend should be able to write “I forgot this” or “I’m still struggling with this” without sending that learning history to a remote AI service.

The design uses an open-weight model to run the coach on his own device. After the initial download, inference does not need a paid model API or upload his notes for processing. The browser is intended to cache the model so local offline use is possible when all required files remain available. It does need internet for the first download, and offline access depends on the browser and its cache.

I can also inspect and change the prompts, replace the model, or adjust how much of his notebook the coach sees. The project isn’t tied to one hosted model provider.

For this particular app, that’s the intended benefit of open innovation: he can keep a private learning notebook and, once the model is successfully installed, get personalized help from it without a paid model API or model server. Browser inference and offline use still need to be confirmed on his device.

Prize Categories

Best Use of GitHub Copilot: The GitHub Actions workflow automates publishing the app to GitHub Pages on every push to main and supports manual deployment runs.