DEV Community: Rohith Matam

PawPace - Dog Days Walk Planner

Rohith Matam — Mon, 17 Aug 2026 03:22:55 +0000

What I Built

I built PawPace, a Dog Days walk planner for people who have ever looked at the sidewalk in August and wondered:

Is this still a walk, or is this a bad idea with a leash?

PawPace takes a simple dog profile and day profile:

air temperature
humidity
pavement feel
walk length
dog size
short-nosed breed sensitivity
senior, puppy, or recovering status
thick or dark coat

Then it turns those signals into a readable walk plan with a caution score, heat/paw/hydration risk bars, best time window, paw-check guidance, hydration reminders, and indoor enrichment backup ideas.

The one-line idea: most dog apps are cute; PawPace tries to prevent actual vet visits.

Demo

rohithmatham12.github.io

Source code: GitHub repository

Quick flow:

Why I Built It

Dog safety advice is often scattered across memory, weather apps, and “I think this pavement is fine” guesses.

I wanted to build something small enough for a weekend challenge but useful enough to imagine opening before an actual walk. PawPace does not replace care or veterinary advice. It just makes the safer choice easier in the moment: shorten the route, move the walk later, check the pavement, carry water, or swap the walk for enrichment when the day is too hot.

Real Weather Grounding

PawPace can use Open-Meteo to pull live local temperature, humidity, and UV index from a city name. No API key is required for weather.

Users can still adjust the sliders manually, but the live weather button keeps the planner from being only vibes. The score is grounded in actual conditions when the user wants that.

Google AI Mode

PawPace works fully without an API key using a rule-based planner.

I also added optional Google AI mode for the prize category. If a user pastes a Google AI Studio API key, PawPace sends the current dog/weather profile to Gemini and asks for a concise custom indoor enrichment plan. The key is not stored; it is only used in the browser session when the button is pressed.

There is also a Walk Report Card mode. It uses the same dog/weather profile to generate a short first-person note from the dog’s perspective, such as:

Today was a 6/10 walk day, buddy. Pavement felt spicy at 2pm, so let’s go after sunset. Also, I want a puzzle toy.

The report card can be downloaded as an image, so the playful part is shareable without taking away from the safety utility.

Screenshots

Desktop:

Planner:

Report card:

Mobile:

Technical Details

Vanilla HTML, CSS, and JavaScript
cute illustrated dog hero with subtle motion overlays
Open-Meteo geocoding and current weather lookup
rule-based scoring model for walk caution, paw risk, and hydration need
color-coded visual risk meter and risk breakdown bars
accessible form labels, fieldsets, live result region, and role="meter"
copyable walk plan
optional Google Generative Language API calls for enrichment and report cards
downloadable report-card image via canvas
responsive layout and prefers-reduced-motion support

What I Am Proud Of

The project tries to answer the challenge theme with something both playful and practical. It is about dogs, but it is also about the tiny responsibility of changing the plan when the day is not safe for them.

The source is MIT licensed.

Monsoon Rasam Window - CSS Art for DEV Frontend Challenge

Rohith Matam — Sun, 16 Aug 2026 18:55:13 +0000

A pure HTML and CSS comfort-food scene inspired by rasam rice on a rainy evening.

What I Built

This is my submission for the DEV Frontend Challenge: Comfort Food Edition,
CSS Art prompt.

I built Monsoon Rasam Window, a pure HTML and CSS illustration of a warm
bowl of rasam rice on a rainy evening. The scene has the pieces that make that
meal feel like home to me: pepper steam, curry leaves, tomato rasam, rice
grains, papad, pickle, a brass lamp, a banana leaf, and rain sliding down the
window.

I wanted the art to feel like the exact minute when the weather is loud outside
but the food in front of you is louder in a quieter way. Rasam rice is simple,
but the smell of pepper, tamarind, mustard seeds, curry leaves, and ghee can
change the whole room. This CSS scene is my attempt to draw that feeling.

Demo

rohithmatham12.github.io

Source code: GitHub repository

Screenshots

Desktop:

Mobile:

CSS Art Details

The main artwork is drawn with CSS:

