docs(rules): add rules for backend logic and manual build process

.cursor/rules/backend-logic.mdc

@@ -0,0 +1,56 @@
+---
+description: Keep business logic in the backend to ensure security and compatibility
+globs: **/*.{ts,js,go}
+---
+<rule>
+When implementing features that involve business logic:
+
+1. Keep critical business logic in the backend:
+   - Data validation and sanitization
+   - ID/UUID generation
+   - Timestamp management
+   - Access control and authorization
+   - Complex calculations or data transformations
+
+2. Frontend should only handle:
+   - UI state management
+   - User input collection
+   - Data display and formatting
+   - Basic input validation for UX
+   - UI-specific transformations
+
+3. Security-sensitive operations must always be in backend:
+   - Cryptographic operations
+   - Token generation/validation
+   - Password handling
+   - Session management
+
+4. When in doubt about where to place logic:
+   - If it affects data integrity → backend
+   - If it requires secure execution → backend
+   - If it needs to work without JavaScript → backend
+   - If it's purely for display/interaction → frontend
+
+metadata:
+  priority: high
+  version: 1.0
+</rule>
+
+examples:
+  - input: |
+      # Bad: Generating UUIDs in frontend
+      const id = crypto.randomUUID();
+    output: |
+      // Backend generates ID
+      const response = await api.createResource(data);
+      const { id } = response;
+
+  - input: |
+      # Bad: Validating permissions in frontend
+      if (user.hasPermission('edit')) { ... }
+    output: |
+      // Let backend handle authorization
+      const response = await api.updateResource(id, data);
+      if (response.status === 403) {
+        showError('Not authorized');
+      }

.cursor/rules/manual-build.mdc

@@ -0,0 +1,51 @@
+---
+description: Always use build.sh for building the application, and remind to run it manually
+globs: **/*.{ts,js,go,svelte}
+---
+<rule>
+When making changes that require rebuilding the application:
+
+1. Never attempt to run build commands directly. Instead:
+   - Use the build.sh script from the project root
+   - Command: ./build.sh
+   - This ensures consistent build process across all environments
+
+2. The build script handles:
+   - Frontend build with correct environment
+   - Static assets copying
+   - Backend compilation
+   - All necessary pre and post-build steps
+
+3. When to run build.sh:
+   - After any frontend code changes
+   - After any backend code changes
+   - After dependency updates
+   - Before testing production builds
+   - Before deploying
+
+4. Important notes:
+   - Always run from project root directory
+   - Ensure script has execute permissions (chmod +x build.sh)
+   - Wait for the build to complete before testing changes
+   - Check build output for any errors
+
+metadata:
+  priority: high
+  version: 1.0
+</rule>
+
+examples:
+  - input: |
+      # Bad: Running individual build commands
+      cd frontend && bun run build
+    output: |
+      # Good: Using build script
+      ./build.sh
+
+  - input: |
+      # Bad: Manual multi-step build
+      bun run build
+      go build
+    output: |
+      # Good: Using unified build script
+      ./build.sh