DEV Community: Pawan Satoshi

Clear the Lineup: Making ARCTIS Bridge Execution Quote-Safe

Pawan Satoshi — Sun, 16 Aug 2026 17:08:35 +0000

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

Project Overview

ARCTIS is an AI operating environment for programmable money built on Arc Testnet.

Its Bridge flow coordinates wallet state, network validation, Circle bridge quotes, transaction preflight, and asynchronous execution.

Live application:
https://arctis-zeta.vercel.app/

Repository:
https://github.com/pawansatoshi/Arctis

Bug Fix or Performance Improvement

The Bridge flow had a subtle asynchronous race condition.

A bridge quote could be requested while the user was changing the amount or route. Because the operation was asynchronous, an older quote response could return after a newer request and overwrite the current state.

There was also a second race: repeated or overlapping execution paths could reach the bridge execution flow before the previous operation had completed.

In a financial transaction flow, this is more than a normal UI race.

The execution layer must never use stale transaction intent, and the same transaction must not be executed more than once because of overlapping asynchronous operations.

Root Cause

The original implementation relied on React state captured by asynchronous callbacks.

That created two related problems:

Stale quote race

An older estimateBridge() response could finish after a newer quote request and update state with obsolete quote information.

Duplicate execution race

More than one execution path could reach the bridge operation before the first operation had completed.

The Circle bridge itself was not the root cause. The problem was the application's client-side orchestration around asynchronous financial operations.

Code

The complete fix is available in this commit:

fix: stop duplicate bridge execution and stale quote races — d3a10816

The relevant Bridge implementation is in:

ARCTIS Bridge page

The execution lock is implemented here:

transaction/execution-lock.ts

The transaction regression coverage is here:

transaction-regression.mjs

My Improvements

I fixed the race at the application level rather than trying to hide it with UI timing.

1. Current state reference

The Bridge flow now keeps a reference to the latest session state.

This prevents asynchronous callbacks from relying on stale React closures.

2. Quote sequencing

Each quote request receives a sequence number.

A quote response is accepted only if it is still the newest request.

This means an old network response can finish normally without being allowed to overwrite a newer quote.

3. Single-flight execution

Bridge execution now uses a deterministic execution lock.

The lock is based on the wallet, execution mode, source/destination route, and amount.

If the same operation is already executing, another execution attempt is rejected instead of entering the bridge flow again.

4. Execution revalidation

The transaction is not allowed to cross the execution boundary using an old quote alone.

Before wallet approval, the flow performs the required validation and obtains current bridge information again.

The resulting execution pipeline is:

User intent → Quote → Network verification → Balance/gas preflight → Fresh quote → Fee validation → Wallet approval → Bridge execution

5. Safe release

The execution lock is released after the execution path completes or fails, preventing a failed transaction from permanently blocking future legitimate attempts.

Why This Matters

The important invariant after the fix is:

Only current, validated transaction state may cross the execution boundary.

This matters especially for financial interfaces because asynchronous timing should not determine which quote, amount, route, or transaction state reaches the wallet.

The fix makes the execution lifecycle deterministic:

Proposal → Quote → Preflight → Fresh quote → Human approval → Submitted → Processing → Confirmed/Failed

Regression Coverage

The repository contains transaction regression checks for the critical safeguards.

The regression coverage checks for:

current session state handling
quote sequencing
execution locking
execution lock release
chain verification
network switching
transaction confirmation handling
bridge safeguards
Circle quote gating

Regression script:

https://github.com/pawansatoshi/Arctis/blob/main/scripts/transaction-regression.mjs

Verification

The latest ARCTIS production deployment is marked READY on Vercel.

Live application:

https://arctis-zeta.vercel.app/

The current production deployment was checked for recent runtime errors and had no errors in the available latest-hour runtime window.

The repository also contains a release QA gate covering:

type checking
build validation
API validation
persistence
concurrency
duplicate execution
retry and timeout behavior
security
accessibility
responsive behavior
production smoke testing

Impact

This was a bug fix in an existing ARCTIS codebase, not a new feature.

The fix removes two classes of timing-dependent failures from the Bridge flow:

stale quote/state races
duplicate execution races

The result is a more deterministic and safer transaction pipeline without changing the intended Bridge user experience.

What Changed

Commit:

d3a10816 — fix: stop duplicate bridge execution and stale quote races

Primary Bridge code:

https://github.com/pawansatoshi/Arctis/blob/main/src/app/bridge/page.tsx

Execution lock:

https://github.com/pawansatoshi/Arctis/blob/main/src/lib/transaction/execution-lock.ts

Regression tests:

https://github.com/pawansatoshi/Arctis/blob/main/scripts/transaction-regression.mjs

Live Demo

https://arctis-zeta.vercel.app/

Repository

https://github.com/pawansatoshi/Arctis

Final Takeaway

A transaction interface can look completely correct while still having a dangerous asynchronous race underneath.

The ARCTIS Bridge bug was caused by stale quote responses and overlapping execution paths.

The fix makes quote state current, execution single-flight, and transaction state revalidated before wallet approval.

The key engineering principle is simple:

Do not let asynchronous timing decide what financial transaction state gets executed.

bugsmash

I Fixed a Modal That Said “Accessible” But Wasn’t

Pawan Satoshi — Sun, 16 Aug 2026 09:01:33 +0000

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

Project Overview

The Comfort Table is an interactive comfort-food editorial experience originally built for the DEV Frontend Challenge.

Visitors can discover comfort dishes through mood and moment, explore a global menu, and open detailed dish stories inside a custom modal.

The project uses semantic HTML, responsive CSS, vanilla JavaScript, visible focus states, aria-pressed, aria-live, reduced-motion support, and touch-friendly interactions.

Bug Fix or Performance Improvement

The bug was in the custom dish-details modal.

The component declared itself with role="dialog" and aria-modal="true", but its behavior did not fully satisfy what those semantics promised.

The visual modal worked, but the focus-management lifecycle was incomplete.

A robust modal needs to:

move focus into the dialog when it opens
keep Tab and Shift+Tab inside the dialog
close with Escape
restore focus to the element that opened it
prevent interaction with the background while open

The root problem was treating ARIA semantics and modal behavior as separate concerns.

A dialog should not claim to be modal while still allowing its interaction model to behave like a normal page.

Code

The accessibility fix is documented in this commit:

62a7f04 — fix: harden modal accessibility

Repository:

github.com/pawansatoshi/the-comfort-table

Primary implementation:

index.html

The fixed modal lifecycle is:

Invoking button → Open modal → Move focus inside → Contain Tab / Shift+Tab → Escape or close → Restore focus → Return to invoking button

The implementation also makes the background inert while the dialog is active and keeps overlay and close behavior within the same lifecycle.

My Improvements

I approached the bug as an accessibility behavior problem rather than simply adding ARIA attributes.

1. Initial Focus

When the modal opens, focus is moved into the dialog instead of leaving the user somewhere behind the modal.

2. Focus Containment

Tab and Shift+Tab are handled so keyboard focus remains within the modal boundary.

3. Escape Handling

The dialog can be dismissed with Escape, providing a predictable keyboard exit.

4. Focus Restoration

When the modal closes, focus returns to the dish control that originally opened it.

This prevents keyboard users from losing their position in the page.

5. Background Inertness

The page behind the modal is treated as unavailable while the dialog is open.

This makes the implementation consistent with the declared aria-modal="true" behavior.

6. Regression Safety

The fix was designed around the existing UI rather than replacing the component with a new visual implementation.

The responsive layout, dish experience, and existing interaction design remain intact.

The key engineering principle was:

ARIA should describe real behavior, not replace it.

Verification

I manually verified the deployed application on mobile.

The following behaviors were checked:

modal opens from the dish details control
modal closes correctly
overlay interaction behaves correctly
repeated open and close cycles remain stable
refresh does not leave the interface in a broken modal state
responsive layout remains usable

The implementation also contains the keyboard lifecycle for Tab, Shift+Tab, Escape, and focus restoration.

I am deliberately not claiming an independently performed desktop keyboard pass because this submission was prepared from a mobile device.

