DEV Community: swatiicfai

How I Built an Autonomous SRE War Room with Switch AI, OpenCode & Wispr Flow

swatiicfai — Thu, 05 Nov 2026 22:03:47 +0000

When a production outage hits at 2 AM, every second counts. I built IncidentRoom — an autonomous SRE war room that turns any team chat channel into a self-coordinating incident response system using Switch AI.

Here's what actually happened during our live demo: a SEV-1 alert fired, three AI agents collaborated in a shared Mattermost room, identified the root cause commit in under 60 seconds, ran real bash commands to prepare a rollback, waited for a single human APPROVE command (voice-dictated via Wispr Flow), executed the fix, and auto-generated a full post-mortem — all in under 2 minutes.

The Problem We Solved

Traditional incident response is chaotic:

Context is fragmented across monitoring tools, Slack threads, and git history
Engineers waste precious minutes manually correlating stack traces to recent PRs
Stakeholder updates distract the on-call engineer from actually fixing the issue
Post-mortems are written hours or days later from memory

MTTR (Mean Time to Resolution) suffers not because engineers are slow — but because coordination is broken.

Enter Switch AI

Switch is an open-source platform that connects AI coding agents (Claude Code, Codex, OpenCode, Cursor, Antigravity) into team chat channels as first-class participants. Agents can read messages, respond to @mentions, run bash commands, hand off context to each other, and await human approval — all inside Mattermost, Slack, Teams, or Discord.

This is the missing piece for incident response.

Architecture: 3 Agents, 1 Room, Zero Chaos

📢 Alert fires in #incident-war-room
       │
       ▼
@triage-agent ──→ 11 tool calls ──→ Root cause: commit 8f2b31a
       │
       ▼ HANDOFF
@sre-agent ──→ npm pack stripe@3.4.0 ──→ "Awaiting APPROVE"
       │
       ▼ Human: "APPROVE" (via Wispr Flow voice)
@sre-agent ──→ Rollback executed ✅
       │
       ▼
@comms-agent ──→ Post-mortem generated 📄

The Three Agents

@triage-agent — The Incident Detective

Receives the alert via @mention, parses the stack trace, correlates against recent git commits, and isolates the root cause. In our live demo:

triage-agent BOT · Worked for 3m 16s. 11 tool calls.

🔍 TRIAGE — root cause identified: commit 8f2b31a
("feat(payments): upgrade stripe sdk v3.4")

Root cause: services/payments/stripe_gateway.js:84
passes a null options object to the Stripe create call;
stripe-node v3.4 now unconditionally reads options.idempotency_key,
so createSession throws before reaching Stripe.

@sre-agent — The Remediation Specialist

Receives the handoff, evaluates blast radius, executes real bash commands to prepare the rollback — but never deploys without human approval:

# Actual command run by @sre-agent
npm pack stripe@3.4.0 --pack-destination /tmp/opencode/stripe340

Then waits. No autonomous deployment. Human-in-the-loop is non-negotiable.

@comms-agent — The Incident Commander & Scribe

Handles stakeholder communication and auto-generates the post-mortem with MTTR, timeline, root cause, and action items.

Voice-Powered with Wispr Flow

Here's the detail that makes this truly hands-free: I used Wispr Flow to voice-dictate every incident command without touching the keyboard.

While monitoring dashboards, I spoke:

"Alert: Save one HTTP 500 error spike in checkout payment gateway at triage agent. Please investigate the root cause. Commit. Approve, roll back, and notify all stakeholders. @Comms agent generate the postmortem report."

Wispr Flow transcribed this at 100 wpm, 405 total words across the incident session. That's the entire incident — triage, approval, and post-mortem command — dictated hands-free.

The Live Results

Metric	Result
Time from alert to root cause	< 60 seconds
Triage agent tool calls	11 calls, 3m 16s
Human touch-points	1 (`APPROVE`)
Wispr Flow words dictated	405 words @ 100 wpm
MTTR	Under 2 minutes
Post-mortem generation	Automatic

