Version 2.3.0 - Improved development workflow documentation

git status

git push github v2.2.3
Merge branch 'main' of https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices

.ai-assistant.md

@@ -16,7 +16,11 @@ Detailed workflow documentation is available in the `.ai-workflows/` directory:
 
 - **@.ai-workflows/bug-fixing.md**: Guidelines for identifying and fixing bugs
 - **@.ai-workflows/code-review.md**: Standards for reviewing code changes
+- **@.ai-workflows/dev-prefs-memory.md**: Persistent memory of developer preferences
 - **@.ai-workflows/feature-development.md**: Process for developing new features
+- **@.ai-workflows/folder-structure.md**: Documentation of the plugin's folder structure and naming conventions
+- **@.ai-workflows/git-workflow.md**: Detailed git workflow and branch management guidelines
+- **@.ai-workflows/incremental-development.md**: Time-efficient approach for incremental development and testing
 - **@.ai-workflows/local-env-vars.md**: Local development environment paths and URLs
 - **@.ai-workflows/release-process.md**: Steps for preparing and publishing releases
 
@@ -28,15 +32,35 @@ We follow [Semantic Versioning](https://semver.org/):
   - **MINOR**: New features, non-breaking
   - **PATCH**: Bug fixes, non-breaking
 
+### Time-Efficient Development Workflow
+
+For efficient development and testing:
+- Create descriptive branches (**fix/**, **feature/**, **patch/**, **refactor/**) without version numbers
+- **Don't update version numbers** during initial development and testing
+- Only create **version branches** (v2.2.3) and update version numbers when changes are confirmed working
+- Use **patch** increments for bug fixes, **minor** for features, and **major** for breaking changes
+- Mark versions as **stable** when confirmed working by the user
+- See **@.ai-workflows/incremental-development.md** for detailed guidelines
+
 When updating version numbers, see **@.ai-workflows/release-process.md** for the complete checklist.
 
 **IMPORTANT**: Always keep the changelogs in README.md, readme.txt, and CHANGELOG.md in sync to avoid confusion. All three files must be updated with the same changes for each release.
 
 ## Git Workflow
 
+Detailed git workflow documentation is available in **@.ai-workflows/git-workflow.md**.
+
+### Key Principles
+- Always pull the latest main branch from origin before creating new branches (mandatory step)
+- Create one branch per issue/feature (fix/patch/feature)
+- Submit one pull/merge request per issue
+- Run CI/CD checks for each pull request
+- Create separate branches for suggested improvements outside the current issue
+
 ### Branch Naming Convention
 - Feature branches: `feature/descriptive-name`
-- Bug fix branches: `fix/issue-description`
+- Bug fix branches: `fix/issue-description` or `fix/issue-number-description`
+- Patch branches: `patch/descriptive-name`
 - Release branches: `v{MAJOR}.{MINOR}.{PATCH}`
 
 ### Commit Message Guidelines
@@ -74,6 +98,16 @@ Before releasing:
 
 Local environment variables and paths are documented in **@.ai-workflows/local-env-vars.md**.
 
+## Developer Preferences
+
+AI assistants should maintain a record of developer preferences in **@.ai-workflows/dev-prefs-memory.md**. When you learn about a new preference through user feedback or conversation:
+
+1. Check if the preference is already documented
+2. If not, add it to the appropriate section in the dev-prefs-memory.md file
+3. Reference these preferences in future interactions
+
+This ensures consistency across coding sessions and reduces the need for developers to repeatedly explain their preferences.
+
 ## Common Tasks
 
 For detailed instructions on common tasks like creating releases, adding features, fixing bugs, and testing previous versions, see **@.ai-workflows/release-process.md**.

.ai-workflows/bug-fixing.md

@@ -6,15 +6,17 @@ This document provides guidance for AI assistants to help with bug fixing for th
 
 ### 1. Create a Bug Fix Branch
 
-Always start by creating a bug fix branch from the main branch:
+Always start by creating a bug fix branch from the latest main branch pulled from origin (this step is mandatory):
 
 ```bash
 git checkout main
-git pull github main
+git pull origin main  # Critical step - never skip this
 git checkout -b fix/bug-description
 ```
 
-Use a descriptive name that clearly indicates what bug is being fixed.
+Use a descriptive name that clearly indicates what bug is being fixed. If there's an issue number, include it in the branch name (e.g., `fix/123-plugin-activation-error`).
+
+For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
 
 ### 2. Understand the Bug
 
@@ -99,13 +101,18 @@ If the repository uses pull requests for code review, create a pull request from
 
 ## Determining Version Increment
 
-After fixing a bug, determine the appropriate version increment:
+After fixing a bug and confirming it works, determine the appropriate version increment:
 
 - **PATCH** (e.g., 1.6.0 → 1.6.1): For most bug fixes that don't change functionality
-  - **IMPORTANT**: Always increment the patch version for every change, even small ones, to make rollbacks easier if issues are found in testing
 - **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
 
+**IMPORTANT**: Don't update version numbers during initial development and testing. Only create a version branch (e.g., `v2.2.3`) and update version numbers when the fix is confirmed working.
+
+This approach is more time-efficient as it allows you to focus on fixing the bug without worrying about version updates until the fix is confirmed working.
+
+For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
+
 ## Testing Previous Versions
 
 To test a previous version of the plugin:

.ai-workflows/dev-prefs-memory.md

@@ -0,0 +1,62 @@
+# Developer Preferences Memory
+
+This document serves as a persistent memory for developer preferences established during coding sessions. AI assistants should refer to this document to understand the developer's preferences and update it as new preferences are established.
+
+## Purpose
+
+- Maintain a consistent record of developer preferences across coding sessions
+- Ensure AI assistants can provide assistance that aligns with the developer's preferred coding style and practices
+- Reduce the need for developers to repeatedly explain their preferences
+
+## How to Use This Document
+
+- **AI Assistants**: Review this document before providing assistance. Update it when new preferences are established through user feedback.
+- **Developers**: Reference this document to see what preferences have been recorded. Feel free to edit it directly to add or modify preferences.
+
+## Recorded Preferences
+
+### File and Directory Structure
+
+- Prefer lowercase filenames for consistency across the codebase
+- Use unique folder names following best practices
+- Folder references should be easily identifiable when using @mentions in AI-assisted coding
+- Admin-specific functionality should be in the `admin/lib/` directory
+- Core plugin functionality should be in the `includes/` directory
+
+### Code Style
+
+- Follow WordPress coding standards
+- Use OOP best practices for WordPress plugins
+- Create modular, maintainable, and efficient code structure
+
+### Documentation
+
+- Prefer token-efficient documentation in `.ai-assistant.md` that references `.ai-workflows/` files
+- Document the release workflow in `.ai-assistant.md` and `.ai-workflows/release-process.md`
+- Store environment variable documentation in `.ai-workflows/local-env-vars.md`
+- Maintain consistent documentation across readme.txt, README.md, and CHANGELOG.md
+
+### Asset Organization
+
+- Store banner, icon, and screenshot images in `.wordpress-org/assets/`
+- Store WORDPRESS_ORG files within `/wordpress-org`
+- Organize files in `/assets` into relevant `/admin` folders
+
+### Version Control
+
+- Use standard Git practices for version control and code management
+- When updating plugin versions, create a GitHub tag and trigger GitHub actions
+- Follow a specific release process with proper tagging and GitHub releases
+- Ensure commits are merged to the main branch as Git Updater pulls data from the readme.txt file in the primary branch
+
+### Plugin Development
+
+- Prefer simpler solutions over complex ones for plugins
+- Use a specific formatting style for the CHANGELOG.md file, using #### for section headings
+- When updating plugin versions, remember to update language files (POT/PO)
+- Comment out redundant code during testing
+
+### Potential AI Assised IDE Issues
+
+- Check for non-standard local terminal commandline customisations that might not be understood by the AI IDE in its terminal useage and cause errors in execution or confusion in not seeing expected results, and advise on how to resolve
+- Check for non-standard or multiple python and node.js versions, including homebrew versions, that might not be understood by the AI IDE in its terminal useage and cause errors in execution or confusion in not seeing expected results, and advise on how to resolve

.ai-workflows/feature-development.md

@@ -6,15 +6,17 @@ This document provides guidance for AI assistants to help with feature developme
 
 ### 1. Create a Feature Branch
 
-Always start by creating a feature branch from the main branch:
+Always start by creating a feature branch from the latest main branch pulled from origin (this step is mandatory):
 
 ```bash
 git checkout main
-git pull github main
+git pull origin main  # Critical step - never skip this
 git checkout -b feature/descriptive-name
 ```
 
-Use a descriptive name that clearly indicates what the feature is about.
+Use a descriptive name that clearly indicates what the feature is about. If there's an issue number, include it in the branch name (e.g., `feature/123-update-source-selector`).
+
+For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
 
 ### 2. Implement the Feature
 
@@ -58,21 +60,39 @@ git commit -m "Add feature: descriptive name"
 
 When the feature is ready to be released:
 
-1. Create a version branch for the release:
+1. Create a version branch with the appropriate version number (typically increment the minor version for features):
 
 ```bash
-git checkout -b v{MAJOR}.{MINOR}.{PATCH}
+# Example: from 2.2.0 to 2.3.0
+git checkout -b v{MAJOR}.{MINOR+1}.0
 ```
 
-2. Merge your feature branch into the version branch:
+2. Now update version numbers in all required files:
+
+- Main plugin file (wp-fix-plugin-does-not-exist-notices.php)
+- CHANGELOG.md (add a new version section)
+- readme.txt
+- README.md
+- languages/wp-fix-plugin-does-not-exist-notices.pot (Project-Id-Version)
+
+3. Commit the version updates:
 
 ```bash
-git merge feature/descriptive-name --no-ff
+git add .
+git commit -m "Version {MAJOR}.{MINOR+1}.0 - [brief description]"
 ```
 
-3. Update version numbers and changelog entries
+4. Tag the version as stable:
 
-4. Follow the standard release process from this point
+```bash
+git tag -a v{MAJOR}.{MINOR+1}.0-stable -m "Stable version {MAJOR}.{MINOR+1}.0"
+```
+
+5. Follow the standard release process from this point
+
+**IMPORTANT**: Don't update version numbers during initial development and testing. Only create a version branch and update version numbers when the feature is confirmed working.
+
+For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
 
 ### 7. Push to Remote (Optional for Collaboration)
 

.ai-workflows/folder-structure.md

@@ -0,0 +1,59 @@
+# Folder Structure
+
+This document outlines the folder structure of the plugin and explains the purpose of each directory.
+
+## Root Directories
+
+- **admin/** - Contains admin-specific functionality and assets
+- **includes/** - Contains core plugin functionality and classes
+- **languages/** - Contains translation files
+- **scripts/** - Contains build and deployment scripts
+- **.ai-workflows/** - Contains documentation for AI assistants
+- **.github/** - Contains GitHub-specific files like workflows
+- **.wordpress-org/** - Contains WordPress.org assets like banners and screenshots
+
+## Admin Directory Structure
+
+- **admin/css/** - Admin-specific CSS files
+- **admin/js/** - Admin-specific JavaScript files
+- **admin/images/** - Admin-specific images
+- **admin/partials/** - Admin-specific template partials
+- **admin/settings/** - Admin settings functionality
+- **admin/tools/** - Admin tools functionality
+- **admin/lib/** - Admin-specific library files and helper functions
+  - **admin/lib/admin.php** - Admin class for handling admin-specific functionality
+  - **admin/lib/modal.php** - Modal class for handling the update source selector modal
+
+## Includes Directory
+
+The `includes/` directory contains the core plugin functionality:
+
+- **includes/core.php** - Core class for handling the main plugin functionality
+- **includes/plugin.php** - Main plugin class that initializes all components
+- **includes/updater.php** - Updater class for handling plugin updates
+
+## File Naming Conventions
+
+- All PHP files in the `includes/` directory use lowercase filenames
+- All directories use lowercase names
+- JavaScript and CSS files use kebab-case (e.g., `update-source-selector.js`)
+
+## Best Practices
+
+1. **Unique Directory Names**: Each directory should have a unique name to avoid confusion
+2. **Logical Organization**: Files should be organized logically by function
+3. **Consistent Naming**: File and directory names should follow consistent naming conventions
+4. **Clear Separation**: Admin functionality should be separate from core functionality
+5. **Minimal Dependencies**: Files should have minimal dependencies on other files
+
+## @mentions for AI Assistants
+
+When referring to files or directories in AI conversations, use the following format:
+
+- **@includes/plugin.php** - Main plugin class
+- **@includes/core.php** - Core functionality
+- **@admin/lib/admin.php** - Admin functionality
+- **@admin/lib/modal.php** - Modal functionality
+- **@includes/updater.php** - Updater functionality
+- **@admin/js/update-source-selector.js** - Update source selector JavaScript
+- **@admin/css/update-source-selector.css** - Update source selector CSS

.ai-workflows/git-workflow.md

@@ -0,0 +1,255 @@
+# Git Workflow Guide for AI Assistants
+
+This document provides guidance for AI assistants to help with git workflow management for the Fix Plugin Does Not Exist Notices plugin.
+
+## Core Git Workflow Principles
+
+### 1. Always Start from Latest Main Branch
+
+Before creating any new branch, always ensure you're working with the latest code from the main branch by pulling from the origin:
+
+```bash
+git checkout main
+git pull origin main
+```
+
+This critical step ensures that your new branch includes all the latest changes from the remote repository and reduces the chance of merge conflicts later. Never skip this step, as working from an outdated main branch can lead to integration problems.
+
+### 2. One Issue Per Branch
+
+Create a separate branch for each issue or feature you're working on:
+
+- For bug fixes: `fix/issue-description` or `fix/issue-number-description`
+- For features: `feature/descriptive-name`
+- For small improvements: `patch/descriptive-name`
+- For code restructuring: `refactor/descriptive-name`
+
+**Important**: Use descriptive names without version numbers for development branches. This allows focusing on the changes without worrying about version updates until the changes are confirmed working.
+
+Only create version branches (e.g., `v2.2.3`) when changes are ready for release, and only then update version numbers in files.
+
+This approach keeps changes focused, makes code review easier, and provides clear rollback points if needed.
+
+### 3. Pull Request for Each Issue
+
+Create a separate pull request for each issue or feature. This ensures:
+
+- Each change can be reviewed independently
+- Issues can be merged as soon as they're ready
+- Changes can be reverted individually if needed
+- CI/CD checks can run on focused changes
+
+## Detailed Workflow
+
+### Starting a New Task
+
+1. **Update Main Branch from Origin**
+   ```bash
+   git checkout main
+   git pull origin main
+   ```
+
+   This step is mandatory before creating any new branch to ensure you're working with the latest code.
+
+2. **Create a New Branch**
+   ```bash
+   git checkout -b [branch-type]/[description]
+   ```
+
+   Examples:
+   ```bash
+   git checkout -b fix/123-plugin-activation-error
+   git checkout -b feature/update-source-selector
+   git checkout -b patch/2.2.1
+   ```
+
+3. **Make Your Changes**
+   - Make focused changes related only to the specific issue
+   - Commit regularly with clear, descriptive messages
+   - Reference issue numbers in commit messages when applicable
+
+4. **Testing Approach**
+
+   For efficient development:
+   - **Local Testing (Default)**: Test without updating version numbers
+     ```bash
+     # Get current version from plugin file
+     CURRENT_VERSION=$(grep -o "Version: [0-9.]*" wp-fix-plugin-does-not-exist-notices.php | cut -d' ' -f2)
+
+     # Build and deploy with current version
+     ./build.sh $CURRENT_VERSION
+     ```
+   - **Remote Testing (When Requested)**: Push development branch to remote
+     ```bash
+     git add .
+     git commit -m "[Brief description] for remote testing"
+     git push origin [branch-name]
+     ```
+   - **Version Creation**: Only when changes are confirmed working
+     ```bash
+     # Create version branch
+     git checkout -b v{MAJOR}.{MINOR}.{PATCH}
+
+     # Update version numbers in all required files
+     # Commit version updates
+     git add .
+     git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description"
+
+     # Tag as stable
+     git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
+     ```
+
+5. **Push Branch to Remote (When Needed)**
+   ```bash
+   git push origin [branch-name]
+   ```
+
+### Creating a Pull Request
+
+1. **Ensure Tests Pass Locally**
+   - Run any available tests to ensure your changes work as expected
+   - Fix any issues before creating a pull request
+
+2. **Create Pull Request**
+   - Create a pull request from your branch to the main branch
+   - Include a clear description of the changes
+   - Reference any related issues
+   - Assign reviewers if appropriate
+
+3. **Address Review Feedback**
+   - Make requested changes
+   - Push additional commits to the same branch
+   - Respond to comments
+
+### CI/CD Integration
+
+Each pull request should pass through CI/CD checks before being merged. This ensures that all changes are compatible with the existing codebase and meet quality standards.
+
+1. **Automated Tests**
+   - Unit tests
+   - Integration tests
+   - Code style checks
+   - Compatibility checks
+
+2. **Manual Review**
+   - Code review by team members
+   - Functional testing in test environment
+   - Verification of feature requirements
+
+3. **Approval Process**
+   - Required approvals before merging
+   - Final checks for conflicts with other pending PRs
+   - Verification that all CI/CD checks have passed
+
+4. **Compatibility with Unmerged PRs**
+   - When multiple PRs are in progress simultaneously, ensure each PR is compatible with the main branch
+   - For related changes, consider using feature flags to allow independent merging
+   - Document dependencies between PRs in the PR description
+
+### Handling Concurrent Development
+
+When working on multiple issues simultaneously:
+
+1. **Keep Branches Independent**
+   - Always create new branches from the latest main branch pulled from origin, not from other feature branches
+   - This ensures each PR can be merged independently and contains all the latest changes
+
+2. **Handle Conflicts Proactively**
+   - If main has been updated with other changes while you're working:
+     ```bash
+     git checkout main
+     git pull origin main
+     git checkout your-branch
+     git merge main
+     ```
+   - Resolve any conflicts locally before pushing
+
+3. **Coordinate on Dependent Changes**
+   - If changes depend on each other, note this in the PR description
+   - Consider using the "Depends on #PR-number" notation in PR descriptions
+
+## Release Process
+
+When preparing for a release:
+
+1. **Ensure All Required PRs are Merged**
+   - All features and fixes planned for the release should be merged to main
+
+2. **Create a Release Branch**
+   ```bash
+   git checkout main
+   git pull origin main
+   git checkout -b v{MAJOR}.{MINOR}.{PATCH}
+   ```
+
+3. **Follow Standard Release Process**
+   - Update version numbers
+   - Update changelogs
+   - Create tag
+   - See **@.ai-workflows/release-process.md** for complete details
+
+## Contributing to External Repositories
+
+When working on issues for external repositories (pull/merge requests):
+
+### 1. Clearly Indicate Testing Status
+
+In the PR description and comments, clearly indicate the testing status:
+
+- **Not tested**: "This PR addresses [issue] but has not been tested locally or remotely. It's ready for community/maintainer testing."
+- **Locally tested**: "This PR has been tested in a local WordPress environment and [describe results]."
+- **Remotely tested**: "This PR has been tested with a remote build and [describe results]."
+
+### 2. Provide Testing Instructions
+
+Include clear instructions for maintainers on how to test the changes:
+
+- Steps to reproduce the original issue (if applicable)
+- Steps to verify the fix or feature
+- Any specific environments or configurations needed for testing
+
+### 3. Be Responsive to Feedback
+
+Monitor the PR for feedback from maintainers and be prepared to make additional changes if requested.
+
+## Best Practices
+
+### Commit Messages
+
+- 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"
+- For more complex changes, add a detailed description after the first line
+
+### Branch Management
+
+- Delete branches after they've been merged
+- Keep branch names descriptive but concise
+- Use consistent naming conventions
+
+### Code Review
+
+- Review code thoroughly before approving
+- Test changes locally when possible
+- Provide constructive feedback
+- See **@.ai-workflows/code-review.md** for detailed code review guidelines
+
+### Suggested Improvements
+
+If you identify potential improvements outside the scope of the current issue:
+
+1. **Document the Suggestion**
+   - Note the suggestion in the PR comments
+   - Create a new issue for the suggestion
+   - Be specific about the benefits and implementation details
+
+2. **Create a Separate Branch**
+   - Don't include unrelated improvements in the current PR
+   - Create a new branch from the latest main branch for the suggested improvement
+   - Submit a separate PR for the suggestion
+
+3. **Ensure Compatibility**
+   - Make sure the suggested improvement is compatible with any unmerged PRs
+   - If the improvement depends on changes in another PR, note this dependency
+   - Consider how the improvement will interact with other pending changes

.ai-workflows/incremental-development.md

@@ -0,0 +1,225 @@
+# Incremental Development and Testing Guide
+
+This document provides guidance for AI assistants to help with incremental development and testing for the Fix Plugin Does Not Exist Notices plugin.
+
+## Time-Efficient Development Principles
+
+### Branch Naming for Development
+
+1. **Initial Development Branches**
+   - Use descriptive names without version numbers:
+     - `fix/issue-description` - For bug fixes
+     - `feature/descriptive-name` - For new features
+     - `patch/descriptive-name` - For small improvements
+     - `refactor/descriptive-name` - For code restructuring
+   - **Don't update version numbers** during this phase
+   - Focus on implementing and testing the changes
+
+2. **Version Branches**
+   - Only create after changes are confirmed working:
+     - `v{MAJOR}.{MINOR}.{PATCH}` (e.g., `v2.2.3`)
+   - Only update version numbers at this point
+   - This minimizes unnecessary version updates
+
+### Version Numbering Guidelines
+
+1. **Patch Versions (X.Y.Z → X.Y.Z+1)**
+   - Use for bug fixes and small improvements
+   - Example: `v2.2.3`
+
+2. **Minor Versions (X.Y.Z → X.Y+1.0)**
+   - Use for new features or significant improvements
+   - Example: `v2.3.0`
+
+3. **Major Versions (X.Y.Z → X+1.0.0)**
+   - Only increment when numerous features and fixes are tested and confirmed stable
+   - Reserved for breaking changes or significant overhauls
+   - Example: `v3.0.0`
+
+### Marking Stable Versions
+
+When the user confirms that changes are working correctly:
+1. Create a version branch and update version numbers
+2. Tag the version branch as stable
+   ```bash
+   git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
+   ```
+3. Document in the PR or issue that this version has been confirmed stable
+
+## Local Testing Workflow
+
+### 1. Create a Descriptive Branch for Development
+
+```bash
+# Ensure you have the latest main branch
+git checkout main
+git pull origin main
+
+# Create a descriptive branch (without version numbers)
+git checkout -b fix/plugin-activation-error
+```
+
+### 2. Make Changes Without Updating Version Numbers
+
+During the development and testing phase:
+- Implement the necessary changes
+- **Don't update version numbers** in any files yet
+- Focus on the functionality
+
+### 3. Build and Deploy Locally
+
+For local testing, use the current version number from the main plugin file:
+
+```bash
+# Get the current version from the plugin file
+CURRENT_VERSION=$(grep -o "Version: [0-9.]*" wp-fix-plugin-does-not-exist-notices.php | cut -d' ' -f2)
+
+# Build and deploy with current version
+./build.sh $CURRENT_VERSION
+```
+
+This will:
+1. Create a build directory
+2. Copy required files to the build directory
+3. Deploy the plugin to your local WordPress testing environment
+
+**Note**: For local testing iterations, you do not need to commit changes, push to remote repositories, or create tags unless specifically requested.
+
+### 4. Test and Evaluate
+
+Test the changes thoroughly in the local environment:
+- Verify that the specific issue is fixed or feature works as expected
+- Check for any regressions or new issues
+- Document the results
+
+### 5. Based on Testing Results
+
+- **If changes need further refinement**: Continue working in the same branch
+- **If changes work as expected**: Proceed to version branch creation
+
+### 6. Creating a Version Branch
+
+When changes are confirmed working and ready for release:
+
+1. Create a version branch with the appropriate version number:
+
+```bash
+# Determine the appropriate version increment (patch, minor, or major)
+# based on the nature of the changes
+git checkout -b v{MAJOR}.{MINOR}.{PATCH}
+```
+
+2. Now update version numbers in all required files:
+
+- Main plugin file (wp-fix-plugin-does-not-exist-notices.php)
+- CHANGELOG.md (add a new version section)
+- readme.txt
+- README.md
+- languages/wp-fix-plugin-does-not-exist-notices.pot (Project-Id-Version)
+
+3. Commit the version updates:
+
+```bash
+git add .
+git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - [brief description]"
+```
+
+4. Tag the version as stable:
+
+```bash
+git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
+```
+
+## Remote Testing Workflow
+
+When the user specifically requests remote testing:
+
+### 1. Commit Changes to Remote Repository
+
+If testing a development branch (without version updates):
+
+```bash
+git add .
+git commit -m "[brief description] for remote testing"
+git push origin [branch-name]
+```
+
+If testing a version branch (with version updates):
+
+```bash
+git add .
+git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - [brief description]"
+git push origin v{MAJOR}.{MINOR}.{PATCH}
+```
+
+### 2. Create and Push Tag (For Version Branches Only)
+
+```bash
+git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} for remote testing"
+git push origin v{MAJOR}.{MINOR}.{PATCH}
+```
+
+This will trigger GitHub Actions to build the installable ZIP file.
+
+### 3. Verify Remote Build
+
+Check that the GitHub Actions workflow completed successfully and the ZIP file is available for download.
+
+### 4. Test and Evaluate
+
+Test the remotely built version and document the results.
+
+## Contributing to External Repositories
+
+When working on issues for external repositories (pull/merge requests):
+
+### 1. Clearly Indicate Testing Status
+
+In the PR description and comments, clearly indicate the testing status:
+
+- **Not tested**: "This PR addresses [issue] but has not been tested locally or remotely. It's ready for community/maintainer testing."
+- **Locally tested**: "This PR has been tested in a local WordPress environment and [describe results]."
+- **Remotely tested**: "This PR has been tested with a remote build and [describe results]."
+
+### 2. Provide Testing Instructions
+
+Include clear instructions for maintainers on how to test the changes:
+
+- Steps to reproduce the original issue (if applicable)
+- Steps to verify the fix or feature
+- Any specific environments or configurations needed for testing
+
+### 3. Be Responsive to Feedback
+
+Monitor the PR for feedback from maintainers and be prepared to make additional changes if requested.
+
+## Rollback Procedure
+
+If a change causes issues after release:
+
+### 1. Identify the Last Stable Version
+
+Find the last version that was marked as stable:
+
+```bash
+git tag -l "*-stable"
+```
+
+### 2. Create a New Branch from the Stable Version
+
+```bash
+git checkout v{MAJOR}.{MINOR}.{PATCH}-stable
+git checkout -b fix/rollback-based-fix
+```
+
+### 3. Make Necessary Changes
+
+Implement the fix based on the stable version. Don't update version numbers yet.
+
+### 4. Test the Changes
+
+Test thoroughly to ensure the fix resolves the issues.
+
+### 5. When Confirmed Working
+
+Create a version branch with an incremented patch version and update all version numbers as described in the "Creating a Version Branch" section.

.ai-workflows/readme.md

@@ -6,7 +6,11 @@ This directory contains workflow documentation for AI assistants working with th
 
 - **bug-fixing.md**: Guidelines for identifying and fixing bugs in the codebase
 - **code-review.md**: Standards and procedures for reviewing code changes
+- **dev-prefs-memory.md**: Persistent memory of developer preferences
 - **feature-development.md**: Process for developing new features
+- **folder-structure.md**: Documentation of the plugin's folder structure and naming conventions
+- **git-workflow.md**: Detailed git workflow and branch management guidelines
+- **incremental-development.md**: Time-efficient approach for incremental development and testing
 - **local-env-vars.md**: Local development environment paths and URLs
 - **release-process.md**: Steps for preparing and publishing new releases
 

.ai-workflows/release-process.md

@@ -15,31 +15,53 @@ This document provides step-by-step instructions for AI assistants to help with
 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
-   - **IMPORTANT**: Always increment the patch version for every change, even small ones, to make rollbacks easier if issues are found in testing
 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
+   - Only increment when numerous features and fixes are tested and confirmed stable
+
+**IMPORTANT**: For time-efficient development:
+- Use descriptive branches (`fix/`, `feature/`, `patch/`, `refactor/`) without version numbers during development
+- Don't update version numbers during initial development and testing
+- Only create version branches (e.g., `v2.2.3`) and update version numbers when changes are confirmed working
+
+This approach allows focusing on the changes without worrying about version updates until they're ready for release.
+
+For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
 
 ## Release Steps
 
-### 1. Start from a Feature Branch or Create a New Branch
+### 1. Create a Version Branch
 
-You can either use an existing feature branch or create a new branch specifically for the release:
+When changes are confirmed working and ready for release:
 
 ```bash
-# Option 1: Use existing feature branch
+# First, ensure you have the latest main branch
-git checkout feature/branch-name
+git checkout main
+git pull origin main
 
-# Option 2: Create a new branch
+# Option 1: If you're coming from a development branch
+git checkout fix/your-fix-branch  # or feature/your-feature-branch
+
+# Option 2: Create a version branch directly from main
 git checkout -b v{MAJOR}.{MINOR}.{PATCH}
 ```
 
 Example:
 ```bash
-git checkout feature/refactor-and-improvements
+git checkout main
-# or
+git pull origin main
-git checkout -b v2.2.1
+
+# If coming from a development branch
+git checkout feature/add-new-selector
+
+# Create the version branch
+git checkout -b v2.3.0
 ```
 
+**IMPORTANT**: The version branch is where you'll update all version numbers. This should only be done after the changes have been tested and confirmed working.
+
+For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
+
 ### 2. Update Version Numbers
 
 Update the version number in the following files:
@@ -135,9 +157,11 @@ Add a new entry to the changelog section:
 * Change 3
 ```
 
-### 3. Build and Test Locally
+### 3. Build and Test
 
-Run the build script to create the plugin ZIP file and deploy to your local WordPress testing environment:
+#### Local Testing (Default for Incremental Development)
+
+For incremental development and testing, only local testing is required unless specifically requested:
 
 ```bash
 ./build.sh {MAJOR}.{MINOR}.{PATCH}
@@ -156,6 +180,17 @@ Test the plugin thoroughly in your local WordPress environment:
 - Check for any PHP warnings or notices
 - Test any specific changes made in this version
 
+#### Remote Testing (When Specifically Requested)
+
+When the user specifically requests remote testing, follow these additional steps after local testing:
+
+1. Commit changes to the remote repository
+2. Create and push a tag
+3. Verify that GitHub Actions builds the installable ZIP file
+4. Test the remotely built version
+
+This is necessary when testing Git Updater integration or other features that require the plugin to be installed from a remote source.
+
 ### 4. Commit Changes
 
 ```bash
@@ -171,6 +206,17 @@ Note: Make sure to include README.md in your commit to keep all changelog files
 git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description of changes"
 ```
 
+#### Marking a Version as Stable
+
+When the user confirms that a version is working correctly and stable:
+
+```bash
+# Create a stable tag for easy reference
+git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
+```
+
+This provides a clear reference point for stable versions that can be used for rollbacks if needed.
+
 ### 6. Push Branch and Tag to Remotes
 
 ```bash
@@ -215,6 +261,7 @@ The `--no-ff` flag creates a merge commit even if a fast-forward merge is possib
 - [ ] Test the plugin from the GitHub release ZIP to ensure it works correctly
 - [ ] Verify that Git Updater can detect and install the new version
 - [ ] Confirm that all changelog files (README.md, readme.txt, and CHANGELOG.md) are in sync
+- [ ] Verify that all CI/CD checks have passed for the release
 
 ## Testing Previous Versions
 

.wordpress-org/WORDPRESS_ORG_ASSETS.md

@@ -14,9 +14,9 @@ When submitting a plugin to WordPress.org, you'll work with an SVN repository th
     banner-1544x500.png
     screenshot-1.png
 /tags/           # Contains tagged releases
-    /1.6.27/
+    /2.2.5/
         [plugin files]
-    /1.6.26/
+    /2.2.4/
         [plugin files]
 /trunk/          # Contains the current version of the plugin
     [plugin files]
@@ -28,8 +28,6 @@ For languages that read from right to left (like Hebrew and Arabic), you can pro
 - `banner-772x250-rtl.png`
 - `icon-256x256-rtl.png`
 
-Note: `-rtl` is specifically for Right-to-Left language support, not for dark theme versions.
-
 ## Asset Requirements
 
 ### Icon
@@ -71,20 +69,20 @@ Note: `-rtl` is specifically for Right-to-Left language support, not for dark th
    - When you receive SVN access, use these commands:
    ```bash
    # Check out the repository
-   svn checkout https://plugins.svn.wordpress.org/fix-plugin-does-not-exist-notices/
+   svn checkout https://plugins.svn.wordpress.org/wp-fix-plugin-does-not-exist-notices/
 
    # Copy plugin files to trunk
-   cp -r [your-local-plugin-files]/* fix-plugin-does-not-exist-notices/trunk/
+   cp -r [your-local-plugin-files]/* wp-fix-plugin-does-not-exist-notices/trunk/
 
    # Copy assets to assets directory
-   cp .wordpress-org/assets/icon-256x256.png fix-plugin-does-not-exist-notices/assets/
+   cp .wordpress-org/assets/icon-256x256.png wp-fix-plugin-does-not-exist-notices/assets/
-   cp .wordpress-org/assets/icon-128x128.png fix-plugin-does-not-exist-notices/assets/
+   cp .wordpress-org/assets/icon-128x128.png wp-fix-plugin-does-not-exist-notices/assets/
-   cp .wordpress-org/assets/banner-772x250.png fix-plugin-does-not-exist-notices/assets/
+   cp .wordpress-org/assets/banner-772x250.png wp-fix-plugin-does-not-exist-notices/assets/
-   cp .wordpress-org/assets/banner-1544x500.png fix-plugin-does-not-exist-notices/assets/
+   cp .wordpress-org/assets/banner-1544x500.png wp-fix-plugin-does-not-exist-notices/assets/
-   cp .wordpress-org/assets/screenshot-1.png fix-plugin-does-not-exist-notices/assets/
+   cp .wordpress-org/assets/screenshot-1.png wp-fix-plugin-does-not-exist-notices/assets/
 
    # Add new files
-   cd fix-plugin-does-not-exist-notices
+   cd wp-fix-plugin-does-not-exist-notices
    svn add --force trunk/*
    svn add --force assets/*
 

.wordpress-org/WORDPRESS_ORG_SUBMISSION.md

@@ -53,9 +53,9 @@ When submitting to WordPress.org, your SVN repository will have this structure:
     banner-1544x500.png
     screenshot-1.png
 /tags/
-    /1.6.27/
+    /2.2.5/
         [plugin files]
-    /1.6.26/
+    /2.2.4/
         [plugin files]
 /trunk/
     [current plugin files]
@@ -68,11 +68,11 @@ When submitting to WordPress.org, your SVN repository will have this structure:
 
 ```bash
 # Copy assets to WordPress.org SVN assets directory
-cp .wordpress-org/assets/icon-256x256.png /path/to/wordpress-svn/assets/
+cp .wordpress-org/assets/icon-256x256.png wp-fix-plugin-does-not-exist-notices/assets/
-cp .wordpress-org/assets/icon-128x128.png /path/to/wordpress-svn/assets/
+cp .wordpress-org/assets/icon-128x128.png wp-fix-plugin-does-not-exist-notices/assets/
-cp .wordpress-org/assets/banner-772x250.png /path/to/wordpress-svn/assets/
+cp .wordpress-org/assets/banner-772x250.png wp-fix-plugin-does-not-exist-notices/assets/
-cp .wordpress-org/assets/banner-1544x500.png /path/to/wordpress-svn/assets/
+cp .wordpress-org/assets/banner-1544x500.png wp-fix-plugin-does-not-exist-notices/assets/
-cp .wordpress-org/assets/screenshot-1.png /path/to/wordpress-svn/assets/
+cp .wordpress-org/assets/screenshot-1.png wp-fix-plugin-does-not-exist-notices/assets/
 ```
 
 ## Resources

CHANGELOG.md

@@ -1,5 +1,34 @@
 All notable changes to this project should be documented both here and in the main Readme files.
 
+#### [2.3.0] - 2025-04-15
+#### Added
+- Improved time-efficient development workflow documentation
+- New git workflow guidelines for better branch management
+- Comprehensive incremental development approach
+
+#### Improved
+- Documentation for local vs. remote testing
+- Version management process for more efficient development
+
+#### [2.2.5] - 2025-04-14
+#### Added
+- Documentation for the developer preferences memory file in .ai-workflows/
+- Improved AI assistant instructions for maintaining developer preferences
+- Updated version numbers across all files for consistency
+
+#### [2.2.4] - 2025-04-14
+#### Added
+- Developer preferences memory file for AI assistants
+- Improved AI assistant documentation with instructions for maintaining developer preferences
+- Updated WordPress.org documentation with correct plugin slug and version numbers
+
+#### [2.2.3] - 2025-04-14
+#### Changed
+- Moved admin-specific files to admin/lib directory for better organization
+- Updated namespaces to reflect the new file locations
+- Added comprehensive folder structure documentation
+- Fixed file references in the main plugin file
+
 #### [2.2.2-stable] - 2025-04-14
 #### Changed
 - Renamed includes files to lowercase for consistency with the rest of the codebase

README.md

@@ -234,6 +234,40 @@ For more information on Git Updater integration, see the [Git Updater Required H
 
 ## Changelog
 
+### 2.3.0
+* Added: Improved time-efficient development workflow documentation
+* Added: New git workflow guidelines for better branch management
+* Added: Comprehensive incremental development approach
+* Improved: Documentation for local vs. remote testing
+* Improved: Version management process for more efficient development
+
+### 2.2.5
+* Added: Documentation for the developer preferences memory file in .ai-workflows/
+* Improved: AI assistant instructions for maintaining developer preferences
+* Updated: Version numbers across all files for consistency
+
+### 2.2.4
+* Added: Developer preferences memory file for AI assistants
+* Improved: AI assistant documentation with instructions for maintaining developer preferences
+* Updated: WordPress.org documentation with correct plugin slug and version numbers
+
+### 2.2.3
+* Improved: Moved admin-specific files to admin/lib directory for better organization
+* Improved: Updated namespaces to reflect the new file locations
+* Added: Comprehensive folder structure documentation
+* Fixed: File references in the main plugin file
+
+### 2.2.2-stable
+* Changed: Renamed includes files to lowercase for consistency with the rest of the codebase
+* Removed: Redundant Git Updater patches and version-fix.js as they're no longer needed
+* Improved: Documentation for Git Updater integration and release process
+* Fixed: Token-efficient documentation with references to .ai-workflows files
+* Added: Comprehensive release process documentation with emphasis on merging to main branch
+
+### 2.2.1
+* Changed: Commented out version-fix.js script as it's no longer needed after refactoring
+* Fixed: Version consistency across all files
+
 ### 2.2.0
 * Added: Completely refactored plugin to use OOP best practices
 * Added: New class structure with proper namespaces

admin/lib/admin.php

@@ -5,7 +5,7 @@
  * @package WPALLSTARS\FixPluginDoesNotExistNotices
  */
 
-namespace WPALLSTARS\FixPluginDoesNotExistNotices;
+namespace WPALLSTARS\FixPluginDoesNotExistNotices\Admin;
 
 /**
  * Admin Class
@@ -17,14 +17,14 @@ class Admin {
     /**
      * Core instance
      *
-     * @var Core
+     * @var \WPALLSTARS\FixPluginDoesNotExistNotices\Core
      */
     private $core;
 
     /**
      * Constructor
      *
-     * @param Core $core Core instance.
+     * @param \WPALLSTARS\FixPluginDoesNotExistNotices\Core $core Core instance.
      */
     public function __construct($core) {
         $this->core = $core;

admin/lib/modal.php

@@ -5,7 +5,7 @@
  * @package WPALLSTARS\FixPluginDoesNotExistNotices
  */
 
-namespace WPALLSTARS\FixPluginDoesNotExistNotices;
+namespace WPALLSTARS\FixPluginDoesNotExistNotices\Admin;
 
 /**
  * Modal Class

build.sh

@@ -43,6 +43,8 @@ mkdir -p $BUILD_DIR/admin/css
 cp -r admin/css/* $BUILD_DIR/admin/css/
 mkdir -p $BUILD_DIR/admin/js
 cp -r admin/js/* $BUILD_DIR/admin/js/
+mkdir -p $BUILD_DIR/admin/lib
+cp -r admin/lib/* $BUILD_DIR/admin/lib/
 
 # Create assets directory structure
 mkdir -p $BUILD_DIR/assets

includes/Plugin.php

@@ -52,7 +52,7 @@ class Plugin {
     /**
      * Admin functionality instance
      *
-     * @var Admin
+     * @var Admin\Admin
      */
     private $admin;
 
@@ -110,9 +110,9 @@ class Plugin {
         }
 
         // Load required files
-        require_once $this->plugin_dir . 'includes/Core.php';
+        require_once $this->plugin_dir . 'includes/core.php';
-        require_once $this->plugin_dir . 'includes/Admin.php';
+        require_once $this->plugin_dir . 'admin/lib/admin.php';
-        require_once $this->plugin_dir . 'includes/Modal.php';
+        require_once $this->plugin_dir . 'admin/lib/modal.php';
     }
 
     /**
@@ -125,7 +125,7 @@ class Plugin {
         $this->core = new Core();
 
         // Initialize admin functionality
-        $this->admin = new Admin($this->core);
+        $this->admin = new Admin\Admin($this->core);
 
         // Initialize Git Updater fixes
         $this->init_git_updater_fixes();
@@ -136,7 +136,7 @@ class Plugin {
         }
 
         // Initialize the modal for update source selection
-        new Modal();
+        new Admin\Modal();
     }
 
     /**

languages/wp-fix-plugin-does-not-exist-notices.pot

@@ -2,14 +2,14 @@
 # This file is distributed under the GPL-2.0+.
 msgid ""
 msgstr ""
-"Project-Id-Version: Fix 'Plugin file does not exist' Notices 2.1.1\n"
+"Project-Id-Version: Fix 'Plugin file does not exist' Notices 2.3.0\n"
 "Report-Msgid-Bugs-To: https://wordpress.org/support/plugin/wp-fix-plugin-does-not-exist-notices\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"POT-Creation-Date: 2025-04-13T00:00:00+00:00\n"
+"POT-Creation-Date: 2025-04-15T00:00:00+00:00\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "X-Generator: WP-CLI 2.9.0\n"
 "X-Domain: wp-fix-plugin-does-not-exist-notices\n"

readme.txt

@@ -5,7 +5,7 @@ Tags: plugins, missing plugins, cleanup, error fix, admin tools, plugin file doe
 Requires at least: 5.0
 Tested up to: 6.7.2
 Requires PHP: 7.0
-Stable tag: 2.2.2-stable
+Stable tag: 2.3.0
 License: GPL-2.0+
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
 
@@ -179,6 +179,29 @@ Manually editing the WordPress database is risky and requires technical knowledg
 
 == Changelog ==
 
+= 2.3.0 =
+* Added: Improved time-efficient development workflow documentation
+* Added: New git workflow guidelines for better branch management
+* Added: Comprehensive incremental development approach
+* Improved: Documentation for local vs. remote testing
+* Improved: Version management process for more efficient development
+
+= 2.2.5 =
+* Added: Documentation for the developer preferences memory file in .ai-workflows/
+* Improved: AI assistant instructions for maintaining developer preferences
+* Updated: Version numbers across all files for consistency
+
+= 2.2.4 =
+* Added: Developer preferences memory file for AI assistants
+* Improved: AI assistant documentation with instructions for maintaining developer preferences
+* Updated: WordPress.org documentation with correct plugin slug and version numbers
+
+= 2.2.3 =
+* Improved: Moved admin-specific files to admin/lib directory for better organization
+* Improved: Updated namespaces to reflect the new file locations
+* Added: Comprehensive folder structure documentation
+* Fixed: File references in the main plugin file
+
 = 2.2.2-stable =
 * Changed: Renamed includes files to lowercase for consistency with the rest of the codebase
 * Removed: Redundant Git Updater patches and version-fix.js as they're no longer needed

wp-fix-plugin-does-not-exist-notices.php

@@ -3,7 +3,7 @@
  * Plugin Name: Fix 'Plugin file does not exist' Notices
  * Plugin URI: https://www.wpallstars.com
  * Description: Adds missing plugins to your plugins list with a "Remove Notice" action link, allowing you to safely clean up invalid plugin references.
- * Version: 2.2.2-stable
+ * Version: 2.3.0
  * Author: Marcus Quinn & The WPALLSTARS Team
  * Author URI: https://www.wpallstars.com
  * License: GPL-2.0+
@@ -32,7 +32,8 @@ if (!defined('WPINC')) {
 }
 
 // Load the main plugin class
-require_once plugin_dir_path(__FILE__) . 'includes/Plugin.php';
+require_once plugin_dir_path(__FILE__) . 'includes/plugin.php';
 
 // Initialize the plugin
-new WPALLSTARS\FixPluginDoesNotExistNotices\Plugin(__FILE__, '2.2.2-stable');
+// This is a test change for our new workflow
+new WPALLSTARS\FixPluginDoesNotExistNotices\Plugin(__FILE__, '2.3.0');