DEV Community: Shikhar Verma

Hypnos: The Local Gemma Daemon That Cleans Your Git Tree & Preps Your Standup While You Sleep

Shikhar Verma — Sun, 25 Oct 2026 13:16:52 +0000

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

What I Built

Let’s be honest about how we actually write code at 1:30 AM.

We don't make clean, atomic commits. We touch 17 different files across the backend and UI to fix one race condition, leave console.log("HERE_4") in three places, ignore the outdated README.md, and tell ourselves, "I'll untangle the git staging and write my standup notes tomorrow morning."

Spoiler: tomorrow morning, you wake up 6 minutes before standup and push git commit -m "wip fixes".

In honor of International Sloth Day and the Slow and Steady theme, I built Hypnos (hypnos-cli)—an autonomous, local-first overnight janitor for lazy engineers.

When you walk away from your keyboard at night, Hypnos wakes up and does the tedious engineering hygiene you dread:

Untangles Dirty Working Trees: Inspects your uncommitted git diff, strips leftover debug statements, and groups entangled changes across files into logical, atomic git patches (git add -p style) on a shadow staging branch.
Writes Semantic Commits & Docs: Uses a local Gemma model to generate strict Conventional Commits for each logical hunk and automatically patches outdated CLI flags or env variables in your README.md.
Preps Your Morning Standup (With Audio): Cross-references your local shell history, git reflog, and resolved issues to draft a crisp 3-bullet standup update—and uses ElevenLabs to synthesize a calm, 45-second audio briefing waiting for you when you open your laptop with your morning coffee.

Who gets to be lazier? Any developer who wants the reputation of a disciplined 10x staff engineer with the actual daily habits of a caffeinated sloth.

Demo

Live Dashboard & Docs:
Video Walkthrough:

Terminal & Trace Preview

$ hypnos sleep --watch ~/projects/core-engine

 🦥 System idle detected (15m). Starting Temporal workflow: overnight-hygiene-884a
 🔍 Found 14 modified files (+412, -89 lines) with uncommitted changes.
 🧹 AST Scrubber removed 3 orphaned debug statements.
 🧠 Gemma (local) partitioned diff into 3 logical atomic commits:
           ├── feat(cache): implement sliding window TTL eviction
           ├── fix(rpc): handle retry backoff on timeout
           └── docs(readme): document REDIS_MAX_POOL env variable
 🎙️ ElevenLabs synthesized morning briefing -> ~/.hypnos/standup-2026-10-25.mp3
 ✅ Staged on branch `hypnos/nightly-2026-10-25`. Run `hypnos apply` over coffee.

Core Architecture: Durable Diff Partitioning & Local Inference

Here is how Hypnos pairs Temporal activities with local Gemma structured JSON outputs to split a messy workspace diff into clean, logical commit hunks without losing state if the laptop suspends:

// src/workflows/overnightHygiene.ts
import { proxyActivities } from '@temporalio/workflow';
import type * as activities from '../activities';

const { 
  extractAstDiffs, 
  partitionWithGemma, 
  stageShadowCommits, 
  synthesizeMorningBriefing 
} = proxyActivities<typeof activities>({
  startToCloseTimeout: '5 minutes',
  retry: {
    initialInterval: '10s',
    backoffCoefficient: 2,
    maximumAttempts: 5, // Survives laptop lid sleep/wake cycles
  },
});

export async function overnightHygieneWorkflow(repoPath: string): Promise<string> {
  const rawDiffs = await extractAstDiffs(repoPath);
  if (rawDiffs.length === 0) return 'Workspace already clean. Keep sleeping!';

  // Local Gemma inference clusters file hunks into atomic semantic units
  const commitPlan = await partitionWithGemma(rawDiffs);

  // Apply hunks onto an isolated shadow branch (never mutates main directly!)
  const branchName = await stageShadowCommits(repoPath, commitPlan);

  // Generate the 45-second audio standup summary
  await synthesizeMorningBriefing(commitPlan);

  return branchName;
}

And the local Gemma activity instrumented with Sentry Agent Tracing:

// src/activities/gemmaPartitioner.ts
import * as Sentry from '@sentry/node';
import ollama from 'ollama';

export async function partitionWithGemma(rawDiffs: string) {
  return await Sentry.startSpan(
    {
      op: 'gen_ai.chat',
      name: 'Gemma Diff Partitioning Agent',
      attributes: { 'gen_ai.request.model': 'gemma3:12b' },
    },
    async (span) => {
      const response = await ollama.chat({
        model: 'gemma3:12b',
        format: 'json',
        messages: [
          {
            role: 'system',
            content:
              'You are an autonomous Git hygiene agent. Partition raw git diffs into atomic, logical Conventional Commits and generate a concise 3-bullet standup summary. Output strict JSON.',
          },
          { role: 'user', content: rawDiffs },
        ],
      });

      span.setAttribute('gen_ai.usage.input_tokens', response.prompt_eval_count ?? 0);
      span.setAttribute('gen_ai.usage.output_tokens', response.eval_count ?? 0);

      return JSON.parse(response.message.content);
    }
  );
}

How I Built It

Hypnos is designed around a local-first, resilient systems architecture:

Open-Weight Inference (Gemma via Ollama): At the core of Hypnos is Google's open-weight Gemma model (gemma3:12b) running locally via Ollama with strict JSON schema constraints. I built a custom Two-Pass Agent loop:
- Pass 1 (The Classifier): Takes AST-parsed diff chunks and clusters related line modifications across files by semantic intent—separating a quick UI styling tweak from a core backend state change that happened in the same late-night coding session.
- Pass 2 (The Scribe): Generates the Conventional Commit message (feat, fix, refactor, docs), updates markdown documentation tables, and summarizes the engineering impact in plain English.
Durable Execution (Temporal): Background daemons on laptops are notoriously fragile—OS sleep states, battery throttling, or locked git index files (index.lock) easily kill standard cron jobs. Wrapping the agent pipeline in a Temporal workflow guarantees that if the machine suspends halfway through local inference, the workflow pauses and resumes cleanly the moment the CPU wakes up.
Observability (Sentry Agent Tracing): Local open-weight models can occasionally hallucinate hunk line numbers or stall on massive lockfile diffs. I integrated Sentry Agent Tracing across every tool call and LLM span to inspect token generation speed (tokens/sec), catch malformed JSON patches, and profile latency across the pipeline.
Voice Synthesis (ElevenLabs): Because reading terminal logs before coffee violates the spirit of slothfulness, Hypnos pipes the final standup script to the ElevenLabs API (eleven_turbo_v2_5) to generate a crisp audio summary triggered via hypnos morning.
Frontend & TUI: Built with TypeScript, Node.js, simple-git, and a high-contrast obsidian terminal UI paired with a Next.js trace dashboard hosted on a .tech domain.

Why Does Open Innovation Matter?

For a tool like Hypnos, open-weight models and local inference aren't just a nice-to-have—they are the only reason this project can exist.

Zero Source Code Exfiltration: Hypnos reads your raw, uncommitted source code, .env.example diffs, and local shell history. Most developers (and virtually all enterprises) cannot pipe proprietary uncommitted diffs to a closed cloud LLM API every night without violating security compliance. Running Gemma locally means your code never leaves 127.0.0.1.
Zero Idle Tax ($0.00/night): An autonomous daemon that runs every single night across multiple repositories would rack up continuous API token bills on closed frontier models—especially when parsing multi-thousand-line diffs. With open weights running on local silicon, Hypnos utilizes idle overnight GPU/NPU cycles for free. Set it up once, and never pay for it again.
Offline & Airplane Mode Ready: Whether you're hacking on a train, in a campus hostel during a Wi-Fi outage, or on a flight, your local git hygiene agent keeps working without an internet connection.
Deterministic Model Pinning: Closed APIs silently update weights and deprecate snapshots, breaking brittle git-patch formatting prompts overnight. Open weights let us lock the exact quantized GGUF hash so our diff parser never regresses.

My Agent Session

During development, I used an agentic workflow to iterate on the git apply --cached patch generator—specifically debugging edge cases where adjacent modified lines in the same file needed to be split into two separate logical commits.

The Lazy Payoff

I ran Hypnos on my own workspace over the last 4 days while building this project:

Before Hypnos: ~15–20 minutes every morning spent running git diff, trying to remember why I modified a utility helper at 2:00 AM, staging hunks manually with git add -p, and typing up standup notes.
With Hypnos: 0 minutes. Every morning, I ran hypnos morning, listened to a 40-second audio recap while making coffee, inspected the pre-staged shadow branch with git log --stat, and fast-forwarded it into main with a single command (hypnos apply).

Over a full year (~250 coding days), saving 15 minutes of daily git and standup housekeeping reclaims 62.5 hours of pure engineering laziness.

Prize Categories

Best Use of Gemma: Uses local Gemma open-weight models (gemma3:12b via Ollama) as the core reasoning engine to classify AST diffs, generate semantic commits, and draft standup summaries completely offline.
Best Use of Temporal: Orchestrates the entire multi-step overnight agent pipeline as a fault-tolerant Temporal workflow that survives OS sleep cycles and git lockfile collisions.
Best Use of Sentry Agent Tracing: Instruments every local LLM call, prompt token count, latency span, and git tool execution with Sentry Agent Tracing to monitor throughput and debug diff-hunk boundary errors.
Best Use of ElevenLabs: Turns the overnight git activity and changelog into a hands-free morning audio standup briefing (eleven_turbo_v2_5).
Best Use of a .tech Domain: Deployed the interactive trace explorer and documentation portal on a custom .tech domain claimed via Hacktoberfest.

CAUSEWEFT: What happens when your business information contradicts itself?

Shikhar Verma — Mon, 19 Oct 2026 03:30:57 +0000

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

What I Built

Your business changed. Did every document get the memo?

Imagine you're a freelancer running a small web design agency.

You update the price of your starter package from ₹15,000 to ₹18,000. You change your pricing page, update your spreadsheet, and move on.

Except your old price is still sitting in a PDF proposal template. Your FAQ still mentions the old package. An outdated quotation is waiting in your drafts.

A few weeks later, you discover the problem when a client points it out.

The frustrating part? Your information wasn't missing. It was simply inconsistent.

That's the problem I'm tackling with CAUSEWEFT: an open-source AI tool that helps small businesses discover information drift across documents and understand what needs to change when an important business fact changes.

The idea is simple:

Change one fact. Find its ripple effects. Fix them with evidence.

How CAUSEWEFT works

CAUSEWEFT is designed around four steps:

1. Gather the scattered information

Import business documents such as pricing sheets, proposals, product catalogs, FAQs, policies, and website content.

2. Extract facts, not just summaries

Instead of only summarizing a document, the AI extracts structured claims: what a product costs, what a service includes, when a deadline applies, and which source supports each claim.

