DEV Community: Vaishnavi Mishra

GrassMapper: An offline AI trail guide that actually runs without Wi-Fi (and has a tiny fox that judges you)

Vaishnavi Mishra — Sun, 11 Oct 2026 18:24:12 +0000

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

"Go touch grass," they said.

Every developer loves joking about touching grass right up until we actually have to step away from our dual monitors and mechanical keyboards.

When this week's Hacktoberfest challenge dropped with the theme "Touch Grass", my first reaction was: alright, how do I build something that genuinely gets people outside without turning into another screen-time trap?

Because here's the thing about most "outdoor" apps: they want your eyeballs the entire time you're outside. You're supposed to look down at your screen, track your pace, check your notifications, and fiddle with settings while walking past actual trees.

Worse yet, the moment you get to a real trailhead—the kind where you can't hear traffic anymore—your phone signal drops to zero bars. And when you open any modern cloud AI assistant to ask about trail conditions or elevation gain:

[!] Network Error: Unable to reach server. Please check your connection.

Your \$1,000 phone is suddenly a paperweight, and the cloud AI you relied on is completely useless.

So I spent this week building GrassMapper.

What is GrassMapper?

GrassMapper is an offline-first trail companion and outdoor habit OS powered by Google's open-weight Gemma 3 model running 100% locally on your machine via Ollama.

It has one core rule: The screen should be the shortest part of your day.

You open it, pick where you want to wander, hit "Pocket Audio Briefing", shove your phone or laptop in your backpack, and go outside. It talks to you through your earbuds while you lace your hiking boots, gives you the trail rundown, and leaves you alone to enjoy the walk.

And because it's built for real people with different setups, it works two ways:

A cute web dashboard running on Flask with interactive Leaflet maps, audio, and live streaming tokens.
A terminal CLI for when you just want to run grassmapper plan in your shell and get right to the point.

The Fun Stuff (Features I Actually Enjoyed Building)

🦊 1. Sprout the Fox (Your Trail Mascot)

Let's be honest: productivity gamification can be pretty annoying. But I couldn't resist giving this project a mascot.

Meet Sprout 🦊. She floats in the corner of your dashboard, keeping an eye on your outdoor habits. When you log a walk, identify a plant, or tick off a daily nature quest, she showers the screen with confetti and plays a little 8-bit celebration chime.

The fun engineering detail? Zero audio files or sound CDNs. The chime is synthesized in real time using the browser's Web Audio API—three oscillators (triangle wave for warmth, sine for sustain, and a snappy attack envelope) vibrating straight out of your browser's audio context. Totally offline, 0 KB download.

🌱 2. Grass Points (GP)

You earn Grass Points for real-world outdoor acts:

Logging a hike (+15 GP)
Identifying a bird or plant (+10 GP)
Keeping an outdoor streak alive (+25 GP)

You level up from Seedling 🌱 (0 GP) → Trail Scout 🥾 (50 GP) → Forest Ranger 🌲 (200 GP) → Peak Bagger ⛰️ (500 GP).

It sounds silly, but seeing your little level progress bar move because you actually went for a 30-minute walk around the neighborhood is surprisingly satisfying.

🗺️ 3. The OpenStreetMap Trail Radar

I didn't want Google Maps tracking anyone or hitting an API billing threshold.

GrassMapper uses Leaflet.js with OpenStreetMap tiles. It renders your trail as an animated polyline with custom pins for the trailhead 🏁, water/vista points 💧, and wildlife hotspots 🦅.

You can change locations three ways:

Search bar: Checks an offline dictionary of 21 famous national parks, peaks, and trails first (so search works with zero internet!), then gracefully falls back to OSM Nominatim if you're online.
Click-to-place: Click anywhere on the map, and the route re-centers right there.
GPS button: One tap pulls your actual coordinates via browser geolocation.

📱 4. It works straight from your phone

You don't need a native app store download. If your laptop is running GrassMapper on your home Wi-Fi (or a mobile hotspot at a campsite), you just open http://YOUR_LOCAL_IP:5000 on your phone's browser. I tuned the meta tags and viewport so it feels like a native full-screen app.

The Technical Stuff I Worked Around

The Gemma 3 Tool-Calling

