DEV Community: Usman Abdullahi Olukayode

Séance: I Summoned the Ghosts of COBOL, FORTRAN and ALGOL — and They Live in My Browser

Usman Abdullahi Olukayode — Sat, 31 Oct 2026 16:46:51 +0000

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

What I Built

Every language you write today is haunted.

Your curly-brace block scope? That's ALGOL 60's ghost. Your for loop over an array? FORTRAN got there in 1957. Your "everything is an object"? Smalltalk said it first at Xerox PARC and has been muttering about being misunderstood ever since. And somewhere, right now, a COBOL program written before your parents met is moving your salary between banks.

Día de los Muertos is about remembering the ancestors: setting out marigolds and candles so the dead can find their way home for a night. So I built them an altar.

Séance is a small web app where you hold a séance with the spirit of a dead (or "dead") programming language. Six spirits answer the call:

COBOL (1959), the Clerk Who Never Left
FORTRAN (1957), the First Formula
ALGOL 60 (1960), the Ancestor of Everything
Pascal (1970), the Strict Schoolmaster
Smalltalk (1972), the Dreamer of Xerox PARC
BASIC (1964), the Spirit of the Home Computer

You pick a spirit, choose a "medium" (an open-weight model) and press Summon. A progress bar fills while the medium crosses over, which in practice means the model weights download and compile on your GPU. Then you can ask the spirit anything. Who made you? What did you run? What do you think of JavaScript? The answer streams back like a planchette, one character at a time.

There's a second mode, Possess code. Paste a snippet of modern JavaScript, Python or Rust, and the ghost takes it over and rewrites it in its own language, followed by a few lines of in-character commentary on what your code got right and wrong.

The ghost and its voice are open-weight models. The séance itself is a handful of static files, and the model runs in your browser, not on a server.

Demo

🕯️ Live: https://seance-ghost-languages.vercel.app

You'll need a browser with WebGPU; a recent desktop Chrome or Edge is the safest bet. Without it the app tells you plainly that "the veil is too thick here" instead of failing silently. The first summoning downloads the model, which can take a few hundred MB to around 1 GB depending on which medium you pick. After that the browser caches it.

Code

📜 Repo: https://github.com/kayode96-max/seance-ghost-languages

No framework and no build step: index.html, style.css, ghosts.js (the spirits) and app.js (the summoning). Clone it, run python3 -m http.server, and you're ready to start a séance. MIT licensed.

How I Built It

The open-source AI at the core is WebLLM from the MLC project (Apache-2.0). It compiles open-weight models to run on WebGPU and gives you an OpenAI-style chat.completions API, entirely client-side. I load it straight from a CDN as an ES module:

const webllm = await import("https://esm.run/@mlc-ai/web-llm@0.2.87");
engine = await webllm.CreateMLCEngine(model, { initProgressCallback: onProgress });

The initProgressCallback drives the "Summoning…" bar, so the slowest part of the experience doubles as the ritual.

The mediums are three small open-weight models from WebLLM's prebuilt list, all 4-bit quantized:

Qwen2.5-0.5B-Instruct: tiny and fast, good for a quick chat
Llama-3.2-1B-Instruct: a richer voice
Qwen2.5-1.5B-Instruct: the best of the three at actually translating code

The spirits are prompts, not fine-tunes. Each ghost in ghosts.js has a persona with its era, its creators, its idioms and its grudges. COBOL talks in DIVISIONS and resents that nobody admits it still runs the banks. BASIC says READY. and is still hurt that someone called GOTO harmful. A shared set of rules keeps them in character and brief, and tells them to be vague and mysterious rather than inventing specifics when unsure. With a 0.5B model that instruction pulls a lot of weight.

The ouija reveal is the part I enjoyed most. Tokens arrive from the model in uneven bursts, so instead of dumping them on screen I push them into a queue that a small timer drains one character at a time. Each character fades in from a blur. When the model runs ahead of the planchette, the timer spells faster to catch up. It's a small trick, but it makes a streaming LLM feel like something is spelling to you from the other side.

Possess mode wraps your code in a structured instruction ("translate into idiomatic FORTRAN; reply with a code block, then two or three sentences of eerie commentary") and raises the token budget. Conversations keep the last few turns as memory, and a Banish button calls WebLLM's interruptGenerate() when a spirit gets long-winded.

The atmosphere is plain CSS: a vignette that flickers like candlelight, marigold accents, candles with animated flames, and a board with a warm wooden glow.

Honest limits. These are very small models doing role-play. The ghosts will sometimes misremember a date, and their COBOL won't always compile. I'd treat what they say as folklore. It's a séance, not a reference manual. The 1.5B medium is noticeably better at code if your GPU can handle it.

Why Open Innovation Matters

This project could only be built this way with open weights, and that's the part I care about most.

