cursorrules example

.cursorrules

You will work against Trello using an MCP server.

pnpm commands:
"dev": "next dev --turbopack --port 3123",
"build": "next build",
"start": "next start",
"lint": "next lint",
"test": "vitest --run",
"db:types:old": "supabase gen types typescript --project-id \"tgtigdqxrdiikinybwoz\" --schema public > db/database.types.ts",
"db:types": "npx supabase gen types typescript --local > supabase/database.types.ts",
"db:pull": "pnpm supabase db pull",
"db:push": "pnpm supabase db push",
"db:reset": "pnpm supabase db reset",
"db:diff": "pnpm supabase db diff -f"

You will maintain a Mermaid diagram of the entire application under the "llm" folder in a file called "architecture.md".

Feature planning:
When planning a new feature, create a label for that feature and add it to all the tickets you create for that feature.
Create a detailed plan and save it in the "llm/features" directory.
If the plan is approved create tickets for each task you need to do to implement the feature (dont forget to add the label to the tickets).

Feature implementation:
When working on a ticket, you will use the following workflow:

1. Get tickets from the NEXT_UP list (mcp get-tickets-by-list tool)
2. Select the most appropriate ticket to the DOING list
3. Create a new branch named after the ticket
4. Make the changes and commit them
5. Write tests (vitest), logic and/or browser tests (using stagehand) if applicable
6. add a markdown file with a slug of the ticket name under the "llm" directory and explain the changes you made and the reason behind them
7. Generate a mermaid diagram of the changes you made and add it to the markdown file
8. You will update the "architecture.md" file to reflect the changes you made
9. Make sure to add a link to the pull request in the markdown files (in the architecture.md put the link under the feature headline)
10. Run the tests (pnpm test)and fix if any fail
11. Push the changes to the remote repository
12. Create a pull request:
    - Title should be descriptive and follow conventional commits format
    - Use the content of the markdown file as the PR description (using gh pr create/edit with --body-file)
    - Include a link to the trello ticket
13. Move the ticket to the INSPECTION list

When planning a new feature, create a label for that feature and add it to all the cards you create for that feature.

When working on a feature start working on the infrastructure first and go up. If possible try to make non breaking changes so we can merge the Pull Request back to main without breaking production since not all the tickets of the features are done.

UI features should be protected by feature flags (PostHog).
Server component:

```ts
import { getFlags } from '@/lib/posthog/posthog';

export default async function SomePage() {
	const flags = await getFlags('user_distinct_id'); // replace with a user's distinct ID
	return <div></div>;
}
```

Client component:

```ts
import {
	useFeatureFlagEnabled,
	useFeatureFlagVariantKey,
	useFeatureFlagPayload,
} from 'posthog-js/react';

function App() {
	const showWelcomeMessage = useFeatureFlagEnabled('flag-key');
	const variantKey = useFeatureFlagVariantKey('show-welcome-message');
	const payload = useFeatureFlagPayload('show-welcome-message');

	return <div></div>;
}
```

- when running supabase cli run it as "pnpm supabase" from the root of the project
- when installing a package use pnpm
- use SWR for data fetching
- run pnpm db:types to generate the database types
- dal directory should consist of data logic and the structure should be as follows (for example):

```
dal/changelog/
  changelog.api.ts (the actual logic)
  changelog.hooks.ts (the hooks)
  changelog.endpoints.ts (the api routes list)
  changelog.test.ts (the tests)
  changelog.types.ts (the types)

- create api routes under the @/app/api folder according to the dal/changelog/changelog.endpoints.ts file (for example) and that use the dal/changelog/changelog.api.ts file (for example)
```