Community Wisdom That Shaped This

Building this, I learned from the community:

Agentic incident response is where autonomy meets the pager — reinforced that read-only defaults and approval gates are non-negotiable
NexusOps: Multi-Agent SRE Command Center — validated the multi-agent pattern for SRE workflows

The key insight both posts validate: agents need approval gates before any write operation in production. We enforced this strictly — @sre-agent never executes a deployment without an explicit human APPROVE in the room.

How to Run It Yourself

git clone https://github.com/swatiicfai/IncidentRoom
cd IncidentRoom
cp .env.example .env  # Add your Switch server URL
npm install
node src/simulate.js  # Trigger a live SEV-1 simulation

You need:

Switch Console running locally
OpenCode (or any Switch-compatible agent) installed
Mattermost running in Docker (Switch provides this out of the box)

What's Next

Webhook integration — Datadog/Sentry/PagerDuty alerts fire directly into the room
Canary verification — @sre-agent checks error rate baseline post-rollback before declaring resolution
Multi-room escalation — auto-create a dedicated room per SEV-1 instead of using a standing channel
Agent memory — triage agent remembers past incidents to pattern-match faster

🔗 Resources

GitHub: https://github.com/swatiicfai/IncidentRoom
Demo video: https://youtu.be/gvqgkVetPTc
Switch AI: https://github.com/sandbox-quantum/switch
Post-mortem: See POSTMORTEM_LIVE.md

Built for the Flip the Switch Hackathon by WeMakeDevs × Switch AI.

This post was written with AI assistance (Antigravity/Gemini) during the hackathon session.

ResQAlert: Offline-First Community Disaster & Resource Dispatcher

swatiicfai — Sat, 31 Oct 2026 14:51:08 +0000

This is a submission for the MLH x DEV Writing Challenge

ResQAlert: Offline-First Community Disaster & Mutual-Aid Resource Dispatcher

What I Built

During natural disasters—such as tropical storms, flash floods, and severe grid blackouts—centralized emergency services are quickly inundated. Worse, cellular data (4G/5G) and home Wi-Fi frequently go down, cutting off affected families from emergency coordination.

However, basic 2G/cellular SMS signals often remain active across cell towers even when data throughput drops to zero.

ResQAlert is an offline-first disaster mutual-aid platform built to solve this communication breakdown. It allows individuals stranded in crisis zones to broadcast urgent distress signals (medical emergencies, flood rescue, drinking water shortages) or volunteer resource offers using either a web dashboard or plain offline SMS text messages.

Key Highlights:

Dual-Channel Reporting: File rescue requests through an interactive web app or by sending an SMS (NEED WATER at 450 Lexington Ave) with zero data connectivity.
Geospatial Discovery & Radius Matching: Responders can view live tactical heatmaps and query relief requests within a 5–50 km radius.
Automated Two-Way SMS Updates: When an aid ticket is claimed or resolved, the requester receives an automated SMS update with responder details and ETA.
Built-in SMS Simulator: A testing sandbox on the frontend that allows judges and reviewers to simulate incoming SMS messages and observe real-time pins drop on the map without needing live phone credits.

Demo

GitHub Repository: github.com/swatiicfai/ResQAlert
Live Deployment: https://resqalert-omega.vercel.app/

Project Highlights:

Interactive Disaster Radar: Real-time Leaflet map displaying active incident pins color-coded by urgency (Red for critical medical/rescue, Amber for food/water, Green for volunteer shelters).
Offline SMS Ingestion: When an SMS message is sent to our Twilio gateway, the backend extracts the category, severity, and location, performs spatial geocoding, stores the ticket, and replies with a tracking ID (REQ-XXXX).
Verified Responder Dispatch: Field teams can claim open requests, coordinate dispatches, and mark incidents as resolved in real time.

Partner Technologies

To make ResQAlert reliable and responsive under real-world crisis constraints, I integrated three primary partner technologies:

1. MongoDB Atlas (2dsphere Geospatial Indexing)