It runs locally. Inference happens on your own GPU. No API, no inference server, no account to sign up for.
It's private. Your questions, and any code you paste into Possess mode, never leave your machine. That includes proprietary code from work.
It's free, for me and for you. There's no per-token bill, so I can host it as a static site and anyone can use it as much as they like without me worrying about cost.
It works offline after the first load. Once the browser has cached the weights, the séance doesn't need a connection to any inference service.
You can swap the medium. If a better small open model comes out next month, switching is one line. Nobody can deprecate the model out from under it.

There's a fitting symmetry here. COBOL, FORTRAN and ALGOL were shared openly as specifications and standards, and they shaped everything that came after them. Open-weight models are doing something similar now: they're the shared ancestors the next generation of tools will grow out of. Leaving them open, and running them on our own machines, is how we make sure the future gets the chance to remember them too.

Light a candle for your favourite dead language, and go ask it what it thinks of you. 🕯️🌼

CartPulse: Building an In-Store AI Budget Guardian That Shoppers Would Actually Pay For

Usman Abdullahi Olukayode — Sun, 18 Oct 2026 22:39:39 +0000

🛒 CartPulse: Building an In-Store AI Budget Guardian That Shoppers Would Actually Pay For

Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 2 ("Side Hustle").

💡 The Side Hustle: What We Built & Who Would Pay For It

Every weekend, millions of shoppers walk into supermarkets with a mental spending limit—say, ₦15,000 or $50—and walk out stunned at the register after spending 30% more than planned.

The reasons are universal:

Product prices are scattered across aisles and easily forgotten while walking the store.
Mental math deteriorates after 20 minutes of navigating fluorescent-lit aisles.
Impulse additions quietly push the basket over the budget limit.
When shoppers finally reach the cashier, returning embarrassing unscanned items causes delays and frustration for everyone in line.

CartPulse is an in-store shopping companion web application that puts a financial guardian in the shopper's pocket. It combines instant barcode scanning, predictive product search, live cart state tracking, dynamic budget metering, and an open-weight AI shopping assistant that actively prevents overspending before reaching checkout.

Who Would Pay For This?

We designed CartPulse with two distinct, viable revenue paths:

1. Direct-to-Consumer (B2C Freemium / $3.99/mo)

Target Audience: College students on tight allowances, single professionals managing strict weekly grocery limits, and families balancing household budgets amidst inflation.
Value Proposition: If CartPulse saves a family ₦5,000–₦15,000 ($10–$30) per shopping trip by highlighting cheaper catalogue substitutes and flagging impulse creep, paying a modest subscription or tip is an immediate positive ROI.
Premium Features: Multi-store loyalty catalogue sync, nutritional goal balancing, household shared lists, and receipt export.

2. Retailer White-Label License (B2B SaaS / Store Partnership)

Target Audience: Supermarket chains (such as Shoprite, Spar, and regional grocery outlets).
Value Proposition: Checkout bottleneck reduction. CartPulse generates an encrypted express checkout QR code summarizing verified items. Retailers accelerate checkout lane throughput by up to 40%, lower cashier staffing overhead during peak hours, and drastically reduce abandoned cart restock labor.

🧠 Why Open Innovation Matters for What We Built

The Hacktoberfest Week 2 prompt asked builders: Tell us why open innovation matters for what you built.

For CartPulse, open-weight AI is not an optional marketing badge—it is the structural reason the business model works:

1. Zero Per-Query API Fees Makes the Unit Economics Work

If you build a shopping assistant with a proprietary closed API (e.g., OpenAI or Claude), every shopper scanning 20 items and asking 5 budget questions burns through dozens of token calls. At thousands of daily users, API bills completely destroy the margins of a lean consumer side hustle.

By running Qwen 2.5 0.5B Instruct (under an Apache 2.0 license) locally in the browser via WebGPU / ONNX, inference costs exactly $0.00 per scan. The business stays profitable from day one.

2. Absolute Customer Privacy of Food & Expense Data

What a shopper buys, what brand of medicine or cereal they pick, and how much cash they have left in their bank account is intimate personal data. Proprietary cloud LLMs route user queries through remote server farms and data brokers. With CartPulse:

Zero shopping cart data ever leaves the user's device.
All session states, budget thresholds, and item tallies live locally in browser storage.

3. Supermarket Aisle Offline Resilience

Physical supermarkets are notorious Faraday cages. Thick concrete walls and metal shelving frequently kill cellular signals in Aisle 4. Because CartPulse pairs local open weights with a deterministic in-browser intelligence engine, shoppers get instant answers even when cellular bars drop to zero.

4. Zero Hallucinations: Deterministic Financial Accuracy

In retail, hallucinating a price or miscalculating a budget total destroys user trust immediately. CartPulse strictly separates financial math from natural language reasoning:

