Playground Pages

Do not add playground routes to the main app navigation.

Content & Coverage

Playground pages are more than scratchpads; they should act as living documentation:

• Showcase all important states:
  • Success, error, loading, disabled, empty, overflowing, selected, etc.
• Showcase key variants:
  • Sizes, color variants, with/without icons, compact vs full layouts.
• Contextual usage:
  • Render components in realistic containers:
    • Narrow sidebars vs wide content areas.
    • Within cards, modals, drawers, or split panes as appropriate.
• Interactions:
  • Include buttons/toggles that mutate $state to flip between states.
  • Use simple, local state (Svelte 5 runes) rather than complex store wiring.

Think of each playground as a storybook-style page dedicated to one feature.

SEO & Accessibility (Even for Playgrounds)

Even though these routes are for development, keep basic hygiene:

• Use a clear <h1> for the main heading.
• Add a descriptive <title> and meta description via SvelteKit page metadata.
• Use semantic HTML (<section>, <article>, <nav>, etc.) where appropriate.
• Ensure labels, roles, and interactive elements are accessible and keyboard-friendly.

IDs should be unique and descriptive when used (for testing hooks, ARIA relationships, etc.).

Cleanup & Lifecycle

• Playground pages are primarily for development and ongoing maintenance.
• They should not appear in primary navigation, but it's fine to access them directly via URL (e.g. /playground/card-checkbox).
• If a playground is truly obsolete and no longer useful for maintenance or regression checks, it can be removed—but keeping useful playgrounds is encouraged.

For full details and original rules, refer to .agent/test-pages.md.