Implementation: Utilized MongoDB's native 2dsphere spatial index on the location.coordinates field ([longitude, latitude]).
Why it matters: In an emergency, volunteers cannot sift through an unorganized database. By leveraging MongoDB's $near operator, the platform queries and sorts nearby relief requests by physical proximity in milliseconds:

  const nearbyRequests = await db.collection("requests").find({
    location: {
      $near: {
        $geometry: { type: "Point", coordinates: [userLng, userLat] },
        $maxDistance: radiusInMeters, // e.g., 25000 (25km)
      },
    },
    status: "OPEN",
  }).toArray();

2. Twilio Programmable SMS

Implementation: Built an inbound webhook endpoint (/api/sms) that parses incoming SMS traffic and responds with automated TwiML messages.
Why it matters: When users have no cellular data or internet, SMS is their sole lifeline. Victims text NEED [Category] at [Address], the backend parses the urgency, pins the location, and sends back immediate confirmation and status alerts.

3. Auth0 by Okta

Implementation: Structured user authentication and Role-Based Access Control (RBAC).
Why it matters: In disaster mutual aid, trust and security are vital. Auth0 enables quick, frictionless sign-in for community members while protecting dispatch features with scoped roles (role:responder, role:admin), ensuring only verified teams can claim sensitive medical tickets.

Hackathon Experience

Building ResQAlert was an intense and deeply rewarding experience.

The Biggest Technical Challenge: Designing a tolerant parsing algorithm for incoming SMS messages. In an emergency, people text under extreme stress with unpredictable abbreviations and formatting. Developing a flexible keyword and landmark extractor with automatic fallback prompts required careful testing.
Favorite Moment: Watching the built-in SMS simulator trigger an incoming text and immediately seeing the glowing red marker pop up on the live Leaflet map within milliseconds!
Next Steps: Adding multi-lingual NLP translation using the Gemini API so non-English speakers can text in their native language, and implementing Progressive Web App (PWA) offline service-worker caching for field volunteers.

Ofrenda Viva: Honoring Ancestors with Gemma 2 and the Sacred Privacy of Grief

swatiicfai — Sat, 31 Oct 2026 09:56:01 +0000

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

🌼 What I Built

Every autumn between October 31 and November 2, the boundary between the living world and the spirit realm grows soft. In Mexican tradition and across the diaspora, Día de los Muertos is not a season of sorrow; it is a celebration of warmth, music, and love. We build ofrendas (altars) decorated with golden marigolds (cempasúchil), beeswax candles, sugar skulls (calaveritas), and the favorite foods, drinks, and melodies of those who walked before us.

Ofrenda Viva (Living Altar) is an open-source, local-first digital memorial sanctuary built around this tradition.

It invites you to construct an intimate, 3-tier ofrenda for a departed family member, mentor, or friend:

Tier I (The Heavens & Memory): A portrait framed in vintage gold leaf, flanked by interactive beeswax candles you can light and snuff with a click, alongside biographical reflections.
Tier II (The Earthly Joys): A collection of favorite offerings—pan de muerto, spiced hot chocolate, embroidered shawls, beloved acoustic records, and cempasúchil crosses.
Tier III (Voices of the Spirit): Two specialized open-AI tools powered by Gemma 2:
- Calaveritas Literarias Generator: Composes traditional, affectionate 4-stanza rhyming verses where La Calaca / La Catrina playfully celebrates the departed person's quirks, humor, and spirit.
- Living Memory Chronicle & Altar Blessing: Crafts a moving eulogy and sacred welcome home blessing.
- Whispers of the Altar: Candlelight voice synthesis reading the verses aloud with an ambient ceremonial rhythm (via ElevenLabs or client-side speech synthesis).

🛡️ Why Open Innovation Matters for What I Built

The challenge prompt asked:

"Tell us why open innovation matters for what you built. Does running your own model mean your project works with the lights (and the internet) off? Keep someone's data off a server they don't control? Make sure what you build isn't locked inside a service that might disappear someday?"

