Oriswell

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 16px row titles; no large headline
• InterBody: Inter 400 16px / 1.5; helper lines 15px in dense rows

Patterns

• status badge + type caption header
• copyable job ID
• progress section with bar and explanation
• succeeded / failed counters
• key-value input summary with helper text per row
• breadcrumb to parent list

States it is designed for

• queued
• running with live progress
• completed
• completed with failures
• failed entirely (error summary)
• cancelled
• not found
• results loading / empty

Who it is for

• developers running crawl jobs
• data engineers debugging failed pages

Layout

1. Console sidebar and credits counter (shared)
2. Breadcrumb: Batches > batch ID (mono)
3. Card (max 380px): header with status badge, mode and format caption, overflow menu; batch ID with copy
4. Progress group: status row, pages crawled row with explanation and full-width bar, succeeded and failed rows
5. Input group: mode, format, start URL (mono on its own line), page budget, max depth, follow subdomains - each with a helper line
6. Results section (below): table of pages with status and download, or failure reasons
7. Mobile: card full width

Palette

Quiet, precise and diagnostic.

• app bg#f7f7f7
• card#ffffff
• row bg#f4f4f4
• text#1a1a1a
• muted text#646464
• success#16a34a
• success badge bg#e8f7ee
• success badge text#166534
• failure#c2410c
• focus ring#0072e6

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 16px row titles; no large headline

Body

Inter 400 16px / 1.5; helper lines 15px in dense rows

JetBrains Mono 15px for IDs and URLs; badge uppercase 12px 600 with 0.06em tracking.

Spacing and imagery

Dense; rows 44-56px with 12px padding, 1px separators, 16px between groups; radius 12px card, 6px badge; card shadow 0 1px 3px rgba(0,0,0,.05).

None; status icons only.

Components

• Breadcrumb
• JobHeader with StatusBadge
• CopyableId
• ProgressGroup
• ProgressBar
• CountRow
• InputSummary (KeyValueRow with helper)
• PageResultsTable
• OverflowMenu (rerun, duplicate, cancel, delete)

Interactions

• Running jobs poll every 3s (or subscribe to realtime) and animate the bar
• Failed count links to the results table filtered to failures
• Overflow: Rerun creates a new batch with the same input; Cancel only while running
• Copy ID shows check feedback
• Start URL row has an external-link button

Data

• Batch{id, mode (scrape|sitemap|crawl), format, start_url?, page_budget, max_depth?, follow_subdomains, status, pages_crawled, succeeded, failed, created_at, finished_at?}
• PageResult{id, batch_id, url, status (ok|error), http_status?, error_reason?, output_path?}

Guardrails

Experience

• Explain outcomes in plain words, not just numbers
• Show inputs so users can reproduce or tweak
• Make failures one click away
• Offer rerun from the same page

Accessibility

• Progress bar is a progressbar with text value
• Status badge text is readable (not colour-only)
• Key-value rows use dl/dt/dd
• Live progress announced at most every 10%
• IDs are selectable and copy buttons labelled

Security

• RLS by workspace on batches and results
• Output files served through signed URLs that expire
• Cancel/rerun check workspace role
• Never display fetched page content as HTML in the console

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 **Oriswell**, the batch detail page of a web-data console: status header, progress, counts, input summary and a results table. Seed batches in each status with fictional URLs.

### Stack
Use React 18, TypeScript, Vite, Tailwind CSS, shadcn/ui, Radix, lucide-react, TanStack Query, react-hook-form, zod, Supabase. Progress updates stream through Supabase Realtime on the batches row. Use Supabase for Auth, Postgres (row-level security on every table) and Storage where noted; keep only the anon key in the browser and run privileged work in Edge Functions.

### Pages & layout
1. **/batches/:id**: this page.
2. **/batches**: list for the breadcrumb.

Regions, in order:
- Console sidebar and credits counter (shared)
- Breadcrumb: Batches > batch ID (mono)
- Card (max 380px): header with status badge, mode and format caption, overflow menu; batch ID with copy
- Progress group: status row, pages crawled row with explanation and full-width bar, succeeded and failed rows
- Input group: mode, format, start URL (mono on its own line), page budget, max depth, follow subdomains - each with a helper line
- Results section (below): table of pages with status and download, or failure reasons
- Mobile: card full width