All monetary calculations (totals, subtotals, remaining budget, overage, percentages) are computed by deterministic, pure TypeScript functions.
The open model receives structured application context and explains trade-offs, compares items, and suggests actions, but never invents fictional prices or products.

5. Localization for Regional Supermarkets

Because the model weights are open, future iterations can easily be adapted for regional supermarkets across Africa, Europe, and Asia, understanding local brand colloquialisms (e.g., Nigerian pantry staples like Maggi Star Cubes, Peak Milk, Indomie, Golden Penny Spaghetti, and Dangote Sugar in Nigerian Naira ₦).

🏛️ System Architecture

flowchart TD
    subgraph Client ["Client Device (Mobile Browser / PWA)"]
        UI["Next.js 14 Mobile-First Interface\\n(Space Grotesk + Plus Jakarta Sans)"]
        ZStore[("Zustand Local Store\\n• Budget: ₦15,000\\n• Cart Items\\n• Active Store\\n• Recent Searches")]
        UI <--> ZStore
    end

    subgraph ScannerEngine ["In-Store Barcode & Search Gateway"]
        Cam["Viewfinder & Real Camera (getUserMedia)"]
        Toast["Scan Confirmation Toast\\n(3s Auto-Add / 5s Reject Pause)"]
        Search["Predictive Search Engine\\n(Aisles 1-6 • Category Filtering)"]
        Cam --> Toast --> ZStore
        Search --> ZStore
    end

    subgraph DeterministicMath ["Deterministic Financial Engine"]
        M1["calculateCartTotal()"]
        M2["calculateRemainingBudget()"]
        M3["getBudgetStatus() (<80%, 80-99%, ≥100%)"]
        M4["simulatePurchaseImpact()"]
        ZStore <--> M1 & M2 & M3 & M4
    end

    subgraph AIEngine ["CartPulse Open AI Layer"]
        Qwen["Qwen 2.5 0.5B Instruct\\n(Apache 2.0 • Local In-Browser Inference)"]
        Adapter["CartPulseAIAdapter"]
        Tools["Recommendation Tools\\n• checkAffordability()\\n• findCartAlternatives()\\n• prioritizeCartItems()\\n• generatePreCheckoutSummary()"]

        Adapter <--> Qwen
        Adapter <--> Tools
        Tools <--> DeterministicMath
        ZStore <--> Adapter
    end

    subgraph CheckoutGate ["Express Gate Checkout"]
        Modal["Reality Check Verification Modal"]
        QR["SVG QR Matrix Session Generator\\n(Prototype Reference Token)"]
        UI --> Modal --> QR
    end

📱 User Experience & Key Features

1. Screen 0: Store Check-In

Shoppers scan the entrance QR code or pick a geo-fenced branch preset (Shoprite Ikeja City Mall, Shoprite Minna, or Spar Victoria Island). Live pricing and aisle maps synchronize immediately with a pulsating laser reticle.

2. Persistent Dynamic Shopping Header

Visible on every screen once checked in:

Active store indicator and live shopping bag unit counter.
Running totals: Total: ₦[cartTotal] and Budget: ₦[budget] (with 1-click inline budget editing).
Dynamic 3-Tier Budget Progress Bar:
- < 80%: Electric emerald positive progress.
- 80%–99%: Amber warning badge with remaining funds reminder.
- ≥ 100%: Red danger alert displaying exact excess amount (₦X over budget!).

3. Screen 1: Camera Scanner & 3-Second Confirmation Toast

Dual-mode viewfinder: supports real camera stream via getUserMedia or high-fidelity simulated supermarket aisle.
Torch toggle with illumination beam effect.
Floating Scan Confirmation Toast: When a barcode is scanned, a compact card appears displaying the product photo, name, and emerald price. A 3-second animated timeout bar counts down—if not rejected, the item is auto-added with an audio synthesizer beep. Pressing Reject cancels the addition and pauses scanning for 5 seconds to prevent accidental duplicates.

4. Screen 2: Predictive Product Search

Sub-millisecond instant filtering across 21 everyday grocery staples.
Category carousel: Seasoning & Spices, Dairy & Breakfast, Pasta & Grains, Household & Pantry, Bakery & Fresh, Snacks & Beverages.
Budget Pacing Card: Live indicator showing available funds and whether the shopper is within limit.
1-tap circular + addition buttons.

5. Screen 3: Live Cart Dashboard

Full itemized basket with micro-steppers (- / +), individual subtotals, and SKU tags.
Accessible item removal with an instant Undo notification banner.
"Review my budget with AI" call-to-action button.
Pinned bottom checkout bar with "Finish Shopping" trigger.

6. Screen 4 & 5: Reality Check & Checkout QR Code

