@bostonuniversity/buwp-local 0.7.1 → 0.7.3

package/bin/buwp-local.js

@@ -27,6 +27,7 @@ import destroyCommand from '../lib/commands/destroy.js';
 import updateCommand from '../lib/commands/update.js';
 import logsCommand from '../lib/commands/logs.js';
 import wpCommand from '../lib/commands/wp.js';
+import watchJobsCommand from '../lib/commands/watch-jobs.js';
 import shellCommand from '../lib/commands/shell.js';
 import configCommand from '../lib/commands/config.js';
 import initCommand from '../lib/commands/init.js';
@@ -66,6 +67,7 @@ program
   .command('update')
   .description('Update Docker images and recreate containers')
   .option('--all', 'Update all service images (default: WordPress only)')
+  .option('--preserve-wpbuild', 'Preserve existing WordPress volume (prevents core file updates)')
   .action(updateCommand);
 
 // Logs command
@@ -107,6 +109,14 @@ program
   .allowUnknownOption()
   .action(wpCommand);
 
+// Watch Jobs command
+program
+  .command('watch-jobs')
+  .description('Watch and automatically process site-manager jobs')
+  .option('--interval <seconds>', `Polling interval in seconds (default: 300, min: 30)`)
+  .option('--quiet', 'Suppress output unless jobs are found')
+  .action(watchJobsCommand);
+
 // Shell command
 program
   .command('shell')

package/docs/ARCHITECTURE.md

@@ -465,16 +465,78 @@ This architecture provides clean boundaries:
 
 | Concern | Location | Update Mechanism |
 |---------|----------|------------------|
-| WordPress core | Docker image | `docker pull` |
-| BU plugins | Docker image | `docker pull` |
-| BU theme | Docker image | `docker pull` |
+| WordPress core | Docker image | `buwp-local update` |
+| BU plugins | Docker image | `buwp-local update` |
+| BU theme | Docker image | `buwp-local update` |
 | **Your plugin** | **Local filesystem** | **Your editor** |
 | **Your theme** | **Local filesystem** | **Your editor** |
-| Database | Docker volume | Persists across updates |
-| Uploads | Docker volume | Persists across updates |
+| Database | Docker volume (db_data) | Persists across updates |
+| **Uploads** | **S3 bucket** | **Via s3proxy** |
 
 Updates to WordPress never touch your development code. Updates to your code never require rebuilding WordPress.
 
+### S3 Upload Architecture
+
+A critical design decision enables safe WordPress core updates: **all media uploads are stored in S3, not in the container filesystem**.
+
+```
+WordPress Upload Flow:
+┌──────────────┐
+│   User       │ Uploads file via WP admin
+└──────┬───────┘
+       │
+       ↓
+┌──────────────────────────────────┐
+│  WordPress Container             │
+│                                  │
+│  BU S3 Uploads Plugin            │
+│  (intercepts upload)             │
+└──────┬───────────────────────────┘
+       │
+       ↓
+┌──────────────────────────────────┐
+│  s3proxy Container               │
+│  (AWS SigV4 authentication)      │
+└──────┬───────────────────────────┘
+       │
+       ↓
+┌──────────────────────────────────┐
+│  S3 Bucket                       │
+│  (permanent storage)             │
+└──────────────────────────────────┘
+```
+
+**Key Configuration** (from `compose-generator.js`):
+
+```javascript
+if (config.services.s3proxy) {
+  wpConfigExtra += "define('S3_UPLOADS_AUTOENABLE', true);\n";
+  wpConfigExtra += "define('S3_UPLOADS_DISABLE_REPLACE_UPLOAD_URL', true);\n";
+}
+```
+
+**What this means for updates:**
+
+The `wp_build` volume contains **zero user data**:
+- ✅ WordPress core files (disposable - from image)
+- ✅ BU plugins/themes (disposable - from image)
+- ❌ **No media uploads** (in S3 bucket)
+- ❌ **No database** (separate db_data volume)
+- ❌ **No custom code** (mapped from host filesystem)
+
+**Result:** The `wp_build` volume is purely infrastructure and can be safely wiped during updates to refresh WordPress core files.
+
+```bash
+# This is safe because:
+# - Database preserved (db_data volume)
+# - Uploads preserved (S3 bucket)  
+# - Your code preserved (local filesystem)
+npx buwp-local update  # Wipes wp_build, recreates from image
+```
+
+**Contrast with traditional WordPress:**
+In a standard WordPress installation, `wp-content/uploads/` contains irreplaceable user media files. In buwp-local, that directory is empty or contains only regenerable thumbnails/cache.
+
 For detailed migration guidance, see [MIGRATION_FROM_VM.md](MIGRATION_FROM_VM.md).
 
 ## Security Model

