From 08616164e9f155154e56f07eeb2f5f3f104ba030 Mon Sep 17 00:00:00 2001
From: Marcus Quinn <6428977+marcusquinn@users.noreply.github.com>
Date: Sat, 12 Apr 2025 00:09:55 +0100
Subject: [PATCH] Add AI assistant guide and workflow documentation

---
 .ai-assistant.md                            | 173 ++++++++++++++++++++
 .github/ai-workflows/bug-fixing.md          | 160 ++++++++++++++++++
 .github/ai-workflows/code-review.md         | 163 ++++++++++++++++++
 .github/ai-workflows/feature-development.md | 130 +++++++++++++++
 .github/ai-workflows/release-process.md     | 173 ++++++++++++++++++++
 5 files changed, 799 insertions(+)
 create mode 100644 .ai-assistant.md
 create mode 100644 .github/ai-workflows/bug-fixing.md
 create mode 100644 .github/ai-workflows/code-review.md
 create mode 100644 .github/ai-workflows/feature-development.md
 create mode 100644 .github/ai-workflows/release-process.md

diff --git a/.ai-assistant.md b/.ai-assistant.md
new file mode 100644
index 0000000..5f7c8b2
--- /dev/null
+++ b/.ai-assistant.md
@@ -0,0 +1,173 @@
+# AI Assistant Guide for Fix Plugin Does Not Exist Notices
+
+This guide helps AI assistants understand the project structure, workflows, and best practices for this repository.
+
+## Project Overview
+
+- **Plugin Name**: Fix 'Plugin file does not exist.' Notices
+- **Repository**: https://github.com/wpallstars/fix-plugin-does-not-exist-notices
+- **Description**: WordPress plugin that adds missing plugins to the plugins list with a "Remove Reference" link to clean up invalid plugin entries and remove error notices.
+
+## Version Management
+
+### Version Numbering Convention
+
+We follow [Semantic Versioning](https://semver.org/):
+- **MAJOR.MINOR.PATCH** (e.g., 1.6.0)
+  - **MAJOR**: Breaking changes
+  - **MINOR**: New features, non-breaking
+  - **PATCH**: Bug fixes, non-breaking
+
+### When to Increment Version Numbers
+
+- **PATCH** (1.6.0 → 1.6.1): 
+  - Bug fixes
+  - Small text changes
+  - Minor improvements that don't add new features
+
+- **MINOR** (1.6.0 → 1.7.0):
+  - New features
+  - Significant improvements to existing functionality
+  - Deprecation of features (but not removal)
+
+- **MAJOR** (1.6.0 → 2.0.0):
+  - Breaking changes
+  - Removal of features
+  - Major architectural changes
+
+### Version Update Checklist
+
+When updating the version number, always update these files:
+1. `fix-plugin-does-not-exist-notices.php` (Plugin header)
+2. `CHANGELOG.md` (Add new version section)
+3. `readme.txt` (Stable tag and Changelog section)
+4. Update `FPDEN_VERSION` constant in the main plugin file
+
+## Git Workflow
+
+### Branch Naming Convention
+
+- Feature branches: `feature/descriptive-name`
+- Bug fix branches: `fix/issue-description`
+- Release branches: `v{MAJOR}.{MINOR}.{PATCH}`
+
+### Commit Message Guidelines
+
+- Use present tense ("Add feature" not "Added feature")
+- Start with a verb
+- Keep the first line under 50 characters
+- Reference issues when relevant: "Fix #123: Resolve plugin detection issue"
+
+### Release Process
+
+1. Create a new branch for the version: `git checkout -b v{MAJOR}.{MINOR}.{PATCH}`
+2. Update version numbers in all required files
+3. Update CHANGELOG.md with all changes
+4. Commit changes: `git commit -m "Prepare release v{MAJOR}.{MINOR}.{PATCH}"`
+5. Push branch to all remotes:
+   ```
+   git push github HEAD:v{MAJOR}.{MINOR}.{PATCH}
+   git push gitea HEAD:v{MAJOR}.{MINOR}.{PATCH}
+   ```
+6. Create and push a tag to trigger the GitHub Actions workflow:
+   ```
+   git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Release version {MAJOR}.{MINOR}.{PATCH}"
+   git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH}
+   git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH}
+   ```
+
+## Build Process
+
+The build process is handled by `build.sh`:
+1. Updates version numbers
+2. Installs composer dependencies
+3. Copies files to build directory
+4. Creates ZIP file
+
+To manually build the plugin:
+```
+./build.sh {MAJOR}.{MINOR}.{PATCH}
+```
+
+## Remote Repositories
+
+The plugin is hosted on multiple repositories:
+- GitHub: https://github.com/wpallstars/fix-plugin-does-not-exist-notices
+- Gitea: https://gitea.wpallstars.com/wpallstars/fix-plugin-does-not-exist-notices
+- WordPress.org: https://wordpress.org/plugins/fix-plugin-does-not-exist-notices/
+
+Always push changes to all remotes to keep them in sync.
+
+## GitHub Actions
+
+The repository uses GitHub Actions for automated builds and deployments:
+- Triggered by tags matching the pattern `v*`
+- Builds the plugin
+- Creates a GitHub release
+- Deploys to WordPress.org
+
+## Testing Guidelines
+
+Before releasing:
+1. Test with the latest WordPress version
+2. Test with PHP 7.0+ (minimum supported version)
+3. Verify all features work as expected
+4. Check for any PHP warnings or notices
+
+## Common Tasks for AI Assistants
+
+### Creating a New Release
+
+```
+# 1. Create a new branch
+git checkout -b v1.7.0
+
+# 2. Update version numbers in files
+# - fix-plugin-does-not-exist-notices.php
+# - CHANGELOG.md
+# - readme.txt
+# - FPDEN_VERSION constant
+
+# 3. Commit changes
+git add .
+git commit -m "Prepare release v1.7.0"
+
+# 4. Push to remotes
+git push github HEAD:v1.7.0
+git push gitea HEAD:v1.7.0
+
+# 5. Create and push tag
+git tag -a v1.7.0 -m "Release version 1.7.0"
+git push github refs/tags/v1.7.0
+git push gitea refs/tags/v1.7.0
+```
+
+### Adding a New Feature
+
+```
+# 1. Create feature branch
+git checkout -b feature/new-feature-name
+
+# 2. Make changes and commit
+git add .
+git commit -m "Add new feature"
+
+# 3. Push to remotes
+git push github HEAD:feature/new-feature-name
+git push gitea HEAD:feature/new-feature-name
+```
+
+### Fixing a Bug
+
+```
+# 1. Create bugfix branch
+git checkout -b fix/bug-description
+
+# 2. Make changes and commit
+git add .
+git commit -m "Fix #123: Fix bug description"
+
+# 3. Push to remotes
+git push github HEAD:fix/bug-description
+git push gitea HEAD:fix/bug-description
+```
diff --git a/.github/ai-workflows/bug-fixing.md b/.github/ai-workflows/bug-fixing.md
new file mode 100644
index 0000000..3c5a7be
--- /dev/null
+++ b/.github/ai-workflows/bug-fixing.md
@@ -0,0 +1,160 @@
+# Bug Fixing Guide for AI Assistants
+
+This document provides guidance for AI assistants to help with bug fixing for the Fix Plugin Does Not Exist Notices plugin.
+
+## Bug Fixing Workflow
+
+### 1. Create a Bug Fix Branch
+
+Always start by creating a bug fix branch from the main branch:
+
+```bash
+git checkout main
+git pull github main
+git checkout -b fix/bug-description
+```
+
+Use a descriptive name that clearly indicates what bug is being fixed.
+
+### 2. Understand the Bug
+
+Before fixing a bug, make sure you understand:
+
+- What is the expected behavior?
+- What is the actual behavior?
+- What are the steps to reproduce the bug?
+- What is the impact of the bug?
+- What is the root cause of the bug?
+
+### 3. Fix the Bug
+
+When fixing a bug:
+
+- Make minimal changes necessary to fix the bug
+- Avoid introducing new features while fixing bugs
+- Maintain backward compatibility
+- Add appropriate comments explaining the fix
+- Consider adding tests to prevent regression
+
+### 4. Update Documentation
+
+Update relevant documentation to reflect the bug fix:
+
+- Add a description to CHANGELOG.md under an "Unreleased" section
+- Update readme.txt if the bug fix affects user-facing functionality
+
+### 5. Testing
+
+Test the bug fix thoroughly:
+
+- Verify that the bug is fixed
+- Ensure no regression in related functionality
+- Test with the latest WordPress version
+- Test with the minimum supported WordPress version (5.0)
+- Test with PHP 7.0+ (minimum supported version)
+
+### 6. Commit Changes
+
+Make atomic commits with clear messages:
+
+```bash
+git add .
+git commit -m "Fix #123: Brief description of the bug fix"
+```
+
+If there's an issue number, reference it in the commit message.
+
+### 7. Push to Remote
+
+Push the bug fix branch to the remote repositories:
+
+```bash
+git push github HEAD:fix/bug-description
+git push gitea HEAD:fix/bug-description
+```
+
+### 8. Create Pull Request (Optional)
+
+If the repository uses pull requests for code review, create a pull request from the bug fix branch to the main branch.
+
+## Determining Version Increment
+
+After fixing a bug, determine the appropriate version increment:
+
+- **PATCH** (e.g., 1.6.0 → 1.6.1): For most bug fixes that don't change functionality
+- **MINOR** (e.g., 1.6.0 → 1.7.0): For bug fixes that introduce new features or significant changes
+- **MAJOR** (e.g., 1.6.0 → 2.0.0): For bug fixes that introduce breaking changes
+
+## Hotfix Process
+
+For critical bugs that need immediate fixing in a released version:
+
+### 1. Create a Hotfix Branch
+
+```bash
+git checkout v{MAJOR}.{MINOR}.{PATCH}
+git checkout -b hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
+```
+
+### 2. Fix the Bug
+
+Apply the minimal fix necessary to address the critical issue.
+
+### 3. Update Version Numbers
+
+Increment the PATCH version and update all version numbers:
+
+- Main plugin file (fix-plugin-does-not-exist-notices.php)
+- FPDEN_VERSION constant
+- CHANGELOG.md
+- readme.txt
+
+### 4. Commit and Push
+
+```bash
+git add .
+git commit -m "Hotfix: Brief description of the critical bug fix"
+git push github HEAD:hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
+git push gitea HEAD:hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
+```
+
+### 5. Create and Push Tag
+
+```bash
+git tag -a v{MAJOR}.{MINOR}.{PATCH+1} -m "Hotfix release version {MAJOR}.{MINOR}.{PATCH+1}"
+git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH+1}
+git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH+1}
+```
+
+## Common Bug Types and Fixing Strategies
+
+### WordPress Compatibility Issues
+
+- Test with the specific WordPress version where the issue occurs
+- Check for deprecated functions or hooks
+- Review WordPress changelog for relevant changes
+
+### PHP Compatibility Issues
+
+- Test with the specific PHP version where the issue occurs
+- Check for deprecated PHP functions or features
+- Use appropriate polyfills if necessary
+
+### JavaScript Issues
+
+- Test in different browsers
+- Check for browser console errors
+- Consider browser-specific workarounds if necessary
+
+### CSS Issues
+
+- Test in different browsers and screen sizes
+- Use browser developer tools to inspect elements
+- Consider browser-specific workarounds if necessary
+
+### Database Issues
+
+- Use proper database prefixing
+- Sanitize database inputs
+- Use prepared statements for queries
+- Consider database version differences
diff --git a/.github/ai-workflows/code-review.md b/.github/ai-workflows/code-review.md
new file mode 100644
index 0000000..37c09f4
--- /dev/null
+++ b/.github/ai-workflows/code-review.md
@@ -0,0 +1,163 @@
+# Code Review Guide for AI Assistants
+
+This document provides guidance for AI assistants to help with code review for the Fix Plugin Does Not Exist Notices plugin.
+
+## Code Review Checklist
+
+When reviewing code, check for the following:
+
+### Functionality
+
+- [ ] Does the code work as expected?
+- [ ] Does it handle edge cases appropriately?
+- [ ] Are there any logical errors?
+- [ ] Is error handling implemented properly?
+
+### Code Quality
+
+- [ ] Does the code follow WordPress coding standards?
+- [ ] Is the code well-organized and easy to understand?
+- [ ] Are there any code smells (duplicate code, overly complex functions, etc.)?
+- [ ] Are functions and variables named appropriately?
+- [ ] Are there appropriate comments and documentation?
+
+### Security
+
+- [ ] Is user input properly validated and sanitized?
+- [ ] Is output properly escaped?
+- [ ] Are capability checks used for user actions?
+- [ ] Are nonces used for form submissions?
+- [ ] Are there any potential SQL injection vulnerabilities?
+- [ ] Are there any potential XSS vulnerabilities?
+
+### Performance
+
+- [ ] Are there any performance bottlenecks?
+- [ ] Are database queries optimized?
+- [ ] Is caching used appropriately?
+- [ ] Are assets (CSS, JS) properly enqueued?
+
+### Compatibility
+
+- [ ] Is the code compatible with the minimum supported WordPress version (5.0)?
+- [ ] Is the code compatible with the minimum supported PHP version (7.0)?
+- [ ] Are there any browser compatibility issues?
+- [ ] Are there any conflicts with other plugins?
+
+### Internationalization
+
+- [ ] Are all user-facing strings translatable?
+- [ ] Is the correct text domain used?
+- [ ] Are translation functions used correctly?
+
+### Accessibility
+
+- [ ] Does the code follow accessibility best practices?
+- [ ] Are ARIA attributes used appropriately?
+- [ ] Is keyboard navigation supported?
+- [ ] Is screen reader support implemented?
+
+## Code Review Process
+
+### 1. Understand the Context
+
+Before reviewing code, understand:
+- What problem is the code trying to solve?
+- What are the requirements?
+- What are the constraints?
+
+### 2. Review the Code
+
+Review the code with the checklist above in mind.
+
+### 3. Provide Feedback
+
+When providing feedback:
+- Be specific and clear
+- Explain why a change is needed
+- Provide examples or suggestions when possible
+- Prioritize feedback (critical issues vs. minor improvements)
+- Be constructive and respectful
+
+### 4. Follow Up
+
+After the code has been updated:
+- Review the changes
+- Verify that issues have been addressed
+- Provide additional feedback if necessary
+
+## Common Issues to Look For
+
+### PHP Issues
+
+- Undefined variables or functions
+- Incorrect function parameters
+- Missing return statements
+- Improper error handling
+- Inefficient loops or conditionals
+- Hardcoded values that should be configurable
+
+### WordPress-Specific Issues
+
+- Incorrect hook usage
+- Missing or incorrect nonces
+- Missing capability checks
+- Direct database queries instead of using WordPress functions
+- Improper enqueuing of scripts and styles
+- Not using WordPress functions for common tasks
+
+### JavaScript Issues
+
+- Undefined variables or functions
+- Event listener memory leaks
+- jQuery conflicts
+- Browser compatibility issues
+- Missing error handling
+
+### CSS Issues
+
+- Browser compatibility issues
+- Specificity issues
+- Unused styles
+- Overriding WordPress admin styles inappropriately
+
+## Example Feedback
+
+### Good Feedback Example
+
+```
+In function `handle_remove_reference()`:
+
+1. The nonce check is missing, which could lead to CSRF vulnerabilities. 
+   Consider adding:
+   ```php
+   if (!isset($_GET['_wpnonce']) || !wp_verify_nonce($_GET['_wpnonce'], 'fpden_remove_reference')) {
+       wp_die(__('Security check failed.', 'fix-plugin-does-not-exist-notices'));
+   }
+   ```
+
+2. The user capability check should be more specific. Instead of:
+   ```php
+   if (!current_user_can('manage_options')) {
+   ```
+   Consider using:
+   ```php
+   if (!current_user_can('activate_plugins')) {
+   ```
+   This is more appropriate for the action being performed.
+
+3. The success message should be translatable:
+   ```php
+   // Change this:
+   add_settings_error('fpden', 'fpden_removed', 'Plugin reference removed successfully.', 'updated');
+   
+   // To this:
+   add_settings_error('fpden', 'fpden_removed', __('Plugin reference removed successfully.', 'fix-plugin-does-not-exist-notices'), 'updated');
+   ```
+```
+
+### Poor Feedback Example
+
+```
+This code has security issues and doesn't follow best practices. Fix it.
+```
diff --git a/.github/ai-workflows/feature-development.md b/.github/ai-workflows/feature-development.md
new file mode 100644
index 0000000..8c7dc2a
--- /dev/null
+++ b/.github/ai-workflows/feature-development.md
@@ -0,0 +1,130 @@
+# Feature Development Guide for AI Assistants
+
+This document provides guidance for AI assistants to help with feature development for the Fix Plugin Does Not Exist Notices plugin.
+
+## Feature Development Workflow
+
+### 1. Create a Feature Branch
+
+Always start by creating a feature branch from the main branch:
+
+```bash
+git checkout main
+git pull github main
+git checkout -b feature/descriptive-name
+```
+
+Use a descriptive name that clearly indicates what the feature is about.
+
+### 2. Implement the Feature
+
+When implementing a new feature:
+
+- Follow WordPress coding standards
+- Ensure all strings are translatable
+- Add appropriate comments
+- Consider performance implications
+- Maintain backward compatibility
+
+### 3. Update Documentation
+
+Update relevant documentation to reflect the new feature:
+
+- Add a description to CHANGELOG.md under an "Unreleased" section
+- Update readme.txt if the feature affects user-facing functionality
+- Update inline documentation/comments
+
+### 4. Testing
+
+Test the feature thoroughly:
+
+- Test with the latest WordPress version
+- Test with the minimum supported WordPress version (5.0)
+- Test with PHP 7.0+ (minimum supported version)
+- Test in different environments (if possible)
+
+### 5. Commit Changes
+
+Make atomic commits with clear messages:
+
+```bash
+git add .
+git commit -m "Add feature: descriptive name"
+```
+
+### 6. Push to Remote
+
+Push the feature branch to the remote repositories:
+
+```bash
+git push github HEAD:feature/descriptive-name
+git push gitea HEAD:feature/descriptive-name
+```
+
+### 7. Create Pull Request (Optional)
+
+If the repository uses pull requests for code review, create a pull request from the feature branch to the main branch.
+
+## Code Standards and Best Practices
+
+### PHP Coding Standards
+
+- Follow [WordPress PHP Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/)
+- Use tabs for indentation, not spaces
+- Use proper naming conventions:
+  - Class names: `Class_Name`
+  - Function names: `function_name`
+  - Variable names: `$variable_name`
+
+### JavaScript Coding Standards
+
+- Follow [WordPress JavaScript Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/)
+- Use tabs for indentation, not spaces
+- Use proper naming conventions:
+  - Function names: `functionName`
+  - Variable names: `variableName`
+
+### Internationalization (i18n)
+
+- Wrap all user-facing strings in appropriate translation functions:
+  - `__()` for simple strings
+  - `_e()` for echoed strings
+  - `esc_html__()` for escaped strings
+  - `esc_html_e()` for escaped and echoed strings
+- Always use the plugin's text domain: `fix-plugin-does-not-exist-notices`
+
+### Security Best Practices
+
+- Validate and sanitize all input
+- Escape all output
+- Use nonces for form submissions
+- Use capability checks for user actions
+
+## Feature Types and Implementation Guidelines
+
+### Admin Interface Features
+
+When adding features to the admin interface:
+
+- Use WordPress admin UI components for consistency
+- Follow WordPress admin UI patterns
+- Ensure accessibility compliance
+- Add appropriate help text
+
+### Plugin Functionality Features
+
+When adding core functionality:
+
+- Ensure compatibility with WordPress hooks system
+- Consider performance impact
+- Maintain backward compatibility
+- Add appropriate error handling
+
+### Integration Features
+
+When adding integration with other plugins or services:
+
+- Make integrations optional when possible
+- Check if the integrated plugin/service is available before using it
+- Provide fallback functionality when the integration is not available
+- Document the integration requirements
diff --git a/.github/ai-workflows/release-process.md b/.github/ai-workflows/release-process.md
new file mode 100644
index 0000000..b91264c
--- /dev/null
+++ b/.github/ai-workflows/release-process.md
@@ -0,0 +1,173 @@
+# Release Process for AI Assistants
+
+This document provides step-by-step instructions for AI assistants to help with the release process for the Fix Plugin Does Not Exist Notices plugin.
+
+## Pre-Release Checklist
+
+- [ ] All features for this release are complete
+- [ ] All bug fixes for this release are complete
+- [ ] CHANGELOG.md is up to date
+- [ ] readme.txt is up to date
+- [ ] All tests pass
+
+## Determining the New Version Number
+
+Based on the changes made, determine the appropriate version increment:
+
+1. **PATCH** (e.g., 1.6.0 → 1.6.1): For bug fixes and minor improvements
+2. **MINOR** (e.g., 1.6.0 → 1.7.0): For new features and significant improvements
+3. **MAJOR** (e.g., 1.6.0 → 2.0.0): For breaking changes
+
+## Release Steps
+
+### 1. Create a New Branch
+
+```bash
+git checkout -b v{MAJOR}.{MINOR}.{PATCH}
+```
+
+Example:
+```bash
+git checkout -b v1.7.0
+```
+
+### 2. Update Version Numbers
+
+Update the version number in the following files:
+
+#### a. Main Plugin File (fix-plugin-does-not-exist-notices.php)
+
+```php
+/**
+ * Plugin Name: Fix 'Plugin file does not exist.' Notices
+ * Plugin URI: https://wordpress.org/plugins/fix-plugin-does-not-exist-notices/
+ * Description: Adds missing plugins to the plugins list with a "Remove Reference" link so you can permanently clean up invalid plugin entries and remove error notices.
+ * Version: {MAJOR}.{MINOR}.{PATCH}
+ * ...
+ */
+```
+
+Also update the FPDEN_VERSION constant:
+
+```php
+define( 'FPDEN_VERSION', '{MAJOR}.{MINOR}.{PATCH}' );
+```
+
+#### b. CHANGELOG.md
+
+Add a new section at the top of the CHANGELOG.md file:
+
+```markdown
+## [{MAJOR}.{MINOR}.{PATCH}] - YYYY-MM-DD
+### Added
+- New feature 1
+- New feature 2
+
+### Changed
+- Change 1
+- Change 2
+
+### Fixed
+- Bug fix 1
+- Bug fix 2
+```
+
+#### c. readme.txt
+
+Update the stable tag:
+
+```
+Stable tag: {MAJOR}.{MINOR}.{PATCH}
+```
+
+Add a new entry to the changelog section:
+
+```
+= {MAJOR}.{MINOR}.{PATCH} =
+* New feature 1
+* New feature 2
+* Change 1
+* Change 2
+* Fixed bug 1
+* Fixed bug 2
+```
+
+Update the upgrade notice section:
+
+```
+= {MAJOR}.{MINOR}.{PATCH} =
+Brief description of the most important changes in this release
+```
+
+### 3. Commit Changes
+
+```bash
+git add fix-plugin-does-not-exist-notices.php CHANGELOG.md readme.txt
+git commit -m "Prepare release v{MAJOR}.{MINOR}.{PATCH}"
+```
+
+### 4. Push Branch to Remotes
+
+```bash
+git push github HEAD:v{MAJOR}.{MINOR}.{PATCH}
+git push gitea HEAD:v{MAJOR}.{MINOR}.{PATCH}
+```
+
+### 5. Create and Push Tag
+
+```bash
+git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Release version {MAJOR}.{MINOR}.{PATCH}"
+git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH}
+git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH}
+```
+
+### 6. Monitor GitHub Actions
+
+Open the GitHub Actions page to monitor the build and deployment process:
+https://github.com/wpallstars/fix-plugin-does-not-exist-notices/actions
+
+### 7. Verify Release
+
+- [ ] Check that the GitHub release was created successfully
+- [ ] Verify that the plugin was deployed to WordPress.org
+- [ ] Test the plugin from WordPress.org to ensure it works correctly
+
+## Rollback Procedure (If Needed)
+
+If issues are discovered after release:
+
+### 1. Create a Hotfix Branch
+
+```bash
+git checkout v{MAJOR}.{MINOR}.{PATCH}
+git checkout -b hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
+```
+
+### 2. Fix the Issues
+
+Make the necessary changes to fix the issues.
+
+### 3. Update Version Numbers
+
+Increment the PATCH version and update all version numbers as described above.
+
+### 4. Commit and Push
+
+```bash
+git add .
+git commit -m "Fix issues in v{MAJOR}.{MINOR}.{PATCH}"
+git push github HEAD:hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
+git push gitea HEAD:hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
+```
+
+### 5. Create and Push Tag
+
+```bash
+git tag -a v{MAJOR}.{MINOR}.{PATCH+1} -m "Hotfix release version {MAJOR}.{MINOR}.{PATCH+1}"
+git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH+1}
+git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH+1}
+```
+
+### 6. Monitor and Verify
+
+Follow steps 6 and 7 from the release process to monitor and verify the hotfix release.