3. Find information drift

CAUSEWEFT compares related claims across different sources. It can flag conflicting prices, inconsistent service descriptions, outdated dates, and other discrepancies.

Each finding should point back to the evidence behind it. An uncertain relationship is marked for review instead of being presented as a confirmed contradiction.

4. Propose a coordinated repair

When a fact changes, CAUSEWEFT identifies potentially affected documents and prepares suggested edits.

The user reviews and approves the changes. The system then checks whether the inconsistencies have actually been resolved.

The goal isn't to let AI rewrite a business's records without supervision. It's to make hidden inconsistencies visible and the work of fixing them much less tedious.

Who would pay for this?

I'm starting with freelancers, small agencies, independent consultants, and online sellers.

These businesses often maintain important information across documents and applications without having a dedicated operations team. A single outdated price, incorrect policy, or conflicting promise can mean lost revenue, avoidable disputes, or wasted time.

CAUSEWEFT could eventually become a paid tool for keeping that information consistent, with a free open-source core and optional paid integrations or team features.

For the first version, I'm focusing on one narrow workflow: upload a small collection of business documents, identify conflicting facts, inspect the source evidence, and generate a reviewable repair plan.

Demo

Try the working prototype: [INSERT DEPLOYED DEMO URL]

Watch the walkthrough: [INSERT SHORT DEMO VIDEO URL]

The demo should use a sample business with a changed service price and several deliberately outdated references. The viewer should be able to follow the chain from the original fact to the detected inconsistencies and the proposed repairs.

Code

GitHub repository: [INSERT PUBLIC GITHUB REPOSITORY URL]

The repository will include the application code, setup instructions, sample data, and instructions for running the model locally.

Contributions that improve document parsers, claim extraction, contradiction detection, and validation rules will be especially valuable.

How I Built It

CAUSEWEFT is designed as a combination of open-weight AI and deterministic validation rather than a chatbot wrapped around document uploads.

The planned architecture has four main components:

Document ingestion: Python-based parsers extract text and relevant metadata from supported files.
AI-powered claim extraction: Google's open-weight Gemma model, served locally through Ollama, converts unstructured content into structured claims and identifies potentially related facts.
Evidence and consistency engine: A structured local store preserves extracted claims, their source locations, and relationships. Deterministic checks handle comparisons such as prices and dates, while ambiguous semantic conflicts are flagged for review.
Review and repair workflow: A lightweight web interface presents each discrepancy, the supporting evidence, and a proposed correction. Changes require approval before they are applied.

The key architectural decision is to keep fact extraction separate from verification.

An LLM can suggest that two statements conflict, but the application should preserve the original evidence, validate what it can deterministically, and distinguish confirmed discrepancies from uncertain interpretations.

The first implementation will focus on supported document formats and a small set of testable inconsistency types rather than pretending to understand every kind of business information.

[UPDATE THIS SECTION TO MATCH THE ACTUAL IMPLEMENTATION BEFORE PUBLISHING. Retain Gemma and Ollama only if they are genuinely integrated into the working project.]

Why Does Open Innovation Matter?

Business documents often contain sensitive information: customer details, quotations, contracts, pricing, and internal policies.

I want CAUSEWEFT to make local AI a practical option rather than forcing users to send every document to a proprietary API.

Using an open-weight model gives the project room to run inference locally, inspect and modify the extraction pipeline, experiment with different models, and adapt prompts and validation strategies for different industries.

It also makes the project more extensible. Someone building an invoicing application could contribute a connector. Someone working with product catalogs could add specialized consistency rules. A freelancer could adapt the workflow to their own documents.

The model is only one part of the system. The open-source value comes from making the full process—claim extraction, evidence tracking, validation, and repair—available for people to inspect, test, and improve.

My goal is to make CAUSEWEFT useful even when users don't trust an AI model to make decisions on their behalf.

AI should help discover the problem. Evidence should explain it. The user should remain in control of the fix.

Prize Categories

Best Use of Gemma — [KEEP ONLY IF GEMMA IS MEANINGFULLY USED IN THE IMPLEMENTED PROJECT.]

What's Next?

I want to expand CAUSEWEFT beyond detecting outdated prices.

The longer-term direction is a reusable consistency engine that can reason about relationships across different information sources, identify the consequences of a change, and help users coordinate safe updates.

For now, the priority is much more concrete: prove that CAUSEWEFT can detect real inconsistencies in a realistic set of business documents, show exactly why each finding was raised, and help the user fix them without introducing new errors.

If you've ever changed something in one place only to discover an outdated version somewhere else, that's the problem I'm building this for.

I'd especially love feedback on which kinds of information drift cost small businesses the most time or money.

How We Built RippleCI: Graph-Native Predictive CI & AI Agent Intelligence with FalkorDB

Shikhar Verma — Sun, 18 Oct 2026 18:07:14 +0000

Running a 45-minute CI pipeline for a three-line bugfix is modern engineering purgatory.

Every developer has lived this: you change a single internal helper function, push a commit, and wait nearly an hour for hundreds of irrelevant test suites to execute before your PR can merge.

To escape this, teams often turn to naïve file-path heuristics (only running test_<filename>.py). But that introduces a catastrophic blindspot: when a subtle change in auth/tokens.py breaks an indirect consumer three hops away in billing/handlers.py, file-matching heuristics miss it completely.

In our empirical studies, file-matching heuristics miss over 33% of real-world regression faults.