bowl, rim, rasam surface, rice grains, tomatoes, pepper, and curry leaves
banana leaf, papad, pickle cup, spoon, and brass lamp
rainy window with moon glow, skyline silhouettes, glass reflections, falling rain, and sliding droplets
table details including a faint kolam pattern, scattered pepper, and curry sprig
CSS-only steam, rasam shimmer, rain, droplet, and flame animations
depth through radial gradients, inset shadows, layered positioning, and blur

I avoided SVG, canvas, and bitmap artwork for the illustration itself. The
screenshots are only for the post preview.

Accessibility Notes

Even though this is a visual CSS Art submission, I still wanted it to be usable
and understandable:

the artwork region has role="img" and descriptive text for screen readers
there is a skip link and visible focus state
text contrast was chosen for readability
animation respects prefers-reduced-motion
the page is responsive and keeps the artwork visible on mobile

Built With

HTML
CSS

The source is MIT licensed.

Rasam House: Comfort Food Landing Page for DEV Frontend Challenge

Rohith Matam — Sun, 16 Aug 2026 08:11:08 +0000

A food-memory inspired landing page for South Indian rasam rice, built with responsive HTML, CSS, and JavaScript.

What I Built

I translated a food memory into a functional, accessible landing page: a tiny rasam rice shop where the order changes based on the kind of day you had.

This is my submission for the DEV Frontend Challenge: Comfort Food Edition, Perfect Landing prompt.

I built Rasam House, a polished landing page for an imaginary comfort-food
spot centered around South Indian rasam rice. I wanted the page to feel like the
meal itself: warm, clear, unfussy, and quietly comforting.

For me, rasam rice is the food equivalent of someone lowering the volume on a
hard day. Before the bowl even reaches the table, the kitchen tells you what is
coming: mustard seeds crackling, curry leaves hitting hot ghee, pepper and
tamarind rising with the steam. It is simple food: rice, tomato, tamarind,
pepper, cumin, curry leaves, and a little ghee. But when it is hot and bright
and spooned into a bowl, it feels like being brought back to yourself. That is
the feeling I tried to turn into a landing page.

Instead of treating comfort food like a normal restaurant conversion page, I
tried to make the interaction feel emotional. The order panel asks what kind of
day it was -- rainy, long workday, or homesick -- and the bowl summary changes
around that mood. The reservation flow also has a small cooking moment before it
returns a pickup code, so the interface feels like something is being prepared
rather than instantly stamped out.

For the final polish, I made the order summary behave more like a tiny comfort
receipt: the bowl price, pickup time, comfort meter, and note all update from
the selected mood and bowl. After reserving, the card gives a pickup code, a
small steam animation, and a copyable pickup note.

The page includes:

a full-viewport food hero with soft steam animation
a conditional cooking loader for slower page loads
accessible navigation and skip link
menu cards
a short cooking ritual section
an interactive "build your bowl" order panel with mood-based copy
a comfort receipt with dynamic ETA, price, meter, and note
a pickup reservation state with progress, confirmation code, copy note, and reset
Open Graph and Twitter preview metadata
responsive mobile layout
WCAG 2.0 AA-focused accessibility checks and reduced-motion support
a no-JavaScript fallback note and MIT-licensed source

Live Demo + Source

Rasam House | Comfort Food Bowls

A warm, responsive comfort-food landing page for South Indian rasam rice bowls.

rohithmatham12.github.io

Source code: GitHub repository

Screenshots

Desktop:

Mobile:

Journey

The main design challenge was making the food memory feel present immediately
without turning the page into a generic restaurant template. I kept the layout
simple and let the dish lead the first screen. The interaction is intentionally
small: users can choose a bowl, spice level, garnish, and mood, and the order
summary updates the copy, ETA, total, and comfort meter without needing a
backend.

I also added a gentle steam animation in the hero, a conditional "Simmering
rasam" loader for slower loads, and a tiny confirmation moment after reserving
pickup. The motion is intentionally quiet because comfort food should not feel
like a slot machine. It should feel like something is patiently getting warm for
you.

I focused on frontend fundamentals:

semantic sections and form labels
visible focus states
readable color contrast
responsive grid changes
no layout overlap on narrow screens
lightweight JavaScript
reduced-motion support for the animated parts

Accessibility Notes

I designed the page around WCAG 2.0 AA fundamentals: perceivable content,
operable controls, understandable form behavior, and robust semantic HTML. The
page includes a skip link, semantic landmarks, a named navigation region,
labeled form controls, visible focus states, and no keyboard traps.

Dynamic order updates are announced with a polite live region. The comfort meter
uses role="meter" with aria-valuenow and aria-valuetext, the mobile menu
button updates aria-expanded, and the reservation card uses aria-busy while
the pickup state is processing.

The page also avoids relying on motion for meaning. Steam, loader, and progress
animations are decorative or supplemental, and the CSS respects
prefers-reduced-motion.

I also included a no-JavaScript fallback note. The core landing page content,
menu, and accessibility notes remain available without JavaScript; the bowl
builder and pickup receipt are progressive enhancements.

Built With

HTML
CSS
JavaScript

The source is MIT licensed.

The Redis URL That Leaked Its Own Password Into AI Agent Context

Rohith Matam — Thu, 16 Jul 2026 16:50:56 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

ContextOS is a context operating system for AI coding agents: it scans a repo, ranks the relevant files, and builds a context pack under a token budget for the agent to work from. Before anything goes into that pack, a secret detector redacts API keys, tokens, and credentials so agents never see live secrets, published on PyPI with 980+ automated tests and an 80% coverage gate.

Bug Fix or Performance Improvement

The database_url secret-detection pattern was supposed to catch connection strings like postgres://user:password@host and redact the password. It required at least one character for the username segment before it would match. That's fine for Postgres and MySQL, which always have a username. It's not fine for Redis, where the standard URI convention is redis://:password@host, no username at all, just a password. That empty-username shape silently failed the pattern's [^:@/\s]+ requirement, so detection was skipped entirely. The password sailed straight into the context pack, unredacted, ready to be handed to an LLM agent.

I found it while auditing detection coverage against real-world connection string formats rather than just the formats already covered by existing tests. The exact format Redis's own documentation recommends when only a password is configured didn't get caught.

Code

PR: Rohithmatham12/ContextOS#1

Before (username segment requires 1+ chars):

r"(?i)(?P<key>(?:postgres(?:ql)?|mysql|mongodb(?:\+srv)?|redis)"
r"://[^:@/\s]+:)"
r"(?P<value>[^@\s]{4,})"
r"(?=@)"

After (username segment allows 0+ chars):

r"(?i)(?P<key>(?:postgres(?:ql)?|mysql|mongodb(?:\+srv)?|redis)"
r"://[^:@/\s]*:)"
r"(?P<value>[^@\s]{4,})"
r"(?=@)"

Before, this stayed exactly as-is, verbatim, in the context pack handed to the agent:

REDIS_URL=redis://:supersecretpass123@cache.internal:6379/0

After:

REDIS_URL=redis://:[REDACTED_DB_PASSWORD]@cache.internal:6379/0

My Improvements

One character, + to *. That's the entire regex fix, but the real work was proving it was safe: I added two regression tests covering both detection and redaction for the empty-username case, then ran the full suite: 952 passed, 2 skipped, no regressions.

This isn't a cosmetic bug. ContextOS exists specifically to hand code to AI agents safely. A credential-detection gap in that exact pipeline defeats the entire point of the tool for any project using Redis, which is most projects doing caching or session storage. The fix closes the gap for every future scan, not just the one string I tested.

The bigger lesson: test coverage that only exercises the formats you thought to write tests for will always look complete. It wasn't a logic bug so much as a coverage gap disguised as a passing test suite. The fix that matters isn't just the regex change, it's making the URL-shape assumption ("usernames are always present") explicit in a code comment so the next person doesn't reintroduce it.

Preserving Resource Attributes During Span Flattening: A Trace Data Collision Story

Rohith Matam — Thu, 16 Jul 2026 15:53:26 +0000

Tracing pipelines flatten nested OpenTelemetry data (resource attributes + span attributes) into a single flat record before storage. Simple in theory. In OpenObserve, it was quietly losing data.