package/docs/CHANGELOG.md

@@ -5,6 +5,29 @@ All notable changes to buwp-local will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.7.3]
+
+### Added
+- `watch-jobs` command for automatic processing of site-manager jobs at regular intervals
+- Configurable polling interval with `--interval` flag (default: 60 seconds, minimum: 10 seconds), and through `jobWatchInterval` in configuration file
+- `--quiet` flag to suppress routine output for long-running background use
+
+## [0.7.2]
+
+### Breaking Changes
+- **Volume Naming Fix:** Corrected double-prefixing bug in Docker volume names
+  - Old: `projectname_projectname_wp_build`
+  - New: `projectname_wp_build`
+  - **Migration required:** See [Migration Guide](docs/temp-breaking-0-7-2.md)
+
+### Added
+- `buwp-local update` now properly refreshes WordPress core files from new images
+- `--preserve-wpbuild` flag to opt-out of WordPress volume refresh during updates
+
+### Fixed
+- Volume deletion during update now works correctly (containers released first)
+- Docker Compose auto-prefixing no longer causes duplicated volume names
+
 ## [0.7.1]
 
 Documentation only release.

package/docs/COMMANDS.md

@@ -117,7 +117,7 @@ npx buwp-local destroy --force
 
 ### `update`
 
-Update Docker images and recreate containers without losing data.
+Update Docker images and refresh WordPress core files.
 
 ```bash
 npx buwp-local update [options]
@@ -125,33 +125,53 @@ npx buwp-local update [options]
 
 **Options:**
 - `--all` - Update all service images (default: WordPress image only)
+- `--preserve-wpbuild` - Keep existing WordPress volume (prevents core file updates)
 
 **Examples:**
 ```bash
-# Update WordPress image only (recommended)
+# Update WordPress core from new image (recommended)
 npx buwp-local update
 
 # Update all service images (Redis, S3 proxy, etc.)
 npx buwp-local update --all