We built RippleCI to solve this: a graph-native predictive CI engine, CLI devtool, and Model Context Protocol (MCP) server powered by FalkorDB.

Here is how we used FalkorDB’s GraphBLAS linear algebra engine to compute multi-hop change blast radiuses in under 15ms, cut CI runtimes by 68%, and mathematically guarantee 100% fault recall.

🧩 The Core Insight: Code is a Graph, Not a Flat Filesystem

Files and directories are an artifact of human filesystem organization. Execution flows don’t care about folder boundaries—they care about symbols, call chains, inheritance hierarchies, and test assertions.

Instead of treating a codebase as raw text lines, RippleCI parses Python source files into an Abstract Syntax Tree (AST) property graph:

┌──────────────┐     ┌────────────────┐     ┌──────────────┐     ┌────────────────┐     ┌──────────────┐
│  Git Commit  │ ──► │ AST Dependency │ ──► │  Multi-Hop   │ ──► │ ML Regression  │ ──► │ Bounded AST  │
│  Diff Lines  │     │  FalkorDB Sync │     │ Blast Radius │     │ Prioritization │     │ Verification │
└──────────────┘     └────────────────┘     └──────────────┘     └────────────────┘     └──────────────┘

The FalkorDB Property Graph Schema

Inside FalkorDB, we model the software graph with fine-grained granularity:

Nodes:
- (:File {id, path, lines, churn_score})
- (:Class {id, name, line_start, line_end})
- (:Function {id, name, is_async, line_start, line_end})
- (:TestCase {id, name, historical_duration_ms, flake_rate})
Edges:
- (:File)-[:DEFINES]->(:Class|Function)
- (:Function)-[:CALLS]->(:Function)
- (:File)-[:IMPORTS]->(:File)
- (:TestCase)-[:TESTS]->(:Function|Class)

⚡ Why FalkorDB Was Non-Negotiable

When a Git commit modifies 10 lines of code, computing what could break requires tracing callers recursively upstream and downstream.

Relational SQL (Postgres / MySQL): Collapses under recursive JOIN cascades and Common Table Expressions (CTEs) when traversing arbitrary depths.
Vector Databases: Non-deterministic. Embeddings approximate semantic similarity, but they cannot tell you whether function $A$ strictly invokes function $B$.
Traditional Graph Databases (Neo4j): Carry heavy JVM runtimes, slow cold-boot times, and high memory footprints ill-suited for developer CLI tools.

FalkorDB solved every single constraint:

GraphBLAS Matrix Operations: FalkorDB represents adjacency graphs as sparse matrices and translates Cypher path queries into linear algebra matrix multiplications. Multi-hop reachability queries execute in single-digit milliseconds (< 15ms).
Redis Protocol Simplicity: With zero JVM overhead, FalkorDB runs as a lightweight service accessible via standard Redis wire protocol (falkordb-py).
Declarative Cypher: OpenCypher lets us express complex graph reachability and shortest-path queries in 5 lines of code.

🔍 Tracing the 3-Hop Blast Radius in Sub-15ms

When a Git diff is analyzed, RippleCI maps changed line numbers to specific AST Symbol IDs. It then queries FalkorDB with a native variable-length Cypher traversal:

MATCH (changed:Symbol {id: $symbol_id})
MATCH path = (t:TestCase)-[:TESTS|CALLS*1..3]->(changed)
RETURN 
    t.id AS test_id,
    t.name AS test_name,
    t.historical_duration_ms AS duration_ms,
    min(length(path)) AS graph_distance
ORDER BY graph_distance ASC, duration_ms ASC

In under 15ms, FalkorDB extracts:

Hop 1: Tests directly executing the changed function.
Hop 2: Tests covering upstream functions that invoke the changed function.
Hop 3: Transitive integration tests that touch downstream services dependent on the altered interface.

🎯 Multi-Signal Test Prioritization

Knowing which tests could fail is step one. Step two is scheduling them under tight CI budgets (e.g. "Give me the safest test plan that finishes in under 180 seconds").

RippleCI scores each candidate test using a multi-signal Pareto-optimal ranker:

$$S(t) = w_1 \cdot \frac{1}{d(t, \Delta)} + w_2 \cdot C(\text{file}) + w_3 \cdot \frac{1}{\log(T(t) + 1)} - w_4 \cdot F(t)$$

Where:

$d(t, \Delta)$ is the shortest topological graph distance computed by FalkorDB.
$C(\text{file})$ is the Git churn recency (frequently edited code has higher bug density).
$T(t)$ is the historical execution runtime (faster tests yield earlier failure signals).
$F(t)$ is the test flakiness penalty (prevents noisy intermittent failures).

🧪 Counterfactual Mutation Verification

How can we be 100% sure the prioritized test suite will actually catch real regressions? We test the tests.

RippleCI features a Counterfactual AST Mutation Engine. Before greenlighting a build, it injects bounded AST mutations into the modified code:

Flipping comparison operators (> to <=, == to !=)
Mutating return values (True to False, None)
Boundary condition shifts (+ 1, - 1)

It executes the selected test plan against the mutated code. If 100% of the synthesized mutants are killed, the safety of the release is empirically proven.

🤖 Direct Agentic Integration: Model Context Protocol (MCP)

AI coding agents (Cursor, Claude Desktop, Windsurf) are writing millions of lines of code. But AI agents suffer from a fatal weakness: context blindness. An agent edits a file without understanding what it breaks across the rest of the repository.

