From 198adf9fb37315880de786ca9f2657d8d48808c0 Mon Sep 17 00:00:00 2001
From: dal <dallin@buster.so>
Date: Fri, 25 Jul 2025 18:33:39 -0600
Subject: [PATCH] global cursor fix

---
 .cursor/rules/global.mdc | 77 +++++++++++++++++++++++++++++++++-------
 1 file changed, 64 insertions(+), 13 deletions(-)

diff --git a/.cursor/rules/global.mdc b/.cursor/rules/global.mdc
index faee8ef68..9a2e8ed68 100644
--- a/.cursor/rules/global.mdc
+++ b/.cursor/rules/global.mdc
@@ -3,12 +3,6 @@ description:
 globs: 
 alwaysApply: true
 ---
-# CLAUDE.md
-
-This file provides guidance to Claude Code when working with code in this monorepo.
-
-**Note**: Many packages and apps have their own CLAUDE.md files with specific implementation details and patterns. Always check for a local CLAUDE.md when working in a specific directory.
-
 ## Monorepo Structure
 
 This is a pnpm-based monorepo using Turborepo with the following structure:
@@ -54,6 +48,58 @@ When writing code, follow this workflow to ensure code quality:
 - Keep business logic separate from infrastructure concerns
 - Use proper error handling at each level
 
+## Environment Variables
+
+This project uses a centralized environment variable system:
+
+1. **All environment variables are defined at the root level** in a single `.env` file
+2. **Turbo passes these variables** to all packages via the `globalEnv` configuration in `turbo.json`
+3. **Individual packages validate** their required environment variables using the shared `@buster/env-utils` package
+
+### Setting Up Environment Variables
+
+1. Copy `.env.example` to `.env` at the project root:
+   ```bash
+   cp .env.example .env
+   ```
+
+2. Fill in the required values in `.env`
+
+3. All packages will automatically have access to these variables through Turbo
+
+### Adding New Environment Variables
+
+When adding new environment variables:
+
+1. Add the variable to `.env.example` with a descriptive comment
+2. Add the variable name to the `globalEnv` array in `turbo.json`
+3. Update the package's `validate-env.js` script to include the new variable
+4. Update the package's `env.d.ts` file with the TypeScript type definition
+
+### Migrating Packages to Centralized Env
+
+To migrate an existing package to use the centralized environment system:
+
+1. Remove any local `.env` files from the package
+2. Add `@buster/env-utils` as a dependency:
+   ```json
+   "@buster/env-utils": "workspace:*"
+   ```
+3. Update the package's `scripts/validate-env.js` to use the shared utilities:
+   ```javascript
+   import { loadRootEnv, validateEnv } from '@buster/env-utils';
+   
+   loadRootEnv();
+   
+   const requiredEnv = {
+     DATABASE_URL: process.env.DATABASE_URL,
+     // ... other required variables
+   };
+   
+   const { hasErrors } = validateEnv(requiredEnv);
+   if (hasErrors) process.exit(1);
+   ```
+
 ### 3. Ensure Type Safety
 ```bash
 # Build entire monorepo to check types
@@ -202,18 +248,23 @@ export async function getWorkspaceSettingsHandler(
 
 ## Database Operations
 
+### Query Organization
+- **All database queries must be created as helper functions** in `@packages/database/src/queries/`
+- **Organize by table** - Each table should have its own subdirectory (e.g., `assets/`, `chats/`, `users/`)
+- **Type all queries** - Every query function must have properly typed parameters and return types
+- **Export from index** - Each subdirectory should have an `index.ts` that exports all queries for that table
+- **Reusable and composable** - Write queries as small, focused functions that can be composed together
+
 ### Soft Delete and Upsert Practices
 - In our database, we never hard delete, we always use soft deletes with the `deleted_at` field
 - For update operations, we should almost always perform an upsert unless otherwise specified
-```
 
-**Test Running Guidelines**:
+## Test Running Guidelines
 - When running tests, use the following Turbo commands:
   - `turbo test:unit` for unit tests
   - `turbo test:integration` for integration tests
   - `turbo test` for running all tests
-# important-instruction-reminders
-Do what has been asked; nothing more, nothing less.
-NEVER create files unless they're absolutely necessary for achieving your goal.
-ALWAYS prefer editing an existing file to creating a new one.
-NEVER proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested by the User.
\ No newline at end of file
+
+## Pre-Completion Workflow
+- Always run `turbo test:unit, lint, and build:dry-run` before making any pull request or finishing a feature, bugfix, etc. to ensure things make it through CI/CD
+- You can run all these checks simultaneously with `turbo build:dry-run lint test:unit`
\ No newline at end of file