+
+# Preserve WordPress volume (skip core file refresh)
+npx buwp-local update --preserve-wpbuild
 ```
 
 **What it does:**
 - Checks if environment exists and Docker is running
 - Pulls latest Docker images from registry
-- Recreates containers with new images using `--force-recreate`
+- **Removes wp_build volume** to get fresh WordPress core files (unless `--preserve-wpbuild`)
+- Recreates containers with new images
 - Loads credentials from Keychain and/or `.env.local`
-- **Preserves volumes** - Database and WordPress files untouched
-- Shows success message confirming what was preserved
+- **Always preserves database** (separate volume)
+- **Always preserves custom mapped code** (your local files)
+- **Uploads safe** (stored in S3, not in container)
+
+**What gets updated:**
+- ✅ WordPress core files (wp-admin, wp-includes, core PHP files)
+- ✅ BU plugins and themes bundled in image
+- ✅ PHP/Apache configuration from image
+
+**What's preserved:**
+- ✅ Database content (posts, users, settings) - separate volume
+- ✅ Your custom mapped code - lives on your Mac
+- ✅ Media uploads - stored in S3 bucket
 
 **Use cases:**
-- Pull latest WordPress updates without losing development work
-- Update only WordPress image (typical use case) or all services
-- Safe alternative to `destroy` when you only want to refresh images
+- Get latest WordPress security patches
+- Pull updated BU plugins/themes from new image
+- Test code against newer WordPress version
+- Refresh environment without losing development work
 
-**Key difference from `stop/start`:**
-- `stop` → `start`: Reuses existing containers (no new images)
-- `update`: Pulls new images and recreates containers (gets updates)
-- `destroy`: Removes everything including volumes (fresh start)
+**Key difference from other commands:**
+- `stop` → `start`: Reuses containers and volumes (no updates)
+- `update`: Refreshes WordPress from image, preserves database
+- `destroy`: Removes everything including database (nuclear option)
+
+**Why it's safe:**
+Because buwp-local uses S3 for media uploads (via s3proxy), the WordPress volume contains no user data - only WordPress core and BU infrastructure code. Your custom development code is mapped from your local filesystem and never touched.
 
 ---
 
@@ -401,6 +421,82 @@ npx buwp-local keychain clear [--force]
 
 ---
 
+### `watch-jobs`
+
+Watch for and automatically process site-manager jobs at regular intervals.
+
+```bash
+npx buwp-local watch-jobs [options]
+```
+
+**Options:**
+- `--interval <seconds>` - Polling interval in seconds (default: 60, min: 10)
+- `--quiet` - Suppress all routine output (for long-running background use)
+
+**Examples:**
+```bash
+# Watch with default 1 minute interval
+npx buwp-local watch-jobs
+
+# Watch with custom 2 minute interval
+npx buwp-local watch-jobs --interval 120
+
+# Quiet mode (silent operation, check web UI for job status)
+npx buwp-local watch-jobs --quiet
+
+# Quiet mode with short interval for active monitoring
+npx buwp-local watch-jobs --interval 20 --quiet
+```
+
+**What it does:**
+- Runs `wp site-manager process-jobs` inside the WordPress container at configured intervals
+- **Default mode**: Shows timestamped output for all checks and job results
+- **Quiet mode**: Silently processes jobs (check site-manager web UI for status)
+- Continues running until stopped (Ctrl+C)
+- Mirrors production cron/EventBridge behavior locally
+
+**Use cases:**
+- Automatic processing of jobs created via web UI
+
+**Configuration:**
+
+Optionally configure default interval in `.buwp-local.json`:
+```json
+{
+  "projectName": "my-project",
+  "jobWatchInterval": 200
+}
+```
+
+Command-line `--interval` flag overrides config file setting.
+
+**Requirements:**
+- WordPress container must be running (`start` first)
+- Site-manager plugin must be installed and activated
+
+**Quiet mode behavior:**
+- **Startup**: Shows configuration banner
+- **Routine operation**: Completely silent - no output for checks or job processing
+- **Critical errors**: Shows only failures requiring intervention (Docker stopped, environment missing)
+- **Job status**: Check site-manager plugin web UI to see job results and history
+- **Best for**: Long-running background monitoring (hours/days) without terminal noise
+
+**Error handling:**
+- **Default mode**: Shows all errors and warnings with timestamps
+- **Quiet mode**: Silently retries transient errors (container restarts), only shows critical failures
+- Graceful shutdown on SIGINT/SIGTERM
+
+**Tips:**
+- Run in separate terminal window for visibility
+- Use **default mode** during active development to see what's happening
+- Use **quiet mode** for set-it-and-forget-it background monitoring
+- Reduce interval during active testing (e.g., `--interval 60`)
+- Increase interval for background monitoring (e.g., `--interval 600`)
+
+**⚠️ Note:** This is a development tool. Production environments should continue using cron/AWS EventBridge for job processing.
+
+---
+
 ## Global Options
 
 These options work with all commands:

package/docs/ROADMAP.md

@@ -154,20 +154,69 @@ hostile.remove('127.0.0.1', config.hostname);
 **Focus:** Ease of use and visibility
 
 ### Shipped in v0.7.0
-- **Docker Image Update Command** 🎯 (Proposed for v0.7.0)
-  - **Problem:** Stopping and restarting containers reuses existing images; newer images aren't pulled
-  - **Solution:** Add `buwp-local update` command that:
-    - Pulls latest Docker images from registry
-    - Recreates containers with new images
-    - Preserves volumes (database, WordPress data)
-  - **Benefit:** Safe, explicit way to apply WordPress/service updates without `destroy`
-  - **Implementation:** Wrapper around `docker-compose pull && docker-compose up -d --force-recreate`
+- **Docker Image Update Command** ✅
+  - Pull latest Docker images from registry
+  - Recreate containers with new images
+  - Preserve volumes (database, WordPress data)
+  - Safely apply WordPress and service updates without `destroy`
+  - Implementation: Stop containers, conditionally remove wp_build volume, start with new images
 
 ### Shipped in v0.7.1
 - **Documentation Improvements**
 
+### Shipped in v0.7.2
+- **Volume Naming Fix** ✅
+  - Fixed double-prefixing bug in Docker volume names
+  - Old: `projectname_projectname_wp_build` → New: `projectname_wp_build`
+  - Corrected `compose-generator.js` to use simple names (Docker Compose handles prefixing)
+  - Update command now properly releases volume locks before deletion
+  - Added `--preserve-wpbuild` flag for opt-out of WordPress volume refresh
+
+### Shipped in v0.7.3
+
+- **Job Watcher Command** 🚧
+  - New `watch-jobs` command to periodically run `wp site-manager process-jobs`
+  - Configurable polling interval (default: 5 minutes)
+  - Runs as standalone process in terminal window
+  - Timestamped output for job processing visibility
+  - Graceful shutdown (Ctrl+C)
+  
+  **Problem:** Production environments use cron/AWS EventBridge to automatically process site-manager jobs (content migration, deployments). Local developers currently must manually run `npx buwp-local wp site-manager process-jobs` to see queued jobs complete.
+  
+  **Solution:** Standalone `watch-jobs` command that runs indefinitely, polling for jobs at configurable intervals. Mirrors production behavior without requiring cron setup. Enables developers to use the site-manager web UI for content operations and see jobs complete automatically.
+  
+  **Implementation location:** `lib/commands/watch-jobs.js`
+  
+  **Configuration support:**
+  ```json
+  {
+    "jobWatchInterval": 60  // seconds, default 60 seconds
+  }
+  ```
+  
+  **Command syntax:**
+  ```bash
+  buwp-local watch-jobs [--interval 200] [--quiet]
+  ```
+  
+  **Technical considerations:**
+  - Requires WordPress container to be running
+  - Uses `docker compose exec` to run WP-CLI command
+  - Handles container stop/restart gracefully
+  - Minimal resource usage (sleeps between checks)
+  - Output includes timestamps for audit trail
+  
+  **Future enhancement (v0.8.0+):** If widely adopted, consider adding `--watch-jobs` flag to `start` command for automatic background execution.
+
 ### Potential Features
 
+- **Ability to add custom WORDPRESS_CONFIG_EXTRA environment variables**
+  - Support for adding custom WP config snippets via env vars
+
+- **Credential Export**
+  - Commands to export credentials to JSON file
+  - Useful for migrating between machines or sharing setup
+
 - **Database Security**
   - Check database access on db port (e.g. `localhost:3306`)
   - Consider more stringent default database passwords
@@ -201,9 +250,6 @@ hostile.remove('127.0.0.1', config.hostname);
   - Credential issues → clear next steps
   - Port conflicts → suggest alternatives
 
-- **Multi project experience**
-  - There is a problem when starting a new project when an existing project exists in docker but is stopped. When starting the new project, docker first starts the container for the stopped project for unknown reasons. If the new project uses the same ports, this causes conflicts. Need to investigate and resolve, projects should be isolated and not interfere with each other.
-
 - **Docker Volume management assistant**
   - listing and cleanup of unused volumes
 
@@ -269,6 +315,54 @@ Will be informed by feedback from initial small group of users and actual pain p
 ### Quality
 - Standardized help for all CLI commands
 
+### Code Structure
+
+#### Refactor credential handling to avoid duplication
+Suggested refactor:
+```javascript
+// lib/docker-helpers.js (new file)
+export function prepareDockerComposeEnv(projectPath, projectName) {
+  const credentials = loadKeychainCredentials();
+  let tempEnvPath = null;
+  
+  if (Object.keys(credentials).length > 0) {
+    try {
+      tempEnvPath = createSecureTempEnvFile(credentials, projectName);
+    } catch (err) {
+      console.warn(chalk.yellow(`⚠️  Could not load keychain credentials: ${err.message}`));
+    }
+  }
+  
+  const envFilePath = path.join(projectPath, ENV_FILE_NAME);
+  const envFileFlag = fs.existsSync(envFilePath) ? `--env-file ${envFilePath}` : '';
+  const tempEnvFileFlag = tempEnvPath ? `--env-file ${tempEnvPath}` : '';
+  
+  return {
+    flags: `${tempEnvFileFlag} ${envFileFlag}`.trim(),
+    tempEnvPath,
+    cleanup: () => tempEnvPath && secureDeleteTempEnvFile(tempEnvPath)
+  };
+}
+```
+
+#### Centralize volume naming logic
+
+Suggested refactor:
+```javascript
+// lib/volume-naming.js (new file)
+export function getVolumeNames(projectName) {
+  return {
+    db: `${projectName}_db_data`,
+    wp: `${projectName}_wp_build`
+  };
+}
+
+// Or simpler - just add to config.js
+export function getWpVolumeName(projectName) {
+  return `${projectName}_wp_build`;
+}
+```
+
 ---
 
 ## Decision Framework

package/docs/temp-breaking-0-7-2.md

@@ -0,0 +1,37 @@
+# Temporary Breaking Changes in v0.7.2
+
+Version 0.7.2 unwinds a problem where the project name was being duplicated in the volume names, e.g. `projectname_projectname_wp_build`. This requires a one-time manual migration of your Docker volumes from the old names to the new names.
+
+## Option 1: Simple Destruction and Recreation
+
+If you don't need to preserve your database or any data in your WordPress volume, you can simply destroy and recreate your environment:
+
+```bash
+npx buwp-local destroy
+npx buwp-local start
+```
+
+## Manual Migration Steps
+
+If you want to preserve your database and WordPress volume, follow these steps to rename your Docker volumes:
+
+```bash
+# Stop environment
+npx buwp-local stop
+
+# Rename volumes manually
+docker volume create projectname_db_data
+docker volume create projectname_wp_build
+
+# Copy data from old to new
+docker run --rm -v projectname_projectname_db_data:/from -v projectname_db_data:/to alpine ash -c "cd /from && cp -av . /to"
+docker run --rm -v projectname_projectname_wp_build:/from -v projectname_wp_build:/to alpine ash -c "cd /from && cp -av . /to"
+
+# Update buwp-local and start
+npm update @bostonuniversity/buwp-local
+npx buwp-local start
+
+# Verify, then remove old volumes
+docker volume rm projectname_projectname_db_data projectname_projectname_wp_build
+
+```

package/lib/commands/update.js

@@ -57,9 +57,52 @@ async function updateCommand(options = {}) {
       process.exit(1);
     }
 
-    // Step 2: Recreate containers with new images (preserves volumes)
+    // Step 2: Stop and remove containers to ensure new images are used
+    // Note: We use 'down' without -v flag to preserve all volumes
+    console.log(chalk.cyan('\n🛑 Stopping containers...'));
+    try {
+      // Remove containers but preserve volumes (no -v flag)
+      execSync(
+        `docker compose -p ${projectName} -f "${composePath}" down`,
+        { 
+          cwd: composeDir,
+          stdio: 'inherit'
+        }
+      );
+    } catch (err) {
+      console.error(chalk.red('\n❌ Failed to stop containers'));
+      process.exit(1);
+    }
+
+    // Step 3: Conditionally remove wp_build volume to get fresh WordPress core
+    const preserveWpBuild = options.preserveWpbuild || false;
+    
+    if (!preserveWpBuild) {
+      // Docker Compose prefixes volume names with project name
+      const wpVolumeName = `${projectName}_wp_build`;
+      
+      console.log(chalk.cyan('\n🗑️  Removing WordPress volume to get fresh core files...'));
+      try {
+        execSync(
+          `docker volume rm ${wpVolumeName}`,
+          { 
+            cwd: composeDir,
+            stdio: 'ignore'
+          }
+        );
+        console.log(chalk.green('✓ WordPress volume removed\n'));
+      } catch (err) {
+        // Volume might not exist - that's okay
+        console.log(chalk.yellow('⚠️  WordPress volume not found (will be created fresh)\n'));
+      }
+    } else {
+      console.log(chalk.yellow('\n⚠️  Preserving existing WordPress volume'));
+      console.log(chalk.gray('WordPress core files will NOT be updated from the image.\n'));
+    }
+
+    // Step 4: Start containers with new images
     // Need to pass environment variables just like start command does
-    console.log(chalk.cyan('\n🔨 Recreating containers with new images...'));
+    console.log(chalk.cyan('🔨 Starting containers with new images...'));
     
     // Load keychain credentials and create secure temp env file if available
     let tempEnvPath = null;
@@ -80,14 +123,14 @@ async function updateCommand(options = {}) {
     
     try {
       execSync(
-        `docker compose -p ${projectName} ${tempEnvFileFlag} ${envFileFlag} -f "${composePath}" up -d --force-recreate`,
+        `docker compose -p ${projectName} ${tempEnvFileFlag} ${envFileFlag} -f "${composePath}" up -d`,
         {
           cwd: composeDir,
           stdio: 'inherit'
         }
       );
     } catch (err) {
-      console.error(chalk.red('\n❌ Failed to recreate containers'));
+      console.error(chalk.red('\n❌ Failed to start containers'));
       process.exit(1);
     } finally {
       // Always clean up temp env file
@@ -98,9 +141,17 @@ async function updateCommand(options = {}) {
 
     // Success message
     console.log(chalk.green('\n✅ Update complete!\n'));
-    console.log(chalk.gray('Preserved:'));
-    console.log(chalk.gray('  ✓ Database and WordPress data'));
-    console.log(chalk.gray('  ✓ Volume mappings and configuration\n'));
+    
+    if (!preserveWpBuild) {
+      console.log(chalk.cyan('Updated:'));
+      console.log(chalk.gray('  ✓ WordPress core files (from new image)'));
+      console.log(chalk.gray('  ✓ BU plugins and themes (from new image)\n'));
+    }
+    
+    console.log(chalk.cyan('Preserved:'));
+    console.log(chalk.gray('  ✓ Database (all content and settings)'));
+    console.log(chalk.gray('  ✓ Custom mapped code (your local files)'));
+    console.log(chalk.gray('  ✓ Uploads (stored in S3)\n'));
     console.log(chalk.cyan('Access your site at:'));
     console.log(chalk.white(`  https://${config.hostname}\n`));
 