To solve this, we built a native MCP Server into RippleCI (ripple mcp serve).

With a single terminal command, developers can connect RippleCI to their local AI editor:

# Auto-detects and configures Cursor IDE
ripple connect cursor

# Or Claude Desktop
ripple connect claude

AI agents gain 7 specialized tools directly inside their context window:

ripple_trace_blast_radius: Traces downstream dependencies before making edits.
ripple_prioritize_tests: Recommends minimal verification tests for generated code.
ripple_verify_mutations: Tests whether AI-generated tests are resilient or superficial.
ripple_query_graph: Allows the agent to query the FalkorDB graph using raw Cypher.

📊 Empirical Benchmarks: 5,000+ Synthetic Mutants

We benchmarked RippleCI against real-world Python codebases injected with over 5,000 synthetic mutation faults:

Strategy	CI Test Duration	Mutation Fault Recall	Escaped Bug Rate
Full Suite Execution	48m 12s (100% budget)	100.0%	0.0%
Naïve File Heuristic	3m 24s (7% budget)	66.7%	33.3% (CRITICAL RISK)
RippleCI (FalkorDB)	15m 18s (31.7% budget)	100.0%	0.0% (ZERO ESCAPES)

Key Result: RippleCI achieved 100% fault recall while slashing CI execution duration by 68.3%.

🚀 Try It on Your Own Codebase

RippleCI is open source and ready to run locally or in your CI pipeline:

# 1. Clone repository
git clone https://github.com/Shikhyy/RippleCI.git
cd RippleCI

# 2. Run standalone diagnostics (Zero package install required)
./ripple doctor

# 3. Index your repository into FalkorDB
./ripple index

# 4. Connect to Cursor or Claude Desktop in one command
./ripple connect cursor

What We Learned Building with FalkorDB

Building RippleCI proved that GraphBLAS-powered graph engines are the future of developer tooling and agentic workflows. The ability to run millisecond Cypher queries directly inside a developer's CLI or an agent's reasoning loop transforms static analysis from a slow batch job into an instantaneous, interactive feedback cycle.

Check out the code, star the repository, and try it today:
👉 GitHub: https://github.com/Shikhyy/RippleCI

ripple-ci.vercel.app

Doorstep: A Local AI That Plans Your Walk, Then Tells You to Leave

Shikhar Verma — Sun, 11 Oct 2026 18:16:38 +0000

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

What I Built

Doorstep is an agent that plans your walk and then tells you to close the laptop.

You ask one question, like "Where should I go before the light goes?" Doorstep checks sunset time, cloud cover, air quality, and recent wildlife sightings near you. It picks one spot within walking distance, draws the route on an open map, and explains the choice in a sentence. Then it shows a QR code. You scan it, shut the laptop, and go.

The idea came from God's Eye View, a browser spy-satellite simulator built on real public data. It's a brilliant way to lose an afternoon watching the planet from a screen. I wanted to point the same idea the other way: use live data from above for two minutes, then spend the evening on the ground.

The number I care about is minutes planning on screen versus minutes outside. Across 6 outings, I spent about 2 minutes on screen per walk and about 45 minutes outside, roughly 1 to 22.

It's for anyone who loses the afternoon to a desk and wants a push out the door, without sending their location and daily routine to a cloud service.

Demo

Question → conditions check → one pick with a reason → route on the map → QR code → phone → outside.

Code

Shikhyy / doorstep

How I Built It

The open pieces

Model: Gemma, run locally through Ollama.
Map: MapLibre GL JS with OpenStreetMap data, so there's no map API key and no account.
Routing: the open-source OSRM routing engine for walking directions.
Data: Open-Meteo for weather, sunset, and air quality, plus iNaturalist's public API for recent sightings.

The decision that mattered: the model doesn't make the choice.
Small local models get unreliable when they have many tools and a vague job. So I gave the agent five boring tools:

get_conditions: weather, sunset time, air quality
find_sightings: recent observations near a point
score_spots: ranks candidate spots
plan_route: walking route on the map
make_handoff: the QR code and route sheet

The actual decision lives in a plain weighted score covering distance, light, cloud cover, air quality, and recent sightings. Gemma's job is to call the tools in order and explain the pick in a friendly sentence. That made results repeatable, and a bad model response could never send me somewhere silly. When the model failed, a deterministic fallback still produced a pick.

The handoff to the phone
The app runs on my laptop, so a link to it is useless on a phone. Instead Doorstep generates a one-page static route sheet (the route, the reason, the sunset time) behind a QR code. It works in airplane mode, which matters on a trail with no signal.

Measuring honestly
I tracked my screen time with ActivityWatch, an open-source tracker that runs locally, so the ratio above comes from real data rather than guesses.

The Field Log

Outing	Screen min	Outside min	Did the prediction hold?	What went wrong
1. Riverside loop, golden hour	3	50	Light was great, no kingfisher	QR sheet text too small in sunlight
2. Cloudy evening	2	25	It warned of cloud, I went anyway	It was right, the sky was flat
3. Park near work	2	40	Heron predicted, and seen	None
4. Hill viewpoint	2	60	Best sunset of the week	Route was longer than I expected

What I learned

The outing I wouldn't have taken: the hill viewpoint. I'd never have picked it myself, and it was the best walk of the week.
The prediction that missed: "recent sighting" does not mean "you'll see it." I changed the wording from "likely" to "worth a look."
The annoying part: my first route sheet was designed for a laptop, not a phone in glare. I rebuilt it with large text and high contrast.