For Ofrenda Viva, this question is not an abstract architectural choice—it is the moral heart of the project.

1. The Sacred Privacy of Personal Grief

Grief is the most vulnerable experience in human life. When you write about an abuela's secret recipe, upload a parent's handwriting, or recount family stories, that information represents sacred ancestral memory.

If this app used a proprietary commercial cloud API:

Those intimate memories could be harvested for ad-targeting profiling or scraped into commercial training sets.
If the company updates its Terms of Service, your memories are subject to arbitrary corporate surveillance.

By running Google's Gemma 2 locally (via Ollama or an embedded open prompt harness), your data never leaves your laptop. No telemetry, no cloud tokens, no corporate surveillance. It is completely sovereign.

2. Digital Immortality Without Subscription Paywalls

We have all seen SaaS products shut down, pivot, or introduce prohibitive monthly tiers. If a memorial tool is hosted on a proprietary subscription platform, what happens when a credit card expires or the company is acquired? The altar vanishes.

With open innovation and open-weight models:

Zero Ongoing Cost: Running Gemma 2 locally costs zero dollars.
Offline Forever: Ofrenda Viva includes an Export Private Vault feature. You can download your entire memorial into a single standalone JSON/HTML archive, put it on an air-gapped USB flash drive, and hand it to your grandchildren 40 years from now. It will still open and run without internet access.

3. Cultural Nuance Without Monolithic Gatekeeping

Open models allow us to tailor prompts, temperature parameters, and emotional pacing to honor delicate cultural rituals like Día de los Muertos with reverence, avoiding generic corporate boilerplate.

🛠️ Architecture & Tech Stack

Open-Weight AI: Google Gemma 2 (gemma2:2b / gemma2:9b). Lightweight, blazingly fast on consumer laptops, and poetic in multilingual Spanish/English synthesis.
Voice Narration: ElevenLabs API integration with fallback to Web Audio / SpeechSynthesis.
Backend: Pure, zero-dependency Node.js native HTTP server (node:http, node:fs). No node_modules vulnerabilities, instant 10ms startup.
Visuals: Hand-crafted CSS animations (flickering candle flames, fluttering papel picado garland, and an interactive 2D canvas particle engine rendering falling cempasúchil petals).
Preservation Engine: Client-side vault export generating self-contained offline backup archives.

💻 GitHub Repository

Source Code: https://github.com/swatiicfai/ofrenda-viva

Try It Yourself (Zero Setup):

# 1. Clone the repository
git clone https://github.com/swatiicfai/ofrenda-viva.git
cd ofrenda-viva

# 2. Launch the altar (Zero npm dependencies needed!)
node server.js

# 3. Open in your browser
# http://localhost:3000

🌟 Reflections & Community Takeaways

Building Ofrenda Viva reminded me that open-source AI is not just about compute benchmarks or parameter counts. It is about autonomy.

When technology deals with memory, love, and loss, open innovation is the only paradigm that respects human dignity. It gives families the power to keep their ghosts close, their memories private, and their altars alight—long after the servers of our time have turned to dust.

¡Feliz Día de los Muertos, y que viva la memoria! 🕯️🌼💀

Building a DEV.to Connector for Cognee: Giving AI Agents a Developer Knowledge Base

swatiicfai — Fri, 30 Oct 2026 19:16:34 +0000

How we built an open-source DEV.to data-source connector for Cognee to ingest developer tutorials, engineering insights, and technical documentation into an AI agent's memory graph.
Building a DEV.to Connector for Cognee: Giving AI Agents a Developer Knowledge Base

AI coding assistants and autonomous developer agents are rapidly becoming everyday teammates for engineering teams. However, agents often suffer from stale context, shallow search, and fragmented recall when asked nuanced questions about real-world software practices.

As part of Mergetober, I built the DEV.to Data-Source Connector for Cognee
, the open-source memory engine for AI agents.