Reality Check Modal: Displays an animated amber warning ping: "Does your physical cart match your digital list exactly? Unscanned items will cause delays at the checkout."
Checkout Confirmation: Generates a high-contrast, self-contained SVG QR code matrix encoding a safe demonstration checkout reference token, accompanied by an itemized grocery breakdown.

7. Smart Shopping Assistant Panel

Accessible from bottom navigation, persistent header, or floating action button (FAB):

Displays the Qwen 2.5 0.5B • Apache 2.0 • Local In-Browser Inference badge.
Instant suggested question chips:
- "Can I still afford milk and bread?"
- "What can I remove to stay within my budget?"
- "Find cheaper alternatives to the products in my cart."
- "Which items should I prioritize?"
- "Summarize my shopping so far."
Interactive Actionable Recommendation Cards: When the assistant suggests cheaper substitutes (e.g. switching Peak Powdered Milk ₦3,100 to Dano Full Cream ₦2,400 to save ₦700), it presents a 1-tap Switch or Add button that directly modifies the live cart!

🧪 Automated Test Suite

We built a comprehensive automated test suite with Vitest to guarantee mathematical correctness, state consistency, and AI reasoning reliability:

 ✓ tests/calculations.test.ts (8 tests)
   • Calculates item subtotals correctly
   • Computes cart total and total units
   • Accurately measures remaining budget and overage amounts
   • Validates 80% warning and 100% danger status triggers
   • Simulates purchase impact before adding items
   • Formats currency with Nigerian Naira (₦)

 ✓ tests/store.test.ts (6 tests)
   • Adds products and increments quantities
   • Updates item quantities and removes when zero
   • Supports item removal with undo restoration
   • Manages budget and store configuration
   • Deduplicates recent search history
   • Ticks simulated camera pause countdown

 ✓ tests/ai-intelligence.test.ts (6 tests)
   • Matches product keywords from natural queries
   • Evaluates affordability within remaining budget accurately
   • Identifies cheaper catalogue alternatives
   • Prioritizes purchases and suggests non-essential removals when over budget
   • Generates pre-checkout executive summary
   • Generates AI responses without price hallucinations

 ✓ tests/scan-flow.test.ts (4 tests)
   • Sets store on check-in and resets session state
   • Selects random demonstration product for mock scanning
   • Rejects product scan and pauses camera for 5 seconds
   • Manages reality check modal and transitions to checkout summary

 ✓ tests/catalogue.test.ts (4 tests)
   • Validates 21 items with unique IDs, barcodes, and positive prices
   • Searches catalogue by query and category filter

Test Files:  5 passed (5)
Tests:       28 passed (28)
Pass Rate:   100%

🛠️ Tech Stack

Framework: Next.js 14 (App Router)
Language: TypeScript 5 (Strict Mode)
Styling: Tailwind CSS 3 (CartPulse Dark Precision Engineering Design System)
Typography: Space Grotesk (Headlines, Numerics, Tabular Figures) & Plus Jakarta Sans (Body)
State Management: Zustand with safe local storage persistence & SSR hydration handling
Audio Feedback: Web Audio API synthesizer
Testing: Vitest
License: Apache 2.0

🛒 Try It Out

Clone the repository:

   git clone https://github.com/kayode96-max/cart.git
   cd cart

Install dependencies:

   npm install

Run automated tests:

   npm test

Start the local server:

   npm run dev

Open http://localhost:3000 in your mobile browser or desktop browser!

CartPulse proves that open-source AI is not just for cloud researchers—it's the foundation for real, privacy-first side hustles that solve everyday human problems.

GrowLocal AI: Building an Offline-First, Gemma-Powered Gardening Companion to Touch Grass

Usman Abdullahi Olukayode — Sun, 11 Oct 2026 14:24:31 +0000

🌱 GrowLocal AI: Touch Grass with Open-Source AI in the Soil

Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1 ("Touch Grass").

🍃 What We Built & Who It's For

When modern AI applications promise to "help you garden," they usually mean trapping you in front of a glowing glass rectangle, chatting with a generic cloud LLM that hallucinates frost dates, sells your garden coordinates to telemetry servers, and goes completely dead the moment you walk out to the back acre where cellular service disappears.

GrowLocal AI takes the opposite approach.

We built a mobile-first, privacy-respecting gardening companion designed to get you off the screen and into the living soil. Whether you're managing a 50 sq ft suburban raised bed or a container balcony in Zone 7b, GrowLocal AI calculates deterministic planting calendars, pairs synergistic companion crops, diagnoses plant stress, and schedules daily hands-on chores.

Once you check your tasks, the app actively instructs you to put your phone away and touch grass.

🧠 Why Open Innovation Matters for What We Built

The core prompt of this challenge asked builders: Tell us why open innovation matters for what you built.

For GrowLocal AI, open innovation is not an optional aesthetic choice—it is the foundational requirement that makes the product viable:

