Quellgate

A mock-up of the screen, drawn from its layout, palette and typefaces. A build follows the full prompt below.

Start from this screenRead the build prompt

Typefaces

The catalog's own faces. A screen composed into a template is drawn in that template's typefaces.

• InterHeadings: Inter 600, 28px/1.2 page title; 20px section
• InterBody: Inter 400 16px/1.5; 14px inside stage cards

Patterns

• two-level top navigation (primary tabs + pill sub-nav)
• pre-auth / post-auth tab pair
• left-to-right stage pipeline on a tinted canvas
• true/false connector badges
• outcome chips colour-coded by decision
• minimap with zoom controls
• empty stage cards with 'no rules yet' copy
• live vs draft strategy label

States it is designed for

• live strategy view (read-only)
• draft with unsaved changes
• empty stage ('No items yet' / 'No rules are added to this rule group')
• publishing / published toast with version
• publish blocked (validation: unreachable outcome)
• viewer role (edit disabled with tooltip)
• loading skeleton pipeline

Who it is for

• risk and fraud analysts
• payments operations
• finance engineers

Layout

1. top bar: account switcher with chevron, help and avatar right
2. primary tabs row (Home, Payments, Reports, Analytics, Fraud detection active with underline) and right-side links (Funds, Team, Developers)
3. sub-nav pills: Performance, Strategy builder (active tinted pill), Rules, Lists
4. page title 'Risk strategy'; tabs Pre-auth / Post-auth
5. section header 'Live strategy' with info icon and (when editing) Draft badge + Publish
6. canvas band (light warm grey) spanning full width: stage cards in a row joined by small play-arrow connectors; rule-group cards branch via 'T'/'F' circular badges to outcome chips
7. minimap card top-right of the canvas with zoom in/out/fit
8. mobile: canvas becomes a vertical list of stages with outcome rows

Palette

Sober, auditable, engineering-grade; colour is reserved for outcomes.

• page background#ffffff
• canvas band#f4f2f3
• primary text#1a1a1a
• secondary text#5c5c66
• active tab / links#1a5fd6
• active sub-nav pill#dbe9fd
• decline outcome#cc3a0f
• challenge outcome#1a66e0
• accept outcome#1b8a4b
• T/F badge#3a3a40
• card border#c9ccd1

Every checked pair, measured again

As vibld’s tokens

The palette on the fifteen colour tokens vibld styles a project with, each text colour on the fill it is read on. Marked tokens are solved from the palette, because no swatch held that role at 4.5:1.

• background
• card
• muted
• primary
• secondary
• accent
• destructive *

Type scale

Display

Inter 600, 28px/1.2 page title; 20px section

Body

Inter 400 16px/1.5; 14px inside stage cards

Stage card titles 14px 600; T/F badges 12px 700 white; tab labels 16px 500.

Spacing and imagery

Moderate: stage cards 200px wide, 4px radius, 1px border, 12px padding; 32px between stages; outcome chips 32px tall, 4px radius, 1.5px coloured border with a filled dot at the connection point.

No imagery; connector lines, small play-triangle arrows, T/F discs and a thumbnail minimap.

Components

• TopNav (primary tabs)
• SubNavPills
• AuthPhaseTabs
• StrategyCanvas
• StageCard (lists / rule group)
• Connector with TFBadge
• OutcomeChip (decline / challenge / accept, selectable)
• Minimap + ZoomControls
• DraftBar (Discard, Publish)
• RuleGroupDrawer

Interactions

• click a stage to open its drawer listing rules with add/edit
• outcome chip for 'false' of the last group is a select (accept / challenge / review)
• editing creates a draft; the header shows Draft and a Publish button
• publish asks for a change note and shows a diff summary
• pan by drag, zoom with controls; minimap viewport box is draggable
• hovering a connector highlights the full path to its outcome

Data

• Strategy{id, account_id, phase (pre_auth|post_auth), version, status (live|draft), published_by, published_at, note}
• Stage{id, strategy_id, kind (trust_list|decline_list|rule_group), position, name}
• Rule{id, stage_id, expression, enabled, created_by}
• Branch{stage_id, when (true|false), outcome (decline|challenge|accept|next)}
• ListItem{id, list_kind, value_hash, type (card|email|ip|device), expires_at}

Guardrails

Experience

• Always label which strategy is live and whether you are looking at a draft.
• Keep outcomes on the right edge so every path reads left to right.
• Use fixed outcome colours (decline red, challenge blue, accept green) plus text labels.
• Require a change note on publish and show what changed.
• Make empty stages explicit so analysts know nothing is filtering there.

Accessibility

• Offer a text 'Strategy outline' view listing stages, rules and T/F outcomes for screen readers.
• T/F badges have accessible names 'if true' / 'if false'.
• Outcome colours all reach 3:1 on white and are always paired with a label.
• Tabs and sub-nav use proper tablist/nav semantics with aria-current.
• Canvas controls are buttons with labels and keyboard shortcuts.

