Opsml UI

Canonical skill for OpsML frontend work. The older sveltekit-neobrutalism skill is a legacy alias; use this skill as the source of truth for crates/opsml_server/opsml_ui.

Work inside the existing opsml_ui architecture and visual language rather than treating this as a generic Svelte app. OpsML is a dense developer tool, not a marketing site: build fast, scannable, task-oriented interfaces that expose operational details clearly.

Start by locating the feature boundary before editing:

• Read references/working-map.md to find the right feature area.

Then load only the topic references needed for the task:

• BFF/data-loading, server routes, load functions, invalidation, auth/session boundaries: read references/sveltekit-architecture.md and, for legacy route notes, references/architecture.md.
• Svelte component state, runes, snippets, effects, .svelte.ts modules, and legacy Svelte anti-patterns: read references/svelte5-patterns.md and, for shorter local patterns, references/sveltekit-patterns.md.
• Large tables, traces, files, charts, pagination, virtualization, search/filtering, and payload budgets: read references/data-performance.md.
• Developer workflow UX, registries, observability, trace inspection, filters, drilldowns, empty/loading/error states: read references/developer-ux.md.
• Tailwind v4, Skeleton, OpsML theme tokens, dark mode, icons, semantic color rules: read references/theming.md and, for short local rules, references/design-system.md.
• Vitest, Svelte Testing Library, pure utility tests, build/manual checks, accessibility and performance checks: read references/testing-verification.md.

Follow these repo-specific rules:

• Keep data fetching server-side by default. Prefer +page.server.ts, +layout.server.ts, and server helpers under src/lib/server/.
• Reuse the BFF shape already in the app. If a component needs backend access, prefer an internal SvelteKit /routes/api/... endpoint plus a server helper instead of calling the Rust backend directly from the browser.
• Reuse route constants from src/lib/components/api/routes.ts before introducing new path strings.
• Preserve OpsML theme tokens and brutalist interaction patterns. Do not introduce arbitrary hex colors, soft shadows, glassmorphism, or generic grayscale borders.
• Use primary-*, secondary-*, and tertiary-* for neutral UI categories. Reserve success-*, warning-*, and error-* for actual state, feedback, risk, or failure semantics.
• Keep types close to the feature unless they are clearly shared by multiple areas.
• Preserve the current auth flow in src/hooks.server.ts and src/lib/server/auth/validateToken.ts.
• Use $derived(expression) or $derived.by(() => expression) for derived state and keep derived values side-effect free.
• Use $effect mainly for external side effects such as browser APIs, observers, Chart.js, CodeMirror, imperative subscriptions, and request side effects.
• Prefer server-backed pagination, filtering, sorting, and aggregation for large remote datasets.
• Use VirtualScroller.svelte or @tanstack/svelte-virtual for large scrollable views.
• Do not add new UI libraries unless the user explicitly asks.

When making changes, inspect in this order:

1. The route entrypoint (+page.svelte, +page.ts, +page.server.ts, +layout.*)
2. The feature component under src/lib/components/...
3. The server helper under src/lib/server/...
4. Shared route constants, schema, or local feature types

Use these verification commands from crates/opsml_server/opsml_ui when relevant:

• pnpm build
• pnpm exec svelte-check
• pnpm exec eslint .

Prefer small, local edits that match existing patterns over broad refactors unless the task explicitly requires architectural cleanup.