DEV Community: ujja

🤖 What happens when your AI agent trusts outdated docs? I built Docgrity to find the gaps.

ujja — Tue, 08 Sep 2026 11:07:13 +0000

ujja

Sep 5

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

#showdev #ai #documentation #opensource

3 min read

ujjavala.github.io

GitHub - ujjavala/docgrity-vscode: Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. · GitHub

Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. - ujjavala/docgrity-vscode

github.com

producthunt.com

I built PadForward because sometimes you just need a pad

ujja — Sat, 05 Sep 2026 13:39:59 +0000

This is a submission for Weekend Challenge: Generosity Edition

💗 Live demo: padforward-generosity.vercel.app · Code: github

What I Built

A few days ago, I unexpectedly got my period while I was out.

I hadn't planned for it, I didn't have a pad with me, and I happened to be near a train station, so I did what seemed like the obvious thing — I went looking for one there.

I expected that a train station would have some way of helping with something as basic as a sanitary product.

It didn't.

I had money. I could have bought one if I could find a shop, and I had enough options to eventually figure it out. But in that moment, I still ended up using toilet paper.

And that got me thinking.

Not just about people who can't afford menstrual products, but about how needing a pad unexpectedly can happen to anyone.

You forget to put one in your bag. Your period comes earlier than expected. You thought you had one left but don't. You're travelling. You're somewhere unfamiliar. You simply didn't think you'd need one that day.

It happens to the best of us.

And then there is the other problem that nobody really talks about enough.

"Does anyone have a pad?"

Even if someone around me had a spare pad, would I actually walk up to them and ask?

Maybe.

But probably not.

We say periods are normal, and they absolutely are. But that doesn't mean asking a random person for a pad in a crowded train station suddenly feels completely normal.

There is that little moment of hesitation.

Do I really want to ask someone?

Who do I ask?

What if they don't have one?

What if this becomes awkward?

And if you're already stressed because you've unexpectedly got your period, the last thing you want is another problem to solve.

That's where PadForward came from.

So, what is PadForward?

PadForward is a community-powered network for finding and donating menstrual products in public places. There are already organisations doing important work like distributing free period products, installing vending machines and helping people find access points. PadForward isn't trying to replace those efforts. I'm interested in what happens when you add a community-powered, supply-aware layer on top of them.

The basic idea is pretty simple: if you need a pad, find one nearby without having to ask someone, and if you have spare pads, help put them somewhere they're likely to be needed.

Think of it as a community layer sitting on top of places people already use — train stations, bus stations, universities, workplaces, community centres and eventually other public spaces.

Someone might donate 20 pads today.

Someone else might need one tomorrow.

Those two people never have to meet.

They don't need to know each other's names.

They don't even need to know who helped whom.

PadForward simply connects the two.

If you need one, you shouldn't have to ask

The first thing I wanted to get right was the emergency experience.

Imagine you're at Central Station and suddenly realise you need a pad.

You open PadForward and tap "I Need a Pad."

You don't need an account.

You don't need to explain what happened.

You don't need to post a request.

You just see what's nearby.

For example:

Central Station
🟢 Available
Verified 12 minutes ago
4 min walk

Town Hall
🟡 A few reported
Verified 28 minutes ago
6 min walk

Museum
🔴 None reported
Verified 18 minutes ago
3 min walk

You pick the closest available location and get directions.

That's it.

No awkward conversation required.

And afterwards, instead of asking for anything back, PadForward can simply say:

Someone helped you today. When you're able, help someone else.

But where do the pads come from?

This is where the other half of PadForward comes in.

Maybe I have a packet of pads at home and want to donate some.

I don't necessarily know which station needs them.

I don't want to spend an hour researching where to take them.

So I can tell PadForward:

I have 20 pads. Where should I donate them?

PadForward looks at the current community supply information and the need at different locations and recommends somewhere that needs them.

For example:

Museum Station

🔴 Critical
Need Score: 94/100
No recent community supply reported
High estimated demand

So instead of simply donating somewhere, I'm donating where the network needs them most.

That's the part I really like about this idea.

It turns a small thing sitting in my cupboard into something that might be exactly where another person needs it.

And yes, I'm using Solana for the donation

I also wanted the Solana integration to actually mean something in the product, rather than adding it just so I could say I used it :)

So PadForward has a "Donate a Pad" flow using Solana.

The idea is that you can sponsor a pad — or several pads — through a Solana transaction, with the donation recorded transparently on-chain.

The physical fulfilment happens through the PadForward community and partner network, so the blockchain isn't pretending to magically move a physical pad from one place to another.

Instead, it gives us a transparent digital record of the generosity behind it.

So the flow becomes:

Donate a pad → Solana transaction → PadForward donation → community supply point → someone can access a pad when they need one.

I like this because the unit of generosity is really easy to understand.

One donation. One pad. One small act that could make someone's day a little easier.

And you don't need to be a crypto person to use it.

The blockchain is underneath the experience rather than becoming the experience.

I didn't want another chatbot

The other technology I really wanted to use properly was Google AI.

I could have added a chatbot that answered questions about periods, but that didn't feel particularly useful.

Instead, PadForward has an AI agent that can actually interact with the application.

You can say:

"I suddenly got my period and I'm at Central."

The agent can understand that you need a nearby pad, find relevant locations, check their current community supply and help you choose one.

Or you can say:

"I have 20 pads to donate."

The agent can look at the current need across nearby stations and recommend where they would be most useful.

You can even report something naturally:

"The donation box at Town Hall is empty."

The AI can understand that this is a supply report and pass it through the application's backend rather than just replying with a paragraph of text.

So Gemini isn't there just to have a conversation.

It's there to help the network make decisions and take actions.

And what if the AI isn't available at all?

This mattered to me, because the moment you most need PadForward is exactly the moment you might be underground at a train station with one bar of signal.

So the assistant degrades gracefully instead of just failing:

Gemini first. When the server and the Gemini API are reachable, the full agent runs — real tool calls, live network data.
Your browser's built-in AI second. If the network is unreachable, PadForward tries the browser's built-in on-device AI (Chrome's Prompt API, powered by Gemini Nano). It runs entirely offline, grounded in the last station data the app cached — and it's told explicitly to never invent availability and to remind you the data may be stale.
Plain heuristics last. If there's no built-in AI either, a small deterministic engine answers from the cached map data: closest place that last reported supply if you need a pad, highest need score if you want to donate.

The answer might get simpler at each step down, but you never get a spinner and a shrug.

Snap the box — AI that counts pads from a photo

Supply reports are the lifeblood of the network, so I wanted reporting to take zero effort.

On any station page — and right inside the Find flow when you pick up a pad — instead of counting pads and tapping buttons, you can just photograph the donation box. Gemini vision looks at the photo and returns a strict JSON estimate — count, confidence, and a one-line description — which prefills a real supply report you confirm with one tap.

And it follows the same philosophy as the assistant: if you're offline, the exact same flow runs on your browser's built-in multimodal AI (Chrome's Prompt API), entirely on-device. The photo is analyzed and discarded either way — never uploaded, never stored.

What if the map says there are pads, but there aren't?

This was another thing I didn't want to fake.

Real-world inventory is messy.

I can't claim that PadForward always knows exactly how many pads are sitting inside a station.

Instead, the community helps keep the information fresh.

Anyone can report:

🟢 Plenty

🟡 A few

🔴 None

⚪ Not sure

The report also has a timestamp, so you might see:

🟢 Available — verified 14 minutes ago

rather than pretending the information is permanently accurate.

Reports from community champions and multiple recent reports can give us more confidence, while old or conflicting reports can lower it.

Over time, this could become a really interesting data problem too — figuring out where demand is happening and when stations tend to run low.

The people who keep it going

Some people might want to do more than make a one-off donation.

That's where Pad Champions come in.

You could adopt a local station and help keep an eye on its community supply.

A champion could verify that a donation point still has supplies, report when it is empty, confirm a restock or help coordinate donations.

The idea is that PadForward shouldn't just be a map that people open when they have a problem.

It should become a little community network that people help maintain.

The bigger idea is the network

This is the part that excites me most.

The actual product isn't really the map.

It's the network behind it.

Someone has spare pads
          ↓
PadForward finds where they're needed
          ↓
Community supply point
          ↓
Someone unexpectedly needs one
          ↓
They find it without asking
          ↓
When they're able, they pay it forward

The donor may never know who received the pad.

The person who received it may never know who donated it.

And that's completely fine.

Generosity doesn't always need a face attached to it.

Sometimes it can just be:

"Someone left one for you."

There's a lot more I want to do with it

For the hackathon, I'm starting with public transport locations because they make the problem very tangible.

But the same idea could work in universities, workplaces, libraries, community centres, airports, shelters and other places where people spend time.

I'd also like to explore route-based discovery, so someone travelling from Parramatta to Central could ask:

"Is there somewhere I can get a pad without making a big detour?"

There is also a lot of interesting work to do around demand prediction, restock alerts, voice accessibility, multilingual support and using analytics to understand where the network needs help.

Snowflake could help with the longer-term demand and supply analytics, while ElevenLabs could make the experience more accessible through voice.

But those are extensions.

The core idea stays the same.

Why PadForward?

I started with a very ordinary, slightly inconvenient experience.

I unexpectedly needed a pad.

I couldn't find one.

And I realised that even though I had the means to solve the problem eventually, getting something so basic wasn't as easy as it should have been.

That made me think about everyone else who might find themselves in the same situation.

Not just someone who can't afford a pad.

Anyone.

Because sometimes you forget.

Sometimes you don't expect it.

Sometimes you're just in the wrong place at the wrong time.

And sometimes there might actually be someone nearby who has exactly what you need — but asking them feels like a bigger deal than it should.

PadForward is my attempt to remove that gap.

No asking.

No explaining.

Just access.

And if you have one to spare?

Pass it forward. 💗

Demo

The demo is live at padforward-generosity.vercel.app — no account, no sign-up.

A few things to try:

Find a pad — share your location (or browse the demo stations) and see nearby community supply with walking times.
Donate — ask "Where should my donation go?", pick the critical station, and watch it flip from 🔴 to 🟢 — optionally paying with SOL.
Ask PadForward — try "I need a pad nearby", "I have 20 pads to donate", or "The donation box at Town Hall is empty" and watch the agent call real application tools.
Impact — see the network's live numbers update as you interact.

All stations are clearly-labelled demo community points at real Sydney station coordinates — supply figures are demo data, not real inventory.

Code

https://github.com/ujjavala/padforward

How I Built It

For the hackathon the whole product ships as a single Next.js 14 app on Vercel — the UI plus API route handlers with an in-memory demo store. The designed architecture (FastAPI + PostgreSQL/PostGIS behind the exact same API contract) lives in services/api with docker-compose and a full pytest suite; the frontend switches to it with one env var.

The interesting pieces:

An agent, not a chatbot (Google AI). Gemini 2.0 Flash gets a registry of 11 validated application tools (find_nearby_stations, get_highest_need_locations, report_supply_status, create_donation, …) and decides which to call — multi-round function calling, and it may only state availability that comes from tool results. It can never touch the data store directly.
A four-tier AI fallback chain. Gemini → a deterministic intent engine using the same tools → the browser's built-in on-device AI (Chrome Prompt API / Gemini Nano) grounded in cached station data when you're fully offline → plain heuristics over the cached map. The answer gets simpler at each step, but you never get a spinner and a shrug.
Vision supply reports. Photograph a donation box and Gemini vision (or the browser's built-in multimodal AI when offline) counts the pads and prefills a supply report — photo analyzed and discarded, never stored.
Solana donations. Sponsoring pads produces a quote (pads → SOL) and records the donation with a transaction signature. With devnet enabled, it submits a real Memo transaction to Solana devnet (auto-airdrop funded) and links to Solana Explorer; otherwise it's transparently labelled devnet (simulated).
A deterministic, ML-ready need score. Every station gets a 0–100 score (40% supply shortage, 20% estimated demand, 15% staleness, 15% recent requests, 10% historical demand) in an isolated module — that's what routes donations to where they help most.
Trust over false precision. Supply is community-reported (🟢/🟡/🔴/⚪) with timestamps and a confidence model — champion reports and agreeing recent reports raise confidence, conflicts lower it.

Prize Categories

Best Use of Google AI — Gemini function-calling agent over real application tools, vision-based photo supply reports, plus the offline Chrome built-in AI (Gemini Nano) fallback for both.
Best Use of Solana — donation flow with SOL quotes and on-chain (devnet) Memo transaction records — the blockchain underneath the experience, not the experience.

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

ujja — Sat, 05 Sep 2026 04:55:38 +0000

Today I'm launching Docgrity — a tool for finding where your documentation disagrees with itself, before it confuses you or the next AI agent working on your codebase.

TL;DR
Docgrity is a documentation integrity tool for repos and Confluence. It finds duplicate or contradictory documentation, surfaces unanswered questions, and gives you the evidence behind each finding so you can decide what needs fixing.
Try it here:
VS Code / CLI / GitHub Actions: https://github.com/ujjavala/docgrity-vscode
VS Code site: https://ujjavala.github.io/docgrity-vscode-site/index.html
CLI: https://www.npmjs.com/package/docgrity
Confluence: https://ujjavala.github.io/docgrity-site/index.html
And if you’re feeling extra supportive, feel free to show the launch some love on Product Hunt or Crowdstax. ❤️
Product Hunt: https://www.producthunt.com/products/docgrity
Crowdstax: https://www.crowdstax.com/products/docgrity

The idea came from a pretty simple problem. I opened one of my own docs recently and realised I didn't believe a word of it.

AI-assisted coding has a side effect nobody really talks about: every agent session leaves documentation behind.

PLAN.md. TODO.md. Implementation notes. Architecture docs. Then another architecture doc because the agent didn't notice the first one.

Eventually, you have a repo full of markdown and no idea what's still true.

And now there's a bigger problem:

AI agents read those docs too.

Stale or contradictory documentation isn't just confusing for developers anymore. It's context for the next agent.

So I built Docgrity.

Start with your repo

Docgrity scans your repository's Markdown and finds:

Duplicates — docs saying essentially the same thing
Contradictions — conflicting claims, shown side by side
Open questions — unanswered questions and stale TODOs

And every finding comes with evidence.

No finding without a receipt.

The source text is quoted verbatim and verified against the actual file before a finding is reported. If the model can't prove it, the finding gets dropped.

VS Code

An interactive dashboard inside VS Code, with clickable evidence and draft GitHub issues you approve before posting.

code --install-extension ujjavala.docgrity

Docgrity for VS Code

CLI

Prefer the terminal? The CLI is read-only and local-first, with Ollama by default.

npm i -g docgrity
docgrity scan --open

Docgrity on npm

GitHub Action

You can also run documentation checks in CI, with deduplicated issues that automatically close when findings are resolved.

- uses: ujjavala/docgrity-vscode/action@main

Docgrity on GitHub

And now, Confluence

Docs don't only live in repositories.

I'm also building Docgrity for Confluence, an early-stage Forge app that scans your Confluence spaces for the same problems: duplicates, contradictions and unanswered questions.

It's currently available through a direct install rather than the Atlassian Marketplace.

Install / try Docgrity for Confluence

It's early, but the idea is the same: make the knowledge your team — and your AI agents — rely on a little more trustworthy.

Zero infrastructure

I wanted Docgrity to be useful without adding another service that needs to own your documentation.

Zero infrastructure. No servers. No telemetry. MIT licensed.

The goal is simple:

Documentation integrity for you, your team, and your agent friends. 🤖

Run a scan on a repo or Confluence space you think you know.

If it finds something that makes you go "wait… that's still in there?" — I'd love to hear about it.

AI Engineering Is Easy. Changing How We Work Is Hard

ujja — Fri, 04 Sep 2026 09:24:10 +0000

AI engineering sounds fancy. New terms are everywhere: agentic development, AI-native engineering, spec-driven development, and now AI harness engineering. Underneath all the terminology, though, something genuinely useful is happening. AI can now help with requirements, challenge a PRD, explore UX ideas, reason about architecture, create implementation plans, write code and validate the result.

The obvious question is what AI can do. The more interesting question is whether the way we build software is ready for it.

The workflow is changing

A workflow we've been exploring breaks development into five stages: requirements, refinement, planning, build and validation. The stages themselves aren't new, but AI can now participate in each one. It can take existing product inputs, help clarify the problem, question assumptions, identify gaps in a PRD and then turn a well-defined requirement into a plan and eventually implementation tasks.

This puts more emphasis on the quality of the requirements. A human involved in a project might understand what “improve the experience” means because they've had several conversations about it. An agent doesn't have that shared history. It needs the problem, scope, constraints, edge cases and expected outcome to be explicit. That doesn't mean writing enormous specifications; it means using AI to help make the requirements precise before we start building.

AI can actually be a useful, slightly annoying reviewer here, asking what happens when something fails, whether a requirement is testable, whether two parts of the document contradict each other and what we haven't considered yet. It can also help compare different versions of a PRD or have one model review another's output, making gaps easier to spot. The important part is that AI is helping us uncover ambiguity, not making the decisions for us.

Maybe coding isn't the bottleneck

This becomes more interesting when we look at where teams actually spend their time. Complex work can involve several rounds between product, UX, requirements and engineering before development can properly begin. That's often necessary, but it can also create significant bottlenecks. If an AI agent can produce a working implementation quickly, waiting two weeks for a requirement to be clarified becomes a much bigger problem than it used to be.

This suggests that engineers need to be involved earlier rather than receiving requirements only once they're considered finished. UX needs to be part of the conversation early too. A rough prototype or wireframe can expose gaps in a requirement much faster than another round of discussion, and AI makes creating those lightweight prototypes much cheaper. Requirements, UX and technical design can become an iterative loop rather than a series of handoffs.

The ticket might be the problem

AI also makes me question how we slice work. A ticket that takes weeks or months is difficult for an agent to reason about, and arguably isn't a particularly useful unit of work for humans either. “Build authentication” is very different from breaking the problem into password reset, token validation, password updates and the associated tests.

That doesn't mean turning every feature into dozens of tiny tickets. We just need work that has a clear purpose, manageable scope and a definition of done. If something takes months, it might be a project hiding in a Jira costume.

At the same time, not everything needs the full AI lifecycle. A large feature may benefit from structured requirements, refinement, planning and validation, while a small BAU change might only need a prompt and a developer. If we apply the same process to everything, we risk replacing one form of bureaucracy with another. The workflow should match the complexity of the work.

The agent needs to see the real system

There is also a fairly fundamental requirement: the agent needs to understand the real system. Giving it a PRD without access to the relevant codebase means it is still making assumptions. With the code, it can find existing patterns, understand constraints, reuse functionality and spot when a proposed solution doesn't fit.

Of course, giving AI access to source code introduces security, licensing, privacy and organisational considerations, so AI adoption isn't simply a matter of choosing the right model. Some of the biggest barriers have nothing to do with the model at all.

And once multiple developers and agents are working in parallel, things get even more interesting. Each agent has its own context and can make decisions based on what it currently sees. One agent can change something another doesn't know about, or two agents can make perfectly reasonable decisions that don't work well together. This makes good engineering practices even more important: small changes, clear boundaries, good tests, frequent reviews and consistent project rules.

So, are we ready?

Probably not completely, and that's fine. We don't need to jump straight into autonomous software development. We can take real pieces of work, try these workflows, see where they break and improve the process as we go.

Because AI isn't just changing how quickly we write code. It is exposing everything around the code that slows us down: unclear requirements, oversized tickets, late UX involvement, documentation drift, handoffs, access restrictions and decisions that take days to make.

That's why I think the idea of an AI harness is bigger than prompts and agent configuration. The harness is the environment we create around the AI: how we define work, how product, UX and engineering collaborate, how knowledge is structured, how repositories are organised, how work is validated and what access the agent has.

The AI might be the new part, but the way we work around it is what will determine whether it actually makes us faster.

AI engineering is easy. Changing how we work is hard.

I Love Dogs, But Dogs Scare Me — So I Built Pawsitive with Gemini 🐾.

ujja — Sat, 15 Aug 2026 09:28:28 +0000

This is a submission for Weekend Challenge: Dog Days Edition

There are only two types of people in the world: those who love dogs, and those who love them from a distance. 😂🐶

What I Built

I love dogs.

There, I said it.

And yet, I am also scared of them.

It is a strange combination. I can happily watch dog videos for hours, admire every dog I see on the street, and still instinctively tense up when one suddenly runs towards me.

A lot of that comes from a traumatic experience I had with a dog as a child. You can grow up knowing that one experience doesn't define every dog you will ever meet, but sometimes your instincts don't get the memo.

While thinking about this challenge, I started wondering if the problem was partly not understanding what I was seeing.

If a dog is wagging its tail, what does that actually mean? If it is staring at me, should I move away? If it is barking, is it excited, nervous, protective, or something else? And if a dog is approaching me on a footpath, what should I actually do?

That question became Pawsitive.

Pawsitive is an interactive learning app for people who feel nervous around dogs. Instead of telling people not to be afraid, it tries to make encounters feel less unpredictable by teaching them how to recognise common body-language signals, understand situations, and make calmer decisions.

But then I realised there was another side to the interaction.

A dog owner might see their dog happily walking towards someone and think:

"Don't worry, he's friendly!"

The person approaching might be thinking:

"Please don't let that dog come any closer."

Both people can be looking at the same dog while experiencing completely different situations.

So Pawsitive has two learning paths: people who are nervous around dogs and dog owners.

The first helps people understand dogs and build confidence. The second helps owners recognise when someone might be uncomfortable, why giving people space matters, and why "my dog is friendly" doesn't necessarily make an approaching dog less intimidating.

That became the idea behind the whole app:

Two perspectives. One better interaction.

Demo

Github link: https://github.com/ujjavala/pawsitive

Vercel deployment: https://pawsitive-nine.vercel.app/

Note: The Vercel deployment does not include a Gemini API key. On supported desktop Chrome devices, Understand This Dog falls back to Chrome's built-in Gemini Nano model and analyses the photo privately on-device. You can also run the app locally and add GEMINI_API_KEY to .env.local for server-side Gemini analysis.

The experience begins with three gentle onboarding questions: how comfortable you are around unfamiliar dogs, which situations feel most uncomfortable, and what you want to achieve. Someone who selects "Very nervous" isn't immediately thrown into a stressful scenario. They start by learning the basics, exploring relaxed and tense body language before gradually moving into realistic situations. Their answer also sets an initial confidence score, but it never locks content or forces them into an interaction.

Then comes What Would You Do?

You might be walking down a footpath when a dog approaches with its owner. Instead of reading instructions, you decide how you would respond and then get an explanation of why one choice may lead to a calmer interaction.

The perspective can then switch to the owner's side. The same encounter looks very different when you realise that giving someone space may be more helpful than reassuring them that your dog is friendly.

Finally, Understand This Dog lets users upload a dog photo and use Gemini to explore the visible body-language cues. The result also suggests a possible breed or breed mix, explains which visible features informed the estimate, and shares typical physical characteristics and cautiously worded breed-level behavioural tendencies. It uses the configured server model when a Gemini key is available and falls back to Chrome's built-in Gemini Nano model when the server has no key and the browser supports multimodal on-device AI.

The entire experience is designed to be short enough to explore in a few minutes while still telling the complete story.

How I Built It

I wanted Pawsitive to feel like something you would actually want to use, rather than a clinical safety course.

That led to a bright, playful interface, an animated SVG dog, playful scenario scenes, gentle sounds, small celebrations, and a mascot named Pip who follows the user through the experience.

The app is built with React, TypeScript and Vite, with Tailwind CSS and Radix UI primitives for the interface, Motion for React (the current Framer Motion package) for animation, SVG illustrations for Pip, and Zustand with localStorage for progress tracking. Zod validates structured AI responses at runtime, while Lucide provides the icon system. Server inference uses Google's @google/genai SDK, while private inference uses Chrome's built-in LanguageModel Prompt API without adding another model runtime to the application bundle.

There is deliberately no authentication or database in the MVP. You can open the app and start learning immediately.

The weekend build includes 10 lessons for nervous users, six owner lessons, eight scenarios, eight body-language signals and five gentle achievements. Routes are lazy-loaded so the non-critical learning, scenario and AI screens do not all have to load up front.

Making Pip feel alive

Pip changes depending on what is happening. They can tilt their head during a question, wag their tail after a correct answer, bounce when a lesson is completed, or look confused when something goes wrong.

The animations are deliberately gentle. There are no sudden dogs jumping towards the screen or unexpected barking, because an app designed for nervous dog lovers shouldn't accidentally make them nervous.

The same thinking shaped the sound design. The current build uses short, synthesised feedback tones for correct answers, lesson completion and soft errors. I deliberately left barking and other dog sounds out of the learning flow so the app cannot unexpectedly startle someone. Sound can be disabled, and motion can be reduced from inside the app. Pip also respects the device's own reduced-motion preference.

The goal is simple: make the app feel alive without making it overwhelming.

🧠 The Gemini Experiment

The most interesting part of Pawsitive is Understand This Dog, where I wanted AI to do something more meaningful than power another generic chatbot.

A user can upload a JPG, PNG or WebP photo of a dog, and Gemini analyses the visible signals in the image. The response is structured into six parts:

Possible breed — an appearance-based breed or breed-mix estimate, the visible traits behind it, and an honest visual-confidence level. If the image is not clear enough, the model can simply return Breed unclear instead of forcing a guess.

The breed section also includes typical physical characteristics and possible breed-level behaviours. These are written as broad tendencies using language such as "often", "may", and "commonly"—never as claims about the individual dog. A clear reminder explains that breed cannot predict this dog's personality, emotional state, safety, or future behaviour.

What we can see — observable cues such as posture, ears, tail visibility and body position, each with a visual-confidence level.

What this might mean — cautious interpretations of those signals.

What we can't know — because one photograph cannot tell us everything about a dog's emotional state or predict what it will do next.

What you can do — conservative guidance focused on giving unfamiliar dogs appropriate space.

Safety note — an explicit reminder not to approach an unfamiliar dog based only on an image interpretation.

That last part was especially important to me.

I didn't want to build an AI-powered "Is this dog safe?" detector. A photograph cannot reliably tell you that a dog is safe, friendly, or won't bite.

So the Gemini integration is deliberately designed to acknowledge uncertainty, using language such as "may indicate" and "can be consistent with" rather than making definitive claims. That same principle applies to breed identification: visual similarity can suggest a breed or mix, but appearance alone cannot confirm ancestry or tell us how an individual dog will behave.

That safety work does not rely only on the interface. In the server path, the browser sends the image to a same-origin Vercel Function, so the Gemini key is never exposed to client code. The function rejects unsupported files and images larger than 5 MB before calling Gemini, requests JSON matching a schema, validates the result with Zod, and rejects responses containing certainty claims such as "definitely friendly", "won't bite" or "safe to approach". The UI validates the response again before rendering it as cards, never as model-generated HTML.

The Gemini model is configured server-side with GEMINI_MODEL and checked against an allowlist. The current default is Gemini 3.5 Flash-Lite, and unsupported model IDs fall back to this default rather than being passed through to the provider. For local development, Vite loads only the server-side Gemini environment variables and mounts the same /api/analyze-dog handler used in deployment. That means npm run dev runs the UI and local API together without requiring the Vercel CLI or a Vercel login.

Private on-device fallback with Gemini Nano

When the server reports that no GEMINI_API_KEY is configured, Pawsitive checks Chrome's built-in LanguageModel API with the exact text-and-image capabilities required by the feature. If the model is ready, the selected image is analysed locally. If Chrome needs to download the model first, the interface shows download progress and provides a cancel action.

The on-device session receives the same cautious system instruction as server Gemini, accepts the selected photo as an image Blob, and returns JSON constrained by the same schema. That schema includes the possible breed, confidence, supporting visual evidence, typical characteristics, possible breed behaviours, body-language observations, uncertainty, and safety guidance. Its output passes through the same Zod validation and certainty checks before anything is displayed. The session is destroyed after analysis to release browser resources, and successful results are clearly labelled analysed privately on this device.

What amazed me about the private mode

This became one of the most surprising parts of the whole project. I expected the private on-device mode to be a useful fallback, but I did not expect Gemini Nano to perform this well. In my testing, its observations and cautious interpretations were often remarkably close to the results produced through the API-key-powered server models.

API mode:

Private mode:

That feels like a small glimpse of how quickly AI is advancing: a browser can now examine an image, follow a detailed instruction, produce structured output and respect the same safety constraints—all without an API key and without sending the photo to a server. The privacy benefit is not achieved by giving up the core experience; the result remains genuinely useful.

There are still differences between devices and models, so I would not call the two paths identical or treat my experiments as a formal benchmark. Even so, seeing capable multimodal AI run privately inside Chrome was a real wow moment for me. Gemini Nano started as a fallback and ended up feeling like one of Pawsitive's most exciting features—and a sign of the possibilities that on-device AI is beginning to unlock.

The fallback order is:

Use server Gemini when GEMINI_API_KEY is configured.
Use Chrome's built-in Gemini Nano model when the key is absent and the requested multimodal session is supported.
Show an honest unavailable message and retain the clearly labelled seeded demo when neither option is available.

Prerequisites for private on-device analysis

Chrome's foundation-model APIs are a progressive enhancement rather than universal browser functionality. The current documented requirements are:

Browser: Google Chrome 148 or newer for the web Prompt API.
Operating system: Windows 10 or 11, macOS 13 or newer, Linux, or a Chromebook Plus device. Chrome on Android, iOS, and non-Plus Chromebooks is not currently supported.
Storage: At least 22 GB free on the volume containing the Chrome profile. Chrome removes the model if available storage later drops below 10 GB.
Compute: Strictly more than 4 GB GPU VRAM, or at least 16 GB system RAM and four CPU cores for CPU execution.
Network: An unmetered connection for the initial browser-managed model download. Subsequent inference can run without a network connection.
User activation: The first download must be started after a meaningful user interaction, which Pawsitive provides through the Help me understand button.

For local testing, enable chrome://flags/#optimization-guide-on-device-model and chrome://flags/#prompt-api-for-gemini-nano, then fully relaunch Chrome. Download and model errors can be inspected at chrome://on-device-internals. After the initial download, Chrome states that inference is local and no prompt or image data is sent to Google or another third party.

The AI feature also fails independently from the rest of the product. If neither server nor on-device analysis is available, the user sees a plain explanation and can continue learning. For challenge demos, there is a clearly labelled sample-photo experience with a seeded educational result; it never pretends to be a live result for a photo the user uploaded. Images are processed only after the user presses Help me understand, and Pawsitive does not add them to application storage. On-device analysis keeps the image local; server analysis does not store it.

AI isn't the authority here. It is the teacher.

The Learning Journey

The product principle follows a simple progression:

Understand → Recognise → Respond → Build Confidence

The actual lesson content is organised into Understanding Dogs, Meeting Dogs Safely, and Thoughtful Ownership modules. Users first learn about relaxed and tense body language, tail movement, barking, staring, and why individual signals shouldn't be interpreted in isolation.

They then move into realistic scenarios and make decisions for themselves.

If they get something wrong, Pawsitive doesn't throw a giant red WRONG screen at them. Pip simply tilts their head and encourages them to look at the situation again.

That was intentional.

Someone who is already nervous doesn't need another reason to feel like they're failing.

Progress follows the same principle. Onboarding starts confidence at 20, 40, 50, 70 or 85 depending on the user's own answer. Completing a lesson or correctly answering a new scenario adds five points, while an incorrect answer has no penalty. Rewards are idempotent, so repeating an activity cannot inflate the score. The Progress screen keeps confidence separate from completion and explicitly describes it as a personal reflection, not a clinical measurement.

🐕 The Owner Perspective

The owner experience came directly from thinking about what makes dog encounters uncomfortable.

A dog owner may genuinely have a friendly dog and genuinely believe nothing is wrong. But that doesn't necessarily change how the other person feels.

One scenario asks an owner what they should do when they notice someone moving away from their dog.

The answer isn't to follow them and explain that the dog is friendly. It's simply to create some space.

That captures what I wanted Pawsitive to teach:

A safe interaction isn't just about understanding the dog. It's about understanding the human too.

The paired scenario is linked in both directions in the content model. Completing the person and owner sides unlocks the Perspective Shift achievement, making the product's central idea visible in the progress journey rather than leaving it as marketing copy.

Testing the Safety Net

Because Pawsitive mixes educational content, stateful rewards and model output, I did not want the demo to depend only on a happy-path click-through.

The project uses Vitest and React Testing Library. The current automated suite checks the required lesson, scenario, signal and achievement counts; unique IDs and answer keys; two-way scenario links; confidence clamping and one-time rewards; and the dog-analysis schema. It also contains regression cases for unsafe AI phrases including "definitely friendly", "won't bite", "you can approach this dog" and "safe to approach".

The on-device adapter tests cover unsupported browsers, successful structured multimodal output, browser model-download progress, session cleanup, and rejection of unsafe local-model certainty. A page-level test confirms that a missing server key selects the private path without uploading the image.

Before submission, the strict TypeScript check, all 20 automated tests, ESLint, and the Vite production build pass.

Why I Built It

Pawsitive started with something personal: the slightly ridiculous feeling of loving dogs while still being afraid of them.

I don't expect an app to erase that fear. That wasn't the goal.

I wanted to build something that says:

It's okay if you're nervous. Let's understand what's happening.

Maybe knowing what to look for makes the next encounter feel a little less unpredictable. Maybe understanding that a wagging tail doesn't always mean "hello" gives someone a little more confidence. Maybe helping owners recognise when to create some distance makes the other person feel less alone in the situation.

And maybe, eventually, someone who currently crosses the street when they see a dog can simply keep walking.

For someone who is afraid of dogs, that might not feel like a small thing at all.

🏆 Prize Category: Best Use of Google AI

I'm submitting Pawsitive for Best Use of Google AI because Gemini is part of the core learning experience rather than simply being added as a chatbot.

Through Understand This Dog, Gemini's multimodal capabilities help users explore visible dog body-language cues while deliberately teaching the limits of what can be inferred from a single image. The app can use a securely configured server model or Chrome's built-in Gemini Nano model, with shared structured-output and safety controls across both paths.

A curious dog:

A playful dog:

A rare breed:

That uncertainty is part of the feature, not a limitation hidden from the user.

🔮 Giving Pip a Voice with ElevenLabs

The next piece I would love to add is a voice for Pip using ElevenLabs. ElevenLabs is not part of the current weekend build; this is a deliberate next step rather than a shipped integration.

Right now, Pip is the animated companion reacting to the user's progress. With voice, Pip could become part of the learning journey itself.

Instead of simply reading instructions, Pip could say:

"Okay, let's take this one slowly. You can see a dog coming towards you. What would you do?"

After an answer:

"Good thinking. Giving the dog and its owner a little more space can make this easier for everyone."

And for someone who is nervous:

"There's no rush. Let's look at what's happening first."

The interesting part would be connecting Pip's voice to the user's confidence journey, so the experience gradually feels more encouraging and energetic as their confidence grows.

That brings together three pieces of the experience:

Gemini understands the visual information.

ElevenLabs gives Pip a natural voice.

Motion for React brings Pip to life.

Together, they could turn Pip from an animated mascot into a genuine dog-confidence companion.

I would keep that integration server-side, accept only a small set of approved narration IDs, and cache generated clips. That would protect the API key, control cost and prevent arbitrary text from turning the feature into an open text-to-speech proxy. Narration would remain user-initiated, optional and accompanied by the same visible text.

What's Next?

There are plenty of directions Pawsitive could take, but the core idea would stay the same: gradually move people from illustrations to photographs, videos and increasingly realistic scenarios as their confidence grows.

I also considered Snowflake, but deliberately did not add it to the weekend MVP simply to increase the technology count. Pawsitive does not need a warehouse to teach a lesson or remember local progress. A future opt-in analytics layer could send anonymous events such as lesson completion, perspective switching, Gemini request success and labelled-demo usage to Snowflake—never uploaded photos, model response text or personal details. For now, keeping that out made the privacy story and the architecture simpler.

For dog owners, there could eventually be more personalised guidance around their individual dogs and situations.

But the weekend version is intentionally focused.

Pawsitive is ultimately about closing the gap between two perspectives:

"I don't know what that dog is going to do."

and

"My dog is friendly. Why are they scared?"

There is a lot of space between those two thoughts.

I wanted to build something that helps close it.

And, perhaps selfishly, something that might one day help me stop jumping every time a dog barks.

You don't have to love dogs.

*You just need to understand them.🐾 *

Turning Ayurveda’s Six Rasas Into CSS Art

ujja — Sat, 15 Aug 2026 03:16:21 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

What does comfort food look like when you don't use food photography?

That was the question behind Rasa.

Rasa is an interactive culinary atlas exploring India through Shadrasa, the six tastes described in Ayurveda:

Madhura — sweet
Amla — sour
Lavana — salty
Katu — pungent
Tikta — bitter
Kashaya — astringent

I wanted to turn those six tastes into something visual rather than simply presenting them as text or cards.

The result is a tongue-shaped interactive map.

One important clarification: the familiar "tongue taste map" is scientifically inaccurate. Taste receptors are distributed across the tongue. In Rasa, the tongue is purely a cultural and artistic navigation metaphor, not an anatomy diagram or medical claim.

The idea was to make something that felt like opening an old food journal rather than browsing a database.

The CSS Art

The tongue is probably the most obvious piece of CSS art in the project.

It isn't an image.

It is a layered CSS illustration with:

Six selectable rasa regions
A draggable, bounded CSS 3D orbit
Pointer-responsive lighting
Pan and zoom
Keyboard orbit and navigation
A dedicated control to centre the 3D view
Papillae and surface texture
A median sulcus
Subtle veins and mucosal variation
Rim lighting
Subsurface colour
Counter-scaled labels that remain readable while zooming

The tongue can be explored almost like a little map.

Select a rasa and the camera moves towards that region, revealing the corresponding field notes.

The 3D effect does not use WebGL, canvas or a 3D library. JavaScript only captures pointer and keyboard input and updates a few CSS custom properties. Perspective, depth, lighting, counter-rotation and shadows remain CSS work.

That interaction was important to me.

I didn't want the CSS art to be something you simply look at.

I wanted it to become part of the interface.

Making Food Without Food Images

The other fun constraint was food itself.

Instead of using food photography, every dish has a small declarative plate-art recipe.

The renderer combines things such as:

Vessel
Food form
Colours
Garnishes
Texture
Lighting
Serving temperature

The renderer supports vessels including thalis, plates, bowls, kadhais, clay pots, banana leaves and leaf cones.

Food forms include rounds, stacks, curries, grains, crescents, cones, cubes and strands.

CSS then adds details such as oil sheen, highlights, contact shadows, steam, heat haze, condensation and cold mist.

So a dish isn't a static illustration.

It is data that becomes an illustration.

That was one of my favourite parts of building Rasa.

Six Handcrafted Taste Guides

Each rasa is accompanied by a guide with a distinct silhouette, costume, hairstyle, expression and role:

Guddi, the Culinary Archivist for sweet
Ami, the Fermentation Botanist for sour
Neer, the Coastal Navigator for salty
Tara, the Spice Route Chronicler for pungent
Nima, the Ethnobotanical Elder for bitter
Jamu, the Tea and Tannin Cartographer for astringent

The characters are built from nested HTML and CSS rather than generated avatars, SVG artwork or image files. Gradients, borders, pseudo-elements, clipping and transforms create their faces, clothing, hair, accessories and tools.

They can greet the visitor, scout ingredients and share lore. Their mouths respond while they speak, and gestures such as walking, waving and pointing are finite rather than perpetual. This keeps the characters playful without turning the page into a wall of constant motion.

Making CSS Feel Less Like CSS

A lot of the work was experimenting with the things CSS is surprisingly good at:

gradients + shadows + transforms + masks + pseudo-elements + 3D transforms

Individually, none of those are particularly exotic.

Combined carefully, they can start to feel much closer to illustration.

I also added a small layer of atmospheric "ingredient wind" across the site.

Different rasas get their own ingredient:

Jaggery for sweet
Mango leaf for sour
Salt crystal for salty
Chilli for pungent
Neem leaf for bitter
Jamun for astringent

The ingredients drift across the page like leaves in a breeze.

It is intentionally subtle.

It can also be paused, disappears in forced-colour mode, and respects reduced-motion preferences.

CSS Art With a Purpose

One thing I wanted to avoid was making a collection of pretty CSS experiments that didn't actually help the user.

The visual language is tied to the content.

The tongue represents the six tastes.

The plate art represents the food.

The notebook changes atmosphere depending on the dish.

Hot dishes introduce warmth, steam and heat shimmer.

Chilled dishes introduce condensation, frost and cool mist.

Festival dishes receive restrained gold details.

Street food gets a subtle field-stamp treatment.

The visual effects are therefore part of the storytelling rather than decoration added afterwards.

84 Dishes Instead of Six

The six tastes are only the entry point.

Rasa contains 84 dishes, with 14 primary dishes for each rasa, covering all 28 Indian states and multiple Union Territories across eight culinary macro-regions.

The dataset intentionally goes beyond the usual shorthand for Indian food.

There are:

Everyday meals
Breakfasts
Snacks
Street foods
Festival foods
Temple foods
City specialities
Folk and Adivasi traditions
Fermented foods
Coastal cuisines
Mountain cuisines
Sweets
Drinks
Pickles
Breads
Rice dishes
Curries
Preserved foods

The goal was breadth rather than stereotype.

The Technical Side

Rasa is built with:

React 18
TypeScript 5.7
Vite 6
Tailwind CSS 4
Lucide React
Handcrafted CSS character art
Playwright
axe-core

The application is data-driven.

The six rasas, dishes, regions, festivals, spices and guides are represented as domain models rather than being embedded directly into components.

That makes the CSS renderer reusable.

A Dish can describe what something is, while its PlateArt recipe describes how it should look.

That separation made it much easier to keep adding dishes without creating a new component for every food.

Accessibility Still Applies to CSS Art

One of the interesting challenges was making something visually experimental still behave like a normal application.

The map is keyboard-operable.

The rasa controls, field-note tabs, guide commands, notebook corners and CSS 3D orbit are keyboard-operable.

Interactive controls have accessible names and 44 × 44px minimum targets.

There is a skip link.

Notebook page changes are announced to screen readers.

The experience supports reduced motion, persistent motion controls, forced colours, 200% zoom, text-spacing overrides and 320px reflow. Native dish names carry language metadata, page and guide changes use polite status announcements, and textured-paper text now uses darker ink colours for enhanced contrast.

I also added 13 Playwright accessibility and interaction journeys. They run axe with WCAG 2.0, 2.1 and 2.2 A, AA and AAA tags, exercise all six rasa states and all field-note tabs, and check keyboard selection, reduced motion, text spacing, target sizes, finite guide animation, CSS 3D keyboard orbit and notebook corner navigation.

The latest automated run passes all 13 journeys with no axe violations or unresolved structural ARIA checks. Textured gradients can prevent automated tools from resolving every contrast pair, so the underlying ink-on-paper colour pairs were also reviewed directly. This still is not a claim that automation proves complete WCAG AAA conformance: manual testing remains necessary for reading order, language and pronunciation, cognitive clarity, and real assistive-technology behaviour.

What I Learned

The biggest lesson was that CSS art becomes much more interesting when it has a job.

It is tempting to ask:

"How can I make this look cool with CSS?"

A better question turned out to be:

"What should this visual communicate?"

Once the answer was clear, the implementation became much easier.

The tongue needed depth because it was a map.

The food needed texture because it represented serving and preparation.

The notebook needed page turns because the content was designed as a field journal.

The current notebook has clickable outer page corners as well as conventional Previous and Next controls. Each corner uses a small rounded CSS curl: the right edge lifts subtly upward and left, while the left edge lifts upward and right. The fold, underside, highlight and shadow are all CSS, while the button underneath remains semantic and keyboard accessible.

The motion needed to communicate state instead of simply moving things around.

That became one of the design principles for the entire project:

Motion should explain state or create atmosphere, never prevent reading.

Demo

🍛 Try Rasa: https://rasa-mu.vercel.app/

The source code is available on GitHub:

ujjavala / rasa

Rasa — The Tongue Map of India

An interactive culinary atlas that explores India through Shadrasa, Ayurveda's six tastes: sweet, sour, salty, pungent, bitter, and astringent.

Rasa is a React experience built for the DEV Frontend Challenge themes CSS Art: Comfort Food and Perfect Landing: Comfort Food. It combines an editorial landing page, a zoomable CSS-art tongue map, character-led exploration, regional food history, and a page-turning field notebook containing 84 dishes from across India.

Important: the familiar “tongue taste map” is scientifically inaccurate. Taste receptors are distributed across the tongue. This project uses the tongue only as a cultural and artistic navigation metaphor for the six rasas; it is not an anatomy chart or medical guidance.

Why this project exists

Indian food is often flattened into a small set of restaurant dishes. Rasa was created to show a wider table: home cooking, street food, temple food, festival dishes…

View on GitHub

Youtube link:

What's Next?

There are plenty of things I'd like to explore further:

Ingredient and state-based search
Seasonal food trails
Audio pronunciation for native dish names
More community-reviewed cultural sources
Shareable notebook pages
Deeper VoiceOver, NVDA, TalkBack and keyboard-only testing

For now, Rasa is my little experiment in asking:

How far can CSS go when you stop treating it as styling and start treating it as an illustration medium?

And perhaps more importantly:

Can a website about comfort food make you hungry without using a single food photograph? 🍚

Designing a Landing Page That Feels Like Opening a Food Journal

ujja — Sat, 15 Aug 2026 03:16:15 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing.

What I Built

I built Rasa, an interactive culinary atlas that explores India through the six tastes of Shadrasa:

sweet, sour, salty, pungent, bitter and astringent.

The starting point was simple:

What if a food atlas felt less like a database and more like opening a traveller's field journal?

That idea shaped the entire landing page.

Instead of starting with a grid of dishes or a traditional restaurant-style hero, I wanted the page to feel editorial, tactile and slightly mysterious.

The landing page introduces the six tastes through a CSS-built rasa mandala and then invites the visitor into the atlas.

From there, the experience expands into an interactive tongue map, character-led exploration, regional food history and a page-turning culinary notebook containing 84 dishes.

The Landing Page Is the Beginning, Not the Destination

I approached the hero as an invitation rather than a summary.

The visitor first encounters the concept of Rasa.

Then the six tastes.

Then the tongue.

Then the exploration.

That progression was deliberate.

I didn't want to put every feature into the first screen.

The landing page establishes the mental model first:

Rasa → taste → region → dish → story

Once that relationship is understood, the rest of the application becomes easier to navigate.

Why a Tongue?

There is a familiar visual idea of dividing the tongue into taste regions.

Taste receptors are distributed across the tongue, so Rasa does not present this as an anatomy chart.

Instead, I used the tongue as a visual metaphor.

Six regions.

Six tastes.

Six entry points into a much larger culinary landscape.

The tongue is interactive, zoomable and keyboard accessible. It also supports a shallow, bounded 3D orbit: visitors can drag the backdrop, use arrow keys, hold Shift for larger steps, or press Home and the dedicated centre control to reset the view.

Selecting a rasa moves the camera towards that region and opens its field notes.

The depth effect is still CSS-first. JavaScript captures input and updates CSS custom properties; perspective, layer separation, lighting, shadows and character depth are rendered in CSS. There is no canvas, WebGL or 3D dependency.

So the hero concept eventually becomes the primary navigation mechanism.

From Landing Page to Field Journal

The biggest design decision was to avoid making the experience feel like a food catalogue.

India has far too many food traditions for that approach to feel right.

Rasa explores:

Everyday home cooking
Street food
Festival and temple food
City specialities
Folk and Adivasi traditions
Fermented foods
Coastal cuisines
Mountain cuisines
Regional ingredients and techniques

The current dataset contains 84 dishes across eight culinary macro-regions, representing all 28 Indian states and multiple Union Territories.

Each dish includes context around its history, ingredients, technique, occasions and regional identity.

The landing page therefore needed to communicate exploration, not simply consumption.

Meet the Guides

I also wanted the interface to have some personality.

Each rasa has a guide with a distinct identity:

Taste	Guide	Role
Madhura · sweet	Guddi	Culinary Archivist
Amla · sour	Ami	Fermentation Botanist
Lavana · salty	Neer	Coastal Navigator
Katu · pungent	Tara	Spice Route Chronicler
Tikta · bitter	Nima	Ethnobotanical Elder
Kashaya · astringent	Jamu	Tea and Tannin Cartographer

Each guide can:

Greet
Scout ingredients
Reveal lore

The portraits are handcrafted from nested HTML and CSS. Each guide has a different figure, skin tone, costume, hairstyle, accessories and expression, with Guddi, Tara and Nima represented as women and Ami, Neer and Jamu as men. They use no generated avatar package, SVG character asset or image file.

Their walking, waving, scouting and lore gestures are intentionally finite rather than constant idle animation. Speech bubbles restart for each command, and the mouth moves briefly while a guide talks.

That was another deliberate choice.

I wanted characters to feel responsive rather than noisy.

The Notebook

The deeper you go into the experience, the more the interface changes.

Instead of a conventional card grid, dishes appear in a two-page field notebook.

You can turn pages.

You can also use the lifted outer corners: the right corner turns forward and the left corner turns backward. They are semantic buttons with subtle rounded CSS curls that rise inward like the edge of a real page, while the existing Previous, Next and direct-jump controls remain available.

Jump directly to a dish.

Move backwards and forwards.

See regional and contextual annotations.

Read the native name with appropriate language metadata.

Follow the dish to further context.

The notebook also changes atmosphere based on the food.

A piping-hot dish can introduce warmth, steam and heat shimmer.

A chilled dish can introduce frost, condensation and cool mist.

Festival foods receive restrained gold detailing.

Street foods receive a subtle field-stamp treatment.

This was my way of making the interface feel like a physical object rather than another collection of UI cards.

Designing for Accessibility From the Start

A visually heavy landing page can very quickly become inaccessible.

So accessibility wasn't treated as something to check after the animations were finished.

The application includes:

Semantic landmarks and headings
A skip link
Keyboard-operable navigation
Roving tab navigation
Visible focus states
Accessible icon controls
44 × 44px minimum interactive targets
Screen-reader announcements
Reduced-motion support
Persistent pause/play motion control
Forced-colour support
200% zoom support
320px reflow
Text-spacing resilience
Keyboard control for the CSS 3D orbit and notebook corners
Enhanced ink-on-paper contrast
Automated axe checks through Playwright across all six rasa states and every field-note tab

The principle was simple:

The experience should remain useful when the visual effects disappear.

If someone disables animation, uses keyboard navigation, zooms the page or doesn't have pointer input, the content and navigation still need to make sense.

The current suite contains 13 accessibility and interaction journeys and passes in Chromium. It runs axe using WCAG 2.0, 2.1 and 2.2 A, AA and AAA tags, and now rejects unresolved structural ARIA findings as well as violations. Automation still cannot certify every AAA success criterion, especially where manual judgement, language, pronunciation, reading clarity or real assistive technology is involved, so manual review remains part of the roadmap.

Motion With Meaning

There is quite a lot of movement in Rasa.

But every type of movement has a reason.

Guide movement communicates an interaction.

The camera movement communicates navigation.

Notebook movement communicates page direction.

Steam and heat haze communicate serving temperature.

Ingredient wind creates atmosphere.

And the global motion control lets the user pause the experience.

The application also respects prefers-reduced-motion.

This led to one of my favourite principles from the project:

Movement should explain state or create atmosphere, never prevent reading.

The Visual Language

I wanted the interface to feel somewhere between:

a field journal + an old map + a recipe notebook + a museum exhibit.

Brass.

Paper.

Ink.

Food vessels.

Spice textures.

Map controls.

Shadows.

Atmospheric movement.

Most of those visual elements are created with CSS rather than remote food photography.

That constraint ended up becoming one of the most interesting parts of the project.

Technical Stack

The application is built with:

React 18
TypeScript 5.7 in strict mode
Vite 6
Tailwind CSS 4
Lucide React
Handcrafted HTML and CSS character art
ESLint
Stylelint
Playwright
axe-core

The application is deliberately data-driven.

Rasas, dishes, regions, festivals, spices and explorers are represented as data models.

React components are responsible for rendering those models rather than containing the cultural content themselves.

That made it possible to build a fairly elaborate experience without turning the components into giant collections of hard-coded content.

What I Enjoyed Most

The most satisfying part was seeing a landing-page idea evolve into an actual world.

At first it was just:

six tastes.

Then:

six tastes → six regions → six guides.

Then:

guides → dishes → regions → festivals → spices.

Eventually it became an atlas containing 84 dishes and multiple ways to explore them.

That progression made the project feel much more like a small product than a challenge submission.

What I Would Improve Next

There is still plenty I would like to add.

Some ideas are:

Search by ingredient, state, season and technique
Audio pronunciation for native dish names
User-created food trails
Shareable notebook pages
More community-reviewed citations and oral-history sources
More manual accessibility testing with VoiceOver, NVDA and TalkBack
Additional contrast review for complex textured and gradient surfaces

Demo

🍛 Explore Rasa: https://rasa-mu.vercel.app/

Source Code

The project is open source on GitHub:

ujjavala / rasa

Rasa — The Tongue Map of India

An interactive culinary atlas that explores India through Shadrasa, Ayurveda's six tastes: sweet, sour, salty, pungent, bitter, and astringent.

Important: the familiar “tongue taste map” is scientifically inaccurate. Taste receptors are distributed across the tongue. This project uses the tongue only as a cultural and artistic navigation metaphor for the six rasas; it is not an anatomy chart or medical guidance.

Why this project exists

Indian food is often flattened into a small set of restaurant dishes. Rasa was created to show a wider table: home cooking, street food, temple food, festival dishes…

View on GitHub

Youtube link:

Final Thought

I started with a comfort-food challenge.

I ended up building a small interactive atlas.

That was probably the most enjoyable part of the challenge.

Instead of asking:

"How do I make a landing page about food?"

I asked:

"How would a food atlas feel if you could walk into it?"

Rasa is my attempt at that answer.

A little paper.

A little spice.

A little CSS magic.

And a very large table. 🍛

You Know What's Worse Than Not Being Able to Log In?

ujja — Thu, 13 Aug 2026 12:38:44 +0000

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

You Know What's Worse Than Not Being Able to Log In?

Being told everything worked right up until you try to actually use your account.

Yes, that was a real bug.

And, somehow, I ended up being pulled into another authentication mystery. At this point, I’m starting to think authentication bugs have a personal grudge against me. 😅

In my previous Smash Story, I wrote about a bug where users simply couldn't log in. This time, the problem was sneakier because most of the flow looked completely healthy. The user was approved, the background task ran, the email and SMS arrived, and Cognito had a user.

Then the user actually tried to use their account.

And everything fell apart.

It Started With Two User Pools

The authentication setup was fairly large and had evolved over time, so there wasn't one shiny User Pool doing everything.

We had an older Cognito User Pool supporting existing authentication flows, including mobile-based signup, while a newer User Pool handled a newer flow where users received an email containing their PIN. Both pools were intentional because they supported different parts of the authentication journey.

That wasn't the problem.

The interesting part was that the application database had its own representation of a user, while Cognito had another. On top of that, some of the work connecting those two systems happened asynchronously.

As long as everyone agreed about who the user was, nobody cared.

The moment they disagreed, authentication became very interested.

The Tiny Timing Window

The problem appeared in the partner and dependant journey.

A member could create a partner or dependant during signup or later from the member details area. A relevant non-member user would then approve the account, which scheduled an asynchronous task called SendingEmailsAfterApprovalBot in a TaskList database table.

That task ran every 15 minutes, and once it executed, the partner or dependant received an email and SMS containing a code. They could then confirm their account, set a password and sign in.

Sounds reasonable, right?

Now imagine this.

A partner gets approved at 10:01 AM, so the background task is scheduled and everyone moves on with their lives. At 10:05 AM, before the task has run, the partner changes their name.

That tiny change matters because the username for partner and dependant accounts is derived from their details. The database now has the new username, while Cognito may still know about the old username.

Nothing has visibly broken yet.

The task is still waiting patiently in the database, completely unaware that the identity it is about to process has changed underneath it.

Then, 15 minutes later, it wakes up.

Cognito Says, "I've Seen This Email Before"

The background task tries to create the Cognito user using the latest username stored in the database.

Cognito rejects the creation because the email address is already associated with an existing user, but that user has a different username.

And there is an important detail here: the Cognito username is immutable.

So we weren't dealing with a simple "just update the username" situation. We had two systems describing the same person with different usernames, and Cognito was quite reasonably refusing to create another user with the same email.

The database was saying:

"This is the current username for this person."

Cognito was effectively saying:

"I already know this email, and it belongs to someone with another username."

Same human.

Different digital identity.

And that mismatch was enough to break the journey.

Everything Looked Fine... Until It Didn't

What made this bug particularly sneaky was what happened next.

The user could still receive the expected email and SMS. There was no obvious failure screaming for attention. The asynchronous task had run, notifications had gone out and Cognito already had a user associated with the email.

So the user did what any reasonable person would do: they followed the instructions.

They entered their code, tried to confirm their account and attempted to set their password.

Except the identity represented in Cognito didn't match the latest identity represented in the database.

The user wasn't looking at a database synchronisation problem. They weren't thinking about immutable Cognito usernames or asynchronous jobs. They had received a perfectly legitimate code and were simply trying to finish creating their account.

From their perspective, the system had basically said:

"Here's your code. Everything is ready!"

Then:

"Actually... never mind."

That was the bug we had to chase.

Enter Sentry

By this point, we knew something was going wrong somewhere between the database, the background task and Cognito, but knowing where it broke was another story.

This is where Sentry became extremely useful. The error context gave us the details around the Cognito failure, while the breadcrumbs helped reconstruct the events leading up to it. Instead of seeing a Cognito error in isolation and assuming we simply had a duplicate-user problem, we could look at what happened before the failure and connect it back to the user's journey.

The important clue was that Cognito was rejecting the user creation because the email was already associated with an existing user. That told us what Cognito didn't like, but the surrounding context helped explain why we had reached that point in the first place.

We could see the relevant user and operation context around the failure, follow the activity leading up to the Cognito call, and use the correlation ID to connect the same operation across services and logs. That made it much easier to piece together the timeline rather than chasing individual log entries and hoping they belonged to the same request.

And once the timeline was visible, the problem suddenly made sense:

approval → delayed task → name changed → username changed → Cognito already has the email → creation rejected → identities drift apart → confirmation fails

That was the moment the bug stopped looking mysterious.

The code told us what should happen. Sentry's error context, breadcrumbs and correlated logs helped us see what actually happened.

And honestly, that's one of the best parts of having good observability during an authentication investigation. The error tells you where the system complained; the breadcrumbs help you understand the story that led it there.

The Fix Was Simpler Than the Investigation

Once we understood the problem, the fix was surprisingly straightforward.

We already checked whether a Cognito user existed for the email, but we were treating that as enough. Instead, we changed the logic to ask: "Does the correct Cognito user for the current database record exist?"

If the email existed in Cognito but belonged to an outdated username, we deleted that user and recreated it with the latest username from the database. Since Cognito usernames are immutable, recreating the user was necessary to bring the two systems back into alignment.

The important change wasn't the delete-and-recreate itself. It was recognising that the database was the source of truth for the current username, while Cognito could still be holding an older representation of the same person.

The Weird Scenario Was the Important One

The happy path already worked, so the interesting tests were the ones where state changed between steps.

We tested the normal signup flows, partner and dependant creation, existing Cognito users, missing Cognito users and, most importantly, the scenario that exposed the bug: a partner or dependant was approved, changed their name before SendingEmailsAfterApprovalBot ran, and then the background process tried to create their Cognito user using the latest database state.

We then verified the part that actually mattered: could they receive their PIN, confirm their account, set their password and successfully sign in?

Because nobody cares about our beautifully synchronised identity records. They just want to get into their account.

The Interesting Part Wasn't Actually Cognito

Looking back, this wasn't really a Cognito bug. The database wasn't broken, and neither was the scheduled task. Each component was behaving according to its own rules.

The problem was the assumption connecting them: that the identity we started processing would still be the identity we needed when the asynchronous process eventually ran.

Then someone changed their name.

That small change was enough to make the database username different from the immutable username already held by Cognito. Since the email was already taken, Cognito rejected the new user creation and the two systems drifted apart.

That's the lesson I took from it: whenever identity exists in multiple systems, you need to be explicit about which system is the source of truth and what happens when those representations disagree.

Because eventually, they will.

Someone will change their name. A background job will run later. A legacy system will already have a record. And Cognito will quite reasonably tell you that it has seen that email before.

And That's What Made This Bug So Sneaky

The approval worked, the task ran, the notification was sent, Cognito had a user and the user followed the instructions. Yet somewhere between those perfectly reasonable steps, the identity had drifted.

From the user's perspective, none of the underlying details mattered. They didn't know there were two User Pools, that the old pool handled mobile signup while the newer one sent the email PIN, or that a background task ran every 15 minutes.

They simply knew they had done everything they were asked to do and still couldn't get into their account.

Which brings me back to the opening question.

What's worse than not being able to log in?

Being told everything worked right up until you try to actually use your account.

At least a failed login is honest. This bug was more like:

"Congratulations! Everything worked!"

"Really? Because I'm still locked out."

And that's probably the biggest lesson I took away from it: when debugging authentication, don't just look at the login screen. Follow the identity through the entire system, use your observability tools to reconstruct what actually happened, and find the moment when the different pieces stopped agreeing about who that user was.

Because sometimes the authentication bug isn't hiding at login.

Sometimes it's hiding in a background job, quietly waiting for someone to change their name.

Auth strikes again. 🔐🐛

You Know What Happens When There's a Bug in Authentication? Absolutely Nothing.

ujja — Thu, 30 Jul 2026 14:23:19 +0000

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

Everything Stops

You know what happens when there's a bug in authentication?

Nothing.

Seriously... absolutely nothing.

Not because nothing is broken, but because users simply can't get past the front door. They can't log in, which means they can't access the application, complete a booking, view their information, or do whatever they came there to do in the first place.

Normally that's annoying.

But what if the application isn't just another website?

At the time, I was part of the authentication engineering team responsible for rolling out Multi-Factor Authentication (MFA) for government service centres across the state. These weren't internal dashboards or social media apps. These were systems used every day by frontline staff helping thousands of citizens.

No login meant staff couldn't process driver's licence applications or renewals. They couldn't register births, deaths or marriages. They couldn't update identity records. During emergencies, they couldn't access systems used to support disaster relief efforts.

The application itself was perfectly healthy. The backend was running. APIs were responding. Databases were online.

But none of that mattered.

Authentication is the front door. If the front door doesn't open, it doesn't matter how well the rest of the house is built.

A Rollout We Thought Was Perfect

Because authentication is so critical, we treated the rollout with the level of care you'd expect.

We had unit tests, integration tests, end-to-end tests, security reviews and user acceptance testing. We tested happy paths, failure scenarios, edge cases and everything in between.

Everything passed.

The rollout went live.

For a while, everything looked great.

Then a few support tickets started appearing.

Some users couldn't log in.

The strange part was that it only affected a handful of people. Most users authenticated successfully, while a small group consistently received a server error.

Those are the bugs every engineer dreads.

If nobody can log in, you usually know where to start.

If only some users can't log in, every assumption suddenly becomes a possibility.

Was it their browser?

Their location?

Their account?

A feature flag?

Some weird cached session?

We checked everything.

We dug through authentication logs, replayed requests, inspected network traffic, reviewed configuration, and read the login code more times than I'd like to admit.

Everything looked correct.

Stop Looking at Logs. Watch People.

Eventually, our team decided to do something different.

Instead of staring at dashboards and log files, we visited one of the service centres and watched people use the application.

Within minutes, we noticed something.

The users clicking the Login button with their mouse authenticated successfully every single time.

The users navigating with the keyboard, pressing Tab and then Enter, consistently hit the server error.

That tiny observation immediately felt important.

As the feature lead developer for the MFA rollout, something clicked.

This wasn't random.

This wasn't infrastructure.

This wasn't the backend.

It had to be the browser.

The Smallest Bug with the Biggest Impact

The culprit?

One missing line.

e.preventDefault();

For anyone unfamiliar with it, e.preventDefault() prevents the browser from performing its default action.

In a React Single Page Application, forgetting it during form submission means the browser performs a traditional form submission instead of letting React handle the authentication flow.

Our React application was being bypassed completely.

Instead of executing our login logic, the browser submitted the form directly to the backend.

Mouse clicks happened to work through our React event handler.

Keyboard submissions didn't.

Every automated test had passed.

Every security review had passed.

And yet government service centre staff couldn't access the systems they needed simply because one line of code was missing.

The Lesson Wasn't About `e.preventDefault()`

I'm proud that once I saw someone press Enter, I immediately suspected browser default behaviour and tracked the problem back to the missing e.preventDefault().

But honestly, that wasn't the biggest lesson.

The biggest lesson was about users.

We spend a lot of time talking about AI-assisted development, automated testing and improving engineering productivity.

I'm a huge believer in all of them.

AI helps me write better code, generate tests, review pull requests and explore solutions much faster than I could a few years ago.

But AI only validates the scenarios we think to test.

Real users don't.

Some never touch a mouse.

Some navigate entirely with a keyboard.

Some use assistive technologies.

Some interact with software in ways we'd never think of while sitting at our desks.

No amount of automation can replace watching someone actually use your application.

Final Thoughts

Whenever people ask me about memorable production bugs, I don't think about distributed systems failures or obscure race conditions.

I think about a missing e.preventDefault().

One line of code.

A rollout that had passed every test.

And government service centres where staff couldn't help citizens because someone pressed Enter instead of clicking a button.

Sometimes the smallest bugs have the biggest impact.

Passion Atlas: A Living Map of Human Curiosity

ujja — Sun, 12 Jul 2026 15:32:47 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built Passion Atlas — an AI-powered map of human curiosity that helps people discover how their interests, experiences, cultures, and ideas connect.

The idea started from something I noticed about myself: I have never had a single passion.

Throughout my life, my interests kept evolving — from anime to dance, boxing to travel, food, culture, and understanding how people live around the world. For a long time, I thought this meant I lacked focus.

But I eventually realised my interests were not random; they were connected.

Anime introduced me to storytelling and different cultures. Dance connected me to movement and expression. Boxing taught me discipline and human psychology. Travel connected everything through food, history, traditions, and people's stories.

Maybe humans are not designed around one fixed passion. Maybe curiosity itself is the passion.

Our minds naturally explore, combine, and connect ideas. The most meaningful discoveries often happen when seemingly unrelated interests come together.

Passion Atlas was built around this idea:

Your interests are not separate islands. They are a connected universe.

Introducing Passion Atlas

Passion Atlas creates a personal Passion Genome — a living representation of someone's curiosity.

Instead of asking:

"What is your passion?"

It asks:

"What are all the things that make you curious, and how do they connect?"

A user might enter:

Travel
Food
Photography
History

Instead of generating a generic recommendation list, Passion Atlas creates connections:

Travel

↓

Cultural Exchange

↓

Local Food Traditions

↓

Storytelling

↓

Heritage Preservation

↓

Traditional Crafts

The goal is not to tell people what they should like.

The goal is to reveal connections they never noticed.

Passion Genome: Your Curiosity Fingerprint

Every person has a unique combination of experiences.

Two people can love the same thing but have completely different curiosity paths.

For example:

Person A:

Photography
+
Travel
+
History

=

Cultural Storytelling

Person B:

Photography
+
Nature
+
Science

=

Environmental Documentation

The same interest can evolve into completely different worlds.

Passion Atlas captures these unique intersections.

The Passion Butterfly Effect

Small moments can create unexpected journeys.

A single experience:

"I attended a traditional tea ceremony in Japan."

Could become:

Tea Culture

↓

Japanese Aesthetics

↓

Ceramics

↓

Traditional Crafts

↓

Sustainable Design

A small spark creates a larger curiosity path.

Passion Atlas helps reveal these hidden chains.

Curiosity Wormholes

Most recommendation systems optimise for similarity.

Passion Atlas optimises for meaningful surprise.

Instead of:

"People who like hiking also like camping."

It explores:

Hiking

↓

Mountain Ecosystems

↓

Indigenous Knowledge

↓

Ancient Navigation

↓

Astronomy

Because sometimes the best discovery is something you were never searching for.

Preserving Human Stories

Passion is not only about consuming knowledge.

It is also about preserving it.

Across the world, thousands of traditions, recipes, crafts, and personal stories risk disappearing.

Passion Atlas creates Passion Time Capsules.

People can contribute:

personal stories
cultural memories
recipes
artisan knowledge
images
audio recordings
videos

AI transforms these into connected cultural experiences.

A grandmother's recipe is not just a recipe.

It is connected to:

migration
family history
geography
tradition
identity

Every story becomes part of the global curiosity map.

How I Built It

Passion Atlas is an AI-native application built using specialised agents.

Passion Extraction Agent

Transforms human stories into structured curiosity data.

It identifies:

interests
emotions
motivations
cultural context
related concepts

Example:

Input:

"I love making traditional food with my grandmother."

Output:

Cooking

Family Heritage

Traditional Knowledge

Cultural Preservation

Curiosity Graph Agent

Builds relationships between:

passions
stories
locations
cultures
experiences

The graph continuously evolves as more people contribute.

Discovery Agent

Finds unexpected connections.

It considers:

novelty
relevance
emotional connection
cultural depth

Cultural Preservation Agent

Transforms human experiences into meaningful knowledge:

summaries
translations
context
connected discovery paths

Demo

The app currently runs on local as it needs environment values. However, a simulation version is deployed on Vercel.

passion-atlas.vercel.app

Code

ujjavala / passion-atlas

🌌 Passion Atlas

A living map of human curiosity.

Passion Atlas is an AI-powered map that helps people discover how their interests, experiences, cultures, and ideas connect. Instead of asking "What is your passion?", it asks "What are all the things that make you curious — and how do they connect?" and renders the answer as a personal Passion Genome: a constellation of your curiosity where unexpected bridges between seemingly unrelated interests light up.

Your interests are not separate islands. They are a connected universe.

Built for the dev.to Weekend Challenge: Passion Edition.

✨ Features

Each screen is a different lens on the same living curiosity graph:

Screen	What it does
🌌 Atlas (Canvas)	Enter a passion and watch it expand into a constellation. Drill into any node to discover its connections; claim ownership of a discovery path on-chain.
🧬 Genome	Your personal "Passion Genome" — the

…

View on GitHub

Prize Categories

🏆 Best Use of Google AI

Google Gemini powers the reasoning layer.

It helps:

extract hidden passions from stories
understand semantic relationships
generate Passion Genomes
discover unexpected connections

Gemini enables the system to reason across thousands of possible curiosity pathways.

🏆 Best Use of Snowflake

Snowflake powers the global Passion Graph.

It stores and analyses:

passion relationships
cultural stories
discovery patterns
human curiosity trends

Over time, the system can uncover patterns like:

"People interested in ceramics often explore gardening, architecture, and sustainable design."

The graph becomes richer with every contribution.

🏆 Best Use of ElevenLabs

Passion is emotional.

A story is not always the same when read as text.

ElevenLabs enables:

voice-based memories
multilingual storytelling
emotional narration

A craftsperson can share their knowledge in their own voice.

A family story can remain human.

🏆 Best Use of Solana

Passion Atlas introduces a contribution layer.

Human knowledge creates value, but contributors are often invisible.

Solana enables:

transparent recognition
contributor rewards
community incentives

Example:

Traditional Weaving Story

↓

500 people discovered this tradition

↓

Contributor recognised

↓

Community preservation supported

The goal is not to financialise every passion.

The goal is to recognise people who preserve and share human knowledge.

Why Passion Atlas?

The internet already connects:

people
places
products
information

But it does not connect something deeply human:

curiosity.

Maybe having many passions is not a lack of direction.

Maybe it is a different way of exploring the world.

Our interests are not random dots.

They are a map.

Passion Atlas helps us discover the connections.

Because every passion leads somewhere.

And every person carries a universe of curiosity waiting to be explored.

How I Built a Turing inspired Treasure-Run Game Where Australia Saves the Sun

ujja — Wed, 10 Jun 2026 08:41:06 +0000

This is a submission for the June Solstice Game Jam

What I Built

For this game jam, I built Dawn Dashers, an adventure runner set during the June Solstice, the longest night of the year in Australia.

The idea started with a simple question:

What if the longest night didn't end?

In Dawn Dashers, a rogue machine called the Turing Engine has stolen the sunrise and scattered seven Sun Fragments across Australia. Players race through deserts, bushland trails, coastal cliffs, and hidden ruins to recover the fragments and bring daylight back.

The game takes inspiration from the June solstice, but with an Australian treasure-hunting twist. Along the way, players dodge obstacles, collect relics, unlock animal abilities, and solve quick logic puzzles inspired by Alan Turing.

One thing I wanted to avoid was making the solstice just part of the story. Instead, it's part of the gameplay itself. At the start, the world is trapped in darkness. As players recover Sun Fragments, the environment gradually becomes brighter, warmer, and more alive until the final sunrise returns.

The goal was simple:

Build something fun first, while using the June Solstice as the heart of the adventure.

Video Demo

You can also try:

Running through the Australian Outback
Discovering treasure clues
Solving Turing-inspired logic challenges
Collecting Sun Fragments
Unlocking animal abilities
Watching the world transform from the longest night back into daylight

... directly through the deployed game (using Vercel)

dawn-dashers.vercel.app

Code

GitHub Repository

Built with:

Vanilla JavaScript — game.js is the entire game engine (~6500+ lines)
Three.js — 3D terrain rendering behind the 2D gameplay HUD
Web Audio API
HTML/CSS — index.html, inline UI modals, HUD
GitHub Copilot

How I Built It

I started by focusing on the core gameplay loop:

Run → Dodge → Collect → Discover → Restore Light

Once movement felt fun, I started layering in everything else.

Making the Solstice Matter

The biggest design decision was making the June Solstice an actual game mechanic rather than just background lore.

The game begins during the longest night of the year. Every Sun Fragment recovered pushes the world closer to dawn.

As players progress:

Darkness slowly recedes
New areas become visible
Lighting becomes warmer
The world feels more hopeful

By the end of the game, the player has literally restored the sunrise.

Building an Australian Adventure

Rather than using generic fantasy locations, I wanted the game to feel distinctly Australian.

The adventure takes players through:

Outback ruins

Bushland trails

A quirky roadside servo

Coastal lighthouse cliffs

Mangroves

Blue Mountains

Nullarbor

Observatory

Aurora-lit Tasmania

Each region introduces new obstacles and visual themes while keeping the action moving.

A Nod to Alan Turing

Since June is also Alan Turing's birth month, I wanted to include a tribute without turning the game into a history lesson.

The game's antagonist, the Turing Engine, believes that endless night is the most logical state of existence.

Players encounter quick puzzles based on:

Pattern recognition
Binary switches
Signal routing
Light circuits

The puzzles are short and designed to support the action rather than interrupt it.

TM Corridors — Turing's Run

At three points in the expedition, the world stops being a runner and becomes a Turing Machine you operate by hand. The level fades away and you step into a glowing sci-fi corridor rendered in one-point perspective — a hallway that is the tape, charging toward a vanishing-point portal.

The story is told in three chapters, framed as Alan Turing bypassing three sealed gates:

Corridor	Machine	The gate demands
I of III	Bit Flipper	Invert every bit until the blank
II of III	Parity Checker	Open only for an even number of `1`s
III of III	Even-Length Protocol	Accept only an even-length message

Art Direction

One of the biggest pivots during development was moving away from a bright arcade aesthetic and leaning into a treasure-hunting adventure style.

The world uses:

Warm desert colours
Ancient ruins
Dust particles
Golden sunlight effects
Treasure-map inspired UI

This direction helped tie together the themes of the solstice, exploration, and treasure hunt.

Technology

The game was built using:

Vanilla JavaScript — game.js is the entire game engine (~6500+ lines)
Three.js — 3D terrain rendering behind the 2D gameplay HUD
Web Audio API
HTML/CSS — index.html, inline UI modals, HUD
Vercel Deployment
GitHub Copilot for development acceleration

The focus throughout was on keeping the project lightweight, responsive, and playable directly in the browser.

Prize Category

Best Ode to Alan Turing

Dawn Dashers is a love letter to Alan Turing, the mathematician, codebreaker, and father of Theoretical computer scientist who was born on 23 June 1912.

Rather than focusing on historical events, I wanted to celebrate the ideas that made his work so influential: logic, patterns, problem-solving, and computation.

The Turing Engine serves as the main antagonist, and players overcome its challenges through quick puzzles inspired by computational thinking.

P.S. For fellow nerds (like me 😄), each puzzle comes with a little extra bit of knowledge. Just click "Learn why this puzzle matters".

In the characters

The 27 playable dashers are all Australian animals and each character's power and quirk are inspired by
concepts from Turing's work:

Emu — relentless forward motion (Turing's unstoppable curiosity)
Wombat — burrow-dodge (evasion, steganography)
Echidna — spiny defence (cryptographic hardening)
Cassowary — apex predator speed (Colossus, the world's first electronic computer)

The "special" dashers can only be unlocked by solving enough treasure puzzles — a direct nod to
the idea that Turing's deeper insights were hidden behind layers of prior work.

In the Game engine

The game's lifecycle is modelled as a real Turing Machine (see Architecture below).
States are labelled q_*, input symbols σ_*, and every transition is written to a tape
with a head that advances R, stays S, or — on a level abort — rewinds L.
This isn't just a metaphor: the implementation is a literal δ(q, σ) → (q′, dir) transition table.

┌─────────────────────────────────────────────────────────────────────┐
│  Browser                                                            │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  game.js  (core)                                             │   │
│  │                                                              │   │
│  │   Run loop / input                                           │   │
│  │        │                                                     │   │
│  │        │  sendFlow(σ_*)        ┌─────────────────────────┐   │   │
│  │        ├─────────────────────► │   game-state.js         │   │   │
│  │        │  ◄── state flags ──── │                         │   │   │
│  │        │                       │   Turing Machine        │   │   │
│  │        │                       │   Q  states  (q_*)      │   │   │
│  │        │                       │   Σ  symbols (σ_*)      │   │   │
│  │        │                       │   δ  transition table   │   │   │
│  │        │                       │   tape[]  head ptr      │   │   │
│  │        │                       └─────────────────────────┘   │   │
│  │        │                                                      │   │
│  │        ├── Puzzle pick & dedup ──► puzzle-tracker.js          │   │
│  │        │                               │                      │   │
│  │        │                          puzzle-filter.js            │   │
│  │        │                               │                      │   │
│  │        │                          puzzle-data.js              │   │
│  │        │                          ├── questions-easy.js       │   │
│  │        │                          ├── questions-medium.js     │   │
│  │        │                          └── questions-hard.js       │   │
│  │        │                                                      │   │
│  │        ├── Three.js + Canvas render                           │   │
│  │        │        └── terrain-styles.js                         │   │
│  │        │                                                      │   │
│  │        └── Config reads                                       │   │
│  │             ├── character-config.js                           │   │
│  │             ├── game-data.js                                   │   │
│  │             └── game-settings.js                              │   │
│  │                                                               │   │
│  │  game-ui.js ──ctx callbacks──► game.js                        │   │
│  └──────────────────────────────────────────────────────────────┘   │
│                                                                     │
│  index.html  (loads all modules via <script> tags)                  │
└─────────────────────────────────────────────────────────────────────┘
         ▲
         │  served by
┌────────┴────────┐
│  Nginx (Docker) │
│  docker-compose │
└─────────────────┘

Best Google AI Usage

I'm also submitting for Best Google AI Usage.

I'll be honest: I'm much more comfortable building systems and writing backend code than designing beautiful interfaces.

One of the challenges during this project was figuring out how to make Dawn Dashers feel cohesive visually. I had a rough idea of the atmosphere I wanted—an Australian treasure-hunting adventure, but translating that into colours, layouts, typography, and UI design isn't my strongest skill.

That's where Google Stitch helped.

I used Stitch to explore rapidly:

UI layouts and screen structure
Menu and HUD designs
Colour palettes
Typography combinations
Visual hierarchy
Overall art direction

What impressed me most was how easy it was to iterate. Instead of spending hours moving elements around in a design tool, I could describe the feeling I wanted and quickly generate multiple directions to evaluate.

For example, I started with a fairly generic arcade-style look, but through a few iterations in Stitch, I landed on a much stronger visual identity built around:

Warm desert colours
Treasure-map inspired UI
Gold accents
Weathered parchment styling
Adventure-game aesthetics

Those explorations directly influenced the final design language of the game.

I also used Gemini extensively during the design phase.

One challenge was incorporating Alan Turing-inspired puzzles without making the game feel like a classroom exercise. I wanted puzzles based on logic, patterns, and computation, but they also needed to feel like they belonged in an Australian treasure-hunting adventure.

Gemini helped me brainstorm and refine puzzle concepts such as:

Pattern recognition challenges
Binary switch puzzles
Signal routing mechanics
Treasure clues tied to Australian locations and wildlife
Turing-inspired logic challenges that could be solved quickly during gameplay

For example, I used Gemini to take abstract puzzle ideas and re-theme them into Australian contexts, turning generic logic puzzles into clues involving lighthouses, Outback landmarks, wildlife, and hidden Sun Fragments.

The combination of Stitch and Gemini helped bridge two areas where I typically spend a lot of time: design exploration and content creation. Instead of starting from a blank page, I could rapidly iterate on ideas, evaluate options, and focus more of my time on building and polishing the game itself.

The AI tools didn't replace the creative decisions—they helped me reach better ones faster.

As a solo developer, having a tool that could help bridge the gap between "I know what I want it to feel like" and "I know how to design it" was incredibly valuable. It let me spend more time building gameplay while still ending up with a much more polished visual experience.

Google Stitch didn't replace the design decisions—it helped me discover and refine them much faster.

Happy Dashing !!!

Thanks for checking out Dawn Dashers 🌅

It was a lot of fun combining the June Solstice, Australian landscapes, treasure hunting, arcade runners, and a small nod to Alan Turing into one adventure.

Is Zero Trust Enough for Agentic Systems?

ujja — Tue, 02 Jun 2026 13:45:15 +0000

I’ve always had a soft spot for authentication systems.

About seven years ago, I started working on auth, and something just clicked. What began as login flows slowly turned into a deeper curiosity about identity, permissions, and how systems decide who gets to do what.

Over time, I’ve worked with tools like Keycloak, Auth0, Okta, and Ping Identity. Different platforms, same core idea kept showing up:

Never trust. Always verify.

For a long time, that felt like the finish line.

Lately, though, it’s starting to feel more like the starting point.

The moment systems stop responding… and start acting

During a recent hackathon, I built something called PlanetLedger. The idea was simple: upload your bank statement to see your environmental impact.

But under the hood, it didn’t behave like a typical app.

An upload didn’t just return a response. It kicked off a series of actions. First, it parsed transactions. Then, it categorised vendors. Next, it calculated a score. It also generated insights and triggered notifications. Finally, it updated a memory timeline for future runs.

All of that started from a single call:

await openClawChainedTrigger(session.user, previousScore);

Which quietly unfolded into:

transactions_uploaded → score_calculated → insights_generated → score_improved

At some point while building this, I realised something had changed.

This wasn’t a request-response system anymore.

It was a system that kept acting.

Where Zero Trust fits perfectly… and where it doesn’t

From a security perspective, I did everything by the book.

Every API route checks whether the agent is allowed to perform an action:

export function canPerform(scopes, resource, action) {
 const required = FGA_RULES[resource]?.[action];
 return required ? scopes.includes(required) : false;
 }

Scopes are tightly defined. Every action is verified. Nothing runs without permission.

If you look at this through a Zero Trust lens, it’s solid.

And yet, the most interesting problems I ran into had nothing to do with access.

They showed up after access was granted.

The real question isn’t “can it act?” — it’s “should it keep acting?”

Take something as simple as a high-impact alert:

export async function highImpactAlert(event) {
 const score = getScore(pseudonymize(event.userId));
 if (!score) return;
if (score.impactScore < 40) {
 pushNotification(event.userId, {
 type: "high_impact",
 title: "High-Impact Alert",
 body: ${score.highImpactCount} high-impact transactions detected,
 });
 }
 }

Everything here is valid.

The user is authenticated. The system has permission. The action is allowed.

But there’s a more subtle question hiding underneath:

Should this alert be triggered right now?

Because that depends on things Zero Trust doesn’t see.

Maybe the score calculation was slightly off. The categorisation step earlier in the pipeline may have misfired. Maybe the context wasn’t complete yet.

Each step is correct individually.

But the outcome might still be… wrong.

When valid steps create questionable behaviour

One of the most interesting things about the OpenClaw pipeline was how easy it was to compose behaviour.

You can attach multiple workflows to the same event:

registerOpenClawTrigger("transactions_uploaded", autoInsightOnUpload);
 registerOpenClawTrigger("transactions_uploaded", highImpactAlert);

On their own, these are harmless.

One generates insights. The other sends alerts.

But together, they begin to shape how a user interprets their financial behaviour. Add weekly reports, detect patterns, and make recommendations. Then, the system starts to influence decisions.

And that’s where things get tricky.

Because even if every individual step is valid, the overall direction can drift.

Zero Trust doesn’t track that. It validates moments, not trajectories.

Intent is where things start to slip

PlanetLedger uses a RAG layer to generate insights grounded in user data:

const ragContext = buildRagContext(transactions, score); const insights = buildAgentInsights( transactions, event.payload?.userContext, score, ragContext );

This works surprisingly well most of the time.

But occasionally, you’ll see something slightly off. A recommendation that technically makes sense but doesn’t quite match what you’d expect. A pattern that’s overemphasised. A suggestion that feels a bit… disconnected.

Nothing is broken.

But something feels misaligned.

That’s the gap.

Zero Trust ensures the system is allowed to act. It doesn’t ensure the system is acting with the right intent.

The part that surprised me: drift

The more I worked with chained workflows, the more I noticed this subtle effect.

If something is slightly off early in the pipeline — say, a categorisation edge case — that error doesn’t stay isolated. It propagates.

It affects scoring. Which affects insights. Which affects alerts. Which affects what the user sees.

By the time it surfaces, it’s no longer obvious where it started.

Everything along the way was technically valid.

But the outcome feels wrong.

That’s drift.

And it’s not something traditional access control is designed to catch.

So what actually helps?

I didn’t sit down with a framework for this. Most of these ideas came from trying to make PlanetLedger behave more predictably.

One thing that helped was thinking beyond request-level authorisation.

Because the pipeline continues after the initial API response, decisions are being made in a flow, not a single moment. That means authorisation needs to become aware of state, timing, and sequence — not just whether a token is valid.

Another thing that made a difference was leaning into deterministic rules where it mattered. The scoring system, for example, is intentionally simple and explainable. Not because an LLM couldn’t do it, but because predictability is a form of control.

The structure of OpenClaw itself also acts as a constraint. It’s deliberately minimal — no retries, no replay, no distributed guarantees. At first, that feels like a limitation, but it actually forces the system to operate within clear, bounded behaviour. It can only do what the registered workflows define.

Logging was another area that evolved quickly. Moving from plain logs to structured outputs made it easier to trace what happened. But even that surfaced a deeper need: understanding why a decision was made, not just what happened.

And then there’s step-up.

In traditional systems, step-up authentication is about verifying identity at critical moments. But in systems like this, identity isn’t usually the weak point. The question isn’t “is this really the user?”

It’s “Should this decision go through?”

That shift—from checking identities to validating decisions—looks small. But it changes how you make safeguards.

What this starts to look like in practice

After building something like PlanetLedger, the architecture stops being just about access control.

Zero Trust still sits at the base, making sure only the right actors can do the right things.

But on top of that, you start layering systems that understand behaviour over time. Systems guide actions. They spot patterns and notice when things feel off. Sometimes, they bring a human back in when the stakes are high.

None of these replaces Zero Trust.

They fill in the gaps that it was never designed to cover.

Final thought

Zero Trust is still essential.

Without it, systems like PlanetLedger wouldn’t hold up for a second.

But once systems move from simply responding to requests to continuously making decisions…

Trust stops being something you verify once.

It becomes something you evaluate, quietly and continuously, across everything the system does.

DEV Community: ujja

🤖 What happens when your AI agent trusts outdated docs? I built Docgrity to find the gaps.

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

GitHub - ujjavala/docgrity-vscode: Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. · GitHub

I built PadForward because sometimes you just need a pad

What I Built

"Does anyone have a pad?"

So, what is PadForward?

If you need one, you shouldn't have to ask

But where do the pads come from?

And yes, I'm using Solana for the donation

I didn't want another chatbot

And what if the AI isn't available at all?

Snap the box — AI that counts pads from a photo

What if the map says there are pads, but there aren't?

The people who keep it going

The bigger idea is the network

There's a lot more I want to do with it

Why PadForward?

Demo

Code

How I Built It

Prize Categories

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖

Start with your repo

VS Code

CLI

GitHub Action

And now, Confluence

Zero infrastructure

AI Engineering Is Easy. Changing How We Work Is Hard

The workflow is changing

Maybe coding isn't the bottleneck

More documentation isn't always better

The ticket might be the problem

The agent needs to see the real system

So, are we ready?

I Love Dogs, But Dogs Scare Me — So I Built Pawsitive with Gemini 🐾.

What I Built

Demo

How I Built It

Making Pip feel alive

🧠 The Gemini Experiment

Private on-device fallback with Gemini Nano

What amazed me about the private mode

Prerequisites for private on-device analysis

The Learning Journey

🐕 The Owner Perspective

Testing the Safety Net

Why I Built It

🏆 Prize Category: Best Use of Google AI

🔮 Giving Pip a Voice with ElevenLabs

What's Next?

Turning Ayurveda’s Six Rasas Into CSS Art

Inspiration

The CSS Art

Making Food Without Food Images

Six Handcrafted Taste Guides

Making CSS Feel Less Like CSS

CSS Art With a Purpose

84 Dishes Instead of Six

The Technical Side

Accessibility Still Applies to CSS Art

What I Learned

Demo

ujjavala / rasa

Rasa — The Tongue Map of India

Why this project exists

What's Next?

Designing a Landing Page That Feels Like Opening a Food Journal

What I Built

The Landing Page Is the Beginning, Not the Destination

Why a Tongue?

From Landing Page to Field Journal

Meet the Guides

The Notebook

Designing for Accessibility From the Start

Motion With Meaning

The Visual Language

Technical Stack

The Lesson Wasn't About `e.preventDefault()`