Spendflo Demo Environment

# Design Guidelines A shared reference for layout decisions, spacing conventions, and component usage. These rules apply across all screens and should be treated as non-negotiable constraints during implementation and design review. --- ## Layout ### Button SpacingAdjacent buttons must have **8px** of space between them. This applies to all button groups: primary/secondary pairs, icon buttons in a toolbar, and inline action clusters. ```[ Primary Action ]  ←8px→  [ Secondary Action ]``` Do not use larger gaps (e.g. 12px or 16px) between buttons just because surrounding whitespace feels loose. Button proximity signals that actions belong to the same context. ### Below Top NavigationAlways leave a **16px gap** between the bottom edge of the top nav and the first content element on the page. This applies whether the first element is a page header, a filter bar, a table, a card, or any other component. ```┌────────────────────────────────────┐│           Top Navigation           │└────────────────────────────────────┘  ↕ 16px┌────────────────────────────────────┐│       First Content Element        │``` Do not collapse this gap for "compact" views unless a layout token explicitly defines a smaller page offset for that context. ### TablesTables are always **edge to edge**: they span the full width of their containing layout column, reaching both the left and right edges with no horizontal padding or margin on either side. ```|←------- Full container width -------→|┌─────────────────────────────────────┐│ Col A      │ Col B     │ Col C      │├────────────┼───────────┼────────────┤│            │           │            │└─────────────────────────────────────┘``` - The table component itself must use `width: 100%` so it fills its container on both sides.- At least one column must be left without a fixed pixel width so it can flex and absorb remaining space, preventing a gap on the right edge when the container is wider than the sum of fixed column widths.- Padding lives inside the table cells, not outside the table. If a table appears inside a card or panel, the table must bleed to the card's inner edges , remove any wrapper padding that would otherwise indent it. ### Table HeaderAlways use the **filled table-header variant**: the header row carries a `--surface-strong` background, never a transparent one. This visually separates the header from the body rows on every table. - Use the `DataTable` header variant whose background is `var(--surface-strong)`. Do not ship a table with a transparent / unfilled header.- The fill is `--surface-strong` specifically, not `--surface-subtle` or any other surface token. --- ## Components and Patterns ### Build Every Screen From the Package

---name: demo-script-to-uidescription: >  Use this skill when a user shares a demo script, sales script, or product walkthrough alongside a codebase and wants it implemented. Triggers: "implement this demo", "build what's in this script", "turn this script into UI", or any time a script + codebase are both present.--- # Demo Script → UI **Rule: Understand the script → Confirm flows → Go scene by scene with user → Build all at end.** ## Steps **1. Inspect the codebase first.** Map components, states, interactions, patterns, and demo infrastructure. Also read `CLAUDE.md` for builder mode instructions. This is the source of truth. **2. Understand the script.** Read it fully and derive logical flows, including every optional, edge case, or conditional flow. Never omit a flow, never assume it's out of scope. Confirm the full interpretation with the user first: ```I see 4 flows in this script, including 1 optional:1. Exception Queue , user reviews a list of flagged invoices2. Invoice Detail , user opens an invoice and reviews AI findings3. Verdict Action , user approves, escalates, or disputes4. (Optional) Empty state , no invoices in the queue Does this look right? Should I include the optional flow?``` Once confirmed, go **scene by scene**. For each scene, present in the Claude interface: - The table row for that scene (user/system POV language)- A builder mode preview rendered in the app showing what that scene looks like  **Never make a silent assumption.** If anything in the script is ambiguous: interaction, layout, content, state, or behaviour , stop and ask before proceeding. Example: ```The script mentions a "verdict badge" but doesn't specify placement.Where should it appear: on the invoice row, in the detail header, or both?``` Action language rules:- User actions: `User clicks X`, `User selects X`, `User types in X`- System responses: `System loads X`, `Page opens with X`, `X updates to show Y` Table format per scene: | # | Action | Where | Reference | Status ||---|---|---|---|---|| 1 | User clicks invoice row | Invoice list page | Row action in Bills page | ✅ Exists | **3. Build.** Once all scenes are confirmed, ask: _"All scenes confirmed. Ready to build everything into the app?"_ Only start building after the user says yes.