True Offline Resilience in the Field: Food resilience and gardening happen in the dirt, often in remote valleys, community plots, or backcountry properties with zero cellular bars. By using Google Gemma 2 2B quantized with 4-bit weights served locally via Ollama, GrowLocal AI runs genuine, new AI reasoning directly on consumer laptop or local hardware without internet access.
Absolute Privacy of Location & Food Data: Knowing what a family grows, where their home beds are, and when they harvest is sensitive personal data. In GrowLocal AI, personal garden layouts, planting schedules, and journal entries are stored strictly in browser IndexedDB on the user's device. No garden data ever leaves the machine.
Deterministic Truth Over Hallucinations: Gardening mistakes cost months of labor and lost harvests. Instead of relying on closed LLM probabilistic memory, we used the open-source Mastra agent harness to ground every model interaction in deterministic, university-extension-verified agronomic knowledge (Cornell, UC Davis, Oregon State, Purdue).
Pluggable Architecture Without Vendor Lock-in: Our Model Registry allows users to run Google Gemma 2, swap to another open-weight model, or use in-browser WebGPU via WebLLM without modifying the gardening tools or application layers.

🏛️ System Architecture

flowchart TD
    subgraph Client ["Client Device (Mobile / PWA)"]
        UI["Next.js 14 Mobile-First Web App"]
        IDB[("Local IndexedDB\n• Garden Profiles\n• Active Plants\n• Care Tasks\n• Journal Observations")]
        UI <--> IDB
    end

    subgraph AgentHarness ["Mastra Agent Framework"]
        Agent["GrowLocalGardener Agent"]
        T1["recommendCrops()"]
        T2["createGardenPlan()"]
        T3["getGardeningKnowledge()"]
        T4["assessPlantSymptoms()"]
        T5["generateCareTasks()"]
        T6["recordGardenObservation()"]
        Agent --> T1 & T2 & T3 & T4 & T5 & T6
    end

    subgraph KnowledgeData ["Local Extension Knowledge Pack"]
        DB[("Versioned Botanical DB\n• 20+ Companion Crops\n• USDA Frost Calendars\n• IPM Diagnostic Rules\n• Cornell & UC ANR Citations")]
        T1 & T2 & T3 & T4 & T5 <--> DB
    end

    subgraph AIProviders ["Model Provider Abstraction Layer"]
        Registry["ModelRegistry"]
        OllamaP["OllamaGemmaProvider\n(gemma2:2b-instruct-q4_K_M)\n100% Local & Offline"]
        WebLLMP["WebLLMGemmaProvider\n(WebGPU In-Browser)"]
        HostedP["HostedRenderProvider\n(Render Cloud Demo)"]
        Registry --> OllamaP & WebLLMP & HostedP
    end

    UI <--> Agent
    Agent <--> Registry

    subgraph Telemetry ["Observability & Privacy"]
        Sentry["Sentry Agent Tracing\n• Execution Latency\n• Tool Duration\n• Stripped PII"]
        Agent -.-> Sentry
    end

🛠️ The Mastra Gardening Agent: 6 Typed Tools

Our agent, GrowLocalGardener, is orchestrated with Mastra and executes 6 deterministic tools validated against strict Zod schemas:

recommendCrops: Evaluates microclimate parameters (USDA hardiness zone, sun hours, available square footage, water access, and container filters) to calculate suitability scores (0-100), yield estimates, and companion groupings.
createGardenPlan: Computes spring indoor seed sowing, direct sowing, transplant dates, and continuous harvest windows based on localized frost dates.
getGardeningKnowledge: Retrieves authoritative organic gardening guidance with exact extension citations.
assessPlantSymptoms: Evaluates physiological stress vs fungal/pest disease, providing safe in-field diagnostic checks, organic remedies, and explicit uncertainty disclaimers.
generateCareTasks: Generates actionable, growth-stage-appropriate care chores (watering, fertilizing, weeding, pruning, harvesting, frost protection).
recordGardenObservation: Validates plant journal entries and commits them to the local persistence layer with user confirmation.

🏆 Hackathon Sponsor Track Integrations

Google Gemma (Priority A): Google Gemma 2 2B Instruct (gemma2:2b, Q4_K_M quantized) runs directly on the local machine via Ollama, generating verified gardening advice completely offline.
Mastra (Priority A): Powers the agentic tool orchestration, validation schemas, and observable execution traces.
Render (Priority A): Complete production deployment configuration (render.yaml and Dockerfile) with clean separation of hosted and local private modes.
GitHub Copilot (Priority A): Agentic pair programming documented in COPILOT.md for schema generation, frost math, and test suites.
Sentry Agent Tracing (Priority A): Real-time telemetry inspector capturing agent durations, tool latency, and error states with PII stripped.
ElevenLabs (Priority B): Voice synthesis reads tasks aloud when hands are covered in dirt, with seamless offline Web Speech fallback.
MongoDB Atlas (Priority B): Vector search configuration in atlas.config.json for optional global knowledge indexing.