Why Does Open Innovation Matter?

My routine stayed mine. An agent that knows where I walk and when I leave my desk holds a record of my life. Running Gemma locally meant none of it left my machine.

It costs nothing per use. Every piece is open or keyless, and the model runs on hardware I already own, so I could ask it questions all day without watching a bill.

I could swap and compare. The model sits behind my own tools, so I ran identical conditions through two Gemma sizes and compared the explanations.

Where closed would have been better:  I accepted that trade because my location data stayed on my own machine.

My Agent Session

Prize Categories

Best Use of Gemma: Gemma runs locally and does all of the agent's reasoning.

Precedent: an agent that knows which Solidity security advice has been overruled

Shikhar Verma — Mon, 05 Oct 2026 05:34:05 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Security advice for Solidity goes stale, and stale advice in this field is expensive. Docs, EIPs, audit reports and old blog posts contradict each other, and much of that disagreement is just time passing: the compiler and the EVM changed underneath the advice. A keyword search or a plain LLM returns the outdated answer with full confidence, because both only see text, not the fact that one piece of text replaced another for a given version.

Precedent treats security guidance like case law. Every claim carries a date and a compiler-version scope, and newer rulings overrule older ones. Ask "is transfer() still safe on 0.8.28?" and you get:

a ruling for your exact version,
a docket: what the older advice said (struck through) and what overruled it, each linked to its original source,
a contested status when sources genuinely disagree and nothing controls, instead of a guess.

It covers [[5]] patterns in depth: [[LIST, e.g. ETH sends with transfer/send, selfdestruct, SafeMath, ERC-4626 inflation attacks, and tx.origin as a no-change control]]. The control case matters: it checks that the agent doesn't invent drift where none exists.

Precedent summarizes published sources. It is not an audit, and every verdict says so.

Who it's for: Solidity developers who need a citable answer for their compiler version, reviewers doing quick triage, and hackathon builders who don't want to ship a pattern that was deprecated last year.

Demo

Live: [[DEPLOYED URL]]

[[VIDEO EMBED OR GIF: a verdict resolving, with overruled claims struck through and the controlling claim highlighted]]

Try these questions [[replace with the questions that work well in your build]]:

[[Question 1: a stale-trap pattern with a version]]
[[Question 2: a genuinely contested pattern]]
[[Question 3: the stable control, which should show no drift]]

Code

[[GITHUB REPO URL]]

How It Works

Question + compiler version
        │
        ▼
  Precedent agent (Vercel AI SDK, multi-step tool loop)
        │
        ├──► Context MCP endpoint A (Knowledge Base)
        │       what do the sources say? where do they conflict?
        │
        ├──► Context MCP endpoint B (dataset, GROQ)
        │       verified claims in scope for this version,
        │       with supersession and sources
        ▼
  Verdict: status, stance, claim IDs only
        │
        ▼
  UI fetches claim text, dates, URLs from Sanity by ID
        │
        ▼
  Ruling card + docket timeline

Identify the pattern and version from the question and the version selector. If no version is given, the agent assumes the latest in the dataset and says so.
Read the sources through the Knowledge Base endpoint to see what they say and where they conflict.
Query the claims through the GROQ endpoint: the verified claims whose version range covers the version, plus which claims supersede which.
Resolve. Controlling claims are in-scope claims that no other in-scope claim supersedes. If their stances agree, the status is settled. If they differ, it's contested and no winner is picked. If none exist, it's out of scope.
Return IDs, not prose. The agent emits a structured verdict containing claim IDs. The UI then loads the text, dates and URLs from Sanity.

Step 5 is deliberate. The model never writes a source, a URL or a date, so it can't fabricate a citation. The API route also re-checks that every ID exists and recomputes the status itself; on a mismatch the user sees an error, not a wrong answer.

How I Used Sanity

The agent reads Sanity through two Context MCP endpoints, because they do different jobs. An endpoint backed by a Knowledge Base serves Knowledge Base mode, and an endpoint backed by a dataset serves GROQ mode, so I use one of each.

Endpoint A: Knowledge Base

I pointed Sanity Context at [[N]] source documents: [[e.g. Solidity docs and changelogs, EIPs, OpenZeppelin docs and release notes, N public audit reports]]. Sanity distills them into a navigable Knowledge Base where each entry stays linked to the source it came from, and where conflicting claims surface side by side with their sources. [[Add what you saw: how many entries it produced, an example of a contradiction it surfaced on its own, and any decision you made about a conflict.]]

I stayed well within the beta's ~150-document budget on purpose: a small, curated set of primary sources beats a large noisy one.

Endpoint B: the dataset, in GROQ mode

Knowledge Base mode can't express "this claim applies only to 0.8.x and was replaced by that one", so I modeled that as structured content:

Type	What it holds
`pattern`	A named pattern, a short summary, and aliases
`source`	Title, URL, publisher, kind (docs, EIP, audit, release notes, blog), publish date, license
`claim`	A paraphrased statement (280 characters max), a stance (safe, unsafe, deprecated, mixed), `fromVersion` / `toVersion`, `supersedes[]`, `contradicts[]`, and a confidence flag

Compiler versions are stored as numbers (for example 0.8.28 becomes 8028) so GROQ can compare them. Only claims I had checked by hand against the primary source are marked verified, and only those are used. [[N]] claims across [[5]] patterns.

The ruling is computed, not stored. This query returns every in-scope claim and which other claims supersede it:

