Arayüz & Tasarım

Build an e-commerce store end to end. Work in this order and stop after each numbered step to show me what you did.

## 0. Working name and demo content
The store is called NOVA. Seed it so no screen ever renders empty:
- 12 products across Bags, Shoes and Accessories — including "Leather Tote"
  at $189, "Canvas Sneaker" at $79, "Wool Scarf" at $45 and "Denim Jacket"
  at $129 — each with 2-3 photos, one variant axis (color or size) and a
  realistic stock count
- a demo customer with a saved address and two past orders
- a session cart pre-filled with the tote and the sneaker (total $268)
Use real photography placeholders (picsum.photos or similar), never gray boxes.

## 1. Data model
- products (id, slug, title, description, base_price, currency, status)
- product_variants (id, product_id, sku, option_values jsonb, price_delta, stock_qty)
- product_images (id, product_id, url, alt, position)
- categories + product_categories (many-to-many)
- carts (id, user_id nullable, session_token, expires_at)
- cart_items (cart_id, variant_id, qty, unit_price_snapshot)
- orders (id, user_id, status, subtotal, shipping, tax, total, address jsonb, placed_at)
- order_items (order_id, variant_id, title_snapshot, unit_price_snapshot, qty)

Snapshot the title and price on the order line: when the product changes later,
past orders must not change with it.

## 2. Screens
- Storefront: hero, featured collection, category strip
- Catalog: grid with filters (category, price range, in-stock), sort, pagination
- Product: gallery, variant picker that disables out-of-stock combinations,
  price that updates with the variant, add to cart
- Cart: line items with quantity steppers, subtotal, shipping estimate, empty state
- Checkout: address form, shipping method, payment step, review
- Order confirmation and order history

## 3. Rules that must hold
- Price and stock are computed on the server on every add-to-cart and at
  checkout. Never trust a price sent from the client.
- Cart survives login: a guest cart merges into the user cart on sign-in.
- Stock is decremented in the same transaction that creates the order;
  a race between two buyers must not oversell.
- Every money value is stored in minor units as an integer, never a float.
- Order status transitions are explicit: pending -> paid -> fulfilled -> delivered,
  plus cancelled and refunded. Reject invalid transitions in the database.

## 4. Payment
Integrate Stripe Checkout. Create the session server-side from the cart total
recomputed at that moment. Fulfill the order from the webhook, not from the
browser redirect — the customer may close the tab.
Make the webhook idempotent: the same event id must not create two orders.

## 5. What to show me
After each step: the migration SQL, the files you created, and one screenshot
or a description of the screen. Do not move to the next step before I confirm.

Build a multi-tenant SaaS analytics dashboard end to end. Stop after each numbered step.

## 0. Working name and demo content
The product is called Pulse. Seed one demo organization with 90 days of
events so every chart has a real shape:
- headline metrics that read MRR $48.2K (+12%), Active users 8,412 (+4%),
  Churn 2.1% (-0.3) against the previous period
- an events table with rows like signup 1,204 (+8%), upgrade 312 (+21%),
  cancel 87 (-5%)
- a team of three: an owner, an admin and a member

## 1. Tenancy first
- organizations (id, name, slug, plan, created_at)
- memberships (org_id, user_id, role: owner | admin | member)
- every domain table carries org_id and is filtered by it

Enforce isolation in the database with row level security, not in application
code. A query that forgets the org filter must return zero rows, not another
tenant's data. Write a test that proves it.

## 2. Metrics
- events (id, org_id, name, properties jsonb, occurred_at)
- daily rollups computed by a scheduled job, not on every page load

The dashboard reads rollups; only the "last 24h" view touches raw events.
Say out loud which query hits which table.

## 3. Screens
- Dashboard: 4 stat tiles (value, delta vs previous period, sparkline),
  one time-series chart, one breakdown table
- Date range picker: 7d / 30d / 90d / custom, and every number on the page
  recomputes against the same range
- Records table: server-side pagination, column sort, saved filters
- Detail drawer: one record with its event timeline
- Team: invite by email, change role, remove member — an owner cannot remove
  the last owner