🤖 Agent Session Transcript

Here is the interactive DevRelay agent session documenting the build, tool schemas, and local test run:

Building GrowLocal AI: Offline-First Gemma 2 & Mastra Gardening Companion

You

Build an offline-first gardening assistant for Hacktoberfest Week 1 'Touch Grass'. It needs to run Google Gemma 2 2B locally via Ollama, orchestrate agronomic tools using Mastra, keep all garden data strictly private in IndexedDB, and give deterministic planting schedules based on USDA frost dates.

Agent

I'll design and build GrowLocal AI with a modular Mastra agent harness, 6 typed Zod tools grounded in Cornell/UC Davis extension data, an offline IndexedDB persistence layer, and Google Gemma 2 2B local inference. Let's start by defining the tools and model registry.

▸ write_to_file apps/agent/src/tools/recommend-crops.ts

Input

apps/agent/src/tools/recommend-crops.ts

Output

Created recommendCrops tool with microclimate suitability scoring (0-100) and companion crop grouping.

▸ write_to_file apps/agent/src/tools/create-garden-plan.ts

Input

apps/agent/src/tools/create-garden-plan.ts

Output

Created createGardenPlan tool calculating indoor sowing, direct seeding, and harvest windows from localized frost dates.

▸ write_to_file apps/agent/src/agent.ts

Input

apps/agent/src/agent.ts

Output

Configured GrowLocalGardener agent with Mastra, binding the 6 extension-grounded tools and Gemma 2 2B provider.

You

Run the test suite to verify the agent tool accuracy across different hardiness zones and frost calculations.

Agent

▸ run_command npx tsx scripts/test-agent.ts

Input

$ npx tsx scripts/test-agent.ts

Output

EVALUATION SUMMARY: 30/30 TESTS PASSED (100% SUCCESS) - Verified microclimate scoring, frost scheduling, Blossom End Rot diagnosis, and Mastra execution traces.

All 30 automated evaluation benchmarks passed with 100% success. The Mastra agent successfully executes tool calls in ~14ms with zero network egress, fully ready for off-grid gardening in the field.

🧪 Automated Evaluation Results

We built an automated evaluation suite (scripts/test-agent.ts) that verifies contrasting microclimates, frost math, symptom differential accuracy, and Mastra agent trace generation:

====================================================
  GROWLOCAL AI: AGENT & TOOL EVALUATION SUITE
====================================================
--- TEST 1: Contrasting Garden Condition Recommendations ---
✅ PASS: Returned recommendations for cold shade container
✅ PASS: Score is appropriately penalized for full shade/scarce water
✅ PASS: Every recommendation includes verified source citations
✅ PASS: High suitability score for optimal sun and water conditions
✅ PASS: Returned companion grouping synergies

--- TEST 2: Structured Garden Plan & Frost Scheduling ---
✅ PASS: Plan contains all selected crops
✅ PASS: Preserves exact last frost date
✅ PASS: Warm-season tomato identified for indoor seed sowing before frost

--- TEST 3: Extension Knowledge Retrieval & Source Citations ---
✅ PASS: Retrieved relevant composting passages
✅ PASS: Knowledge pack marked as offline verified

--- TEST 4: Plant Symptom Assessment & Uncertainty Guardrails ---
✅ PASS: Accurately recognized Blossom End Rot
✅ PASS: Enforced scientific non-definitive uncertainty disclaimer

--- TEST 5: Daily Care Tasks Generation ---
✅ PASS: Generated multiple care tasks

--- TEST 6: Observation Validation & Privacy ---
✅ PASS: Flagged for local-only storage

--- TEST 7: Mastra Agent GrowLocalGardener End-to-End Trace ---
✅ PASS: Observable trace captured tool execution (Trace Duration: ~14ms)

--- TEST 8: Pluggable Model Provider Architecture ---
✅ PASS: Default model is Google Gemma 2 2B

====================================================
  EVALUATION SUMMARY: 30/30 TESTS PASSED (100% SUCCESS)
====================================================

🌿 Try It Yourself

Clone repository: git clone https://github.com/kayode96-max/Growlocal.git
Run npm install
Start Ollama and pull Gemma: ollama run gemma2:2b
Run npm run dev and open http://localhost:3000
Disconnect your Wi-Fi, take your laptop into the garden, and touch grass!

[Boost]

Usman Abdullahi Olukayode — Sun, 04 Oct 2026 17:48:13 +0000

Hacktoberfest Weekend Challenge: Build for a Friend Submission 🤝

Abdulaleem Zakariyah

Oct 4

PyReviewer: A Production-Grade Python AST, Security & Docker Reviewer for Large Codebases

