{"owner":"Varying-Vagrant-Vagrants","repo":"VVV","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":4899,"categories":["root-instruction","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":["agents.md","CLAUDE.md"],"skills":{"agents.md":"# VVV Development Environment - AI Agent Instructions\n\n**Project:** Varying Vagrant Vagrants (VVV)\n**Type:** WordPress Development Environment Infrastructure\n**Repository:** https://github.com/Varying-Vagrant-Vagrants/VVV\n\n## Project Context\n\nVVV is a **local WordPress development environment** using Vagrant. Think of it like Docker Compose for WordPress - it's infrastructure that hosts multiple WordPress sites, not a WordPress project itself.\n\n**Critical Concept:** The `www/` folder contains local development sites that are unique to each developer and should NEVER be committed to the VVV repository (similar to Docker volumes).\n\n## File Structure\n\n```\nvvv-local/\n├── Vagrantfile # Core Vagrant config (DO NOT MODIFY)\n├── .gitignore # Git exclusions (DO NOT MODIFY)\n├── config/\n│ └── config.yml # USER SITE CONFIGURATION (gitignored)\n├── provision/ # VVV provisioning scripts (modify only for VVV improvements)\n├── www/ # LOCAL DEVELOPMENT SITES (gitignored except defaults)\n│ ├── wordpress-one/ # User's site (gitignored)\n│ ├── wordpress-two/ # User's site (gitignored)\n│ └── default/ # VVV dashboard (tracked in git)\n├── database/ # MySQL data (gitignored)\n└── log/ # Logs (gitignored)\n```\n\n## Critical Rules\n\n### 🚨 NEVER Do These Things\n\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or bypass git hooks\n3. **NEVER commit files from `www/`** (except the specific defaults: `www/vvv-hosts`, `www/default/`)\n4. **NEVER create files directly in `www/`** - use `config/config.yml` instead\n5. **NEVER modify core files** (`.gitignore`, `Vagrantfile`, `/provision/`) without explicit permission\n6. **NEVER run `vagrant init`**\n\n### ✅ ALWAYS Do These Things\n\n1. **ALWAYS check `git check-ignore `** before committing files\n2. **ALWAYS review `git status` and `git diff`** before commits\n3. **ALWAYS ask yourself:** \"Is this VVV infrastructure or site-specific work?\"\n4. **ALWAYS edit `config/config.yml`** for site configuration, never create files directly\n5. **ALWAYS ask the user** if uncertain whether something should be committed\n\n## Common Tasks\n\n### Task: Create a New WordPress Site\n\n**Correct approach:**\n\n```yaml\n# Edit: config/config.yml\nsites:\n my-new-site:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mynewsite.test\n custom:\n db_name: mynewsite_db\n site_title: \"My New Site\"\n install_plugins:\n - query-monitor\n wpconfig_constants:\n WP_DEBUG: true\n```\n\nThen instruct user: `vagrant up --provision`\n\n**Incorrect approach:**\n- ❌ Creating `www/my-new-site/` directory manually\n- ❌ Downloading WordPress files\n- ❌ Modifying `.gitignore` to track the site\n- ❌ Modifying files inside the Virtual Machine to track the site\n\n### Task: Modify a WordPress Theme/Plugin\n\n**Correct approach:**\n\n1. Ask: \"Which site in `www/` are you working on?\"\n2. Navigate to: `www/site-name/public_html/wp-content/themes/theme-name/`\n3. Make changes within that directory\n4. DO NOT commit to VVV repository (site files are separate)\n5. Suggest user initializes git within their theme if they want version control\n\n**Incorrect approach:**\n- ❌ Committing theme changes to VVV repository\n- ❌ Committing theme changes to custom site template repository\n- ❌ Creating pull requests with site-specific code\n\n### Task: Improve VVV Provisioning\n\n**Correct approach:**\n\n1. Review files in `/provision/` directory\n2. Make improvements to VVV's core scripts\n3. These changes CAN be committed to VVV\n4. Create pull request with VVV improvements\n\n**When to commit to VVV:**\n- Bug fixes in provisioning scripts\n- Documentation improvements\n- New VVV features\n- CI/CD improvements\n\n## Configuration Format\n\n### Site Configuration Schema\n\n```yaml\nsites:\n site-name:\n repo: # Template repository\n branch: master # Git branch (optional)\n php: 8.2 # PHP version\n skip_provisioning: false # Skip on vagrant up\n hosts: # Domains\n - site.test\n - www.site.test\n custom:\n # WordPress\n wp_version: latest # Or specific: \"6.4.2\"\n wp_type: single # Or: multisite\n locale: en_US\n site_title: \"Site Title\"\n\n # Database\n db_name: database_name\n db_prefix: wp_\n\n # Admin\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n\n # Plugins & Themes\n delete_default_plugins: true\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin.zip\n install_themes:\n - twentytwentyfour\n\n # Constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n SCRIPT_DEBUG: true\n```\n\n## Pre-Commit Checklist\n\nBefore any commit or pull request:\n\n- [ ] Run `git status` - no `www/` files appear (except defaults)\n- [ ] Run `git diff` - review ALL changes\n- [ ] Run `git check-ignore www/test-site` - confirms sites are ignored\n- [ ] Verify `.gitignore` is unmodified\n- [ ] Ask: \"Is this improving VVV or is it site-specific?\"\n- [ ] If uncertain, ask the user\n\n## What IS Tracked in www/\n\nOnly these files in `www/` are committed:\n- `www/vvv-hosts` - Default hostname mappings\n- `www/default/index.php` - VVV dashboard\n- `www/default/phpinfo/index.php` - PHP info page\n- `www/default/xdebuginfo/index.php` - Xdebug info page\n\n**Everything else in `www/` is gitignored.**\n\n## Technology Stack\n\n- **Infrastructure:** Vagrant, VirtualBox/Docker/Parallels\n- **OS:** Ubuntu Linux (in VM)\n- **Web Server:** Nginx\n- **Database:** MySQL/MariaDB\n- **Languages:** PHP (multiple versions: 7.4, 8.0, 8.1, 8.2, 8.3), Bash\n- **Tools:** WP-CLI, Composer, Node.js/npm, Git\n\n## Helpful Commands\n\n```bash\n# Provision sites\nvagrant up --provision\n\n# SSH into VM\nvagrant ssh\n\n# WP-CLI in VM\nvagrant ssh -c \"wp --info\"\n\n# Check if path is gitignored\ngit check-ignore \n\n# View site configuration\ncat config/config.yml\n```\n\n## Architecture Principles\n\n1. **VVV is infrastructure, not content** - It provides the environment, not the sites\n2. **Configuration over files** - Use `config/config.yml`, not manual file creation\n3. **Separation of concerns** - VVV code vs. site code are completely separate\n4. **Gitignore by default** - User content stays local unless explicitly tracked\n\n## Testing Changes\n\nWhen making VVV improvements:\n\n1. Test in a local VVV environment\n2. Run `vagrant up --provision` to test provisioning changes\n3. Verify changes work across different PHP versions\n4. Check that existing sites aren't affected\n5. Update documentation if adding features\n\n## Questions to Ask Yourself\n\n- ❓ Am I modifying VVV infrastructure or site-specific content?\n- ❓ Would this change benefit all VVV users or just one site?\n- ❓ Should this file be in git history?\n- ❓ Am I creating files manually when config.yml could do it?\n- ❓ Have I checked what's actually going to be committed?\n\n## When Uncertain\n\n**If you're unsure about any of the following, STOP and ask the user:**\n\n- Whether a file should be committed\n- Whether a change is VVV core or site-specific\n- Whether to modify `.gitignore`, `Vagrantfile`, or provisioning scripts\n- Whether something should be in `config/config.yml` or created manually\n\n**Better to ask than to make an inappropriate commit.**\n\n## Summary\n\n| DO ✅ | DON'T ❌ |\n|------|---------|\n| Edit `config/config.yml` for sites | Create files in `www/` directly |\n| Commit VVV infrastructure improvements | Commit site-specific code |\n| Use `vagrant up --provision` to create sites | Manually download/install WordPress |\n| Work within site directories for development | Commit theme/plugin changes to VVV |\n| Ask when uncertain | Modify `.gitignore` to track `www/` |\n| Check `git status` before committing | Force commit with `--no-verify` |\n\n## Contributing to VVV\n\nSee `.github/CONTRIBUTING.md` for contribution guidelines.\n\nVVV uses:\n- Google's Shell Style Guide for Bash scripts\n- WordPress coding standards for PHP\n\nAll PRs should target the `develop` branch.\n\n---\n\n**Remember:** VVV is like Docker Compose. The `www/` folder is like volumes - it's local data, not the application itself. Keep infrastructure changes separate from content changes.\n","CLAUDE.md":"# VVV Development Environment Instructions for LLM Agents\n\nThis document provides critical guidance for AI coding assistants working with Varying Vagrant Vagrants (VVV). **Read and follow these instructions carefully to avoid inappropriate changes.**\n\n## 🚨 Critical Boundaries - NEVER Cross These Lines\n\n### DO NOT Modify These Core Files\n- **`.gitignore`** - NEVER modify to allow committing `www/` content or other gitignored paths\n- **`Vagrantfile`** - Core Vagrant configuration, do not modify without explicit permission\n- **`/provision/`** scripts - Core provisioning logic (only modify for VVV improvements, not site work)\n- **Git-tracked files** - Assume files tracked by git are VVV core files unless explicitly told otherwise\n\n### Git Safety Rules - Follow These Strictly\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or similar flags\n3. **ALWAYS check `git check-ignore `** before committing files to verify they should be tracked\n4. **If files in `www/` appear in git status** - they should almost certainly NOT be committed (except the defaults listed below)\n5. **Ask before committing** if you're uncertain whether a file belongs in the VVV repository\n\n## What is VVV?\n\nVVV (Varying Vagrant Vagrants) is a **WordPress development environment** using Vagrant. It's infrastructure, not a project itself.\n\n**Key Concept:** VVV is like Docker Compose for WordPress development. The `www/` folder is like Docker volumes - it contains local development sites that are **unique to each developer** and **should never be shared** via the VVV repository.\n\n### Architecture\n- **`www/` folder** - Contains local development WordPress sites (gitignored, except specific defaults)\n- **`config/config.yml`** - User's site configuration (gitignored)\n- **`provision/`** - Provisioning scripts that set up the Vagrant environment\n- **`database/`** - MySQL data (gitignored)\n- **`log/`** - Log files (gitignored)\n\n## Working with WordPress Sites - The Correct Way\n\n### Creating a New Site\n\nWhen asked to create a new WordPress site:\n\n**✓ CORRECT approach:**\n1. Edit `/config/config.yml` (or create it from `config/default-config.yml` template)\n2. Add a site configuration:\n```yaml\nsites:\n my-site-name:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mysite.test\n custom:\n db_name: my_database\n site_title: \"My Site\"\n admin_user: admin\n admin_password: password\n install_plugins:\n - query-monitor\n - debug-bar\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n```\n3. Instruct user to run: `vagrant up --provision`\n4. VVV will automatically create the site in `www/my-site-name/`\n\n**✗ INCORRECT approach:**\n- ❌ Creating directories directly in `www/my-site-name/`\n- ❌ Downloading and copying WordPress files manually\n- ❌ Modifying `.gitignore` to track the new site\n- ❌ Committing site files to VVV repository\n- ❌ Committing site files to site template repository\n\n### Modifying an Existing Site\n\nWhen asked to work on a WordPress site (themes, plugins, content):\n\n**✓ CORRECT approach:**\n1. Identify which site: \"Which site in `www/` are you working on?\"\n2. Navigate to that site's directory: `www/site-name/public_html/`\n3. Work within that site's directory structure:\n - Themes: `www/site-name/public_html/wp-content/themes/`\n - Plugins: `www/site-name/public_html/wp-content/plugins/`\n - Uploads: `www/site-name/public_html/wp-content/uploads/`\n4. **DO NOT** offer to commit these changes to VVV repository\n5. If user wants version control, suggest initializing git within their theme/plugin folder\n\n**✗ INCORRECT approach:**\n- ❌ Committing theme/plugin changes to VVV repository\n- ❌ Creating pull requests with site-specific code\n- ❌ Modifying VVV core to accommodate site-specific needs\n\n### Site Configuration Options\n\nThe `custom:` section in `config/config.yml` supports extensive configuration:\n\n```yaml\ncustom:\n # WordPress installation\n wp_version: latest # Or specific version like \"6.4.2\"\n wp_type: single # Or \"multisite\"\n locale: en_US # WordPress language\n\n # Database\n db_name: my_database\n db_prefix: wp_\n\n # Admin user\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n site_title: \"My Site Title\"\n\n # Plugins & themes\n delete_default_plugins: true # Remove Akismet and Hello Dolly\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin-repo/archive/main.zip\n install_themes:\n - twentytwentyfour\n\n # wp-config.php constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n WP_DEBUG_DISPLAY: false\n SCRIPT_DEBUG: true\n```\n\n## What CAN Be Committed to VVV\n\nOnly these types of changes are appropriate for VVV pull requests:\n- 🐛 Bug fixes in VVV core provisioning scripts\n- 📚 Documentation improvements\n- ✨ New features for VVV itself (not sites)\n- ⚙️ Default configuration updates\n- 🔧 CI/CD improvements\n- 🛠️ Improvements to VVV utilities and tools\n\n## Files That ARE Tracked in www/\n\nOnly these specific files in `www/` are committed to VVV:\n- `www/default/` directory - VVV dashboard and utilities:\n - `www/default/index.php` - VVV dashboard page\n - `www/default/phpinfo/index.php` - PHP version info page\n - `www/default/xdebuginfo/index.php` - Xdebug configuration page\n\n**Everything else in `www/` is gitignored** - this includes all user sites like:\n- `www/wordpress-one/`\n- `www/wordpress-two/`\n- `www/my-custom-site/`\n- etc.\n\n## Pre-Commit Checklist\n\n**Before creating commits or pull requests, ALWAYS:**\n\n1. ✅ Run `git status` - verify no files from `www/` appear (except the defaults listed above)\n2. ✅ Run `git diff` - review ALL changes to ensure nothing from user sites is included\n3. ✅ Check `git check-ignore www/my-site` - should confirm the path is ignored\n4. ✅ Verify `.gitignore` has not been modified to allow `www/` content\n5. ✅ Ask yourself: \"Is this change improving VVV itself, or is it site-specific work?\"\n6. ✅ If uncertain, **ask the user** before committing\n\n## Example Scenarios\n\n### Scenario 1: \"Create a new WordPress site called myproject\"\n\n**✓ CORRECT Response:**\n```\nI'll help you create a new site in VVV. You need to add it to your config/config.yml file:\n\nsites:\n myproject:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - myproject.test\n\nAfter adding this, run: vagrant up --provision\n\nThis will create the site at www/myproject/ and set it up automatically.\n```\n\n**✗ INCORRECT Response:**\n- Creating directories in `www/myproject/`\n- Downloading WordPress with wget/curl\n- Modifying `.gitignore` to track the new site\n- Offering to commit the site to VVV\n\n### Scenario 2: \"Fix a bug in my site's theme\"\n\n**✓ CORRECT Response:**\n```\nI'll help fix the bug in your theme. Which site in www/ are you working on?\n\n[After user responds: www/myproject/]\n\nLet me look at your theme files in www/myproject/public_html/wp-content/themes/.\n\n[Make the fix]\n\nNote: These theme changes are specific to your site and shouldn't be committed to the VVV repository. If you want to version control your theme, consider initializing a git repository within your theme folder.\n```\n\n**✗ INCORRECT Response:**\n- Offering to commit theme changes to VVV\n- Creating a pull request with site-specific code\n- Modifying VVV core to fix a site-specific issue\n\n### Scenario 3: \"Improve VVV's provisioning for PHP 8.3\"\n\n**✓ CORRECT Response:**\n```\nI'll help improve VVV's PHP 8.3 provisioning. Let me review the provisioning scripts in the /provision/ directory.\n\n[Review and make improvements to VVV core scripts]\n\nThese changes improve VVV itself and are appropriate for a pull request to the VVV repository.\n```\n\nThis is a legitimate VVV improvement and CAN be committed.\n\n### Scenario 4: \"Install the Yoast SEO plugin on my site\"\n\n**✓ CORRECT Response:**\n```\nI'll help you install Yoast SEO. Add this to the site's configuration in config/config.yml:\n\nsites:\n your-site:\n custom:\n install_plugins:\n - wordpress-seo\n\nThen run: vagrant up --provision\n\nAlternatively, you can SSH into the VM and use WP-CLI:\nvagrant ssh -c \"wp plugin install wordpress-seo --activate --path=/srv/www/your-site/public_html\"\n```\n\n**✗ INCORRECT Response:**\n- Downloading the plugin ZIP file to `www/site/public_html/wp-content/plugins/`\n- Offering to commit the plugin to VVV repository\n\n## Site Development Workflow Summary\n\nWhen asked to work on a WordPress site in VVV:\n\n1. **Identify the site** - Ask which site in `www/` if unclear\n2. **Navigate to site directory** - e.g., `www/my-site/public_html/`\n3. **Work ONLY within that site** - Themes, plugins, content, etc.\n4. **NEVER commit site changes to VVV** - Site work is separate from VVV work\n5. **Separate repositories** - If the site has its own git repo, that's completely separate from VVV's git repo\n\n## Advanced: Site Provisioning\n\nEach site can have custom provisioning scripts:\n\n**Site structure:**\n```\nwww/my-site/\n├── provision/\n│ ├── vvv-init.sh # Custom provisioning script\n│ └── vvv-nginx.conf # Custom Nginx configuration\n├── public_html/ # WordPress root\n├── log/ # Site-specific logs\n└── wp-cli.yml # WP-CLI configuration\n```\n\n**Helper functions available in vvv-init.sh:**\n- `get_config_value 'key' 'default'` - Get custom config values\n- `get_primary_host` - Get the first domain\n- `noroot` - Run commands without root\n- `wp` - WP-CLI commands\n\n## VVV Extensions\n\nSystem-level tools are installed via extensions in `config/config.yml`:\n\n```yaml\nextensions:\n core:\n - tls-ca # HTTPS certificates\n - phpmyadmin # Database management\n - memcached-admin # Cache management\n - php81 # Additional PHP versions\n - nvm # Node Version Manager\n```\n\n## When You're Unsure\n\n**If you're uncertain about ANY of these:**\n- Whether a file should be committed\n- Whether a change affects VVV core or a site\n- Whether to modify `.gitignore`\n- Whether to modify provisioning scripts\n\n**STOP and ask the user for clarification.** It's better to ask than to make an inappropriate commit.\n\n## Summary of Responsibilities\n\n| Your Responsibility | NOT Your Responsibility |\n|-------------------|------------------------|\n| Help edit `config/config.yml` | Create files in `www/` directly |\n| Suggest proper VVV configuration | Commit site-specific code to VVV |\n| Fix bugs in VVV core scripts | Modify `.gitignore` for sites |\n| Improve VVV documentation | Force commit gitignored files |\n| Guide users on VVV usage | Make changes without understanding impact |\n\n## Questions to Ask Yourself\n\nBefore making any changes:\n1. ❓ Is this improving VVV infrastructure, or is it site-specific work?\n2. ❓ Would this change benefit all VVV users, or just this specific site?\n3. ❓ Am I modifying VVV core files when I should be editing user configuration?\n4. ❓ Will this change appear in `git status`? Should it?\n5. ❓ Have I checked `git check-ignore` for any new files?\n\n---\n\n**Remember:** VVV is infrastructure. Sites are content. Infrastructure changes go to VVV repository. Site changes stay local.\n"},"files":{"agents.md":"# VVV Development Environment - AI Agent Instructions\n\n**Project:** Varying Vagrant Vagrants (VVV)\n**Type:** WordPress Development Environment Infrastructure\n**Repository:** https://github.com/Varying-Vagrant-Vagrants/VVV\n\n## Project Context\n\nVVV is a **local WordPress development environment** using Vagrant. Think of it like Docker Compose for WordPress - it's infrastructure that hosts multiple WordPress sites, not a WordPress project itself.\n\n**Critical Concept:** The `www/` folder contains local development sites that are unique to each developer and should NEVER be committed to the VVV repository (similar to Docker volumes).\n\n## File Structure\n\n```\nvvv-local/\n├── Vagrantfile # Core Vagrant config (DO NOT MODIFY)\n├── .gitignore # Git exclusions (DO NOT MODIFY)\n├── config/\n│ └── config.yml # USER SITE CONFIGURATION (gitignored)\n├── provision/ # VVV provisioning scripts (modify only for VVV improvements)\n├── www/ # LOCAL DEVELOPMENT SITES (gitignored except defaults)\n│ ├── wordpress-one/ # User's site (gitignored)\n│ ├── wordpress-two/ # User's site (gitignored)\n│ └── default/ # VVV dashboard (tracked in git)\n├── database/ # MySQL data (gitignored)\n└── log/ # Logs (gitignored)\n```\n\n## Critical Rules\n\n### 🚨 NEVER Do These Things\n\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or bypass git hooks\n3. **NEVER commit files from `www/`** (except the specific defaults: `www/vvv-hosts`, `www/default/`)\n4. **NEVER create files directly in `www/`** - use `config/config.yml` instead\n5. **NEVER modify core files** (`.gitignore`, `Vagrantfile`, `/provision/`) without explicit permission\n6. **NEVER run `vagrant init`**\n\n### ✅ ALWAYS Do These Things\n\n1. **ALWAYS check `git check-ignore `** before committing files\n2. **ALWAYS review `git status` and `git diff`** before commits\n3. **ALWAYS ask yourself:** \"Is this VVV infrastructure or site-specific work?\"\n4. **ALWAYS edit `config/config.yml`** for site configuration, never create files directly\n5. **ALWAYS ask the user** if uncertain whether something should be committed\n\n## Common Tasks\n\n### Task: Create a New WordPress Site\n\n**Correct approach:**\n\n```yaml\n# Edit: config/config.yml\nsites:\n my-new-site:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mynewsite.test\n custom:\n db_name: mynewsite_db\n site_title: \"My New Site\"\n install_plugins:\n - query-monitor\n wpconfig_constants:\n WP_DEBUG: true\n```\n\nThen instruct user: `vagrant up --provision`\n\n**Incorrect approach:**\n- ❌ Creating `www/my-new-site/` directory manually\n- ❌ Downloading WordPress files\n- ❌ Modifying `.gitignore` to track the site\n- ❌ Modifying files inside the Virtual Machine to track the site\n\n### Task: Modify a WordPress Theme/Plugin\n\n**Correct approach:**\n\n1. Ask: \"Which site in `www/` are you working on?\"\n2. Navigate to: `www/site-name/public_html/wp-content/themes/theme-name/`\n3. Make changes within that directory\n4. DO NOT commit to VVV repository (site files are separate)\n5. Suggest user initializes git within their theme if they want version control\n\n**Incorrect approach:**\n- ❌ Committing theme changes to VVV repository\n- ❌ Committing theme changes to custom site template repository\n- ❌ Creating pull requests with site-specific code\n\n### Task: Improve VVV Provisioning\n\n**Correct approach:**\n\n1. Review files in `/provision/` directory\n2. Make improvements to VVV's core scripts\n3. These changes CAN be committed to VVV\n4. Create pull request with VVV improvements\n\n**When to commit to VVV:**\n- Bug fixes in provisioning scripts\n- Documentation improvements\n- New VVV features\n- CI/CD improvements\n\n## Configuration Format\n\n### Site Configuration Schema\n\n```yaml\nsites:\n site-name:\n repo: # Template repository\n branch: master # Git branch (optional)\n php: 8.2 # PHP version\n skip_provisioning: false # Skip on vagrant up\n hosts: # Domains\n - site.test\n - www.site.test\n custom:\n # WordPress\n wp_version: latest # Or specific: \"6.4.2\"\n wp_type: single # Or: multisite\n locale: en_US\n site_title: \"Site Title\"\n\n # Database\n db_name: database_name\n db_prefix: wp_\n\n # Admin\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n\n # Plugins & Themes\n delete_default_plugins: true\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin.zip\n install_themes:\n - twentytwentyfour\n\n # Constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n SCRIPT_DEBUG: true\n```\n\n## Pre-Commit Checklist\n\nBefore any commit or pull request:\n\n- [ ] Run `git status` - no `www/` files appear (except defaults)\n- [ ] Run `git diff` - review ALL changes\n- [ ] Run `git check-ignore www/test-site` - confirms sites are ignored\n- [ ] Verify `.gitignore` is unmodified\n- [ ] Ask: \"Is this improving VVV or is it site-specific?\"\n- [ ] If uncertain, ask the user\n\n## What IS Tracked in www/\n\nOnly these files in `www/` are committed:\n- `www/vvv-hosts` - Default hostname mappings\n- `www/default/index.php` - VVV dashboard\n- `www/default/phpinfo/index.php` - PHP info page\n- `www/default/xdebuginfo/index.php` - Xdebug info page\n\n**Everything else in `www/` is gitignored.**\n\n## Technology Stack\n\n- **Infrastructure:** Vagrant, VirtualBox/Docker/Parallels\n- **OS:** Ubuntu Linux (in VM)\n- **Web Server:** Nginx\n- **Database:** MySQL/MariaDB\n- **Languages:** PHP (multiple versions: 7.4, 8.0, 8.1, 8.2, 8.3), Bash\n- **Tools:** WP-CLI, Composer, Node.js/npm, Git\n\n## Helpful Commands\n\n```bash\n# Provision sites\nvagrant up --provision\n\n# SSH into VM\nvagrant ssh\n\n# WP-CLI in VM\nvagrant ssh -c \"wp --info\"\n\n# Check if path is gitignored\ngit check-ignore \n\n# View site configuration\ncat config/config.yml\n```\n\n## Architecture Principles\n\n1. **VVV is infrastructure, not content** - It provides the environment, not the sites\n2. **Configuration over files** - Use `config/config.yml`, not manual file creation\n3. **Separation of concerns** - VVV code vs. site code are completely separate\n4. **Gitignore by default** - User content stays local unless explicitly tracked\n\n## Testing Changes\n\nWhen making VVV improvements:\n\n1. Test in a local VVV environment\n2. Run `vagrant up --provision` to test provisioning changes\n3. Verify changes work across different PHP versions\n4. Check that existing sites aren't affected\n5. Update documentation if adding features\n\n## Questions to Ask Yourself\n\n- ❓ Am I modifying VVV infrastructure or site-specific content?\n- ❓ Would this change benefit all VVV users or just one site?\n- ❓ Should this file be in git history?\n- ❓ Am I creating files manually when config.yml could do it?\n- ❓ Have I checked what's actually going to be committed?\n\n## When Uncertain\n\n**If you're unsure about any of the following, STOP and ask the user:**\n\n- Whether a file should be committed\n- Whether a change is VVV core or site-specific\n- Whether to modify `.gitignore`, `Vagrantfile`, or provisioning scripts\n- Whether something should be in `config/config.yml` or created manually\n\n**Better to ask than to make an inappropriate commit.**\n\n## Summary\n\n| DO ✅ | DON'T ❌ |\n|------|---------|\n| Edit `config/config.yml` for sites | Create files in `www/` directly |\n| Commit VVV infrastructure improvements | Commit site-specific code |\n| Use `vagrant up --provision` to create sites | Manually download/install WordPress |\n| Work within site directories for development | Commit theme/plugin changes to VVV |\n| Ask when uncertain | Modify `.gitignore` to track `www/` |\n| Check `git status` before committing | Force commit with `--no-verify` |\n\n## Contributing to VVV\n\nSee `.github/CONTRIBUTING.md` for contribution guidelines.\n\nVVV uses:\n- Google's Shell Style Guide for Bash scripts\n- WordPress coding standards for PHP\n\nAll PRs should target the `develop` branch.\n\n---\n\n**Remember:** VVV is like Docker Compose. The `www/` folder is like volumes - it's local data, not the application itself. Keep infrastructure changes separate from content changes.\n","CLAUDE.md":"# VVV Development Environment Instructions for LLM Agents\n\nThis document provides critical guidance for AI coding assistants working with Varying Vagrant Vagrants (VVV). **Read and follow these instructions carefully to avoid inappropriate changes.**\n\n## 🚨 Critical Boundaries - NEVER Cross These Lines\n\n### DO NOT Modify These Core Files\n- **`.gitignore`** - NEVER modify to allow committing `www/` content or other gitignored paths\n- **`Vagrantfile`** - Core Vagrant configuration, do not modify without explicit permission\n- **`/provision/`** scripts - Core provisioning logic (only modify for VVV improvements, not site work)\n- **Git-tracked files** - Assume files tracked by git are VVV core files unless explicitly told otherwise\n\n### Git Safety Rules - Follow These Strictly\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or similar flags\n3. **ALWAYS check `git check-ignore `** before committing files to verify they should be tracked\n4. **If files in `www/` appear in git status** - they should almost certainly NOT be committed (except the defaults listed below)\n5. **Ask before committing** if you're uncertain whether a file belongs in the VVV repository\n\n## What is VVV?\n\nVVV (Varying Vagrant Vagrants) is a **WordPress development environment** using Vagrant. It's infrastructure, not a project itself.\n\n**Key Concept:** VVV is like Docker Compose for WordPress development. The `www/` folder is like Docker volumes - it contains local development sites that are **unique to each developer** and **should never be shared** via the VVV repository.\n\n### Architecture\n- **`www/` folder** - Contains local development WordPress sites (gitignored, except specific defaults)\n- **`config/config.yml`** - User's site configuration (gitignored)\n- **`provision/`** - Provisioning scripts that set up the Vagrant environment\n- **`database/`** - MySQL data (gitignored)\n- **`log/`** - Log files (gitignored)\n\n## Working with WordPress Sites - The Correct Way\n\n### Creating a New Site\n\nWhen asked to create a new WordPress site:\n\n**✓ CORRECT approach:**\n1. Edit `/config/config.yml` (or create it from `config/default-config.yml` template)\n2. Add a site configuration:\n```yaml\nsites:\n my-site-name:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mysite.test\n custom:\n db_name: my_database\n site_title: \"My Site\"\n admin_user: admin\n admin_password: password\n install_plugins:\n - query-monitor\n - debug-bar\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n```\n3. Instruct user to run: `vagrant up --provision`\n4. VVV will automatically create the site in `www/my-site-name/`\n\n**✗ INCORRECT approach:**\n- ❌ Creating directories directly in `www/my-site-name/`\n- ❌ Downloading and copying WordPress files manually\n- ❌ Modifying `.gitignore` to track the new site\n- ❌ Committing site files to VVV repository\n- ❌ Committing site files to site template repository\n\n### Modifying an Existing Site\n\nWhen asked to work on a WordPress site (themes, plugins, content):\n\n**✓ CORRECT approach:**\n1. Identify which site: \"Which site in `www/` are you working on?\"\n2. Navigate to that site's directory: `www/site-name/public_html/`\n3. Work within that site's directory structure:\n - Themes: `www/site-name/public_html/wp-content/themes/`\n - Plugins: `www/site-name/public_html/wp-content/plugins/`\n - Uploads: `www/site-name/public_html/wp-content/uploads/`\n4. **DO NOT** offer to commit these changes to VVV repository\n5. If user wants version control, suggest initializing git within their theme/plugin folder\n\n**✗ INCORRECT approach:**\n- ❌ Committing theme/plugin changes to VVV repository\n- ❌ Creating pull requests with site-specific code\n- ❌ Modifying VVV core to accommodate site-specific needs\n\n### Site Configuration Options\n\nThe `custom:` section in `config/config.yml` supports extensive configuration:\n\n```yaml\ncustom:\n # WordPress installation\n wp_version: latest # Or specific version like \"6.4.2\"\n wp_type: single # Or \"multisite\"\n locale: en_US # WordPress language\n\n # Database\n db_name: my_database\n db_prefix: wp_\n\n # Admin user\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n site_title: \"My Site Title\"\n\n # Plugins & themes\n delete_default_plugins: true # Remove Akismet and Hello Dolly\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin-repo/archive/main.zip\n install_themes:\n - twentytwentyfour\n\n # wp-config.php constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n WP_DEBUG_DISPLAY: false\n SCRIPT_DEBUG: true\n```\n\n## What CAN Be Committed to VVV\n\nOnly these types of changes are appropriate for VVV pull requests:\n- 🐛 Bug fixes in VVV core provisioning scripts\n- 📚 Documentation improvements\n- ✨ New features for VVV itself (not sites)\n- ⚙️ Default configuration updates\n- 🔧 CI/CD improvements\n- 🛠️ Improvements to VVV utilities and tools\n\n## Files That ARE Tracked in www/\n\nOnly these specific files in `www/` are committed to VVV:\n- `www/default/` directory - VVV dashboard and utilities:\n - `www/default/index.php` - VVV dashboard page\n - `www/default/phpinfo/index.php` - PHP version info page\n - `www/default/xdebuginfo/index.php` - Xdebug configuration page\n\n**Everything else in `www/` is gitignored** - this includes all user sites like:\n- `www/wordpress-one/`\n- `www/wordpress-two/`\n- `www/my-custom-site/`\n- etc.\n\n## Pre-Commit Checklist\n\n**Before creating commits or pull requests, ALWAYS:**\n\n1. ✅ Run `git status` - verify no files from `www/` appear (except the defaults listed above)\n2. ✅ Run `git diff` - review ALL changes to ensure nothing from user sites is included\n3. ✅ Check `git check-ignore www/my-site` - should confirm the path is ignored\n4. ✅ Verify `.gitignore` has not been modified to allow `www/` content\n5. ✅ Ask yourself: \"Is this change improving VVV itself, or is it site-specific work?\"\n6. ✅ If uncertain, **ask the user** before committing\n\n## Example Scenarios\n\n### Scenario 1: \"Create a new WordPress site called myproject\"\n\n**✓ CORRECT Response:**\n```\nI'll help you create a new site in VVV. You need to add it to your config/config.yml file:\n\nsites:\n myproject:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - myproject.test\n\nAfter adding this, run: vagrant up --provision\n\nThis will create the site at www/myproject/ and set it up automatically.\n```\n\n**✗ INCORRECT Response:**\n- Creating directories in `www/myproject/`\n- Downloading WordPress with wget/curl\n- Modifying `.gitignore` to track the new site\n- Offering to commit the site to VVV\n\n### Scenario 2: \"Fix a bug in my site's theme\"\n\n**✓ CORRECT Response:**\n```\nI'll help fix the bug in your theme. Which site in www/ are you working on?\n\n[After user responds: www/myproject/]\n\nLet me look at your theme files in www/myproject/public_html/wp-content/themes/.\n\n[Make the fix]\n\nNote: These theme changes are specific to your site and shouldn't be committed to the VVV repository. If you want to version control your theme, consider initializing a git repository within your theme folder.\n```\n\n**✗ INCORRECT Response:**\n- Offering to commit theme changes to VVV\n- Creating a pull request with site-specific code\n- Modifying VVV core to fix a site-specific issue\n\n### Scenario 3: \"Improve VVV's provisioning for PHP 8.3\"\n\n**✓ CORRECT Response:**\n```\nI'll help improve VVV's PHP 8.3 provisioning. Let me review the provisioning scripts in the /provision/ directory.\n\n[Review and make improvements to VVV core scripts]\n\nThese changes improve VVV itself and are appropriate for a pull request to the VVV repository.\n```\n\nThis is a legitimate VVV improvement and CAN be committed.\n\n### Scenario 4: \"Install the Yoast SEO plugin on my site\"\n\n**✓ CORRECT Response:**\n```\nI'll help you install Yoast SEO. Add this to the site's configuration in config/config.yml:\n\nsites:\n your-site:\n custom:\n install_plugins:\n - wordpress-seo\n\nThen run: vagrant up --provision\n\nAlternatively, you can SSH into the VM and use WP-CLI:\nvagrant ssh -c \"wp plugin install wordpress-seo --activate --path=/srv/www/your-site/public_html\"\n```\n\n**✗ INCORRECT Response:**\n- Downloading the plugin ZIP file to `www/site/public_html/wp-content/plugins/`\n- Offering to commit the plugin to VVV repository\n\n## Site Development Workflow Summary\n\nWhen asked to work on a WordPress site in VVV:\n\n1. **Identify the site** - Ask which site in `www/` if unclear\n2. **Navigate to site directory** - e.g., `www/my-site/public_html/`\n3. **Work ONLY within that site** - Themes, plugins, content, etc.\n4. **NEVER commit site changes to VVV** - Site work is separate from VVV work\n5. **Separate repositories** - If the site has its own git repo, that's completely separate from VVV's git repo\n\n## Advanced: Site Provisioning\n\nEach site can have custom provisioning scripts:\n\n**Site structure:**\n```\nwww/my-site/\n├── provision/\n│ ├── vvv-init.sh # Custom provisioning script\n│ └── vvv-nginx.conf # Custom Nginx configuration\n├── public_html/ # WordPress root\n├── log/ # Site-specific logs\n└── wp-cli.yml # WP-CLI configuration\n```\n\n**Helper functions available in vvv-init.sh:**\n- `get_config_value 'key' 'default'` - Get custom config values\n- `get_primary_host` - Get the first domain\n- `noroot` - Run commands without root\n- `wp` - WP-CLI commands\n\n## VVV Extensions\n\nSystem-level tools are installed via extensions in `config/config.yml`:\n\n```yaml\nextensions:\n core:\n - tls-ca # HTTPS certificates\n - phpmyadmin # Database management\n - memcached-admin # Cache management\n - php81 # Additional PHP versions\n - nvm # Node Version Manager\n```\n\n## When You're Unsure\n\n**If you're uncertain about ANY of these:**\n- Whether a file should be committed\n- Whether a change affects VVV core or a site\n- Whether to modify `.gitignore`\n- Whether to modify provisioning scripts\n\n**STOP and ask the user for clarification.** It's better to ask than to make an inappropriate commit.\n\n## Summary of Responsibilities\n\n| Your Responsibility | NOT Your Responsibility |\n|-------------------|------------------------|\n| Help edit `config/config.yml` | Create files in `www/` directly |\n| Suggest proper VVV configuration | Commit site-specific code to VVV |\n| Fix bugs in VVV core scripts | Modify `.gitignore` for sites |\n| Improve VVV documentation | Force commit gitignored files |\n| Guide users on VVV usage | Make changes without understanding impact |\n\n## Questions to Ask Yourself\n\nBefore making any changes:\n1. ❓ Is this improving VVV infrastructure, or is it site-specific work?\n2. ❓ Would this change benefit all VVV users, or just this specific site?\n3. ❓ Am I modifying VVV core files when I should be editing user configuration?\n4. ❓ Will this change appear in `git status`? Should it?\n5. ❓ Have I checked `git check-ignore` for any new files?\n\n---\n\n**Remember:** VVV is infrastructure. Sites are content. Infrastructure changes go to VVV repository. Site changes stay local.\n"},"items":[{"name":"agents.md","path":"agents.md","rawUrl":"https://raw.githubusercontent.com/Varying-Vagrant-Vagrants/VVV/HEAD/agents.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# VVV Development Environment - AI Agent Instructions\n\n**Project:** Varying Vagrant Vagrants (VVV)\n**Type:** WordPress Development Environment Infrastructure\n**Repository:** https://github.com/Varying-Vagrant-Vagrants/VVV\n\n## Project Context\n\nVVV is a **local WordPress development environment** using Vagrant. Think of it like Docker Compose for WordPress - it's infrastructure that hosts multiple WordPress sites, not a WordPress project itself.\n\n**Critical Concept:** The `www/` folder contains local development sites that are unique to each developer and should NEVER be committed to the VVV repository (similar to Docker volumes).\n\n## File Structure\n\n```\nvvv-local/\n├── Vagrantfile # Core Vagrant config (DO NOT MODIFY)\n├── .gitignore # Git exclusions (DO NOT MODIFY)\n├── config/\n│ └── config.yml # USER SITE CONFIGURATION (gitignored)\n├── provision/ # VVV provisioning scripts (modify only for VVV improvements)\n├── www/ # LOCAL DEVELOPMENT SITES (gitignored except defaults)\n│ ├── wordpress-one/ # User's site (gitignored)\n│ ├── wordpress-two/ # User's site (gitignored)\n│ └── default/ # VVV dashboard (tracked in git)\n├── database/ # MySQL data (gitignored)\n└── log/ # Logs (gitignored)\n```\n\n## Critical Rules\n\n### 🚨 NEVER Do These Things\n\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or bypass git hooks\n3. **NEVER commit files from `www/`** (except the specific defaults: `www/vvv-hosts`, `www/default/`)\n4. **NEVER create files directly in `www/`** - use `config/config.yml` instead\n5. **NEVER modify core files** (`.gitignore`, `Vagrantfile`, `/provision/`) without explicit permission\n6. **NEVER run `vagrant init`**\n\n### ✅ ALWAYS Do These Things\n\n1. **ALWAYS check `git check-ignore `** before committing files\n2. **ALWAYS review `git status` and `git diff`** before commits\n3. **ALWAYS ask yourself:** \"Is this VVV infrastructure or site-specific work?\"\n4. **ALWAYS edit `config/config.yml`** for site configuration, never create files directly\n5. **ALWAYS ask the user** if uncertain whether something should be committed\n\n## Common Tasks\n\n### Task: Create a New WordPress Site\n\n**Correct approach:**\n\n```yaml\n# Edit: config/config.yml\nsites:\n my-new-site:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mynewsite.test\n custom:\n db_name: mynewsite_db\n site_title: \"My New Site\"\n install_plugins:\n - query-monitor\n wpconfig_constants:\n WP_DEBUG: true\n```\n\nThen instruct user: `vagrant up --provision`\n\n**Incorrect approach:**\n- ❌ Creating `www/my-new-site/` directory manually\n- ❌ Downloading WordPress files\n- ❌ Modifying `.gitignore` to track the site\n- ❌ Modifying files inside the Virtual Machine to track the site\n\n### Task: Modify a WordPress Theme/Plugin\n\n**Correct approach:**\n\n1. Ask: \"Which site in `www/` are you working on?\"\n2. Navigate to: `www/site-name/public_html/wp-content/themes/theme-name/`\n3. Make changes within that directory\n4. DO NOT commit to VVV repository (site files are separate)\n5. Suggest user initializes git within their theme if they want version control\n\n**Incorrect approach:**\n- ❌ Committing theme changes to VVV repository\n- ❌ Committing theme changes to custom site template repository\n- ❌ Creating pull requests with site-specific code\n\n### Task: Improve VVV Provisioning\n\n**Correct approach:**\n\n1. Review files in `/provision/` directory\n2. Make improvements to VVV's core scripts\n3. These changes CAN be committed to VVV\n4. Create pull request with VVV improvements\n\n**When to commit to VVV:**\n- Bug fixes in provisioning scripts\n- Documentation improvements\n- New VVV features\n- CI/CD improvements\n\n## Configuration Format\n\n### Site Configuration Schema\n\n```yaml\nsites:\n site-name:\n repo: # Template repository\n branch: master # Git branch (optional)\n php: 8.2 # PHP version\n skip_provisioning: false # Skip on vagrant up\n hosts: # Domains\n - site.test\n - www.site.test\n custom:\n # WordPress\n wp_version: latest # Or specific: \"6.4.2\"\n wp_type: single # Or: multisite\n locale: en_US\n site_title: \"Site Title\"\n\n # Database\n db_name: database_name\n db_prefix: wp_\n\n # Admin\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n\n # Plugins & Themes\n delete_default_plugins: true\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin.zip\n install_themes:\n - twentytwentyfour\n\n # Constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n SCRIPT_DEBUG: true\n```\n\n## Pre-Commit Checklist\n\nBefore any commit or pull request:\n\n- [ ] Run `git status` - no `www/` files appear (except defaults)\n- [ ] Run `git diff` - review ALL changes\n- [ ] Run `git check-ignore www/test-site` - confirms sites are ignored\n- [ ] Verify `.gitignore` is unmodified\n- [ ] Ask: \"Is this improving VVV or is it site-specific?\"\n- [ ] If uncertain, ask the user\n\n## What IS Tracked in www/\n\nOnly these files in `www/` are committed:\n- `www/vvv-hosts` - Default hostname mappings\n- `www/default/index.php` - VVV dashboard\n- `www/default/phpinfo/index.php` - PHP info page\n- `www/default/xdebuginfo/index.php` - Xdebug info page\n\n**Everything else in `www/` is gitignored.**\n\n## Technology Stack\n\n- **Infrastructure:** Vagrant, VirtualBox/Docker/Parallels\n- **OS:** Ubuntu Linux (in VM)\n- **Web Server:** Nginx\n- **Database:** MySQL/MariaDB\n- **Languages:** PHP (multiple versions: 7.4, 8.0, 8.1, 8.2, 8.3), Bash\n- **Tools:** WP-CLI, Composer, Node.js/npm, Git\n\n## Helpful Commands\n\n```bash\n# Provision sites\nvagrant up --provision\n\n# SSH into VM\nvagrant ssh\n\n# WP-CLI in VM\nvagrant ssh -c \"wp --info\"\n\n# Check if path is gitignored\ngit check-ignore \n\n# View site configuration\ncat config/config.yml\n```\n\n## Architecture Principles\n\n1. **VVV is infrastructure, not content** - It provides the environment, not the sites\n2. **Configuration over files** - Use `config/config.yml`, not manual file creation\n3. **Separation of concerns** - VVV code vs. site code are completely separate\n4. **Gitignore by default** - User content stays local unless explicitly tracked\n\n## Testing Changes\n\nWhen making VVV improvements:\n\n1. Test in a local VVV environment\n2. Run `vagrant up --provision` to test provisioning changes\n3. Verify changes work across different PHP versions\n4. Check that existing sites aren't affected\n5. Update documentation if adding features\n\n## Questions to Ask Yourself\n\n- ❓ Am I modifying VVV infrastructure or site-specific content?\n- ❓ Would this change benefit all VVV users or just one site?\n- ❓ Should this file be in git history?\n- ❓ Am I creating files manually when config.yml could do it?\n- ❓ Have I checked what's actually going to be committed?\n\n## When Uncertain\n\n**If you're unsure about any of the following, STOP and ask the user:**\n\n- Whether a file should be committed\n- Whether a change is VVV core or site-specific\n- Whether to modify `.gitignore`, `Vagrantfile`, or provisioning scripts\n- Whether something should be in `config/config.yml` or created manually\n\n**Better to ask than to make an inappropriate commit.**\n\n## Summary\n\n| DO ✅ | DON'T ❌ |\n|------|---------|\n| Edit `config/config.yml` for sites | Create files in `www/` directly |\n| Commit VVV infrastructure improvements | Commit site-specific code |\n| Use `vagrant up --provision` to create sites | Manually download/install WordPress |\n| Work within site directories for development | Commit theme/plugin changes to VVV |\n| Ask when uncertain | Modify `.gitignore` to track `www/` |\n| Check `git status` before committing | Force commit with `--no-verify` |\n\n## Contributing to VVV\n\nSee `.github/CONTRIBUTING.md` for contribution guidelines.\n\nVVV uses:\n- Google's Shell Style Guide for Bash scripts\n- WordPress coding standards for PHP\n\nAll PRs should target the `develop` branch.\n\n---\n\n**Remember:** VVV is like Docker Compose. The `www/` folder is like volumes - it's local data, not the application itself. Keep infrastructure changes separate from content changes.\n","isInternal":false,"tokens":2103,"sizeBytes":8635},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Varying-Vagrant-Vagrants/VVV/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# VVV Development Environment Instructions for LLM Agents\n\nThis document provides critical guidance for AI coding assistants working with Varying Vagrant Vagrants (VVV). **Read and follow these instructions carefully to avoid inappropriate changes.**\n\n## 🚨 Critical Boundaries - NEVER Cross These Lines\n\n### DO NOT Modify These Core Files\n- **`.gitignore`** - NEVER modify to allow committing `www/` content or other gitignored paths\n- **`Vagrantfile`** - Core Vagrant configuration, do not modify without explicit permission\n- **`/provision/`** scripts - Core provisioning logic (only modify for VVV improvements, not site work)\n- **Git-tracked files** - Assume files tracked by git are VVV core files unless explicitly told otherwise\n\n### Git Safety Rules - Follow These Strictly\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or similar flags\n3. **ALWAYS check `git check-ignore `** before committing files to verify they should be tracked\n4. **If files in `www/` appear in git status** - they should almost certainly NOT be committed (except the defaults listed below)\n5. **Ask before committing** if you're uncertain whether a file belongs in the VVV repository\n\n## What is VVV?\n\nVVV (Varying Vagrant Vagrants) is a **WordPress development environment** using Vagrant. It's infrastructure, not a project itself.\n\n**Key Concept:** VVV is like Docker Compose for WordPress development. The `www/` folder is like Docker volumes - it contains local development sites that are **unique to each developer** and **should never be shared** via the VVV repository.\n\n### Architecture\n- **`www/` folder** - Contains local development WordPress sites (gitignored, except specific defaults)\n- **`config/config.yml`** - User's site configuration (gitignored)\n- **`provision/`** - Provisioning scripts that set up the Vagrant environment\n- **`database/`** - MySQL data (gitignored)\n- **`log/`** - Log files (gitignored)\n\n## Working with WordPress Sites - The Correct Way\n\n### Creating a New Site\n\nWhen asked to create a new WordPress site:\n\n**✓ CORRECT approach:**\n1. Edit `/config/config.yml` (or create it from `config/default-config.yml` template)\n2. Add a site configuration:\n```yaml\nsites:\n my-site-name:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mysite.test\n custom:\n db_name: my_database\n site_title: \"My Site\"\n admin_user: admin\n admin_password: password\n install_plugins:\n - query-monitor\n - debug-bar\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n```\n3. Instruct user to run: `vagrant up --provision`\n4. VVV will automatically create the site in `www/my-site-name/`\n\n**✗ INCORRECT approach:**\n- ❌ Creating directories directly in `www/my-site-name/`\n- ❌ Downloading and copying WordPress files manually\n- ❌ Modifying `.gitignore` to track the new site\n- ❌ Committing site files to VVV repository\n- ❌ Committing site files to site template repository\n\n### Modifying an Existing Site\n\nWhen asked to work on a WordPress site (themes, plugins, content):\n\n**✓ CORRECT approach:**\n1. Identify which site: \"Which site in `www/` are you working on?\"\n2. Navigate to that site's directory: `www/site-name/public_html/`\n3. Work within that site's directory structure:\n - Themes: `www/site-name/public_html/wp-content/themes/`\n - Plugins: `www/site-name/public_html/wp-content/plugins/`\n - Uploads: `www/site-name/public_html/wp-content/uploads/`\n4. **DO NOT** offer to commit these changes to VVV repository\n5. If user wants version control, suggest initializing git within their theme/plugin folder\n\n**✗ INCORRECT approach:**\n- ❌ Committing theme/plugin changes to VVV repository\n- ❌ Creating pull requests with site-specific code\n- ❌ Modifying VVV core to accommodate site-specific needs\n\n### Site Configuration Options\n\nThe `custom:` section in `config/config.yml` supports extensive configuration:\n\n```yaml\ncustom:\n # WordPress installation\n wp_version: latest # Or specific version like \"6.4.2\"\n wp_type: single # Or \"multisite\"\n locale: en_US # WordPress language\n\n # Database\n db_name: my_database\n db_prefix: wp_\n\n # Admin user\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n site_title: \"My Site Title\"\n\n # Plugins & themes\n delete_default_plugins: true # Remove Akismet and Hello Dolly\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin-repo/archive/main.zip\n install_themes:\n - twentytwentyfour\n\n # wp-config.php constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n WP_DEBUG_DISPLAY: false\n SCRIPT_DEBUG: true\n```\n\n## What CAN Be Committed to VVV\n\nOnly these types of changes are appropriate for VVV pull requests:\n- 🐛 Bug fixes in VVV core provisioning scripts\n- 📚 Documentation improvements\n- ✨ New features for VVV itself (not sites)\n- ⚙️ Default configuration updates\n- 🔧 CI/CD improvements\n- 🛠️ Improvements to VVV utilities and tools\n\n## Files That ARE Tracked in www/\n\nOnly these specific files in `www/` are committed to VVV:\n- `www/default/` directory - VVV dashboard and utilities:\n - `www/default/index.php` - VVV dashboard page\n - `www/default/phpinfo/index.php` - PHP version info page\n - `www/default/xdebuginfo/index.php` - Xdebug configuration page\n\n**Everything else in `www/` is gitignored** - this includes all user sites like:\n- `www/wordpress-one/`\n- `www/wordpress-two/`\n- `www/my-custom-site/`\n- etc.\n\n## Pre-Commit Checklist\n\n**Before creating commits or pull requests, ALWAYS:**\n\n1. ✅ Run `git status` - verify no files from `www/` appear (except the defaults listed above)\n2. ✅ Run `git diff` - review ALL changes to ensure nothing from user sites is included\n3. ✅ Check `git check-ignore www/my-site` - should confirm the path is ignored\n4. ✅ Verify `.gitignore` has not been modified to allow `www/` content\n5. ✅ Ask yourself: \"Is this change improving VVV itself, or is it site-specific work?\"\n6. ✅ If uncertain, **ask the user** before committing\n\n## Example Scenarios\n\n### Scenario 1: \"Create a new WordPress site called myproject\"\n\n**✓ CORRECT Response:**\n```\nI'll help you create a new site in VVV. You need to add it to your config/config.yml file:\n\nsites:\n myproject:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - myproject.test\n\nAfter adding this, run: vagrant up --provision\n\nThis will create the site at www/myproject/ and set it up automatically.\n```\n\n**✗ INCORRECT Response:**\n- Creating directories in `www/myproject/`\n- Downloading WordPress with wget/curl\n- Modifying `.gitignore` to track the new site\n- Offering to commit the site to VVV\n\n### Scenario 2: \"Fix a bug in my site's theme\"\n\n**✓ CORRECT Response:**\n```\nI'll help fix the bug in your theme. Which site in www/ are you working on?\n\n[After user responds: www/myproject/]\n\nLet me look at your theme files in www/myproject/public_html/wp-content/themes/.\n\n[Make the fix]\n\nNote: These theme changes are specific to your site and shouldn't be committed to the VVV repository. If you want to version control your theme, consider initializing a git repository within your theme folder.\n```\n\n**✗ INCORRECT Response:**\n- Offering to commit theme changes to VVV\n- Creating a pull request with site-specific code\n- Modifying VVV core to fix a site-specific issue\n\n### Scenario 3: \"Improve VVV's provisioning for PHP 8.3\"\n\n**✓ CORRECT Response:**\n```\nI'll help improve VVV's PHP 8.3 provisioning. Let me review the provisioning scripts in the /provision/ directory.\n\n[Review and make improvements to VVV core scripts]\n\nThese changes improve VVV itself and are appropriate for a pull request to the VVV repository.\n```\n\nThis is a legitimate VVV improvement and CAN be committed.\n\n### Scenario 4: \"Install the Yoast SEO plugin on my site\"\n\n**✓ CORRECT Response:**\n```\nI'll help you install Yoast SEO. Add this to the site's configuration in config/config.yml:\n\nsites:\n your-site:\n custom:\n install_plugins:\n - wordpress-seo\n\nThen run: vagrant up --provision\n\nAlternatively, you can SSH into the VM and use WP-CLI:\nvagrant ssh -c \"wp plugin install wordpress-seo --activate --path=/srv/www/your-site/public_html\"\n```\n\n**✗ INCORRECT Response:**\n- Downloading the plugin ZIP file to `www/site/public_html/wp-content/plugins/`\n- Offering to commit the plugin to VVV repository\n\n## Site Development Workflow Summary\n\nWhen asked to work on a WordPress site in VVV:\n\n1. **Identify the site** - Ask which site in `www/` if unclear\n2. **Navigate to site directory** - e.g., `www/my-site/public_html/`\n3. **Work ONLY within that site** - Themes, plugins, content, etc.\n4. **NEVER commit site changes to VVV** - Site work is separate from VVV work\n5. **Separate repositories** - If the site has its own git repo, that's completely separate from VVV's git repo\n\n## Advanced: Site Provisioning\n\nEach site can have custom provisioning scripts:\n\n**Site structure:**\n```\nwww/my-site/\n├── provision/\n│ ├── vvv-init.sh # Custom provisioning script\n│ └── vvv-nginx.conf # Custom Nginx configuration\n├── public_html/ # WordPress root\n├── log/ # Site-specific logs\n└── wp-cli.yml # WP-CLI configuration\n```\n\n**Helper functions available in vvv-init.sh:**\n- `get_config_value 'key' 'default'` - Get custom config values\n- `get_primary_host` - Get the first domain\n- `noroot` - Run commands without root\n- `wp` - WP-CLI commands\n\n## VVV Extensions\n\nSystem-level tools are installed via extensions in `config/config.yml`:\n\n```yaml\nextensions:\n core:\n - tls-ca # HTTPS certificates\n - phpmyadmin # Database management\n - memcached-admin # Cache management\n - php81 # Additional PHP versions\n - nvm # Node Version Manager\n```\n\n## When You're Unsure\n\n**If you're uncertain about ANY of these:**\n- Whether a file should be committed\n- Whether a change affects VVV core or a site\n- Whether to modify `.gitignore`\n- Whether to modify provisioning scripts\n\n**STOP and ask the user for clarification.** It's better to ask than to make an inappropriate commit.\n\n## Summary of Responsibilities\n\n| Your Responsibility | NOT Your Responsibility |\n|-------------------|------------------------|\n| Help edit `config/config.yml` | Create files in `www/` directly |\n| Suggest proper VVV configuration | Commit site-specific code to VVV |\n| Fix bugs in VVV core scripts | Modify `.gitignore` for sites |\n| Improve VVV documentation | Force commit gitignored files |\n| Guide users on VVV usage | Make changes without understanding impact |\n\n## Questions to Ask Yourself\n\nBefore making any changes:\n1. ❓ Is this improving VVV infrastructure, or is it site-specific work?\n2. ❓ Would this change benefit all VVV users, or just this specific site?\n3. ❓ Am I modifying VVV core files when I should be editing user configuration?\n4. ❓ Will this change appear in `git status`? Should it?\n5. ❓ Have I checked `git check-ignore` for any new files?\n\n---\n\n**Remember:** VVV is infrastructure. Sites are content. Infrastructure changes go to VVV repository. Site changes stay local.\n","isInternal":false,"tokens":2796,"sizeBytes":11459}],"systemPromptSnippet":"\n\n# VVV Development Environment - AI Agent Instructions\n\n**Project:** Varying Vagrant Vagrants (VVV)\n**Type:** WordPress Development Environment Infrastructure\n**Repository:** https://github.com/Varying-Vagrant-Vagrants/VVV\n\n## Project Context\n\nVVV is a **local WordPress development environment** using Vagrant. Think of it like Docker Compose for WordPress - it's infrastructure that hosts multiple WordPress sites, not a WordPress project itself.\n\n**Critical Concept:** The `www/` folder contains local development sites that are unique to each developer and should NEVER be committed to the VVV repository (similar to Docker volumes).\n\n## File Structure\n\n```\nvvv-local/\n├── Vagrantfile # Core Vagrant config (DO NOT MODIFY)\n├── .gitignore # Git exclusions (DO NOT MODIFY)\n├── config/\n│ └── config.yml # USER SITE CONFIGURATION (gitignored)\n├── provision/ # VVV provisioning scripts (modify only for VVV improvements)\n├── www/ # LOCAL DEVELOPMENT SITES (gitignored except defaults)\n│ ├── wordpress-one/ # User's site (gitignored)\n│ ├── wordpress-two/ # User's site (gitignored)\n│ └── default/ # VVV dashboard (tracked in git)\n├── database/ # MySQL data (gitignored)\n└── log/ # Logs (gitignored)\n```\n\n## Critical Rules\n\n### 🚨 NEVER Do These Things\n\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or bypass git hooks\n3. **NEVER commit files from `www/`** (except the specific defaults: `www/vvv-hosts`, `www/default/`)\n4. **NEVER create files directly in `www/`** - use `config/config.yml` instead\n5. **NEVER modify core files** (`.gitignore`, `Vagrantfile`, `/provision/`) without explicit permission\n6. **NEVER run `vagrant init`**\n\n### ✅ ALWAYS Do These Things\n\n1. **ALWAYS check `git check-ignore `** before committing files\n2. **ALWAYS review `git status` and `git diff`** before commits\n3. **ALWAYS ask yourself:** \"Is this VVV infrastructure or site-specific work?\"\n4. **ALWAYS edit `config/config.yml`** for site configuration, never create files directly\n5. **ALWAYS ask the user** if uncertain whether something should be committed\n\n## Common Tasks\n\n### Task: Create a New WordPress Site\n\n**Correct approach:**\n\n```yaml\n# Edit: config/config.yml\nsites:\n my-new-site:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mynewsite.test\n custom:\n db_name: mynewsite_db\n site_title: \"My New Site\"\n install_plugins:\n - query-monitor\n wpconfig_constants:\n WP_DEBUG: true\n```\n\nThen instruct user: `vagrant up --provision`\n\n**Incorrect approach:**\n- ❌ Creating `www/my-new-site/` directory manually\n- ❌ Downloading WordPress files\n- ❌ Modifying `.gitignore` to track the site\n- ❌ Modifying files inside the Virtual Machine to track the site\n\n### Task: Modify a WordPress Theme/Plugin\n\n**Correct approach:**\n\n1. Ask: \"Which site in `www/` are you working on?\"\n2. Navigate to: `www/site-name/public_html/wp-content/themes/theme-name/`\n3. Make changes within that directory\n4. DO NOT commit to VVV repository (site files are separate)\n5. Suggest user initializes git within their theme if they want version control\n\n**Incorrect approach:**\n- ❌ Committing theme changes to VVV repository\n- ❌ Committing theme changes to custom site template repository\n- ❌ Creating pull requests with site-specific code\n\n### Task: Improve VVV Provisioning\n\n**Correct approach:**\n\n1. Review files in `/provision/` directory\n2. Make improvements to VVV's core scripts\n3. These changes CAN be committed to VVV\n4. Create pull request with VVV improvements\n\n**When to commit to VVV:**\n- Bug fixes in provisioning scripts\n- Documentation improvements\n- New VVV features\n- CI/CD improvements\n\n## Configuration Format\n\n### Site Configuration Schema\n\n```yaml\nsites:\n site-name:\n repo: # Template repository\n branch: master # Git branch (optional)\n php: 8.2 # PHP version\n skip_provisioning: false # Skip on vagrant up\n hosts: # Domains\n - site.test\n - www.site.test\n custom:\n # WordPress\n wp_version: latest # Or specific: \"6.4.2\"\n wp_type: single # Or: multisite\n locale: en_US\n site_title: \"Site Title\"\n\n # Database\n db_name: database_name\n db_prefix: wp_\n\n # Admin\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n\n # Plugins & Themes\n delete_default_plugins: true\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin.zip\n install_themes:\n - twentytwentyfour\n\n # Constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n SCRIPT_DEBUG: true\n```\n\n## Pre-Commit Checklist\n\nBefore any commit or pull request:\n\n- [ ] Run `git status` - no `www/` files appear (except defaults)\n- [ ] Run `git diff` - review ALL changes\n- [ ] Run `git check-ignore www/test-site` - confirms sites are ignored\n- [ ] Verify `.gitignore` is unmodified\n- [ ] Ask: \"Is this improving VVV or is it site-specific?\"\n- [ ] If uncertain, ask the user\n\n## What IS Tracked in www/\n\nOnly these files in `www/` are committed:\n- `www/vvv-hosts` - Default hostname mappings\n- `www/default/index.php` - VVV dashboard\n- `www/default/phpinfo/index.php` - PHP info page\n- `www/default/xdebuginfo/index.php` - Xdebug info page\n\n**Everything else in `www/` is gitignored.**\n\n## Technology Stack\n\n- **Infrastructure:** Vagrant, VirtualBox/Docker/Parallels\n- **OS:** Ubuntu Linux (in VM)\n- **Web Server:** Nginx\n- **Database:** MySQL/MariaDB\n- **Languages:** PHP (multiple versions: 7.4, 8.0, 8.1, 8.2, 8.3), Bash\n- **Tools:** WP-CLI, Composer, Node.js/npm, Git\n\n## Helpful Commands\n\n```bash\n# Provision sites\nvagrant up --provision\n\n# SSH into VM\nvagrant ssh\n\n# WP-CLI in VM\nvagrant ssh -c \"wp --info\"\n\n# Check if path is gitignored\ngit check-ignore \n\n# View site configuration\ncat config/config.yml\n```\n\n## Architecture Principles\n\n1. **VVV is infrastructure, not content** - It provides the environment, not the sites\n2. **Configuration over files** - Use `config/config.yml`, not manual file creation\n3. **Separation of concerns** - VVV code vs. site code are completely separate\n4. **Gitignore by default** - User content stays local unless explicitly tracked\n\n## Testing Changes\n\nWhen making VVV improvements:\n\n1. Test in a local VVV environment\n2. Run `vagrant up --provision` to test provisioning changes\n3. Verify changes work across different PHP versions\n4. Check that existing sites aren't affected\n5. Update documentation if adding features\n\n## Questions to Ask Yourself\n\n- ❓ Am I modifying VVV infrastructure or site-specific content?\n- ❓ Would this change benefit all VVV users or just one site?\n- ❓ Should this file be in git history?\n- ❓ Am I creating files manually when config.yml could do it?\n- ❓ Have I checked what's actually going to be committed?\n\n## When Uncertain\n\n**If you're unsure about any of the following, STOP and ask the user:**\n\n- Whether a file should be committed\n- Whether a change is VVV core or site-specific\n- Whether to modify `.gitignore`, `Vagrantfile`, or provisioning scripts\n- Whether something should be in `config/config.yml` or created manually\n\n**Better to ask than to make an inappropriate commit.**\n\n## Summary\n\n| DO ✅ | DON'T ❌ |\n|------|---------|\n| Edit `config/config.yml` for sites | Create files in `www/` directly |\n| Commit VVV infrastructure improvements | Commit site-specific code |\n| Use `vagrant up --provision` to create sites | Manually download/install WordPress |\n| Work within site directories for development | Commit theme/plugin changes to VVV |\n| Ask when uncertain | Modify `.gitignore` to track `www/` |\n| Check `git status` before committing | Force commit with `--no-verify` |\n\n## Contributing to VVV\n\nSee `.github/CONTRIBUTING.md` for contribution guidelines.\n\nVVV uses:\n- Google's Shell Style Guide for Bash scripts\n- WordPress coding standards for PHP\n\nAll PRs should target the `develop` branch.\n\n---\n\n**Remember:** VVV is like Docker Compose. The `www/` folder is like volumes - it's local data, not the application itself. Keep infrastructure changes separate from content changes.\n\n\n# VVV Development Environment Instructions for LLM Agents\n\nThis document provides critical guidance for AI coding assistants working with Varying Vagrant Vagrants (VVV). **Read and follow these instructions carefully to avoid inappropriate changes.**\n\n## 🚨 Critical Boundaries - NEVER Cross These Lines\n\n### DO NOT Modify These Core Files\n- **`.gitignore`** - NEVER modify to allow committing `www/` content or other gitignored paths\n- **`Vagrantfile`** - Core Vagrant configuration, do not modify without explicit permission\n- **`/provision/`** scripts - Core provisioning logic (only modify for VVV improvements, not site work)\n- **Git-tracked files** - Assume files tracked by git are VVV core files unless explicitly told otherwise\n\n### Git Safety Rules - Follow These Strictly\n1. **NEVER modify `.gitignore`** to allow committing `www/` content\n2. **NEVER force commit** using `--no-verify`, `-f`, or similar flags\n3. **ALWAYS check `git check-ignore `** before committing files to verify they should be tracked\n4. **If files in `www/` appear in git status** - they should almost certainly NOT be committed (except the defaults listed below)\n5. **Ask before committing** if you're uncertain whether a file belongs in the VVV repository\n\n## What is VVV?\n\nVVV (Varying Vagrant Vagrants) is a **WordPress development environment** using Vagrant. It's infrastructure, not a project itself.\n\n**Key Concept:** VVV is like Docker Compose for WordPress development. The `www/` folder is like Docker volumes - it contains local development sites that are **unique to each developer** and **should never be shared** via the VVV repository.\n\n### Architecture\n- **`www/` folder** - Contains local development WordPress sites (gitignored, except specific defaults)\n- **`config/config.yml`** - User's site configuration (gitignored)\n- **`provision/`** - Provisioning scripts that set up the Vagrant environment\n- **`database/`** - MySQL data (gitignored)\n- **`log/`** - Log files (gitignored)\n\n## Working with WordPress Sites - The Correct Way\n\n### Creating a New Site\n\nWhen asked to create a new WordPress site:\n\n**✓ CORRECT approach:**\n1. Edit `/config/config.yml` (or create it from `config/default-config.yml` template)\n2. Add a site configuration:\n```yaml\nsites:\n my-site-name:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - mysite.test\n custom:\n db_name: my_database\n site_title: \"My Site\"\n admin_user: admin\n admin_password: password\n install_plugins:\n - query-monitor\n - debug-bar\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n```\n3. Instruct user to run: `vagrant up --provision`\n4. VVV will automatically create the site in `www/my-site-name/`\n\n**✗ INCORRECT approach:**\n- ❌ Creating directories directly in `www/my-site-name/`\n- ❌ Downloading and copying WordPress files manually\n- ❌ Modifying `.gitignore` to track the new site\n- ❌ Committing site files to VVV repository\n- ❌ Committing site files to site template repository\n\n### Modifying an Existing Site\n\nWhen asked to work on a WordPress site (themes, plugins, content):\n\n**✓ CORRECT approach:**\n1. Identify which site: \"Which site in `www/` are you working on?\"\n2. Navigate to that site's directory: `www/site-name/public_html/`\n3. Work within that site's directory structure:\n - Themes: `www/site-name/public_html/wp-content/themes/`\n - Plugins: `www/site-name/public_html/wp-content/plugins/`\n - Uploads: `www/site-name/public_html/wp-content/uploads/`\n4. **DO NOT** offer to commit these changes to VVV repository\n5. If user wants version control, suggest initializing git within their theme/plugin folder\n\n**✗ INCORRECT approach:**\n- ❌ Committing theme/plugin changes to VVV repository\n- ❌ Creating pull requests with site-specific code\n- ❌ Modifying VVV core to accommodate site-specific needs\n\n### Site Configuration Options\n\nThe `custom:` section in `config/config.yml` supports extensive configuration:\n\n```yaml\ncustom:\n # WordPress installation\n wp_version: latest # Or specific version like \"6.4.2\"\n wp_type: single # Or \"multisite\"\n locale: en_US # WordPress language\n\n # Database\n db_name: my_database\n db_prefix: wp_\n\n # Admin user\n admin_user: admin\n admin_password: password\n admin_email: admin@local.test\n site_title: \"My Site Title\"\n\n # Plugins & themes\n delete_default_plugins: true # Remove Akismet and Hello Dolly\n install_plugins:\n - query-monitor\n - debug-bar\n - https://github.com/user/plugin-repo/archive/main.zip\n install_themes:\n - twentytwentyfour\n\n # wp-config.php constants\n wpconfig_constants:\n WP_DEBUG: true\n WP_DEBUG_LOG: true\n WP_DEBUG_DISPLAY: false\n SCRIPT_DEBUG: true\n```\n\n## What CAN Be Committed to VVV\n\nOnly these types of changes are appropriate for VVV pull requests:\n- 🐛 Bug fixes in VVV core provisioning scripts\n- 📚 Documentation improvements\n- ✨ New features for VVV itself (not sites)\n- ⚙️ Default configuration updates\n- 🔧 CI/CD improvements\n- 🛠️ Improvements to VVV utilities and tools\n\n## Files That ARE Tracked in www/\n\nOnly these specific files in `www/` are committed to VVV:\n- `www/default/` directory - VVV dashboard and utilities:\n - `www/default/index.php` - VVV dashboard page\n - `www/default/phpinfo/index.php` - PHP version info page\n - `www/default/xdebuginfo/index.php` - Xdebug configuration page\n\n**Everything else in `www/` is gitignored** - this includes all user sites like:\n- `www/wordpress-one/`\n- `www/wordpress-two/`\n- `www/my-custom-site/`\n- etc.\n\n## Pre-Commit Checklist\n\n**Before creating commits or pull requests, ALWAYS:**\n\n1. ✅ Run `git status` - verify no files from `www/` appear (except the defaults listed above)\n2. ✅ Run `git diff` - review ALL changes to ensure nothing from user sites is included\n3. ✅ Check `git check-ignore www/my-site` - should confirm the path is ignored\n4. ✅ Verify `.gitignore` has not been modified to allow `www/` content\n5. ✅ Ask yourself: \"Is this change improving VVV itself, or is it site-specific work?\"\n6. ✅ If uncertain, **ask the user** before committing\n\n## Example Scenarios\n\n### Scenario 1: \"Create a new WordPress site called myproject\"\n\n**✓ CORRECT Response:**\n```\nI'll help you create a new site in VVV. You need to add it to your config/config.yml file:\n\nsites:\n myproject:\n repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git\n php: 8.2\n hosts:\n - myproject.test\n\nAfter adding this, run: vagrant up --provision\n\nThis will create the site at www/myproject/ and set it up automatically.\n```\n\n**✗ INCORRECT Response:**\n- Creating directories in `www/myproject/`\n- Downloading WordPress with wget/curl\n- Modifying `.gitignore` to track the new site\n- Offering to commit the site to VVV\n\n### Scenario 2: \"Fix a bug in my site's theme\"\n\n**✓ CORRECT Response:**\n```\nI'll help fix the bug in your theme. Which site in www/ are you working on?\n\n[After user responds: www/myproject/]\n\nLet me look at your theme files in www/myproject/public_html/wp-content/themes/.\n\n[Make the fix]\n\nNote: These theme changes are specific to your site and shouldn't be committed to the VVV repository. If you want to version control your theme, consider initializing a git repository within your theme folder.\n```\n\n**✗ INCORRECT Response:**\n- Offering to commit theme changes to VVV\n- Creating a pull request with site-specific code\n- Modifying VVV core to fix a site-specific issue\n\n### Scenario 3: \"Improve VVV's provisioning for PHP 8.3\"\n\n**✓ CORRECT Response:**\n```\nI'll help improve VVV's PHP 8.3 provisioning. Let me review the provisioning scripts in the /provision/ directory.\n\n[Review and make improvements to VVV core scripts]\n\nThese changes improve VVV itself and are appropriate for a pull request to the VVV repository.\n```\n\nThis is a legitimate VVV improvement and CAN be committed.\n\n### Scenario 4: \"Install the Yoast SEO plugin on my site\"\n\n**✓ CORRECT Response:**\n```\nI'll help you install Yoast SEO. Add this to the site's configuration in config/config.yml:\n\nsites:\n your-site:\n custom:\n install_plugins:\n - wordpress-seo\n\nThen run: vagrant up --provision\n\nAlternatively, you can SSH into the VM and use WP-CLI:\nvagrant ssh -c \"wp plugin install wordpress-seo --activate --path=/srv/www/your-site/public_html\"\n```\n\n**✗ INCORRECT Response:**\n- Downloading the plugin ZIP file to `www/site/public_html/wp-content/plugins/`\n- Offering to commit the plugin to VVV repository\n\n## Site Development Workflow Summary\n\nWhen asked to work on a WordPress site in VVV:\n\n1. **Identify the site** - Ask which site in `www/` if unclear\n2. **Navigate to site directory** - e.g., `www/my-site/public_html/`\n3. **Work ONLY within that site** - Themes, plugins, content, etc.\n4. **NEVER commit site changes to VVV** - Site work is separate from VVV work\n5. **Separate repositories** - If the site has its own git repo, that's completely separate from VVV's git repo\n\n## Advanced: Site Provisioning\n\nEach site can have custom provisioning scripts:\n\n**Site structure:**\n```\nwww/my-site/\n├── provision/\n│ ├── vvv-init.sh # Custom provisioning script\n│ └── vvv-nginx.conf # Custom Nginx configuration\n├── public_html/ # WordPress root\n├── log/ # Site-specific logs\n└── wp-cli.yml # WP-CLI configuration\n```\n\n**Helper functions available in vvv-init.sh:**\n- `get_config_value 'key' 'default'` - Get custom config values\n- `get_primary_host` - Get the first domain\n- `noroot` - Run commands without root\n- `wp` - WP-CLI commands\n\n## VVV Extensions\n\nSystem-level tools are installed via extensions in `config/config.yml`:\n\n```yaml\nextensions:\n core:\n - tls-ca # HTTPS certificates\n - phpmyadmin # Database management\n - memcached-admin # Cache management\n - php81 # Additional PHP versions\n - nvm # Node Version Manager\n```\n\n## When You're Unsure\n\n**If you're uncertain about ANY of these:**\n- Whether a file should be committed\n- Whether a change affects VVV core or a site\n- Whether to modify `.gitignore`\n- Whether to modify provisioning scripts\n\n**STOP and ask the user for clarification.** It's better to ask than to make an inappropriate commit.\n\n## Summary of Responsibilities\n\n| Your Responsibility | NOT Your Responsibility |\n|-------------------|------------------------|\n| Help edit `config/config.yml` | Create files in `www/` directly |\n| Suggest proper VVV configuration | Commit site-specific code to VVV |\n| Fix bugs in VVV core scripts | Modify `.gitignore` for sites |\n| Improve VVV documentation | Force commit gitignored files |\n| Guide users on VVV usage | Make changes without understanding impact |\n\n## Questions to Ask Yourself\n\nBefore making any changes:\n1. ❓ Is this improving VVV infrastructure, or is it site-specific work?\n2. ❓ Would this change benefit all VVV users, or just this specific site?\n3. ❓ Am I modifying VVV core files when I should be editing user configuration?\n4. ❓ Will this change appear in `git status`? Should it?\n5. ❓ Have I checked `git check-ignore` for any new files?\n\n---\n\n**Remember:** VVV is infrastructure. Sites are content. Infrastructure changes go to VVV repository. Site changes stay local.\n"}