*[_type == "claim" && confidence == "verified" && pattern._ref == $patternId
  && (!defined(fromVersion) || fromVersion <= $v)
  && (!defined(toVersion)   || toVersion   >= $v)]{
    _id, statement, stance,
    "source": source->{title, url, publishedAt},
    "supersededBy": *[_type == "claim" && ^._id in supersedes[]._ref]._id
  }

The controlling claims are the ones with no in-scope claim in supersededBy. Because the ruling is derived, fixing one claim or adding a newer one changes every affected answer immediately, with no re-curation.

Why structure matters here

Keyword search finds passages that mention a pattern. It has no way to know that one passage replaced another for a specific compiler version. The supersedes chain and the version scope are the content model, and the agent's correctness depends on them. The Knowledge Base shows what the sources say; the dataset says which statement controls.

Tools the agent used

[[List the actual tool names each endpoint exposed, discovered at runtime, and what the agent used each one for. Example format: tool_name (endpoint A): used to ... ]]

The Context endpoints are read-only, so the agent can't change the content. Claims are seeded by a script and edited in Studio.

Does It Actually Beat the Alternatives?

I wrote [[N]] "Stale-Trap" questions where the obvious answer is outdated: [[N]] stale traps, [[N]] genuinely contested cases, [[N]] stable controls, and [[N]] out-of-scope. I labeled the ground truth by hand from the verified claims, then ran three systems with the same model, same output schema, and [[3]] runs per question:

A: keyword search over the raw sources (top passages given to the model, no tools)
B: Knowledge Base only (Endpoint A without the claims layer)
C: Precedent (both endpoints)

Because every system returns the same structured verdict, grading is deterministic rather than a model judging a model: an answer is stale if it matches a superseded claim, and a citation is correct if it includes a controlling claim.

System	Stale-answer rate (lower is better)	Cites the controlling source	Says "contested" when it should
A: keyword search	[[X%]]	[[X%]]	[[X%]]
B: Knowledge Base only	[[X%]]	[[X%]]	[[X%]]
C: Precedent	[[X%]]	[[X%]]	[[X%]]

[[Two or three sentences in your own words: which system did best, where B failed and why, and one specific question that shows the difference.]]

Design Decisions

IDs only from the model. Prevents fabricated citations.
Contested is a first-class outcome. A security tool that picks a winner between genuinely conflicting sources is worse than one that says so.
Verified claims only. Unreviewed claims never reach the ruling path.
No fallback to model memory. If the endpoints fail, the user gets an error, not a guess from the model's training data.
Small and deep. [[5]] patterns done properly beat 50 done loosely.
A control case. tx.origin has no drift, so a correct agent should report a stable answer.

Guardrails

Precedent never writes exploit code and never audits user code. Every verdict shows "Summarizes published sources. Not an audit." Claims are my paraphrases with links to the originals, and I used permissively licensed sources where possible.

Challenges and What I Learned

[[Write 3 to 4 honest items from your actual build. Prompts to answer: What broke first? What did the Knowledge Base do better or worse than expected? Where did the model misread supersession, and how did you fix it? How long did verifying claims by hand take, and what did you find?]]

Limits, Honestly