The bug: When a span's attributes and its resource's attributes shared the same key, for example service_name appearing in both places, the flattening step let the span-level value silently overwrite the resource-level one. Resource attributes are supposed to be the authoritative source (they describe the entity emitting the trace); span attributes are per-operation and shouldn't be able to clobber them. But the flattening code had no collision handling at all: last write wins, whoever happened to serialize second.

That's a correctness bug that's invisible until it isn't. Your dashboards keep working. Your queries keep returning results. They're just returning the wrong service_name for a subset of spans, and nothing errors to tell you.

Root cause: No collision-avoidance strategy existed between BLOCK_FIELDS and RESERVED_SPAN_FIELDS. Two separate reserved-field lists, no coordination between them, and no prefixing scheme to keep colliding keys distinguishable during flattening.

The fix:

Resource's canonical service.name stays authoritative as service_name, full stop.
Any other resource attribute that collides gets a service_attr_ prefix instead of silently competing.
Colliding span attributes get an attr_ prefix before flattening, so they land next to the resource value instead of over it.
Merged the two separate reserved-field lists into one unified list, closing the gap that let the collision happen in the first place.
Added regression tests specifically covering the three-way collision: resource service.name, resource name, and span service_name all present at once.

Impact: Trace data integrity restored for any pipeline where span and resource attributes overlap, which in practice is common (service metadata gets attached at both levels by different instrumentation layers). The unified reserved-field list also closes the door on the same class of bug reappearing with a different field name.

Lesson: Attribute collisions are a "works on the happy path" bug class. Nothing throws, nothing fails a test that only checks the non-colliding case. The fix wasn't just patching the one field, it was building a naming convention (canonical vs. prefixed) that makes the next collision safe by construction instead of requiring another one-off fix.

PR: openobserve/openobserve#12456 (merged)

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I built a "context OS" that stops AI agents from drowning in your codebase

Rohith Matam — Wed, 01 Jul 2026 03:44:37 +0000

The problem every AI coding session hits

You open Claude or Copilot, paste in your task, and immediately hit the wall: the codebase is too big. You either:

Dump everything and burn 80% of your context window on irrelevant files
Hand-pick files and miss the one import that breaks everything
Pay for a bigger context window and repeat the problem at scale

I got tired of this and built ContextOS — a local CLI that acts as an intelligent context layer between your repo and your AI agent.

What it does

pip install rm-contextos
cd your-project
contextos scan
contextos pack --task "add rate limiting to the auth endpoint" --budget 8000

Output: a Markdown (or JSON) context pack with only the files that matter for that task — ranked by keyword match, import graph centrality, AST symbol overlap, and git churn. Secrets redacted automatically.

Token savings report on every pack:

Packed 12 files · ~6,840 tokens · saved ~47,200 tokens (87%) vs full repo

How ranking works

Five signals combine into a score per file:

Signal	What it catches
Keyword match	Files whose content/name overlap with your task
Import graph centrality	Files that everything else imports (critical shared modules)
AST symbol overlap	Function/class names, not just grep strings
Git churn score	Recently modified files are probably active code
Secret penalty	Credential files silently excluded

No LLM calls. No cloud. Fully offline.

MCP server (for Claude Desktop / Claude Code)

pip install "rm-contextos[mcp]"
contextos serve --stdio

Register in claude_desktop_config.json and your AI agent can call pack_context, scan_repo, list_files, get_file, churn_report directly as tools — no CLI needed.

What's shipped

980 tests, 96% coverage
Apache-2.0, no telemetry, no accounts
Python 3.11–3.13, Linux + macOS
Export formats: Claude, Codex, Cursor, Aider, JSON
Incremental scan cache — re-scans only changed files

pip install rm-contextos
pip install "rm-contextos[mcp]"   # + MCP server
pip install "rm-contextos[all]"   # everything

GitHub: https://github.com/Rohithmatham12/ContextOS
Docs: https://Rohithmatham12.github.io/ContextOS/

Would love feedback — especially on the ranking signals and MCP integration. What signals are you missing?