LLM context files cleanup

.cursor/rules/cursor_rules.mdc

@@ -50,4 +50,5 @@ alwaysApply: true
   - Keep descriptions concise
   - Include both DO and DON'T examples
   - Reference actual code over theoretical examples
-  - Use consistent formatting across rules 
+  - Use consistent formatting across rules
+

.cursor/rules/general-rules.mdc

@@ -12,6 +12,7 @@ alwaysApply: true
   - Read [project-conventions.mdc](mdc:.cursor/rules/project-conventions.mdc) to understand _how_ to write code for the codebase
   - Read [ui-ux-design-guidelines.mdc](mdc:.cursor/rules/ui-ux-design-guidelines.mdc) to understand how to implement frontend code specifically
 - Ignore i18n methods and files. Hardcode strings in English for now to optimize speed of development.
+- ActiveRecord migrations must inherit from `ActiveRecord::Migration[7.2]`. Do **not** use version 8.0 yet.
 
 ## Prohibited actions
 

.cursor/rules/project-conventions.mdc

@@ -70,3 +70,4 @@ All code should maximize readability and simplicity.
 - Enforce `null` checks, unique indexes, and other simple validations in the DB
 - ActiveRecord validations _may_ mirror the DB level ones, but not 100% necessary.  These are for convenience when error handling in forms.  Always prefer client-side form validation when possible.
 - Complex validations and business logic should remain in ActiveRecord
+

.cursor/rules/self_improve.mdc

@@ -69,4 +69,5 @@ alwaysApply: true
   - Update references to external docs
   - Maintain links between related rules
   - Document breaking changes
+
 Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.

.cursor/rules/stimulus_conventions.mdc

@@ -61,4 +61,3 @@ This rule describes how to write Stimulus controllers.
 
 - **Component controllers should not be used outside the component**
   - If a Stimulus controller is in the app/components directory, it should only be used in its component view. It should not be used anywhere in app/views.
-

.cursor/rules/testing.mdc

@@ -80,8 +80,7 @@ Due to the open-source nature of this project, we have chosen Minitest + Fixture
   - Never test the implementation details of one class in another classes test suite
 
 - **Stubs and mocks**
-  - Use `mocha` gem 
+  - Use `mocha` gem
   - Always prefer `OpenStruct` when creating mock instances, or in complex cases, a mock class
   - Only mock what's necessary. If you're not testing return values, don't mock a return value.
 
-

.cursor/rules/ui-ux-design-guidelines.mdc

@@ -17,6 +17,7 @@ The codebase uses TailwindCSS v4.x (the newest version) with a custom design sys
 - Always prefer using the functional "tokens" defined in @maybe-design-system.css when possible.
   - Example 1: use `text-primary` rather than `text-white`
   - Example 2: use `bg-container` rather than `bg-white`
-  - Example 3: use `border border-primary` rather than `border border-gray-200` 
+  - Example 3: use `border border-primary` rather than `border border-gray-200`
 - Never create new styles in [maybe-design-system.css](mdc:app/assets/tailwind/maybe-design-system.css) or [application.css](mdc:app/assets/tailwind/application.css) without explicitly receiving permission to do so
 - Always generate semantic HTML
+

.cursor/rules/view_conventions.mdc

@@ -97,4 +97,5 @@ Use this rule to learn how to write ERB views, partials, and Stimulus controller
   - **Components**: Use `ComponentName` suffix (e.g., `ButtonComponent`, `DialogComponent`, `FilledIconComponent`)
   - **Partials**: Use underscore prefix (e.g., `_trend_change.html.erb`, `_form_errors.html.erb`, `_sync_indicator.html.erb`)
   - **Shared partials**: Place in `app/views/shared/` directory for reusable content
-  - **Context-specific partials**: Place in relevant controller view directory (e.g., `accounts/_account_sidebar_tabs.html.erb`)
+  - **Context-specific partials**: Place in relevant controller view directory (e.g., `accounts/_account_sidebar_tabs.html.erb`)
+