### Design system
- Colors: `--app-bg: #f7f7f7` (app bg), `--card: #ffffff` (card), `--row-bg: #f4f4f4` (row bg), `--text: #1a1a1a` (text), `--muted-text: #646464` (muted text), `--success: #16a34a` (success), `--success-badge-bg: #e8f7ee` (success badge bg), `--success-badge-text: #166534` (success badge text), `--failure: #c2410c` (failure), `--focus-ring: #0072e6` (focus ring).
- Fonts: Inter 600 16px row titles; no large headline for headings; Inter 400 16px / 1.5; helper lines 15px in dense rows for body. JetBrains Mono 15px for IDs and URLs; badge uppercase 12px 600 with 0.06em tracking.
- Spacing, radius and shadows: Dense; rows 44-56px with 12px padding, 1px separators, 16px between groups; radius 12px card, 6px badge; card shadow 0 1px 3px rgba(0,0,0,.05).
- Motion: 150-200 ms ease-out for hover, focus and overlay transitions; overlays fade and scale from 98% to 100%; everything collapses to an instant change under prefers-reduced-motion.
- Mood: Quiet, precise and diagnostic. Imagery: None; status icons only.

### Components & interactions
Build these components: Breadcrumb; JobHeader with StatusBadge; CopyableId; ProgressGroup; ProgressBar; CountRow; InputSummary (KeyValueRow with helper); PageResultsTable; OverflowMenu (rerun, duplicate, cancel, delete).

- Running jobs poll every 3s (or subscribe to realtime) and animate the bar
- Failed count links to the results table filtered to failures
- Overflow: Rerun creates a new batch with the same input; Cancel only while running
- Copy ID shows check feedback
- Start URL row has an external-link button

### Data & state
Model: `Batch{id, mode (scrape|sitemap|crawl), format, start_url?, page_budget, max_depth?, follow_subdomains, status, pages_crawled, succeeded, failed, created_at, finished_at?}`; `PageResult{id, batch_id, url, status (ok|error), http_status?, error_reason?, output_path?}`.

Explanation text is derived from status and counts (e.g. 'stopped early: no more reachable pages under the budget'). Results page by 50.

States to implement and demo:
- queued
- running with live progress
- completed
- completed with failures
- failed entirely (error summary)
- cancelled
- not found
- results loading / empty

### Accessibility
- Progress bar is a progressbar with text value
- Status badge text is readable (not colour-only)
- Key-value rows use dl/dt/dd
- Live progress announced at most every 10%
- IDs are selectable and copy buttons labelled
- Body text is 16px with line-height 1.5 (15px only inside dense tables), nothing renders below 12px, weights of 300 or lighter appear only at 24px and above, and uppercase is limited to short labels with at least 0.05em tracking.
Verified contrast: body text on row bg: #1a1a1a on #f4f4f4 = 15.82:1; muted helper on row bg: #646464 on #f4f4f4 = 5.38:1; completed badge text: #166534 on #e8f7ee = 6.44:1; progress bar on row bg: #16a34a on #f4f4f4 = 3.00:1; failed count text on row bg: #c2410c on #f4f4f4 = 4.71:1; focus ring on app bg: #0072e6 on #f7f7f7 = 4.31:1.

### Security
- RLS by workspace on batches and results
- Output files served through signed URLs that expire
- Cancel/rerun check workspace role
- Never display fetched page content as HTML in the console

RLS: `batches`, `page_results` - select for workspace members; updates via service role (workers); storage outputs private with signed URLs.

### Performance & SEO
Realtime instead of aggressive polling; virtualise results. Noindex.

### Guardrails
- Explain outcomes in plain words, not just numbers
- Show inputs so users can reproduce or tweak
- Make failures one click away
- Offer rerun from the same page
- Use the product name Oriswell and fresh, generic copy throughout; all people, companies, amounts and IDs are invented, and no third-party brand, logo or wordmark appears.
- Keep components small and typed (no `any`), and surface every failure visibly instead of swallowing it.

Acceptance criteria:
- [ ] All statuses render
- [ ] Live progress updates
- [ ] Failures filter works
- [ ] 390px layout works
- [ ] Contrast pairs pass

Open the builderAll templatesThis palette on its own