docs(rules): simplify conventional commits rule to avoid diff issues

.cursor/rules/conventional_commits.mdc

@@ -3,42 +3,19 @@ description: Automatically commit changes made by CursorAI using conventional co
 globs: **/*
 ---
 <rule>
-filters:
+Before committing changes:
-  - type: event
-    pattern: "build_success"
-  - type: file_change
-    pattern: "*"
 
-actions:
+1. Always review changed files:
-  - type: execute
+   ```bash
-    command: |
+   git status  # Check which files were modified
-      # Extract the change type and scope from the changes
+   ```
-      CHANGE_TYPE=""
-      case "$CHANGE_DESCRIPTION" in
-        *"add"*|*"create"*|*"implement"*) CHANGE_TYPE="feat";;
-        *"fix"*|*"correct"*|*"resolve"*) CHANGE_TYPE="fix";;
-        *"refactor"*|*"restructure"*) CHANGE_TYPE="refactor";;
-        *"test"*) CHANGE_TYPE="test";;
-        *"doc"*|*"comment"*) CHANGE_TYPE="docs";;
-        *"style"*|*"format"*) CHANGE_TYPE="style";;
-        *"perf"*|*"optimize"*) CHANGE_TYPE="perf";;
-        *) CHANGE_TYPE="chore";;
-      esac
 
-      # Extract scope from file path
+2. Follow conventional commits format:
-      SCOPE=$(dirname "$FILE" | tr '/' '-')
+   ```
+   <type>(<scope>): <description>
+   ```
 
-      # Commit the changes
+3. Types:
-      git add "$FILE"
-      git commit -m "$CHANGE_TYPE($SCOPE): $CHANGE_DESCRIPTION"
-
-  - type: suggest
-    message: |
-      Changes should be committed using conventional commits format:
-
-      Format: <type>(<scope>): <description>
-
-      Types:
    - feat: A new feature
    - fix: A bug fix
    - docs: Documentation only changes
@@ -48,23 +25,33 @@ actions:
    - test: Adding missing tests or correcting existing tests
    - chore: Changes to the build process or auxiliary tools
 
-      The scope should be derived from the file path or affected component.
+4. Guidelines:
-      The description should be clear and concise, written in imperative mood.
+   - Scope should be derived from the file path or affected component
+     - special cases:
+       - `notes`, `feeds` and `links` indicate the three subapplication scopes
+       - `rules` indicates changes to cursor rules
+       - `frontend` and `go` indicates broad changes to the typescript or go code respectively
+       - `infra` is for changes to the repo "infrastructure": scripts, ci configs etc
+   - Description should be clear, concise, and in imperative mood
+   - If changes span multiple scopes, use comma separation or omit scope
+   - If changes are breaking, add ! after type/scope: feat!: or feat(scope)!:
+
+metadata:
+  priority: high
+  version: 1.0
+</rule>
 
 examples:
   - input: |
       # After adding a new function
+      git status
       CHANGE_DESCRIPTION="add user authentication function"
       FILE="src/auth/login.ts"
     output: "feat(src-auth): add user authentication function"
 
   - input: |
       # After fixing a bug
+      git status
       CHANGE_DESCRIPTION="fix incorrect date parsing"
       FILE="lib/utils/date.js"
     output: "fix(lib-utils): fix incorrect date parsing"
-
-metadata:
-  priority: high
-  version: 1.0
-</rule>