Impact

This was a focused code fix with a meaningful accessibility impact.

Without proper focus management, a custom modal can be visually correct while still creating a confusing experience for keyboard and assistive-technology users.

The fix brings the component's actual interaction model closer to the semantics it already declared.

It also establishes a reusable pattern for future dialogs in the project:

semantic state + focus management + keyboard behavior + background isolation + focus restoration

Live Demo

https://the-comfort-table.vercel.app/

Repository

https://github.com/pawansatoshi/the-comfort-table

Accessibility Fix Commit

https://github.com/pawansatoshi/the-comfort-table/commit/62a7f04a88d798c0dc6221f7c647b344f84f221b

Supporting Documentation

https://github.com/pawansatoshi/the-comfort-table/blob/main/DEV-SUBMISSION.md

https://github.com/pawansatoshi/the-comfort-table/blob/main/README.md

bugsmash

The Comfort Table — Food That Remembers

Pawan Satoshi — Sun, 16 Aug 2026 05:36:33 +0000

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

What I Built

I built The Comfort Table, an interactive food-memory experience inspired by the meals that make an ordinary day feel like home.

Instead of creating a traditional restaurant landing page, I wanted to make the landing page itself feel like a small digital dining room.

The experience combines:

A responsive editorial-style landing page
An interactive Comfort Finder based on mood and moment
A searchable world menu
Country filtering
Detailed dish cards with ingredients, preparation, taste and serving notes
A dish-details modal with keyboard-accessible interaction
Multilingual UI support for English, Hindi, Spanish, French, Japanese, Korean and Arabic
Responsive layouts for mobile, tablet and desktop
CSS-generated hero artwork
Reduced-motion support
Semantic HTML and accessibility-focused interaction

The central idea is simple:

Comfort food has no passport.

Whether it is khichdi in India, ramen in Japan, pasta in Italy or tacos in Mexico, food can carry memory, place and emotion.

Demo

Live Demo:

https://the-comfort-table.vercel.app/

Source Code:

https://github.com/pawansatoshi/the-comfort-table

Journey

I started with the idea of building something that felt more personal than a conventional food website.

The challenge was not only to make the page visually polished, but to make the experience useful and enjoyable to interact with.

The Comfort Finder became the core interaction: users can choose how their day feels and the moment they are eating, and the interface recommends a dish from the collection.

I also spent significant time on responsive behavior because the experience should work equally well on a phone, tablet and desktop.

One part I am particularly proud of is the accessibility work around the dish-details modal. A visually attractive modal is not enough if keyboard users can escape into the background content or lose their place after closing it.

The modal interaction was therefore hardened with:

focus management
focus restoration
Tab and Shift+Tab containment
Escape-to-close behavior
inert background content
proper modal lifecycle handling

This made accessibility part of the interaction model rather than an afterthought.

Another challenge was keeping the interface expressive without making it dependent on a large frontend framework. The project uses semantic HTML, CSS and purposeful JavaScript to keep the experience lightweight and understandable.

What I Learned

This project reinforced an important frontend lesson for me:

A landing page is not just a visual composition. It is an interaction system.

Typography, spacing, responsive layout, keyboard behavior, focus management, loading behavior and content hierarchy all contribute to whether the experience actually works.

I also learned that small details can have a large impact. A remembered focus target, a properly contained modal, a reduced-motion fallback or a thoughtful empty state can make the difference between something that merely looks good and something that feels finished.

What I'm Proud Of

I'm particularly proud of combining visual storytelling with practical frontend engineering.

The project is intentionally designed to feel like a warm editorial food experience while still behaving like a real interactive product.

The goal was not to build the biggest food website.

It was to build a small experience that makes people want to explore one more dish.

What's Next

I'd like to continue expanding the experience with richer food stories, more regional dishes, stronger discovery interactions and additional accessibility testing.

Ultimately, I'd like The Comfort Table to become less like a collection of recipes and more like a digital map of the memories people associate with food.

Thanks for checking it out.This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

Demo

Journey

No Passport Required — Comfort Food Around the World

Pawan Satoshi — Sun, 16 Aug 2026 03:59:05 +0000

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