When I started, my plan was classic agentic AI: give Gemma 3 a SerpApi search tool via Ollama so it could look up trail conditions autonomously whenever it needed to.

Then I ran it:

ollama._types.ResponseError: registry.ollama.ai/library/gemma3 does not support tools (status code: 400)

Turns out, the current Ollama build for Gemma 3 throws an immediate HTTP 400 if you pass a tools= list.

My initial thought was to downgrade to another model. But I really wanted Gemma 3—Google's open weights are incredibly snappy and have surprisingly rich botanical and geographical knowledge for their size.

So instead of tool-calling loops, I built a pre-inference grounding pipeline in Python:

[ User Input: "Kedarkantha Trek, moderate" ]
                    │
                    ▼
       Is SERPAPI_KEY available & online?
           ├── YES ──► Search SerpApi for recent trail reports & weather
           │           Inject results into system prompt as [GROUNDING]
           └── NO  ──► Skip quietly (graceful offline fallback)
                    │
                    ▼
     Stream Gemma 3 locally via simple_stream()
                    │
                    ▼
   Token-by-token SSE stream directly to browser

It ended up being way better than native tool calling:

Zero latency wasted on the model deciding whether to call a tool.
Zero tool-call hallucination or format errors.
When you're offline in the woods, it just skips SerpApi without a hitch and lets Gemma 3 run pure local inference.

Architecture: Zero Cloud Lock-In

┌────────────────────────────────────────────────────────┐
│             Web Dashboard / Phone / CLI                │
│       Leaflet Map • Web Audio • Audio Briefing         │
└──────────────────────────┬─────────────────────────────┘
                           │
┌──────────────────────────▼─────────────────────────────┐
│             Flask Server (SSE Streaming)               │
│        Token-by-token output with 0 WebSockets         │
└──────────────┬──────────────────────────┬──────────────┘
               │                          │
┌──────────────▼─────────────┐   ┌────────▼──────────────┐
│  Ollama Engine (Local)     │   │ SerpApi Grounding     │
│  Gemma 3 Open Weights      │   │ (Optional, live data) │
└──────────────┬─────────────┘   └────────┬──────────────┘
               │                          │
               └───────────┬──────────────┘
                           │
┌──────────────────────────▼─────────────────────────────┐
│   SQLite (~/.grassmapper.db)  •  Sentry Agent Tracing  │
└────────────────────────────────────────────────────────┘

Everything that matters—your journal, hike logs, sightings, habit streaks—is stored in a local SQLite file in your home directory (~/.grassmapper.db). No telemetry, no account creation, no analytics tracking where you walk.

🏆 Hacktoberfest Prize Alignment

Here is how GrassMapper addresses the challenge prize categories:

🌟 Best Use of Gemma ($200)

Gemma 3 is the primary intelligence here. It powers:

Trail Architect: Custom itineraries with gear checklists, elevation notes, and difficulty ratings.
Naturalist Guide: Explaining wildlife sightings, botany facts, and seasonal changes.
Trail Debriefs: Reflecting on your journal entries and encouraging healthy outdoor habits. All running locally via open weights, zero closed API reliance.

🚀 Best Use of Render ($200)

GrassMapper comes with a production-ready render.yaml Blueprint and requirements.txt. With one click, an outdoor club, scout troop, or university hiking group can host a shared community instance of GrassMapper on Render backed by Gunicorn.

🔍 Best Use of SerpApi ($100)

AI models have knowledge cutoffs. Trails have seasonal mud seasons, flash flood warnings, and bridge closures. When internet is available, SerpApi grounds Gemma 3 with live trail reports and weather data right before generation runs.

📊 Best Use of Sentry Agent Tracing ($100)

Every single AI interaction is wrapped with sentry_sdk:

op="ai.inference" traces Ollama token generation time and model latency.
op="tool.search" traces SerpApi roundtrips. You get crystal-clear flame graphs showing exactly where your time went during every trail plan generation.

Try It in 2 Minutes

1. Make sure you have Ollama & Gemma 3

# From https://ollama.com
ollama pull gemma3

2. Clone & Install

git clone https://github.com/your-username/grassmapper.git
cd grassmapper
pip install -r requirements.txt

3. (Optional) Add your API keys in `.env`