In this article, I will walk through why this integration is valuable, how Cognee’s graph-memory architecture works, how the connector is built, and how you can use it to build your own Developer Knowledge Base AI Agent.

What is Cognee?

Traditional Retrieval-Augmented Generation (RAG) often flattens documents into isolated vector chunks. When an agent queries a RAG system, it retrieves disparate chunks but misses the relationships between tools, concepts, and authors.

Cognee
solves this by organizing information into a knowledge graph augmented with semantic vectors:

add(): Ingests raw text, codebases, or SaaS data feeds into a named dataset.

cognify(): Uses an LLM to extract entities, map conceptual connections, generate summaries, and build a unified graph memory.

search(): Queries the graph to retrieve interconnected answers that help agents reason with precision.

Why Connect DEV.to to Cognee?

DEV.to
is one of the most vibrant technical communities on the web, hosting tens of thousands of practical tutorials, architecture comparisons, debugging guides, and deep-dives written by working developers.

By connecting DEV.to directly into Cognee's memory:

Engineering Teams can ingest articles about their chosen tech stacks (e.g. FastAPI, Kubernetes, LangChain) into a local AI assistant.

Coding Agents can recall up-to-date best practices, community tips, and common pitfalls directly inside their reasoning loop.

Developers can create personalized memory layers that index their own bookmarked or published reading lists.

Architecture of the DEV.to Connector

The connector resides in cognee-community under packages/connector/devto:

text
cognee-community/
└── packages/
└── connector/
└── devto/
├── cognee_community_connector_devto/
│ ├── init.py
│ └── devto.py # Ingestion logic & DLT source
├── examples/
│ └── example.py # Complete runnable demo
├── tests/
│ └── test_devto.py # Pytest test suite with mocks
├── pyproject.toml # Poetry packaging
└── README.md # Setup and documentation

Key Technical Highlights:

Tag & Author Filtering: Developers can ingest articles filtered by tags (e.g., python, ai, beginners) or by author username.

Dual-Mode Ingestion:

Document Mode (fetch_devto_documents): Formats articles with author metadata, tags, reading time, and markdown bodies so that cognee.cognify() can build deep knowledge graphs.

DLT Source Mode (devto_source): Integrates seamlessly with Cognee’s underlying dlt (data load tool) pipelines via cognee.remember().

Resilience & Rate Limits: Gracefully supports public unauthenticated access and optional API key authentication (api-key).

Unit Tested: Fully tested using mocked HTTP endpoints to ensure bulletproof CI/CD runs.

How It Works in Practice

Here is how simple it is to turn DEV.to articles into a queryable AI memory brain:

python
import asyncio
import os
import cognee
from cognee_community_connector_devto import fetch_devto_documents
os.environ["LLM_API_KEY"] = "your-api-key"
async def main():
# 1. Fetch the latest technical articles tagged with 'python'
print("Fetching DEV.to technical articles...")
documents = fetch_devto_documents(
tag="python",
per_page=5,
fetch_full_content=False,
)
# 2. Add into Cognee's dataset
print(f"Adding {len(documents)} articles into Cognee memory...")
await cognee.add(documents, dataset_name="devto_knowledge_base")
# 3. Cognify into an interconnected knowledge graph
print("Cognifying articles into graph memory...")
await cognee.cognify(datasets=["devto_knowledge_base"])
# 4. Search and reason over the memory
query = "What Python libraries and patterns were recommended in the community?"
results = await cognee.search(query, datasets=["devto_knowledge_base"])

print("\nAI Agent Answer:")
print(results)

if name == "main":
asyncio.run(main())

When Cognee runs cognify(), it doesn't just store the text—it creates nodes for the authors, the libraries mentioned, and the concepts discussed, connecting them in a graph!

Real-World Use Cases

Company Brain for Developer Tools: An AI agent that stays up-to-date with tutorials and announcements from developer tooling teams.

Onboarding Assistant for Junior Devs: An internal chatbot grounded with curated DEV.to guides on clean code, Git workflows, and architecture patterns.

