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

.cursor/rules/conventional_commits.mdc

@@ -3,68 +3,55 @@ 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"
+   - feat: A new feature
-      git commit -m "$CHANGE_TYPE($SCOPE): $CHANGE_DESCRIPTION"
+   - fix: A bug fix
+   - docs: Documentation only changes
+   - style: Changes that do not affect the meaning of the code
+   - refactor: A code change that neither fixes a bug nor adds a feature
+   - perf: A code change that improves performance
+   - test: Adding missing tests or correcting existing tests
+   - chore: Changes to the build process or auxiliary tools
 
-  - type: suggest
+4. Guidelines:
-    message: |
+   - Scope should be derived from the file path or affected component
-      Changes should be committed using conventional commits format:
+     - 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)!:
 
-      Format: <type>(<scope>): <description>
+metadata:
-
+  priority: high
-      Types:
+  version: 1.0
-      - feat: A new feature
+</rule>
-      - fix: A bug fix
-      - docs: Documentation only changes
-      - style: Changes that do not affect the meaning of the code
-      - refactor: A code change that neither fixes a bug nor adds a feature
-      - perf: A code change that improves performance
-      - 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.
-      The description should be clear and concise, written in imperative mood.
 
 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>