SERPAPI_KEY=your_key_here
SENTRY_DSN=your_dsn_here

(Both are optional! It works completely fine offline without them.)

4. Fire it up!

To open the Web Dashboard:

python app.py

Open http://localhost:5000 (or http://YOUR_LOCAL_IP:5000 on your phone).

Or stay in the terminal:

python grassmapper.py plan        # Generate a trail plan
python grassmapper.py log         # Log a finished hike
python grassmapper.py observe     # ID a wildflower or bird
python grassmapper.py stats       # Check your Grass Points & streak

Closing Thoughts

We build so much software that tries to capture attention and hold it hostage inside a browser tab.

Building GrassMapper was a breath of fresh air—literally. It was fun to build an AI app where the definition of success isn't "how many minutes did the user spend on this page?", but "did the user shut their laptop and step outside?"

If you've been glued to your IDE all day: save your files, run python grassmapper.py plan, and go touch some grass. You've earned it. 🌿🥾

AI Disclosure

This project utilizes Google's open-weight Gemma 3 model running locally via Ollama to generate offline trail itineraries, nature observations, and outdoor journaling reflections. AI assistance was also used during development for drafting documentation, structuring test cases, and writing code. All core application logic, database schemas, web endpoints, and Leaflet map integrations were implemented, tested, and verified with combined efforts of me and my coding buddies (bunch of AI coding tools an software).

Source Code: github.com/VaishnaviOnPC/grassmapper

Built with: Python, Flask, Gemma 3, Ollama, Leaflet.js, SerpApi, Sentry, Render

License: MIT

🧟‍♂️ Stitching the Spirit: Engineering a "Frankenstein" AI Agent with Kiro & MCP

Vaishnavi Mishra — Fri, 05 Dec 2025 18:22:50 +0000

Most AI hackathon projects are just chatbots with a fancy wrapper. For Kiro-ween, the theme was 'Frankenstein,' so I took that literally. I didn't want another polished, polite chatbot. I wanted to stitch together a bunch of messy, incompatible tech stacks into something that felt alive—and maybe a little dangerous.

We are currently living in the era of "Chat." We ask an LLM a question, and it gives us text back. But the future of AI isn't just about retrieval; it's about agency. It's about agents that can reach out of the chat window and touch the operating system, the file structure, and the hardware.

For the Kiro-ween Hackathon, I entered the "Frankenstein" category with a specific goal: To stitch together incompatible technologies—Local File Systems, IoT simulation, and Reactive Frontend Animations—into a single, cohesive entity.

The result is HauntHub: A Victorian Ghost Butler super-agent that doesn't just talk to you; it haunts your desktop.

Here is the engineering story of how I used Kiro and the Model Context Protocol (MCP) to orchestrate a digital séance.

⚡ The "Frankenstein" Problem

The "Frankenstein" category challenged us to combine disparate tools. In modern web development, sticking a React Frontend, a Node.js Backend, and System-Level Operations together is common. But controlling them all conversationally via a single LLM stream is a nightmare.

I needed an architecture that could handle:

State Management: Remembering the lights are red while reading a text file.
Latency: Triggering a jump-scare animation instantly, not waiting for the LLM to finish typing a paragraph.
Persona Integrity: Ensuring the agent never breaks its 19th-century character, even when throwing JSON parsing errors.

To solve this, I treated the architecture like anatomy. The Frontend is the face, the MCP Tools are the limbs, and Kiro is the nervous system connecting them.

[Image of System Architecture]

🧠 The Brain: Spec-Driven Development

One of the biggest time-sinks in hackathons is writing boilerplate code. I skipped that entirely.

Using Kiro’s Spec-to-Code engine, I wrote a rigorous System Specification (ghost-butler-spec.md) first. I defined the state machine, the valid transitions, and the UI components required. Kiro then generated the React/Node.js scaffolding.

This meant that instead of debugging useEffect hooks for three hours, I was spending my time building the actual "haunted" logic. The spec became the single source of truth—the DNA of the monster.

🦾 The Limbs: Custom MCP Servers

This is where the magic happens. Instead of hard-coding functions into the LLM's system prompt (which bloats context and increases cost), I utilized the Model Context Protocol (MCP).