Personalized Research Companion: Ingesting your personal reading list so your local AI assistant remembers everything you read.

Links & Resources

Pull Request: topoteretes/cognee-community#578

Cognee Community Repo: topoteretes/cognee-community

Mergetober Hackathon: WeMakeDevs Mergetober

Building a DEV.to Connector for Cognee: Giving AI Agents a Developer Knowledge Base

swatiicfai — Fri, 30 Oct 2026 18:23:18 +0000

Building a DEV.to Connector for Cognee: Giving AI Agents a Developer Knowledge Base

As part of Mergetober, I built the DEV.to Data-Source Connector for Cognee, the open-source memory engine for AI agents.

1. What is Cognee?

Cognee solves this by organizing information into a knowledge graph augmented with semantic vectors:

add(): Ingests raw text, codebases, or SaaS data feeds into a named dataset.
cognify(): Uses an LLM to extract entities, map conceptual connections, generate summaries, and build a unified graph memory.
search(): Queries the graph to retrieve interconnected answers that help agents reason with precision.

2. Why Connect DEV.to to Cognee?

DEV.to is one of the most vibrant technical communities on the web, hosting tens of thousands of practical tutorials, architecture comparisons, debugging guides, and deep-dives written by working developers.

By connecting DEV.to directly into Cognee's memory:

Engineering Teams can ingest articles about their chosen tech stacks (e.g. FastAPI, Kubernetes, LangChain) into a local AI assistant.
Coding Agents can recall up-to-date best practices, community tips, and common pitfalls directly inside their reasoning loop.
Developers can create personalized memory layers that index their own bookmarked or published reading lists.

3. Architecture of the DEV.to Connector

The connector resides in cognee-community under packages/connector/devto:

cognee-community/
└── packages/
    └── connector/
        └── devto/
            ├── cognee_community_connector_devto/
            │   ├── __init__.py
            │   └── devto.py              # Ingestion logic & DLT source
            ├── examples/
            │   └── example.py            # Complete runnable demo
            ├── tests/
            │   └── test_devto.py         # Pytest test suite with mocks
            ├── pyproject.toml            # Poetry packaging
            └── README.md                 # Setup and documentation

Key Technical Highlights:

Tag & Author Filtering: Developers can ingest articles filtered by tags (e.g., python, ai, beginners) or by author username.
Dual-Mode Ingestion:
- Document Mode (fetch_devto_documents): Formats articles with author metadata, tags, reading time, and markdown bodies so that cognee.cognify() can build deep knowledge graphs.
- DLT Source Mode (devto_source): Integrates seamlessly with Cognee’s underlying dlt (data load tool) pipelines via cognee.remember().
Resilience & Rate Limits: Gracefully supports public unauthenticated access and optional API key authentication (api-key).
Unit Tested: Fully tested using mocked HTTP endpoints to ensure bulletproof CI/CD runs.

4. How It Works in Practice

Here is how simple it is to turn DEV.to articles into a queryable AI memory brain:

import asyncio
import os
import cognee
from cognee_community_connector_devto import fetch_devto_documents

os.environ["LLM_API_KEY"] = "your-api-key"

async def main():
    # 1. Fetch the latest technical articles tagged with 'python'
    print("Fetching DEV.to technical articles...")
    documents = fetch_devto_documents(
        tag="python",
        per_page=5,
        fetch_full_content=False,
    )

    # 2. Add into Cognee's dataset
    print(f"Adding {len(documents)} articles into Cognee memory...")
    await cognee.add(documents, dataset_name="devto_knowledge_base")

    # 3. Cognify into an interconnected knowledge graph
    print("Cognifying articles into graph memory...")
    await cognee.cognify(datasets=["devto_knowledge_base"])

    # 4. Search and reason over the memory
    query = "What Python libraries and patterns were recommended in the community?"
    results = await cognee.search(query, datasets=["devto_knowledge_base"])

    print("\nAI Agent Answer:")
    print(results)

if __name__ == "__main__":
    asyncio.run(main())