package/lib/commands/watch-jobs.js

@@ -0,0 +1,192 @@
+/**
+ * Watch Jobs command - Periodically process site-manager jobs
+ * Mirrors production cron/EventBridge behavior for local development
+ */
+
+import chalk from 'chalk';
+import { execSync, exec } from 'child_process';
+import path from 'path';
+import fs from 'fs';
+import { loadConfig } from '../config.js';
+
+const DEFAULT_INTERVAL = 60; // 1 minute in seconds
+const MIN_INTERVAL = 10; // Minimum 10 seconds
+
+/**
+ * Format timestamp for log output
+ */
+function timestamp() {
+  const now = new Date();
+  return now.toLocaleString('en-US', {
+    year: 'numeric',
+    month: '2-digit',
+    day: '2-digit',
+    hour: '2-digit',
+    minute: '2-digit',
+    second: '2-digit',
+    hour12: false
+  }).replace(',', '');
+}
+
+/**
+ * Check if container is running
+ */
+function isContainerRunning(projectName, composePath) {
+  try {
+    const result = execSync(
+      `docker compose -p ${projectName} -f "${composePath}" ps --status running --services`,
+      { encoding: 'utf8', stdio: ['pipe', 'pipe', 'ignore'] }
+    );
+    return result.includes('wordpress');
+  } catch (err) {
+    return false;
+  }
+}
+
+/**
+ * Process site-manager jobs
+ */
+async function processJobs(projectName, composePath, quiet) {
+  return new Promise((resolve) => {
+    const composeDir = path.dirname(composePath);
+    const command = `docker compose -p ${projectName} -f "${composePath}" exec -T wordpress wp site-manager process-jobs`;
+
+    if (!quiet) {
+      console.log(chalk.gray(`[${timestamp()}] Checking for jobs...`));
+    }
+
+    exec(command, { cwd: composeDir }, (error, stdout, stderr) => {
+      if (error) {
+        // In quiet mode, silently retry on transient errors (container might restart)
+        // Only verbose mode shows these errors
+        if (!quiet) {
+          if (stderr.includes('container') || stderr.includes('not running')) {
+            console.log(chalk.yellow(`[${timestamp()}] ⚠️  Container not running. Waiting...`));
+          } else {
+            console.log(chalk.red(`[${timestamp()}] ❌ Error executing command:`));
+            console.log(chalk.red(stderr || error.message));
+          }
+        }
+        resolve(false);
+        return;
+      }
+
+      const output = stdout.trim();
+      
+      // Check if jobs were found and processed
+      if (output && output.length > 0) {
+        // In quiet mode, suppress all output (user checks web UI for job status)
+        // In verbose mode, show full job output
+        if (!quiet) {
+          console.log(chalk.green(`[${timestamp()}] ✓ Processing jobs:`));
+          console.log(output);
+        }
+        resolve(true);
+      } else if (!quiet) {
+        // No jobs found - only show in verbose mode
+        console.log(chalk.gray(`[${timestamp()}] No jobs found.`));
+        resolve(false);
+      } else {
+        // Quiet mode and no jobs - silent
+        resolve(false);
+      }
+    });
+  });
+}
+
+/**
+ * Watch jobs command
+ */
+async function watchJobsCommand(options) {
+  try {
+    const projectPath = process.cwd();
+    const composePath = path.join(projectPath, '.buwp-local', 'docker-compose.yml');
+
+    // Check if docker-compose.yml exists
+    if (!fs.existsSync(composePath)) {
+      console.log(chalk.yellow('⚠️  No running environment found.'));
+      console.log(chalk.gray('Run "buwp-local start" to create an environment.\n'));
+      return;
+    }
+
+    // Load config to get project name and optional interval setting
+    const config = loadConfig(projectPath);
+    const projectName = config.projectName || 'buwp-local';
+
+    // Determine interval (priority: CLI flag > config file > default)
+    let interval = DEFAULT_INTERVAL;
+    if (options.interval) {
+      interval = parseInt(options.interval, 10);
+      if (isNaN(interval) || interval < MIN_INTERVAL) {
+        console.log(chalk.red(`❌ Invalid interval. Minimum is ${MIN_INTERVAL} seconds.`));
+        process.exit(1);
+      }
+    } else if (config.jobWatchInterval) {
+      interval = config.jobWatchInterval;
+      if (interval < MIN_INTERVAL) {
+        console.log(chalk.yellow(`⚠️  Config interval too low. Using minimum: ${MIN_INTERVAL}s`));
+        interval = MIN_INTERVAL;
+      }
+    }
+
+    const quiet = options.quiet || false;
+
+    // Check if Docker is running
+    try {
+      execSync('docker info', { stdio: 'ignore' });
+    } catch (err) {
+      console.error(chalk.red('❌ Docker is not running.'));
+      console.log(chalk.gray('Start Docker Desktop and try again.'));
+      process.exit(1);
+    }
+
+    // Check if container is running initially
+    if (!isContainerRunning(projectName, composePath)) {
+      console.log(chalk.yellow('⚠️  WordPress container is not running.'));
+      console.log(chalk.gray('Run "buwp-local start" first, then try again.\n'));
+      return;
+    }
+
+    // Display startup message
+    console.log(chalk.cyan('🔍 Watching for site-manager jobs...'));
+    console.log(chalk.gray(`   Interval: ${interval}s`));
+    console.log(chalk.gray(`   Project: ${projectName}`));
+    console.log(chalk.gray(`   Mode: ${quiet ? 'quiet' : 'verbose'}`));
+    console.log(chalk.gray('\nPress Ctrl+C to stop\n'));
+
+    // Set up graceful shutdown
+    let isShuttingDown = false;
+    const shutdown = () => {
+      if (isShuttingDown) return;
+      isShuttingDown = true;
+      console.log(chalk.cyan('\n\n👋 Stopping job watcher...'));
+      process.exit(0);
+    };
+
+    process.on('SIGINT', shutdown);
+    process.on('SIGTERM', shutdown);
+
+    // Main watch loop
+    const watch = async () => {
+      // Check if we should stop
+      if (isShuttingDown) return;
+
+      // Process jobs
+      await processJobs(projectName, composePath, quiet);
+
+      // Schedule next check
+      if (!isShuttingDown) {
+        setTimeout(watch, interval * 1000);
+      }
+    };
+
+    // Start watching
+    await watch();
+
+  } catch (err) {
+    console.error(chalk.red('\n❌ Error:'), err.message);
+    process.exit(1);
+  }
+}
+
+export default watchJobsCommand;

package/lib/compose-generator.js

@@ -13,10 +13,9 @@ import path from 'path';
  * @returns {object} Docker Compose configuration object
  */
 function generateComposeConfig(config) {
-  // Use project name for unique volume naming
-  const projectName = config.projectName || 'buwp-local';
-  const dbVolumeName = `${projectName}_db_data`;
-  const wpVolumeName = `${projectName}_wp_build`;
+  // Volume names without project prefix - Docker Compose will add the prefix automatically
+  const dbVolumeName = 'db_data';
+  const wpVolumeName = 'wp_build';
 
   const composeConfig = {
     services: {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bostonuniversity/buwp-local",
-  "version": "0.7.1",
+  "version": "0.7.3",
   "description": "Local WordPress development environment for Boston University projects",
   "type": "module",
   "main": "lib/index.js",