chore(ai): update windsurf rules with the latest from the llmconfig repo

.windsurfrules

@@ -1,7 +1,39 @@
-- Consider security and quality in all decisions
-- Write all code using test driven development
-- Commits should be atomic and short.
-- Run the project linters after each change
-- Refer to the @docs/contributors and ensure you follow the vision, plans, policies and decisions.
-- Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
-- Don't chain changes unless specifically requested. Request user input after each change.
+# Project-specific rules
+
+## !!Priority rules
+
+- Refer to the @docs/contributors folder in the project if available and ensure you follow the vision, plans, policies and decisions.
+
+## Information verification
+
+- Never make assumptions or speculate without clear evidence.
+- If less than 90% confident in understanding a request, ask for clarification.
+
+## Code change management
+
+- Make changes file by file to allow for proper review.
+- Combine all edits into a single chunk per file instead of separate steps.
+- Only suggest updates to files that need modifications.
+- Do not chain multiple changes one after the other, avoid looping back on your output without user feedback.
+
+## File handling
+
+- Always give links to real files (no placeholder x.md references)
+- Never reference or consider earlier file versions from memory
+- Do not show or discuss current implementations unless specifically requested
+- Check provided file contents for current implementations
+
+## Coding practices
+
+- Always use test driven development for code changes. This means:
+  1. If the test case has not been created by the user, propose a test case and stop for feedback
+  2. If a test case has been created and is failing, propose the minimal code change that would make that test pass.
+  3. If a test case has been created and is passing, look for oportunities for refactoring the test and/or production code.
+- Commits should be atomic (change one thing at a time) and as small as possible. Warn the user before making changes if there are already changes that haven't been committed yet.
+- Run the configured project linters after each change.
+
+## Communication style
+
+- Do not use apologies
+- Avoid giving feedback about understanding (e.g., "Understood", "Got it")
+- Never invent or suggest changes beyond what the user explicitly requested