Security

• RLS: strategies and rules scoped to the merchant account; only 'risk_admin' may publish.
• Store list values (cards, emails) hashed; never show full card numbers.
• Validate rule expressions server-side against an allowlisted grammar.
• Audit every publish with actor, note and diff; support one-click rollback.

Build prompt

The baseline every prompt in the catalog assumes, then this design’s own ten sections, from goal to guardrails.

Copy the baseline and build prompt

### How to use these prompts
Paste an entry's build prompt into your coding agent as the first message. Each prompt names its own stack, tokens and acceptance criteria; the rules below apply to all of them and can be prepended once per project.

### Engineering baseline
- TypeScript strict mode, no `any`, small typed components, feature folders, and one source of truth for design tokens (CSS variables consumed by Tailwind).
- Validate every input with a shared zod schema on the client and again on the server or edge function. Never trust client-side checks alone.
- Show loading, empty and error states for every async view. Surface errors in plain language with a retry, and log details to the console in development only.
- Keep secrets out of the bundle. Only publishable keys (for example a Supabase anon key) belong in client code; service-role keys, API keys and webhooks live in server or edge-function environment variables.

### Data and auth baseline (full-stack entries)
- Enable Row Level Security on every table before inserting data. Default-deny, then add owner-scoped policies (`auth.uid() = user_id`) and explicit role checks for admin views.
- Store roles in a separate table checked by a security-definer function, never in a user-editable profile field.
- Upload files to private storage buckets with size and MIME limits, and serve them through signed URLs.
- Rate-limit public endpoints (forms, auth, AI calls) and add a honeypot field or captcha to anonymous forms.
- Take payments through a hosted checkout and verify webhooks by signature. Never handle raw card data.

### Accessibility and UX baseline
- Target WCAG 2.2 AA: 4.5:1 contrast for normal text and 3:1 for large text, input borders, focus rings and meaningful icons or chart lines. Every palette in this catalog lists its verified pairs; re-check with a contrast tool after any colour change.
- Keep body text at 16px or larger with 1.5 line height, nothing below 12px, no light weights under 24px, and uppercase only for short labels.
- Give every interactive element a visible focus ring, full keyboard support, semantic landmarks, labelled form fields, and alt text on meaningful images.
- Respect `prefers-reduced-motion` for every animation. Give drag-and-drop and carousels keyboard and button alternatives.
- Build mobile-first and test at 375px, 768px and 1280px.

### Content guardrails
- Use original copy, fictional sample data and placeholder or licensed imagery. Do not reuse another product's name, logo, screenshots or marketing text.
- Label demo testimonials and metrics as samples. Collect the minimum personal data the feature needs.

### SaaS screen baseline
- Design every screen for its full set of states: first-run empty, loading skeleton, partial data, error with retry, permission-denied, and success feedback. Each entry lists the states its screen needs.
- Keep destructive actions (delete, revoke, downgrade, remove member) behind a confirmation that names the object, and prefer undo over a second dialog where the action is reversible.
- Enforce authorisation on the server for every action a screen exposes. Hiding a button is not access control; check the role again in the API or RLS policy.
- Never show secrets (API keys, tokens) in full after creation. Show them once, then mask them, and offer rotate and revoke.
- Keep the app shell (navigation, workspace switcher, account menu) consistent across screens, and preserve filters, sort and scroll position when the user navigates back.

### Goal
Build **Quellgate**, the fraud strategy builder of a payments dashboard. It shows the live pre-authorisation and post-authorisation strategies as a left-to-right pipeline of lists and rule groups with true/false branches into outcomes, and lets risk admins edit a draft and publish it with a note.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Tabs, Sheet, Select, Dialog, Badge), lucide-react, TanStack Query, react-hook-form + zod for rules, date-fns. Supabase Auth, Postgres, and an Edge Function that validates and publishes strategies transactionally.

### Pages & layout
1. **Dashboard shell**: top bar, primary tabs, sub-nav pills.
2. **/fraud/strategy?phase=pre|post**: title, phase tabs, live/draft header, canvas, minimap.
3. **Rule group drawer**: rules table with add/edit/disable.
4. **Publish dialog** with note and diff.
5. Mobile: vertical outline instead of canvas.