#devchallenge #weekendchallenge #hf26challenge #render

4 min read

FixIt AI: An Open-Weight Technical Troubleshooting Friend Powered by Google Gemma

Usman Abdullahi Olukayode — Sun, 04 Oct 2026 17:43:53 +0000

"Don't just ask AI what's wrong. Let AI help you find out."

💡 The Story: Who I Built This For

Living with solar power or off-grid electrical equipment is empowering—until something silently stops working.

I built FixIt AI for my close friend who relies on a small off-grid solar setup. Recently, their portable power station stopped charging from the solar panels in full daylight. They had no idea whether the problem was a dead solar cell, an incompatible MPPT controller, a loose cable, or something dangerous.

When they tried asking a generic closed AI chatbot, it dumped 18 bullet points of dense electrical advice all at once. My friend felt more overwhelmed and terrified of an electrical shock than before asking.

I realized what they actually needed was a patient technical troubleshooting friend who could:

Assess safety first before touching anything.
Form structured hypotheses without pretending to know everything.
Walk them through one diagnostic test at a time.
Separate safe DIY checks from hazardous work requiring a licensed technician.

That is why I created FixIt AI.

⚡ What FixIt AI Does

Instead of the standard Photo → AI → Generic Wall of Text pattern, FixIt AI acts as an interactive state machine:

Photo & Symptoms
      ↓
Safety Hazard Triage (Smoke / Thermal / Arcing)
      ↓
Form Ranked Hypotheses
      ↓
Run Single Diagnostic Check (Step 1)
      ↓
User Observes & Reports Result (or Multimeter Reading)
      ↓
Update Evidence & Narrow Down Possibilities
      ↓
Run Next Test (Step 2)
      ↓
Resolve (🟢 Solved | 🟡 Continue | 🔴 Tech Required)

Key Features:

Priority Safety Layer: Halts DIY tests immediately if arcing, smoke, or swollen lithium cells are present, producing a structured Technician Handover Brief.
Interactive Step-by-Step Mode: Delivers single, actionable checks (e.g., inspecting the inline DC breaker before taking anything apart).
Multimeter Support: Prompts for DC voltage and current readings when testing open panel terminals or socket pins.
Pure Flat Modern UI: High-contrast black and emerald mobile-first interface (320px–480px optimized) with zero underlines, pure white typography, and Lucide SVG iconography.
Evidence Audit Log: Generates an exportable/printable repair timeline for maintenance records or handoffs.

🧠 Why Open-Source AI Matters for This Project

The Hacktoberfest prompt asked: Why does open matter for what you built?

For FixIt AI, using an open-weight model (Google Gemma 2) is fundamental to why the app works in the real world:

1. Power Outages = Zero Internet Access

When a solar generator or home electrical system fails, the WiFi and home router often fail with it. Closed cloud APIs (OpenAI, Claude) are completely useless when there is no internet connection. Because Gemma-2 runs locally on consumer hardware (or an offline laptop via Ollama), my friend can diagnose power failures in a blackout with zero internet.

2. Privacy of Home Electrical Infrastructure

Troubleshooting requires photographing breaker distribution boxes, wiring runs, and serial tags. Homeowners should not have to upload intimate schematics of their home's physical layout to third-party cloud servers. Open-weight models ensure images stay strictly on the local machine.

3. Predictable JSON Schemas at Zero Token Cost

Interactive troubleshooting requires multiple round-trip checks (5 to 10 inference steps per session). Calling proprietary APIs for every small test is cost-prohibitive. Gemma's strong instruction-following allows strict JSON schema validation at $0.00 marginal cost.

🛠️ Tech Stack & Architecture

AI Model: Google Gemma 2 (gemma2-9b-it via Groq for high-speed cloud inference, with native Ollama support for 100% offline edge inference).
Frontend & App Framework: Next.js (App Router, Turbopack, React 19, TypeScript).
Design System: Flat Vanilla CSS with a black and emerald palette, crisp typography, and Lucide icons.
Deployment: Hosted on Render using a native render.yaml Blueprint.

🔗 Live Demo & Links

💻 GitHub Repository: github.com/kayode96-max/hacktoberfest_fixit
⚙️ Render Blueprint: https://fixit-ai-1hz8.onrender.com