## 4. Rules
- Every number shows the period it covers; a bare number is a bug.
- Deltas state the comparison window ("vs previous 30 days").
- Empty state for a brand-new org explains how to send the first event,
  with a copyable snippet.
- Loading uses skeletons shaped like the tiles, not a spinner.
- The chart works in both light and dark theme; colors come from the palette,
  not the chart library defaults.

## 5. What to show me
After each step: the schema, the RLS policies with the test that proves
isolation, then the screens.

Build an appointment booking system end to end. Stop after each numbered step.

## 0. Working name and demo content
The clinic is called CalmCare. Seed it so booking can be tried end to end:
- three services: Dental checkup 30min $60, Teeth cleaning 45min $85,
  Whitening 60min $120
- two staff members with weekday availability 09:00-17:00 and one day off
- existing appointments so slots like 09:30, 11:00 and 14:15 show as taken
  or free on the demo day
- an admin agenda showing 8 appointments today with one no-show

## 1. Data model
- services (id, name, duration_min, price, buffer_before_min, buffer_after_min)
- staff (id, name, timezone)
- staff_services (staff_id, service_id)
- availability_rules (staff_id, weekday, start_time, end_time)
- time_off (staff_id, starts_at, ends_at, reason)
- appointments (id, staff_id, service_id, customer_id, starts_at, ends_at,
  status: pending | confirmed | cancelled | no_show, notes)

Store every timestamp in UTC with timezone. Store the staff timezone
separately — availability rules are local wall-clock times, appointments are
absolute instants. Getting this wrong breaks the system twice a year at DST.

## 2. Slot generation
Given a service, a staff member and a date, produce bookable slots:
- expand availability rules for that weekday into the staff timezone
- subtract time off
- subtract existing appointments plus their buffers
- step by the service duration
- drop slots that start in the past or inside the minimum notice window

Write this as a pure function with unit tests, including a DST transition day.

## 3. Double booking
Two customers may hit the same slot at the same second. Prevent it in the
database, not in the UI: add an exclusion constraint on (staff_id, time range)
so overlapping confirmed appointments cannot exist. Handle the constraint
violation by telling the second customer the slot just went, and offer the
next three.

## 4. Screens
- Service list with duration and price
- Calendar: month or week view, days with no availability visibly disabled
- Slot picker for the chosen day, grouped morning / afternoon / evening
- Confirmation form: name, contact, notes, and a clear cancellation policy
- Customer view: upcoming and past appointments, cancel and reschedule
- Staff admin: day agenda, block time off, mark no-show

## 5. Notifications
Confirmation immediately, reminder 24 hours before. Send from a queue with
retry, not inline in the request. Include an .ics attachment and a cancel link
that does not require login.

## 6. What to show me
The slot function with its tests first, then the constraint, then the screens.

Build a kanban project board end to end. Stop after each numbered step.

## 0. Working name and demo content
The tool is called TaskFlow. Seed one board so drag and drop is testable:
- columns To do, In progress, Done
- cards including "Design review", "API error states", "Auth flow",
  "Search UI" and "Landing page" (done), with assignees and due dates
- one card carrying a longer description, two labels and three comments

## 1. Data model
- boards (id, org_id, name)
- columns (id, board_id, name, position)
- cards (id, column_id, title, description, assignee_id, due_date, position,
  archived_at)
- labels + card_labels
- comments (id, card_id, author_id, body, created_at)
- activity (id, card_id, actor_id, kind, payload jsonb, created_at)

Use a fractional position (numeric or a lexicographic rank string) instead of
an integer index. Moving one card between two others must update exactly one
row, not renumber the column.

## 2. Drag and drop
- Optimistic: the card moves the moment it is dropped, before the server answers
- On failure it returns to its original place and an error toast explains why
- Keyboard support is not optional: focus a card, then move it with
  arrow keys plus a modifier, announcing the new position to screen readers
- Auto-scroll when dragging near the edge of the board

## 3. Realtime
Two people looking at the same board see each other's moves. Subscribe to
changes per board. Handle the case where a card you are dragging is moved by
someone else: do not fight the user's pointer, apply the remote move when the
drag ends.

