You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .windsurf/rules/enterprise/code-change-principles.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,7 @@ Critical principles for enterprise-level plugin development.
16
16
3.**Backward compatibility**: Maintain 100% compatibility with existing callers
17
17
4.**No custom solutions**: Never invent new patterns. Use existing ones or search the web to review best practices, then follow the official WordPress standards or VIP guidelines.
18
18
5.**User changes are final**: If user makes manual changes, treat as authoritative
19
+
6.**Multi-issue fixes**: When fixing multiple issues in one request, run all 6 phases independently for each issue. Findings from one issue's phases may inform the next, but every phase is mandatory for every issue, even when issues share a root cause.
19
20
20
21
---
21
22
@@ -40,6 +41,7 @@ Before proposing solutions:
40
41
- Trace execution flow from entry point to failure
41
42
-**Analyze complete context** of the class or file being changed — all features, logic, and flows
42
43
-**Trace parent hierarchy**: search parent classes and files up to plugin root
44
+
-**CSS-Specific Rules - Trace complete style cascade**: When debugging CSS on an element, identify ALL classes on the element and its ancestors, then search for ALL CSS rules affecting it (not just the obvious class). Understand the complete cascade before proposing changes
43
45
- Identify ALL affected locations in the codebase
44
46
- Map dependencies: what calls this code, what does this code call
45
47
- Check plugin requirements: must code work standalone or require Pro/addons
@@ -78,6 +80,8 @@ Before proposing solutions:
78
80
- Never refactor unrelated code in the same commit
79
81
- If a rule conflicts with existing code in the file being modified, follow the rule for new code but do not refactor unrelated existing code
80
82
- Make the smallest change that completely solves the problem
83
+
-**CSS-Specific Rules - Never modify shared CSS classes**: If a CSS class is already used elsewhere in the plugin, do not change its behavior. Instead, add a new specific class for the feature and define new styles for it
84
+
- Use Big-O to compare algorithms and choose the most efficient one for large inputs and iterations
81
85
- Never change method signatures, return types, or data structures
82
86
- Add defensive checks where data comes in, not where used everywhere
83
87
- Add PHPDoc/JSDoc for new methods/properties/functions and comments for complex logic
0 commit comments