Cline rules for SvelteKit

# Cline and Roo rules

Project rules for Cline and Roo Code in this SvelteKit repository.
Use the project's commands. Do not invent a package manager, and do not run destructive shell commands.

## Tool use

- Read the files you will change before editing them.
- Prefer a focused patch over rewriting a whole file.
- Run the test command from this file after a behavior change, or say why you could not.
- Do not delete generated folders, lockfiles, or migrations unless the task says so.

## Stack

This repository is a SvelteKit app. Load data in load functions, mutate through form actions, and write new components with Svelte 5 runes.

## Layout

- Routes live in `src/routes/`. Shared UI lives in `src/lib/components/`.
- Server-only modules belong in `*.server.ts` files or under `$lib/server`.
- Keep `+page.svelte` focused on rendering. Data loading belongs in `+page.server.ts` or `+page.ts`.

## Commands

- Dev server: `npm run dev`
- Production build: `npm run build`
- Typecheck: `npm run check`
- Tests: `npm test`

Use the script the repo already defines when it differs from the command above.

## Conventions

- Load data in load functions. Do not fetch in `onMount` for data the server can load.
- Mutations go through form actions when the route already uses them.
- New components use Svelte 5 runes. Do not introduce a store for state a rune can hold.
- Use `$lib` imports for shared code. Relative imports that climb out of a route are a smell.
- Type the load function's data and the component's `$props`.
- Progressive enhancement matters. A form should still make sense without a custom click handler.

## Testing

Add or update tests when behavior changes.

Use the runner the repo already has. Test load functions and form actions as data, and add a browser test only for a real interaction.

## Style

- Optimize for the next reader over the shortest diff.
- Comment only when the why is non-obvious.
- Name things the way neighboring files already do.
- Do not reformat code you did not change.

## Errors

- Fail at the boundary. Do not swallow errors.
- Use SvelteKit's `error` and `fail` helpers so the page can render a useful message. Do not throw a bare string.

## Scope

- Do the requested task. Do not refactor unrelated code.
- Match the rigor already in the repo. Fix what you touch.
- Ask one clarifying question only when the task cannot be finished without it. Otherwise state the assumption and continue.

## Avoid

- Do not import `$lib/server` into client code.
- Do not put secrets in `$env/dynamic/public` or `$env/static/public`.
- Do not disable SSR for a route to paper over a window access bug.
- Do not rewrite a working Svelte 4 component into runes unless you are already editing it.

## Done when

- The requested behavior works.
- `npm run check` is clean for the files you touched, and the route still loads in `npm run dev`.
- The diff stays inside the task.
- You list anything you could not run.