---
title: "Walkthrough: a full-stack store"
sidebar_title: "Walkthrough: an online store"
description: One real Ysra session — a Moroccan lifestyle store with a customer storefront and a Medusa back office, built from one brief. What was asked, what was built, what it cost, and how the session reported its own result.
status: new
---

This page follows one real session: **Atlas Market**, an ecommerce platform for
a Moroccan lifestyle brand, built from a single brief into a new repository. The
screenshots are from the running result; the catalog is seeded demonstration
data, and the store says so.

![The Atlas Market homepage: "Moroccan living, thoughtfully made." over a riad courtyard, with a Discover the collection button and a banner noting the catalog is demonstration data](../assets/screens/atlas/home.webp){ width="1600" height="917" }

## 1. The brief

The brief was long and specific — the kind Ysra works best with. In summary:

| Area | What was asked |
|---|---|
| **Architecture** | Inspect first, choose the commerce integration, and scaffold a complete local Medusa backend if no store is connected — with seeded data clearly labelled as demonstration content. |
| **Storefront** | Branded homepage; catalog with search, category and price filters, sorting and paging; product pages with gallery, variants, stock and related products; a persistent cart; checkout with Moroccan address fields; order confirmation with a real order reference; customer account. |
| **Market** | English, French and Arabic, with correct right-to-left layout for Arabic; prices in MAD; mobile, tablet and desktop layouts. |
| **Administration** | A real, authenticated back office for the catalog — separate from the storefront. A management claim only counts if a staff member can make the change, it persists, and the storefront shows it. |
| **Payments** | Test mode only; if card payments aren't available, an honest cash-on-delivery path instead of fake success. |
| **Quality** | Secrets server-side, validated input, no admin APIs in the browser, no mock arrays standing in for real behaviour, tests for catalog, cart, checkout, authorisation and one full customer journey. |
| **Proof** | Run the whole stack from a clean copy, then walk it in a real browser: home → category → search → product → variant → cart → quantity → checkout → order → confirm the order exists in the back office. |

It also said what *not* to do: no "Product A", no lorem ipsum, no placeholder
admin pages, and name anything unfinished precisely instead of claiming success.

## 2. What Ysra built

A two-app repository — a **Medusa backend** and a **customer storefront** — with
**67 files and about 21,800 lines**, including a seeded catalog of 12 products in
4 categories, each with variants, MAD prices, stock levels and generated product
photography.

### The storefront

<div class="cards" markdown>

- ![Shop by collection: Textiles, Ceramics, Pantry and Homewares](../assets/screens/atlas/collections.webp){ width="1600" height="1000" }

    **Collections** — four categories from the catalog.

- ![The Shop page with search, collection and price filters, sorting, and a product grid](../assets/screens/atlas/catalog.webp){ width="1600" height="1000" }

    **Catalog** — search, collection and price filters, sorting.

- ![Marrakech Brass Lantern product page: MAD 1,070, finish choice Gift wrapped or Classic, quantity and Add to cart, delivery and cash-on-delivery notes](../assets/screens/atlas/product.webp){ width="1600" height="904" }

    **Product** — variants, price in MAD, quantity, delivery and returns.

- ![Empty basket: "Your basket is ready for its first find." with a Discover the collection button](../assets/screens/atlas/cart.webp){ width="1600" height="1000" }

    **Cart** — including a real empty state, not a blank page.

- ![Product detail with "You may also like" related products](../assets/screens/atlas/detail.webp){ width="1600" height="1000" }

    **Related products** under each product.

- ![Our story page: "Craft carries a place forward." with a weaver at a loom](../assets/screens/atlas/about.webp){ width="1600" height="1000" }

    **Editorial** — an honest brand story that labels the demo catalog.

</div>

### The back office

The catalog lives in Medusa, not in the storefront's code. Staff manage it in
Medusa's own admin, behind a sign-in — kept apart from the public store.

![The Medusa admin Products list: 12 products — Marrakech Brass Lantern, Taznakht Lumbar Cushion, Beni Ouarain Wool Cushion and more — each with 2 variants, on the Atlas Market Web sales channel, all Published](../assets/screens/atlas/admin-products.webp){ width="1600" height="959" }
/// caption
The seeded catalog in the back office: 12 products, 2 variants each, published
to the storefront's sales channel.
///

## 3. How the session ended

| | |
|---|---|
| **Changes** | 67 files, about 21,800 lines added. |
| **Effort** | 264 model calls and 375 tool actions. |
| **Spend** | $15.81 against the session budget. |
| **Outcome** | **Failed** — Ysra reported *work stopped with a failure*. |

A large part of the product works, and you can click through it above. But the
brief demanded proof — the full stack started from a clean copy and a ten-step
customer journey ending in a real order — and not every required check passed.
So the session was reported as **failed**, with its candidate, checks and
evidence kept, rather than as done.

!!! note "Why a failed session belongs in the docs"
    The brief said *"Name anything genuinely unfinished precisely; do not claim
    success without evidence."* This is what that looks like. The storefront and
    back office are real, the catalog comes from Medusa, the demo data is
    labelled — and the verdict still says failed, because the required proof
    wasn't complete. You decide what happens next: read the failing check, steer
    the session to fix it, and it continues from the same candidate.

## 4. What you'd do next

1. Open the session's **Checks** and **Review** panels to see which proof
   failed and why. See [The workroom](../developer/workroom.md).
2. **Steer** with what the failing check shows — a missing setting, a service
   that didn't start, a step of the journey that broke — and the session
   continues from the same candidate. See [Steering](../developer/steering.md).
3. When the journey passes in the browser, **preview** it and open the pull
   request.

## Try it yourself

- Write a brief as concrete as this one: outcomes, constraints, what must not
  happen, and how it should be proven.
- Turn on **browser review** for anything a customer clicks.
- Read the verdict before the screenshots.

See [Start a session](../developer/start-a-session.md).