## 4. Screens
- Board: horizontally scrolling columns, card count per column,
  collapsed column state, empty column call to action
- Card detail: title, rich description, assignee, due date, labels, comments,
  activity log
- Filter bar: assignee, label, due date, text search — filters apply to the
  board without losing scroll position
- Archive view

## 5. Rules
- A card must always belong to exactly one column.
- Deleting a column asks what to do with its cards; never silently delete them.
- The board keeps working with 500 cards: virtualize the columns.

## 6. What to show me
The position strategy and the move mutation first, then the board.

Build a chat application on the Claude API end to end. Stop after each numbered step.

## 0. Working name and demo content
The assistant is called Clara. Seed a believable history:
- three past conversations titled "Q3 report summary", "Trip planning" and
  "SQL query help"
- the open conversation shows a user asking "Summarize this PDF", a rich
  assistant answer, and a follow-up "What are the key risks?" mid-stream
- usage page reads 1.2M tokens / $8.40 this month

## 1. Data model
- conversations (id, user_id, title, model, created_at, updated_at)
- messages (id, conversation_id, role, content jsonb, tokens_in, tokens_out,
  created_at)
- Store content as the API's block array, not a plain string: a message may
  contain text, tool_use and tool_result blocks.

## 2. Streaming
- Stream from the server to the browser; never call the API from the client
  with a key in the bundle.
- The user can stop generation mid-stream, and the partial answer is saved.
- If the connection drops, the conversation must not end up with a half-written
  assistant message that breaks the next request.
- Render markdown as it arrives without re-parsing the whole message on
  every token.

## 3. Model configuration
Default to claude-opus-5. Keep the model id in one place so it can be changed
without touching call sites. Use adaptive thinking and set output_config.effort
per route: low for title generation, high for the main conversation.

## 4. Screens
- Chat: message list, streaming cursor, stop button, copy per message,
  regenerate last answer
- Composer: multi-line input, submit on Enter with newline on Shift+Enter,
  attachment support, character or token hint
- History sidebar: conversations grouped by day, rename, delete, search
- Usage: tokens and cost per day and per conversation

## 5. Rules
- Show the model name on each assistant message; a conversation may span models.
- Track tokens from the API response usage field, not by estimating.
- Long conversations must not fail: when the context grows, either summarize
  earlier turns or enable server-side compaction, and tell the user it happened.
- Errors are specific: rate limit, overloaded, invalid request and network
  failure each get their own message and their own retry behavior.

## 6. What to show me
The streaming route and the message persistence first, then the interface.

Build a content site end to end. Stop after each numbered step.

## 0. Working name and demo content
The publication is called The Ledger. Seed it with six published essays —
including "Why we ship weekly", "Notes on deep focus" and "The real cost
of meetings" — each with a cover image, reading time and 3-5 paragraphs of
plausible body text (not lorem ipsum), plus one scheduled draft.

## 1. Data model
- posts (id, slug, title, excerpt, body, cover_url, status: draft | scheduled |
  published, published_at, author_id, reading_minutes)
- categories + post_categories, tags + post_tags
- revisions (id, post_id, body, saved_at) — the editor autosaves here

## 2. Reading experience
- Measure capped around 68 characters, line-height 1.7
- Headings build a table of contents; anchor links on hover
- Code blocks with copy button and language label
- Images lazy-loaded with width and height set, so nothing shifts while loading
- Reading time computed from word count, shown before the article

## 3. Editor
- Markdown with live preview, or a rich text editor that stores markdown
- Autosave every few seconds into revisions; show "saved" state
- Publish flow: draft -> preview link that works without login -> publish
- Scheduled posts go live via a cron job, not a check on page load

## 4. Discovery
- Full-text search over title and body with ranking
- Category and tag pages with their own descriptions
- RSS feed, sitemap.xml, robots.txt
- JSON-LD Article structured data on every post
- Open Graph image per post, falling back to a site default

## 5. Rules
- The URL of a published post never changes; renaming the title keeps the slug
  and records a redirect if you must change it.
- Drafts are unreachable without auth, including by guessing the slug.
- Every page renders without JavaScript for the article body.