MCP provides a standardized way for the agent to "discover" tools. I built four custom Node.js MCP servers to act as the ghost's supernatural powers:

1. `haunted-lights-tool.js` (The IoT Hand)

This tool simulates a smart home bridge. It accepts parameters like brightness (0-100) and color_hex.

Input: "Dim the lights for a séance."
Execution: set_light_state({ brightness: 10, color: "#880000" })

2. `file-haunting-tool.js` (The System Hand)

A wrapper around Node's fs module. This allows the ghost to list, read, and rename files.

The Twist: It’s not just a file reader. It’s a haunted file reader. The output is formatted to look like ancient parchment in the UI.

3. `scare-effects-tool.js` (The Poltergeist)

This is a bridge to the frontend Event Bus. It allows the backend agent to trigger client-side CSS animations.

Capabilities: Screen shake, strobe lights, sudden "Glitch" artifacts.

4. `spooky-ascii-tool.js` (The Artist)

A procedural generation tool that creates complex ASCII art on the fly, rendering it into code blocks in the chat interface.

Configuring these in Kiro was shockingly simple. I just pointed mcp.json to my scripts, and the agent immediately knew how to use them.

🫀 The Nervous System: Agent Hooks & Routing

The biggest technical hurdle was Latency vs. Impact.

If a user says "Scare me!", the agent usually does two things:

Generates text ("BOO! Did I frighten you?").
Calls the tool (trigger_scare).

In a standard LLM pipeline, the tool call often happens after or during the text generation. This ruins the timing. A jump scare that happens 3 seconds after the ghost says "Boo" isn't scary; it's just a bug.

The Solution: Kiro Agent Hooks.

I set up specific hooks to intercept intents. When the intent INTENT_SCARE is detected, the hook prioritizes the MCP payload execution immediately.

User Voice → Hook Detection → DOM Manipulation (Shake) → Audio Response

This optimized the "Time-to-Scare" to under 500ms, creating a visceral, reactive experience that feels like a real presence in the machine.

🎭 The Soul: Steering & Vibe Coding

You cannot have a Victorian Ghost Butler who says, "I'm sorry, as an AI language model, I cannot rename that file." It kills the immersion instantly.

Standard "Prompt Engineering" wasn't enough. I used Kiro’s Steering Documents to create a system-level constraint on the model's output. I defined a "High Vibe" setting that penalized modern vocabulary and enforced an archaic dialect.

The "Error Handling" Test

The true test of an agent's persona is how it handles failure.

Standard AI: "Error: File not found in directory."
HauntHub: "Alas, the parchment you seek has vanished into the ether. The spirits deny me access to this realm."

The steering document ensures that even the system logs feel haunted. This turns technical errors into narrative elements.

🔒 Security Spotlight: The "Chroot" Sandbox

Giving an AI agent fs.rename permissions on your local machine is inherently dangerous (and fits the "Frankenstein" theme of playing with dangerous forces).

To make this safe for the judges to run, I implemented a strict Chroot-style sandbox within the file-haunting tool.

// Inside file-haunting-tool.js
const HAUNTED_DIR = path.join(__dirname, '../haunted-files');

function validatePath(userPath) {
    // Resolve path relative to the haunted directory
    const resolvedPath = path.resolve(HAUNTED_DIR, userPath);

    // Security Check: Prevent directory traversal (../)
    if (!resolvedPath.startsWith(HAUNTED_DIR)) {
        throw new Error("The spirits are forbidden from leaving the haunted grounds!");
    }
    return resolvedPath;
}

If the agent (or a malicious user) tries to access system files outside the ./haunted-files/ folder, the tool throws a thematic error, which Kiro then relays to the user in the Butler's voice.

🚀 Conclusion: Agents are Operators

Building HauntHub taught me that the next wave of AI isn't about better chatbots; it's about Agents as Operators.

By combining MCP for standardized tooling, Hooks for routing, and Steering for reliability, we can build software that doesn't just retrieve information—it manages our digital lives.

HauntHub might be a spooky Halloween project, but the architecture underneath it is ready for the enterprise.

Happy Kiro-ween! 👻

HauntHub was a submission for the Kiroween Hackathon. You can view the source code and try the demo yourself on https://github.com/VaishnaviOnPC/HauntHub and Devpost.