> ## Documentation Index
> Fetch the complete documentation index at: https://design.slingshotai.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> This site documents Sundial 2.0, the design system of the Ash mobile app (Flutter). For implementing UI: use the Design System pages — color/typography tokens (foundations/*), Flutter theming (theming/*), and component APIs (components/*) — as your reference; every value there mirrors the Dart source in lib/design_system/. The Philosophy pages (philosophy/*) are design rationale written for humans: consult them when making design decisions, not for API lookups. Golden rules: never hardcode colors or text styles — read tokens via context.colorTheme and context.textTheme; prefer the 2.0 semantic names (contentPrimary, surfaceComponent, accentSolid…) over legacy contrast*/surface* getters and over SundialRef primitives; the accent is a single pale lavender solid that takes dark content — never use accent fills as text, icons, or borders (use contentAccent / borderSelected); brand surfaces are mode-invariant and pair with the contentOnBrand* inks; check lib/design_system/components/ before building custom widgets.

# Anti-Patterns

> Design rationale: the never-do-these list — dark patterns, emoji UI, arbitrary values, border overuse, and more

These are hard rules, not preferences. If a design does any of these, it's wrong — fix it.

* **Dark patterns of any kind.** No manipulative modals, no guilt-tripping copy, no artificial urgency, no buried opt-outs.
* **Emojis in UI** unless they are user-generated content. The product chooses its personality through design, not emoji.
* **Bad typography.** Inconsistent hierarchy, too many font sizes, decorative type without purpose. See [Typography](https://design.slingshotai.com/philosophy/craft/typography.md).
* **Uncomfortable spacing.** Generous, consistent whitespace. When something feels wrong, it's usually cramped or inconsistently spaced. Err on the side of breathing room.
* **Unjustified elements.** Every button, label, section, and interaction must have a reason for existing. If you can't articulate why it's there, remove it.
* **Gratuitous visual complexity.** No glassmorphism, gradients, shadows, or animation unless they serve a specific functional or emotional purpose.
* **Designing for the business instead of the user.** If a feature exists primarily to move a metric rather than help the person, flag it.
* **Border overuse.** Don't reach for borders by default to separate content. Spacing, background color changes, and subtle shadows are almost always cleaner. See [Color & Depth](https://design.slingshotai.com/philosophy/craft/color-and-depth.md).
* **Stretching content to fill space.** On large screens, content should have a comfortable max-width. Don't let it stretch edge-to-edge just because the viewport allows it.
* **Neglected empty states.** Never leave a blank state undesigned. “No results” or “Nothing here yet” without intention is a missed opportunity.
* **Arbitrary values.** Never use a spacing value, font size, or color that isn't from the design system's defined scale. If it feels “close enough,” use the nearest system value instead. In Sundial terms: tokens from [Semantic Colors](https://design.slingshotai.com/foundations/colors/semantic.md) and [Typography](https://design.slingshotai.com/foundations/typography.md), never hand-picked values.

> [!NOTE]
>
> The system-level enforcement of several of these lives in [Conventions](https://design.slingshotai.com/patterns/conventions.md) — e.g. “never hardcode colors or text styles” is the code-level form of the arbitrary-values rule.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.