## 6. What to show me
The schema and the article page first, then the editor, then discovery.

Build a learning platform end to end. Stop after each numbered step.

## 0. Working name and demo content
The platform is called Learnly. Seed it so progress is visible:
- four courses: React Basics 12h $49, SQL Deep-dive 8h $39, Design 101 6h
  $29, Python Path 15h $59, each with 3 modules and 8-12 lessons
- a demo student enrolled in three of them at 62%, 100% (completed, with
  certificate) and 15% progress
- lesson "03 · State & props" holds a video, a transcript and a 4-question quiz

## 1. Data model
- courses (id, slug, title, summary, price, level, published_at)
- modules (id, course_id, title, position)
- lessons (id, module_id, title, kind: video | text | quiz, content jsonb,
  duration_sec, position, is_preview)
- enrollments (user_id, course_id, enrolled_at, expires_at nullable)
- lesson_progress (user_id, lesson_id, seconds_watched, completed_at)
- quiz_attempts (user_id, lesson_id, answers jsonb, score, attempted_at)

## 2. Access control
- Free preview lessons are public; everything else requires an enrollment.
- Enforce it on the video URL too: sign the media URL per user and expire it.
  A lesson page that hides the player but leaves the file public is not access
  control.

## 3. Progress
- A video lesson counts as complete at 90% watched, not at 100% — people skip
  the outro.
- Progress writes are throttled: one write per 15 seconds of playback, plus one
  on pause and unload. Do not write on every timeupdate event.
- Course progress is derived from lesson progress, never stored denormalized
  without a recompute path.

## 4. Screens
- Catalog: cards with level, duration, lesson count, price
- Course page: syllabus with modules and lessons, preview badges, enroll CTA
- Lesson player: video, transcript, notes, previous/next, autoplay next toggle
- Quiz: one question per screen, immediate feedback, retry policy
- My learning: continue where you left off, percentage per course
- Certificate on completion, with a verifiable public URL

## 5. Rules
- Resume playback at the last position, per device.
- The syllabus shows completion state without an extra request per lesson.
- Course price changes never affect people already enrolled.

## 6. What to show me
The access control and progress writes first, then the player.

Build a listings marketplace end to end. Stop after each numbered step.

## 0. Working name and demo content
The marketplace is called Yuva. Seed 20 property listings with photos —
including "2BR City Flat $284K", "Garden House $412K" and "Compact Studio
$126K" — spread across 3 districts with real-looking coordinates, plus one
message thread on the garden house that reads "Is it still available?" /
"Yes — viewing on Saturday?".

## 1. Data model
- listings (id, seller_id, title, description, price, currency, status,
  category_id, location geography(Point), address jsonb, attributes jsonb,
  published_at, expires_at)
- listing_images (listing_id, url, position)
- saved_searches (user_id, query jsonb, notify: none | daily | instant)
- favorites (user_id, listing_id)
- threads + messages between buyer and seller

Attributes differ per category (rooms and square meters for property, mileage
and year for cars). Keep them in jsonb but define a schema per category and
validate against it; do not let arbitrary keys in.

## 2. Search
- Facets: category, price range, location radius, and the category's own
  attributes
- Geo: PostGIS ST_DWithin against the point, with a GiST index
- Full-text over title and description, ranked, combined with the facets
- Every filter is in the URL so a search can be shared and the back button works
- Result count updates with the filters; a filter that would return zero
  results is shown as disabled with its count, not silently applied

## 3. Screens
- Search: list and map side by side on desktop, toggle on mobile; hovering a
  card highlights its pin
- Listing: gallery, key attributes as a table, seller card, contact button,
  similar listings
- Post a listing: multi-step form with image upload, draft saved between steps
- Messages: thread per listing, unread count, reply
- Saved searches with email notification

## 4. Rules
- Never expose the seller's phone or email; contact goes through the thread.
- Expired listings stay reachable by URL but are clearly marked and excluded
  from search.
- Image upload strips EXIF location before storing.
- Price is filterable as a number; store it as an integer in minor units.

## 5. What to show me
The search query with its indexes first, proven on seeded data, then the screens.