# Project rules (legacy .cursorrules format; prefer .cursor/rules/project.mdc)

## Project
<!-- Fill this in. Keep it short. -->
- What it is: <one sentence>
- Stack: <e.g. Next.js + TypeScript + Tailwind + Postgres (Supabase)>
- Package manager: <npm | pnpm | bun>
- Commands: dev `<cmd>` · test `<cmd>` · lint `<cmd>` · build `<cmd>`

## How to work
- Before coding anything non-trivial, write a short plan (files to touch, steps) and wait for my OK.
- Make the smallest change that solves the task. Do not refactor unrelated code.
- Work in small steps; after each step the app must still build and run.
- If a requirement is ambiguous, ask one clear question instead of guessing.
- Never invent APIs, packages, or config options. If unsure a library supports something, say so and check the docs.
- Prefer the libraries already in the project over adding new dependencies. Ask before adding one.

## Code style
- TypeScript strict mode; no `any` unless unavoidable (add a comment why).
- Small, named functions. Descriptive names over comments. Comments explain *why*, not *what*.
- Handle errors explicitly; show the user a helpful message, log details server-side.
- Match the existing formatting and file layout.

## Security (non-negotiable)
- Never hardcode secrets, API keys, or tokens. Read them from environment variables.
- Never expose server secrets to the client (e.g. only `NEXT_PUBLIC_*` vars reach the browser — never put secrets there).
- Validate and sanitize all user input on the server. Use parameterized queries; never build SQL with string concatenation.
- Check authorization on every server route/action, not just in the UI.
- Do not disable security features (CORS, CSRF, RLS, auth checks) to "make it work".

## Testing
- Add or update tests for any logic you change. Run the test command and report the result.
- When fixing a bug, first write a test that reproduces it.

## Done means
- Builds, lints, and tests pass. You summarized what changed, which files, and anything I must do manually (env vars, migrations).