### Design system
- Colors: `--bg: #ffffff` (page background), `--canvas: #f4f2f3` (canvas band), `--fg: #1a1a1a` (primary text), `--muted: #5c5c66` (secondary text), `--accent: #1a5fd6` (active tab / links), `--pill: #dbe9fd` (active sub-nav pill), `--decline: #cc3a0f` (decline outcome), `--challenge: #1a66e0` (challenge outcome), `--accept: #1b8a4b` (accept outcome), `--badge: #3a3a40` (T/F badge), `--border: #c9ccd1` (card border).
- Fonts: Inter 600, 28px/1.2 page title; 20px section for headings; Inter 400 16px/1.5; 14px inside stage cards for body. Stage card titles 14px 600; T/F badges 12px 700 white; tab labels 16px 500.
- Spacing: Moderate: stage cards 200px wide, 4px radius, 1px border, 12px padding; 32px between stages; outcome chips 32px tall, 4px radius, 1.5px coloured border with a filled dot at the connection point.
- Radius: 4px cards and chips, full pills for sub-nav and T/F discs.
- Shadows: minimap card only.
- Motion: 150ms path highlight; drawer 200ms slide.

### Components & interactions
TopNav, SubNavPills, AuthPhaseTabs, StrategyCanvas (SVG connectors + DOM cards), StageCard, TFBadge, OutcomeChip, Minimap, ZoomControls, DraftBar, RuleGroupDrawer, PublishDialog, StrategyOutline.

Interactions: click a stage to open its drawer listing rules with add/edit; outcome chip for 'false' of the last group is a select (accept / challenge / review); editing creates a draft; the header shows Draft and a Publish button; publish asks for a change note and shows a diff summary; pan by drag, zoom with controls; minimap viewport box is draggable; hovering a connector highlights the full path to its outcome.

States to build: live strategy view (read-only); draft with unsaved changes; empty stage ('No items yet' / 'No rules are added to this rule group'); publishing / published toast with version; publish blocked (validation: unreachable outcome); viewer role (edit disabled with tooltip); loading skeleton pipeline.

### Data & state
Canvas layout is computed from stage order; branches map to outcome chips. Drafts are copies of the live version; publishing bumps version and archives the old one. Seed a pre-auth strategy with empty trust and decline lists, an empty decline rule group and an empty challenge rule group whose false branch is 'accept'.

Model: `Strategy{id, account_id, phase (pre_auth|post_auth), version, status (live|draft), published_by, published_at, note}`; `Stage{id, strategy_id, kind (trust_list|decline_list|rule_group), position, name}`; `Rule{id, stage_id, expression, enabled, created_by}`; `Branch{stage_id, when (true|false), outcome (decline|challenge|accept|next)}`; `ListItem{id, list_kind, value_hash, type (card|email|ip|device), expires_at}`.

### Accessibility
Offer a text 'Strategy outline' view listing stages, rules and T/F outcomes for screen readers. T/F badges have accessible names 'if true' / 'if false'. Outcome colours all reach 3:1 on white and are always paired with a label. Tabs and sub-nav use proper tablist/nav semantics with aria-current. Canvas controls are buttons with labels and keyboard shortcuts.
Verified contrast: body text: #1a1a1a on #ffffff = 17.4:1; muted text on canvas: #5c5c66 on #f4f2f3 = 5.93:1; active tab text: #1a5fd6 on #ffffff = 5.75:1; pill text: #1a5fd6 on #dbe9fd = 4.68:1; decline outline: #cc3a0f on #ffffff = 5.02:1; challenge outline: #1a66e0 on #ffffff = 5.22:1; accept outline: #1b8a4b on #ffffff = 4.39:1; T/F badge label: #ffffff on #3a3a40 = 11.3:1.

### Security
RLS: strategies and rules scoped to the merchant account; only 'risk_admin' may publish. Store list values (cards, emails) hashed; never show full card numbers. Validate rule expressions server-side against an allowlisted grammar. Audit every publish with actor, note and diff; support one-click rollback. RLS per table: `strategies`, `stages`, `rules`, `branches` select for account members; insert/update only on draft rows by `risk_analyst` or `risk_admin`; status 'live' set only by the publish function for `risk_admin`; `list_items` store hashed values and are writable by analysts.

### Performance & SEO
Render SVG connectors once per layout change; memoise stage cards. Lazy-load the drawer. Dashboard routes noindex.

### Guardrails
- Always label which strategy is live and whether you are looking at a draft.
- Keep outcomes on the right edge so every path reads left to right.
- Use fixed outcome colours (decline red, challenge blue, accept green) plus text labels.
- Require a change note on publish and show what changed.
- Make empty stages explicit so analysts know nothing is filtering there.
- Write all copy fresh; use invented people, companies and numbers only. No real brands, logos, wordmarks or third-party product names anywhere in the UI or seed data.
- Do not trace or copy any existing product's layout assets, icons or illustrations; draw generic ones.
- Acceptance criteria:
  - [ ] Live strategy renders all stages and outcomes
  - [ ] Editing creates a draft with a Draft badge
  - [ ] Publishing requires a note and shows a diff
  - [ ] Viewers cannot edit
  - [ ] The outline view conveys the same logic as the canvas

Open the builderAll templatesThis palette on its own