Submitted to the Hacktoberfest Weekend Challenge: Build for a Friend (#hf26challenge).

What Clicked for Me After Building on Solana for a Few Days

Usman Abdullahi Olukayode — Fri, 22 May 2026 16:47:45 +0000

Before I started working through day 08 to day 12, I expected blockchain data to feel a lot more opaque than it does. I thought I would be dealing with something closer to a black box, where the main challenge was just figuring out which API call returned which value. What surprised me most was how quickly Solana started to feel like a public database I could inspect directly.

Day 08 was the first real "oh, this is usable" moment. Reading a balance with RPC did not feel like hitting a special blockchain endpoint so much as querying state. Day 09 pushed that further when I fetched recent transaction signatures and started seeing the chain as a history of real events instead of just a number on a screen. That made the data feel alive. It was no longer just "wallet balance" or "transaction count." It was a record of activity I could trace.

The biggest click came when I compared devnet and mainnet on day 12. Same code, same RPC patterns, different networks, different answers. That made the shared-state model feel real to me. I was not talking to one app's private backend. I was asking two different views of the network the same questions and getting different slices of reality back.

Working on day 10 also helped connect the pieces. Once I put balance and transaction lookups into a small browser app, Solana stopped feeling like a set of disconnected scripts. It started to feel like something you could actually build a product around. That was the moment the SDK made sense: it was not abstract blockchain machinery; it was just a way to read and present on-chain state cleanly.

What is still a little confusing is how the deeper account model fits together under the hood. I get the high-level idea now: accounts hold data, programs define behavior, and the chain is public by default. But I still want more practice understanding when to think about wallet addresses, when to think about program-owned accounts, and how PDAs fit into the picture.

So far, the takeaway has been simple. Solana is not just "a blockchain where data lives somewhere else." It changes the whole mental model. The data is public, the state is shared, and the challenge is learning how to read and shape that state without relying on a traditional backend in the middle.

This is day 13 of my #100DaysOfSolana journey. I’m sharing weekly reflections as I build from zero to proficiency with blockchain development.

Solana Accounts vs Databases

Usman Abdullahi Olukayode — Fri, 22 May 2026 15:41:33 +0000

If you know databases, Solana can feel familiar and strange at the same time. A database row becomes an account, a primary key becomes a public key or PDA, and a schema becomes program logic.

The big shift is this: data lives on a shared network, not one company server. The program decides what the data means, and only the right signer can change it.

That is why Solana asks you to think less about tables and more about ownership, permissions, and state.

The table and the solana address output make the idea easier to see at a glance. On Solana, identity and data are tied to accounts, and accounts behave very differently from rows in a normal database.

Identity on Solana: How It's Different From Web2 (And Why That Matters)

Usman Abdullahi Olukayode — Sat, 16 May 2026 07:53:09 +0000

You know how frustrating it is when you get locked out of your email and have to jump through hoops to prove you own the account? Or when a platform gets hacked and someone else gains access to your data? If you're a Web2 developer, you've probably built login flows, managed authentication, and dealt with the complexity of keeping user credentials safe.

Solana does identity completely differently. And once you understand how, a lot of blockchain concepts suddenly click into place.

The SSH Key Analogy

If you've set up SSH, you already understand Solana identity. You generate a keypair: the public key is on the server, and the private key stays secret. You prove ownership by signing with your private key.

Solana works identically. Every account has a keypair—public key (your address) and a private key (proves ownership). No company involved. No email verification. Just cryptography.

Cryptographic Ownership Changes Everything

In Web2, companies manage your identity. They store credentials, reset passwords, and can lock you out. On Solana, you own your account if and only if you control the private key. No password resets. No lockouts. No company can revoke it, but losing the key means losing access forever. It's true autonomy, but with full responsibility.

How You Hold Your Private Key Matters: Wallet Types and Safety

But here's the practical question: where do you keep your private key?

Hot vs Cold: Hot wallets (CLI, browser, and mobile) keep your key on an internet-connected device, fast and convenient but vulnerable. Cold wallets (like Ledger) keep it offline, much more secure, but slower.

Custodial vs Non-Custodial: Non-custodial wallets (Phantom, CLI) give you full control of the keypair. Custodial wallets (exchanges) have a company holding them, which is convenient, but you're trusting them again.

The tradeoff is real: more security means less convenience. During my first week, I experimented with CLI (full control), browser extensions (convenient), and mobile wallets (very convenient). Each one is a valid identity. Which you use depends on what you're doing and how much you're storing.

The key insight? The security of your keypair is your responsibility.

What This Enables

Because your address is cryptographically tied to your private key, you can own tokens without custodians, interact with smart contracts, vote on governance, and build reputation that travels across all Solana applications.

The killer feature? It's permissionless. You don't ask anyone for permission to own your identity. You generate a keypair and you're in.

The Aha Moment

Here's what clicked for me: Solana identity isn't about replacing passwords. It's about replacing the role of the company.

In Web2, the company is the arbiter of who you are. On Solana, you are. You prove it with cryptography, and that shift unlocks everything—true ownership, interoperability, and permissionless access.

This is day 6 of my #100DaysOfSolana journey. I'll be posting weekly reflections on what I'm learning as I build from zero to proficiency with blockchain development.

100daysofsolana #solana #web3 #blockchain #beginners