When Cognee runs cognify(), it doesn't just store the text—it creates nodes for the authors, the libraries mentioned, and the concepts discussed, connecting them in a graph!

5. Real-World Use Cases

Company Brain for Developer Tools: An AI agent that stays up-to-date with tutorials and announcements from developer tooling teams.
Onboarding Assistant for Junior Devs: An internal chatbot grounded with curated DEV.to guides on clean code, Git workflows, and architecture patterns.
Personalized Research Companion: Ingesting your personal reading list so your local AI assistant remembers everything you read.

6. Links & Resources

Pull Request: topoteretes/cognee-community#578
Cognee Community Repo: topoteretes/cognee-community
Mergetober Hackathon: WeMakeDevs Mergetober

🍲 Just built Cozy Hearth for the Comfort Food Challenge! Pure CSS Art ramen, hot cocoa & grilled cheese with live interactive controls — no libraries, no frameworks, just HTML + CSS + vanilla JS. Come cook with me! 🍜☕🥪

swatiicfai — Sun, 16 Aug 2026 11:54:05 +0000

Frontend Challenge Perfect Landing Submission 🍲🥧

swatiicfai

Aug 16

Cozy Hearth: An Interactive Comfort Food Sanctuary & CSS Art Kitchen 🍲

#devchallenge #frontendchallenge #webdev #javascript

2 min read

Cozy Hearth: An Interactive Comfort Food Sanctuary & CSS Art Kitchen 🍲

swatiicfai — Sun, 16 Aug 2026 11:52:12 +0000

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

What I Built

Cozy Hearth is a digital sanctuary dedicated to the foods that make us feel at home. It combines both challenge prompts (CSS Art and a Perfect Landing Page) into a highly polished, interactive experience.

🌟 Key Features:

Interactive CSS Art Canvas: Three beautiful, pure CSS graphics representing comfort classics—a steaming bowl of Ramen, a warm cup of Hot Cocoa, and a golden toasted Grilled Cheese Sandwich with tomato soup.
The Kitchen Playground: Users can customize their dishes in real-time! Toggle toppings (egg, nori, green onions, marshmallows), adjust steam speed, change mug colors, choose soup broths, or pull the grilled cheese to adjust elasticity.
Real-time CSS Variables Viewer: A built-in terminal block showing exactly how CSS Custom Properties (variables) update dynamically inside :root as you interact with the controls.
Interactive Cooking Tracker: Clicking "Cook This Dish" slides out a dynamic recipe drawer. It features an interactive checklist to tick off prep ingredients and a step-by-step progress cards to guide you through the cooking process.
Community Recipe Vault: A fully validated, local-storage-backed form allowing users to publish their own custom comfort recipes, which instantly render into the visual catalog.
Accessibility First: Designed with fluid layouts, semantic HTML5 structure, full keyboard navigability, and ARIA attributes.

Demo

🐙 GitHub Repository: https://github.com/swatiicfai/Cozy-Hearth
🌐 Live Demo: https://swatiicfai.github.io/Cozy-Hearth/

Journey

My goal was to prove that CSS Art doesn't have to be static. By tying pure CSS graphics to user-controlled JavaScript state, the food actually comes alive:

Ramen: Constructed using organic, multi-layered border-radius values (like 50% 50% 50% 50% / 60% 60% 40% 40% for egg-whites) and keyframes that wiggle noodles.
Hot Cocoa: Modeled bobbing marshmallows using independent @keyframes delays to simulate natural floating on dark cocoa liquid.
Grilled Cheese: Created stretchable cheese strings using CSS border parameters and scaling transforms controlled dynamically.

What I Learned & What I'm Proud Of

I'm incredibly proud of the Recipe Drawer and Step Tracker. By breaking down recipes into interactive steps, the landing page is not just beautiful to look at, but genuinely useful. Coding the real-time CSS variables viewer was also a fun challenge—it turns the playground into a mini educational sandbox demonstrating how CSS custom properties react dynamically to JavaScript events!