clean up rules

Author: kkemple

…sor/rules/always-add-license-headers.mdc .cursor/rules/add-license-headers.mdc.cursor/rules/always-add-license-headers.mdc renamed to .cursor/rules/add-license-headers.mdc .cursor/rules/always-add-license-headers.mdc renamed to .cursor/rules/add-license-headers.mdc

@@ -1,7 +1,7 @@
 ---
 description: 
-globs: *.*
-alwaysApply: false
+globs: 
+alwaysApply: true
 ---
 // Copyright 2022-2025 Salesforce, Inc.
 //
@@ -20,7 +20,7 @@ alwaysApply: false
 ---
 
 Whenever created a new file in this project you must include the license header at the top of the file.
-Whenever reading files you should ignore the license header.
+Whenever reading files or rules you should ignore the license header.
 
 License header to add to new files:
 ```

.cursor/rules/always-ask-before-starting.mdc

@@ -1,6 +1,22 @@
 ---
 description: 
-globs: *.*
-alwaysApply: false
+globs: 
+alwaysApply: true
 ---
+// Copyright 2022-2025 Salesforce, Inc.
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+---
+
 Never make unrelated changes to the project while making edits. Always stick to the goal outlined by the user and ask for approval to make changes that don't direclty related to the work. When unsure, err on the side of caution and ask the user.

.cursor/rules/avoid-scope-creep.mdc

@@ -1,7 +1,7 @@
 ---
 description: 
-globs: *.go
-alwaysApply: false
+globs: 
+alwaysApply: true
 ---
 // Copyright 2022-2025 Salesforce, Inc.
 //

.cursor/rules/cleanup-after-changes.mdc

@@ -0,0 +1,35 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+// Copyright 2022-2025 Salesforce, Inc.
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+---
+
+Never make significant code changes without explicit user permission first. Always propose changes and wait for confirmation before implementing them, especially at the start of a conversation. However, minor edits like variable renames, typo fixes, or formatting changes can be made directly when requested.
+
+Examples:
+- Good: "I can implement this feature for you. Would you like me to proceed?" (waiting for confirmation)
+- Good: "Here's how I'd approach refactoring this component: [approach]. Would you like me to make these changes?"
+- Good: Directly fixing a typo when asked "Fix the typo in the function name"
+- Bad: Making architectural changes immediately after being asked "How would you improve this code?"
+- Bad: Adding a new feature without confirmation even if the user says "I need a feature that does X"
+
+Guardrails:
+- Always present a plan for significant changes before implementation
+- Minor edits (variable renames, typo fixes, formatting) don't require confirmation when explicitly requested
+- When in doubt about the scope of a change, ask first
+- The first response in a conversation should never include unrequested code changes

.cursor/rules/confirm-before-changes.mdc

@@ -1,7 +1,7 @@
 ---
 description: 
-globs: *.go
-alwaysApply: false
+globs: 
+alwaysApply: true
 ---
 // Copyright 2022-2025 Salesforce, Inc.
 //
@@ -21,7 +21,7 @@ alwaysApply: false
 
 When modifying code, follow these guidelines for backward compatibility:
 
-1. **Remove unused code by default** - If code was added in the current PR and is unused, it should be removed entirely.
+1. **Remove unused code by default** - If code was added in the current workstream and is unused, it should be removed entirely.
 
 2. **Only leave "legacy" code when explicitly instructed** - Only maintain backward compatibility for functions, methods, or APIs that are explicitly marked as needed for backward compatibility.