Inspiration

Comfort food does not need a passport.

Everywhere in the world, there is a dish that means something more than food. It can mean home, family, a long day ending, a celebration, or simply someone taking care of you.

For this challenge, I wanted to turn that idea into a single CSS artwork.

No Passport Required is a CSS-only celebration of comfort food around the world.

The scene brings together familiar comfort foods from different cultures around one shared table:

Italy — Margherita pizza
Japan — ramen
Mexico — tacos
India — khichdi
USA — mac and cheese
France — French onion soup
Korea — tteokbokki

Different dishes.

Different kitchens.

Different traditions.

One feeling.

Comfort.

Demo

View the live CSS Art

The artwork is rendered directly in the browser using HTML and CSS.

No food photographs, canvas drawings, or external illustration libraries are used for the artwork.

Source Code

View the project on GitHub

What I Built

I created a warm late-evening dining table where different comfort foods meet in one visual composition.

The scene uses CSS shapes, gradients, shadows, pseudo-elements and responsive positioning to create:

plates and bowls
pizza
ramen
tacos
rice
soup
noodles
cheese
herbs and toppings
utensils
steam
table lighting
shadows and depth
a warm kitchen atmosphere

The goal was not photorealism.

The goal was to make the viewer immediately understand the feeling behind the food.

Why CSS?

CSS is usually treated as the layer that makes an interface look good.

For this challenge, I wanted to push it further and use CSS as the illustration medium itself.

Instead of placing photographs of food on a page, I built the visual language from scratch using:

gradients
border-radius
pseudo-elements
box-shadow
transforms
layered positioning
CSS animation
responsive media queries

The artwork is intentionally asset-light so the shapes, composition and CSS techniques remain visible.

The Idea

The title is No Passport Required because comfort is universal.

A person does not need to know the complete history of a dish to recognize what it represents.

Warm food.

A familiar smell.

A table.

Someone waiting.

A place that feels like home.

Responsive Design

The composition is designed to adapt across:

desktop
laptop
tablet
mobile
portrait layouts
landscape layouts

The artwork scales and repositions instead of simply shrinking the desktop composition.

It also supports prefers-reduced-motion so users who prefer reduced motion are not dependent on the steam animation.

What I Learned

The hardest part was not creating individual food shapes.

It was making different foods from different cultures feel like part of one coherent visual scene.

The solution was to focus on the shared experience rather than making every dish perfectly realistic.

CSS became the tool for creating atmosphere rather than just decoration.

What I'm Proud Of

I'm proud that the artwork starts with a simple idea:

Comfort food is different everywhere, but the feeling is familiar.

The visual then turns that idea into one shared table.

What's Next

I would love to expand this into a larger interactive collection where visitors can select a country and discover the comfort food, ingredients, preparation and story behind it.

That idea also became the foundation for The Comfort Table, the larger interactive landing-page experience accompanying this CSS artwork.

Built With

HTML + CSS

No framework.

No external illustration library.

No canvas.

Challenge

Frontend Challenge — Comfort Food Edition

Thanks for taking a seat at the table.This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Demo

Journey

I Built BARKVERSE: What If Dogs Had Their Own Internet? 🐶

Pawan Satoshi — Sat, 15 Aug 2026 09:23:57 +0000

What If Dogs Had Their Own Internet?

Every dog has a personality.

They have their own habits, moods, favourite things, secret missions, suspicious refrigerator investigations, and an impressive ability to understand humans without saying a single word.

But what if dogs had their own internet?

That question became BARKVERSE.

🐶 BARKVERSE is an AI-powered interactive dog world where a real dog photo becomes the beginning of a playful digital identity.

Instead of building another static AI image analyzer, I wanted to create something people could actually explore, play with, and come back to.

🐾 Meet BARKVERSE

[WATCH THE DEMO VIDEO]
https://youtu.be/v2fX4cu7eRA

👉 Live Demo: https://barkverse.vercel.app/

👉 GitHub: https://github.com/pawansatoshi/barkverse

The experience starts with one simple thing:

A dog.

You can take a photo using your camera