Update

Author: PDowney

.github/copilot-instructions.md

@@ -57,43 +57,81 @@ You must read files completely and thoroughly, with a minimum of 1000 lines per
 - Use WordPress PHP Documentation Standards:
 - [PHP Documentation Standards](https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/)
 
+## Version Control and Documentation
+
+- Release versions, software tested versions, and minimum software supported versions for this project are listed in numerous places, when updating the release version for this project, ensure that all of these locations are updated accordingly.
+- Version Locations:
+  - README.md
+  - changelog.txt
+  - changelog.md
+  - plugin header (in the main plugin file)
+  - plugin section: "// Define plugin constants"
+  - plugin *.pot files (e.g., languages/plugin-name.pot)
+  - package.json (if applicable)
+  - composer.json (if applicable)
+  - documentation files (e.g., docs/README.md)
+- Use semantic versioning (MAJOR.MINOR.PATCH) for all releases.
+- Do not automatically update the version number in the plugin header or other files. Instead, provide a clear and concise change summary that includes the version number and a brief description of the changes made.
+- When making changes to the codebase, always update the relevant documentation files, including README.md, readme.txt, changelog.txt, and changelog.md even when a new version is not released.
+- I will instruct you when to update the version number, and you should not do this automatically. Always ask for confirmation before updating the version number.
+
 # General Coding Standards
 
 - The above standards are prioritized over general coding standards.
 - The standards below are general coding standards that apply to all code, including WordPress code. Do not apply them if they conflict with WordPress standards.
 
-**Accessibility & UX**
+## Accessibility & UX
+
 - Follow accessibility best practices for UI components
 - Ensure forms are keyboard-navigable and screen reader friendly
 - Validate user-facing labels, tooltips, and messages for clarity
 
-**Performance & Optimization**
+## Performance & Optimization
+
 - Optimize for performance and scalability where applicable
 - Avoid premature optimization—focus on correctness first
 - Detect and flag performance issues (e.g., unnecessary re-renders, N+1 queries)
 - Use lazy loading, memoization, or caching where needed
 
-**Type Safety & Standards**
+## Type Safety & Standards
+
 - Use strict typing wherever possible (TypeScript, C#, etc.)
 - Avoid using `any` or untyped variables
 - Use inferred and narrow types when possible
 - Define shared types centrally (e.g., `types/` or `shared/` folders)
 
-**Security & Error Handling**
+## Security & Error Handling
+
 - Sanitize all input and output, especially in forms, APIs, and database interactions
 - Escape, validate, and normalize all user-supplied data
 - Automatically handle edge cases and error conditions
 - Fail securely and log actionable errors
 - Avoid leaking sensitive information in error messages or logs
+- Use secure coding practices to prevent common vulnerabilities (e.g., XSS, CSRF, SQL injection)
+- Use prepared statements for database queries
+- Use secure authentication and authorization mechanisms
+- When using third-party libraries or APIs, ensure they are well-maintained and secure
+- Regularly update dependencies to their latest stable versions
+- Use HTTPS for all API requests and data transmission
+- When handling sensitive data, ensure it is encrypted both in transit and at rest
+- If you suspect a security vulnerability, immediately notify the project maintainers and provide details for investigation
+- If you encounter a security vulnerability in the codebase, do not disclose it publicly. Instead, report it privately to the project maintainers or through a responsible disclosure process.
+- If you are unsure about the security implications of a specific code change, ask for clarification or guidance before proceeding.
+- Always follow the principle of least privilege when implementing security features, ensuring that users and processes have only the permissions they need to perform their tasks.
+- If you encounter a security vulnerability in a third-party library or dependency, check if there is an updated version that addresses the issue. If not, consider alternatives or report the vulnerability to the library maintainers.
+- If there is a possible security vulnerability in the codebase, you should always ask for confirmation before proceeding with any changes. This ensures that the project maintainers are aware of the potential risk and can provide guidance on how to address it safely.
+- If I ask you to make changes that could potentially introduce security vulnerabilities, you should always ask for confirmation before proceeding. This ensures that the project maintainers are aware of the potential risk and can provide guidance on how to address it safely.
+
+## Code Quality & Architecture
 
-**Code Quality & Architecture**
 - Organize code using **feature-sliced architecture** when applicable
 - Group code by **feature**, not by type (e.g., keep controller, actions, and helpers together by feature)
 - Write clean, readable, and self-explanatory code
 - Use meaningful and descriptive names for files, functions, and variables
 - Remove unused imports, variables, and dead code automatically
 
-**Task Execution & Automation**
+## Task Execution & Automation
+
 - Always proceed to the next task automatically unless confirmation is required
 - Only ask for confirmation when an action is destructive (e.g., data loss, deletion)
 - Always attempt to identify and fix bugs automatically