[[N]] questions is a small sample, so treat the percentages as indicative, not conclusive.
Only [[5]] patterns are covered.
Claims are paraphrased and hand-verified, so errors are possible. Check the linked sources before relying on a ruling.
[[Knowledge Bases are in beta; mention anything that didn't work as expected.]]

What's Next

More patterns and more eras of the EVM
Paste a code snippet and detect which patterns it touches
A compare mode: the same pattern across two compiler versions
[[Anything else you genuinely plan]]

Built with: Next.js, TypeScript, Vercel AI SDK, Sanity Studio and Sanity Context, [[model name and provider]], deployed on [[Vercel]], with Google Antigravity as the coding environment. (keep only if true)

Sanity Project Details

Project ID: [[YOUR SANITY PROJECT ID]] (dataset: [[DATASET NAME]])
[[OR: public dataset URL, and confirm the dataset is public]]

First Light: The Privacy-First Morning Brief & Radar for Hackathon Hunters

Shikhar Verma — Mon, 05 Oct 2026 05:18:31 +0000

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

What I Built

My friend Anant is a machine learning engineer, backend enthusiast, and avid hackathon hunter. Between tracking global tech affairs, web3 releases, ML benchmarks, hackathon registration windows, and daily personal tasks, his mornings were overwhelmed by a storm of notification badges, spam newsletters, and calendar alerts. He needed a way to wake up, glance at his phone, and see only the top 5 things that actually matter to him today—without shipping his entire personal calendar, private to-do list, and unreleased project ideas to a third-party cloud LLM.
To solve this, I built First Light: a privacy-first, 100% locally-run morning intelligence brief and hackathon radar. Every morning at 6:30 AM, First Light:

Gathers events from local ICS calendars, markdown to-do files, RSS news feeds, and a curated hackathon radar (DEV, Devpost, MLH, Kaggle, and Web3/ETHGlobal).
Mathematically calculates urgency windows and deduplicates cross-posted hackathons across platforms.
Uses a local open-weight model (Google Gemma 2B) to synthesize the noise into a concise, prioritized 5-bullet morning brief tailored to Anant's profile.
Delivers a native, lock-screen Web Push notification to his phone via a self-hosted PWA, complete with an interactive dashboard and an ElevenLabs audio briefing. > "Waking up to just 5 bullet points that actually matter to me—instead of 40 noisy emails and calendar popups—has completely changed my mornings. And knowing it's all running locally on my own machine makes me trust it enough to feed it my real daily to-do list." — Anant

Demo

Video Walkthrough: Watch the Full Demo on Google Drive
Live Interface & Features:
- 🔔 Native PWA Web Push: Lock-screen notification delivered directly to mobile without third-party messaging apps.
- 🌅 Dawn-Themed Dashboard: Frosted glass UI displaying the AI briefing, deadline countdowns, and urgency meters.
- 🎧 First Light Audio: On-demand text-to-speech briefing player powered by ElevenLabs.
- 🎯 Hackathon Radar: Filterable list of competitions with direct registration links and AI "Should I enter?" verdicts.
- ✅ Interactive To-Dos: Real-time task completion synced directly to the local SQLite database.

Code

Shikhyy / firstlight

First Light 🌅

A privacy-first, locally-run morning brief and hackathon radar. First Light cuts through the noise by summarizing your calendar, markdown to-do lists, RSS feeds, and upcoming hackathons into a single, personalized push notification every morning at 6:30 AM.

All data fetching, deduplication, and AI summarization (using gemma:2b via Ollama) runs 100% locally on your machine. Your schedule never leaves your device.

Features

Hackathon Radar: Aggregates and deduplicates hackathons from DEV, Devpost, MLH, Kaggle, and Web3 sources.
Local AI Summarization: Uses Ollama to read your top events and tell you why they matter based on your configured interests.
Privacy-First: No cloud APIs for your personal data.
PWA Web Push: Sends a native lock-screen notification to your phone without relying on third-party apps.
Deterministic Math: LLMs are bad at math, so all deadline urgency and countdowns ("closes in 13h") are calculated entirely in Python before…

View on GitHub

Repository URL: https://github.com/Shikhyy/firstlight

How I Built It

First Light is engineered in Python with an installable CLI (pip install -e .), backed by SQLite and a lightweight Flask PWA with a custom Service Worker.

1. Open-Source AI Architecture

Local-First Core: We run Google's Gemma 2B (gemma:2b) locally via Ollama. It runs on consumer hardware (such as an Apple Silicon Mac) with near-zero latency and zero operational cost.
Pydantic Structured Outputs: The pipeline enforces structured JSON schema validation (BriefSummary) directly on the model's output to guarantee schema compliance.
Graceful Cloud Fallbacks: For cloud deployments where local Ollama is inaccessible, First Light seamlessly falls back to Hugging Face Serverless Inference (google/gemma-2-2b-it) or Groq, keeping the architecture strictly on open Gemma models.

2. The "Code Does Dates, AI Judges" Architecture

LLMs frequently hallucinate calendar math and relative dates. First Light enforces a strict architectural separation:

Deterministic Engine (Python): Date parsing, deadline countdowns (e.g., "closes in 13h"), urgency scores ([0.0, 1.0]), and deduplication (canonical URL normalization + RapidFuzz token matching) are calculated purely in Python.
Judgment Engine (Gemma): The LLM receives pre-calculated facts and strictly evaluates relevance: "Why does this matter to Shikhar based on his interests in ML, Web3, and Backend?"

3. Resilient Pipeline & Fail-Safe Delivery

Each data connector (DEV, Devpost, MLH, Kaggle, RSS, Calendar) is isolated in a try/except sandbox; if one scraper fails, the pipeline logs the error in a source_runs health table and continues uninterrupted.
If Ollama is offline or times out, the pipeline triggers a deterministic fallback generator, ensuring a morning brief is always delivered on time.

Why Does Open Innovation Matter?

Open innovation and open-weights models are essential for personal software like First Light:

Absolute Data Privacy: Your personal calendar, daily tasks, health appointments, and unreleased project ideas are deeply intimate data. Routing this stream through proprietary closed APIs means sharing your life with centralized corporate servers. With Gemma running locally, your personal data literally never leaves your device.
Zero Marginal Cost & No Rate Limits: Closed APIs charge per token, rate-limit automated jobs, and risk breaking changes. Open models allow automated morning pipelines and background cron jobs to run indefinitely for free.
Resilience & Vendor Independence: Open innovation ensures First Light will function offline, on an airplane, or years in the future without risk of API deprecation, subscription price hikes, or account suspensions.

My Agent Session

First Light was designed, implemented, and tested through an intensive pair-programming session using Google Antigravity:

Orchestrated the full project lifecycle: data connectors, SQLite schema design, fuzzy deduplication algorithms, Pydantic schema validation, and PWA Web Push implementation with VAPID crypto keys.
Iterated rapidly on prompt engineering and deterministic fallback logic to guarantee sub-minute pipeline execution on lightweight hardware.

Prize Categories

We are entering the following partner categories:

Gemma: Core intelligence is built entirely around Google's gemma:2b via Ollama for fast, local, privacy-first summarization, with Hugging Face Serverless integration for google/gemma-2-2b-it.
ElevenLabs: Integrated ElevenLabs Text-to-Speech into firstlight/delivery/audio.py to synthesize a natural, spoken morning briefing playable directly from the PWA dashboard.
Render: Provided a turnkey render.yaml Infrastructure-as-Code Blueprint with persistent disk mounts to deploy First Light as a cloud web service and automated cron worker with a single click.
Sentry Agent Tracing: Integrated sentry-sdk to trace pipeline transactions, monitor scraper reliability, and observe local LLM inference performance.