From cf085eb2cf008a1670f6db5d31cdffde0477dd4b Mon Sep 17 00:00:00 2001
From: Hein van Vlastuin <hein@obox.co.za>
Date: Thu, 4 Sep 2025 14:11:01 +0200
Subject: [PATCH 1/3] Clone release workflow

---
 .github/BUILD-ACTION-COMPARISON.md            | 247 +++++++++++
 .github/BUILD-COMPATIBILITY-ANALYSIS.md       | 297 +++++++++++++
 .github/CLONE-RELEASE-PREPARATION.md          | 392 ++++++++++++++++++
 .../CRITICAL-QUESTIONS-FOR-IMPLEMENTATION.md  | 383 +++++++++++++++++
 .../actions/build-theme-release/action.yml    |  72 ++++
 .../bump-theme-version-release/action.yml     | 164 ++++++++
 .../action.yml                                |  40 ++
 .../create-theme-release-release/action.yml   |  68 +++
 .../action.yml                                |  33 ++
 .../install-dependencies-release/action.yml   |  49 +++
 .../action.yml                                | 144 +++++++
 .../action.yml                                | 249 +++++++++++
 .../generate-upload-instructions-release.sh   |  69 +++
 .../get-changelog-from-readme-release.js      |  88 ++++
 .github/scripts/validate-versions-release.sh  |  70 ++++
 .github/workflows/release-preparation.yml     | 350 ++++++++++++++++
 16 files changed, 2715 insertions(+)
 create mode 100644 .github/BUILD-ACTION-COMPARISON.md
 create mode 100644 .github/BUILD-COMPATIBILITY-ANALYSIS.md
 create mode 100644 .github/CLONE-RELEASE-PREPARATION.md
 create mode 100644 .github/CRITICAL-QUESTIONS-FOR-IMPLEMENTATION.md
 create mode 100644 .github/actions/build-theme-release/action.yml
 create mode 100644 .github/actions/bump-theme-version-release/action.yml
 create mode 100644 .github/actions/create-pr-with-bumped-theme-version-release/action.yml
 create mode 100644 .github/actions/create-theme-release-release/action.yml
 create mode 100644 .github/actions/get-changelog-from-readme-release/action.yml
 create mode 100644 .github/actions/install-dependencies-release/action.yml
 create mode 100644 .github/actions/theme-slack-notification-release/action.yml
 create mode 100644 .github/actions/update-main-branch-version-release/action.yml
 create mode 100755 .github/scripts/generate-upload-instructions-release.sh
 create mode 100644 .github/scripts/get-changelog-from-readme-release.js
 create mode 100755 .github/scripts/validate-versions-release.sh
 create mode 100644 .github/workflows/release-preparation.yml

diff --git a/.github/BUILD-ACTION-COMPARISON.md b/.github/BUILD-ACTION-COMPARISON.md
new file mode 100644
index 00000000..d09e7f31
--- /dev/null
+++ b/.github/BUILD-ACTION-COMPARISON.md
@@ -0,0 +1,247 @@
+# Build Action Detailed Comparison
+# Hello Commerce vs Hello Theme
+
+## Overview
+This document provides a line-by-line comparison of the build-theme actions from both repositories to inform the decision on which approach to use.
+
+## Current Build Actions
+
+### Hello Theme Build Action Features
+**File:** `.github/workflows/build-theme/action.yml` (120 lines)
+
+#### Key Features:
+- **Sophisticated npm retry logic** with 3 attempts
+- **Multiple fallback strategies**:
+  - Primary: `npm ci --prefer-offline`
+  - Fallback 1: `npm install --legacy-peer-deps`  
+  - Fallback 2: Public registry explicitly
+  - Fallback 3: Install without package-lock
+- **Advanced error handling** with cache clearing
+- **Registry fallback mechanisms**
+- **Detailed logging** for debugging
+
+#### Build Process:
+```yaml
+- Install npm dependencies (with retry logic)
+- Install composer dependencies  
+- Set package version
+- Run build script (npm run build:prod by default)
+- Create theme build directory (/tmp/hello-theme-builds)
+- Package theme (hello-elementor-${VERSION}.zip)
+- Move to workspace
+```
+
+### Hello Commerce Build Action Features  
+**File:** `.github/workflows/build-theme/action.yml` (68 lines)
+
+#### Key Features:
+- **Simple npm installation** with single attempt
+- **Basic error handling**  
+- **Straightforward approach**
+- **Minimal logging**
+
+#### Build Process:
+```yaml
+- Install npm dependencies (npm ci only)
+- Install composer dependencies
+- Set package version  
+- Run build script (npm run build by default)
+- Create theme build directory (/tmp/hello-commerce-builds)
+- Package theme (hello-commerce-${VERSION}.zip)
+- Move to workspace
+```
+
+## Detailed Feature Comparison
+
+| Feature | Hello Theme | Hello Commerce | Advantage |
+|---------|-------------|----------------|-----------|
+| **NPM Installation Retries** | 3 attempts with exponential backoff | 1 attempt only | 🏆 Hello Theme |
+| **Registry Fallbacks** | 4 different strategies | None | 🏆 Hello Theme |
+| **Error Handling** | Comprehensive error recovery | Basic error handling | 🏆 Hello Theme |
+| **Cache Management** | Automatic cache clearing on failure | None | 🏆 Hello Theme |
+| **Logging Detail** | Verbose logging for debugging | Minimal logging | 🏆 Hello Theme |
+| **Code Complexity** | 120 lines (more complex) | 68 lines (simpler) | 🏆 Hello Commerce |
+| **Maintenance** | More complex to maintain | Easier to maintain | 🏆 Hello Commerce |
+| **Build Reliability** | Higher (due to retry logic) | Lower (single attempt) | 🏆 Hello Theme |
+
+## NPM Installation Logic Comparison
+
+### Hello Theme Approach
+```yaml
+# Enhanced retry logic for npm ci with registry fallbacks and cache clearing
+for i in {1..3}; do
+  echo "🔄 Attempt $i/3: Installing npm dependencies..."
+  
+  # Try npm ci first
+  if npm ci --prefer-offline --no-audit --no-fund --silent; then
+    echo "✅ npm ci succeeded on attempt $i"
+    break
+  else
+    echo "❌ npm ci failed on attempt $i"
+    
+    # Check if it's a 403/registry error and clear cache
+    if [ $i -lt 3 ]; then
+      echo "🧹 Clearing npm cache to resolve potential registry issues..."
+      npm cache clean --force 2>/dev/null || true
+      echo "⏳ Waiting 30 seconds before retry..."
+      sleep 30
+    else
+      # Multiple fallback strategies...
+      # Fallback 1: npm install --legacy-peer-deps
+      # Fallback 2: NPM_CONFIG_REGISTRY=https://registry.npmjs.org/
+      # Fallback 3: Install without package-lock.json
+    fi
+  fi
+done
+```
+
+### Hello Commerce Approach
+```yaml
+- name: Install npm dependencies
+  shell: bash
+  run: |
+    export PUPPETEER_SKIP_DOWNLOAD=true
+    npm ci
+```
+
+## Package Creation Comparison
+
+### Hello Theme
+```yaml
+# Create zip file with proper naming (following Hello Commerce pattern)
+zip -r "/tmp/hello-theme-builds/hello-elementor-${PACKAGE_VERSION}.zip" . \
+  -x "node_modules/*" "test-results/*" "tests/*" ".git/*" "*.zip" \
+     "playwright-report/*" ".wp-env.json.*" ".wp-env"
+```
+
+### Hello Commerce
+```yaml
+# Create zip file with proper naming
+zip -r "/tmp/hello-commerce-builds/hello-commerce-${PACKAGE_VERSION}.zip" . \
+  -x "node_modules/*" "test-results/*" "tests/*" ".git/*" "*.zip" \
+     "playwright-report/*" ".wp-env.json.*" ".wp-env"
+```
+
+**Identical exclusion patterns - no compatibility issues**
+
+## Performance Analysis
+
+### Hello Theme Build Action
+**Pros:**
+- ✅ High reliability due to retry logic
+- ✅ Handles network issues gracefully
+- ✅ Comprehensive error recovery
+- ✅ Production-tested in hello-theme repository
+- ✅ Better for CI/CD environments with network instability
+
+**Cons:**
+- ❌ More complex code to maintain
+- ❌ Longer execution time (due to retries)
+- ❌ More verbose output
+- ❌ Higher complexity for debugging
+
+### Hello Commerce Build Action
+**Pros:**  
+- ✅ Simple and straightforward
+- ✅ Faster execution (no retries)
+- ✅ Easy to understand and maintain
+- ✅ Less verbose output
+
+**Cons:**
+- ❌ Can fail on transient network issues
+- ❌ No fallback strategies
+- ❌ Less reliable in unstable environments
+- ❌ May require manual intervention on failures
+
+## Recommendation Analysis
+
+### Technical Recommendation: **Use Hello Theme's Build Action**
+
+**Rationale:**
+1. **Higher Reliability** - The retry logic and fallback strategies make builds more reliable in CI/CD environments
+2. **Production Proven** - Already tested and working in Hello Theme production environment
+3. **Future Proof** - Handles edge cases that Hello Commerce might encounter as it scales
+4. **Error Recovery** - Automatic recovery from transient failures reduces manual intervention
+
+### Adaptation Required:
+```yaml
+# Changes needed for Hello Commerce integration:
+1. Update temp directory: /tmp/hello-theme-builds → /tmp/hello-commerce-builds  
+2. Update package naming: hello-elementor-${VERSION} → hello-commerce-${VERSION}
+3. Update default build script: npm run build:prod → npm run build
+```
+
+## Integration Strategy
+
+### Phase 1: Direct Copy with Adaptations
+```yaml
+# Copy Hello Theme's build action to Hello Commerce
+# Update these variables:
+- TEMP_DIR: "/tmp/hello-commerce-builds"
+- ZIP_NAME: "hello-commerce-${PACKAGE_VERSION}.zip"  
+- DEFAULT_BUILD_SCRIPT: "npm run build"
+```
+
+### Phase 2: Optional Enhancements
+```yaml
+# Consider these improvements:
+1. Make retry count configurable (input parameter)
+2. Add option to disable retry logic for simple builds
+3. Add build timing metrics
+4. Enhance error reporting
+```
+
+### Phase 3: Standardization
+```yaml
+# Long term: Standardize across all theme repositories
+1. Create shared build action in common repository
+2. Use consistent naming patterns
+3. Share retry/fallback logic across all themes
+```
+
+## Testing Requirements
+
+### Build Action Testing Checklist
+- [ ] Test with Hello Commerce dependencies
+- [ ] Test retry logic with simulated network failures
+- [ ] Test fallback strategies
+- [ ] Verify package naming changes
+- [ ] Validate temp directory creation
+- [ ] Test with both npm ci and npm install scenarios
+- [ ] Verify exclusion patterns work correctly
+- [ ] Test error recovery mechanisms
+
+### Performance Testing
+- [ ] Compare build times with and without retry logic
+- [ ] Test memory usage during build
+- [ ] Validate artifact size and contents
+- [ ] Test concurrent build scenarios
+
+## Risk Assessment
+
+### Low Risk Changes
+- ✅ Package naming updates
+- ✅ Temp directory path changes  
+- ✅ Build script parameter changes
+
+### Medium Risk Changes
+- 🟡 Retry logic integration
+- 🟡 Error handling adaptation
+- 🟡 Fallback strategy testing
+
+### High Risk Areas
+- 🔴 NPM dependency compatibility with Hello Commerce packages
+- 🔴 Registry fallback behavior in Hello Commerce environment
+- 🔴 Build timing impact on overall workflow duration
+
+## Conclusion
+
+**Hello Theme's build action is superior** due to its comprehensive error handling and retry mechanisms. The additional complexity is justified by the increased reliability, especially in CI/CD environments where network issues are common.
+
+**Recommended Approach:**
+1. **Adopt Hello Theme's build action** as the base
+2. **Customize** for Hello Commerce naming and paths  
+3. **Test thoroughly** with Hello Commerce specific scenarios
+4. **Consider standardizing** across all theme repositories
+
+This approach ensures maximum build reliability while maintaining the proven functionality that Hello Theme has already validated in production.
diff --git a/.github/BUILD-COMPATIBILITY-ANALYSIS.md b/.github/BUILD-COMPATIBILITY-ANALYSIS.md
new file mode 100644
index 00000000..e44d4b34
--- /dev/null
+++ b/.github/BUILD-COMPATIBILITY-ANALYSIS.md
@@ -0,0 +1,297 @@
+# Build Process Compatibility Analysis
+# Hello Commerce vs Hello Theme
+
+## Executive Summary
+
+This document provides a detailed technical comparison of the build processes, version management, and workflow structures between Hello Commerce and Hello Theme. This analysis is critical for ensuring successful cloning of the release-preparation workflow.
+
+## 1. Build Process Comparison
+
+### Package.json Scripts Comparison
+
+| Feature | Hello Commerce | Hello Theme | Compatibility Risk |
+|---------|----------------|-------------|-------------------|
+| **Main Build** | `"build"` | `"build:prod"` | 🟡 MEDIUM - Script name different |
+| **Clean Command** | `"clean"` | `"clean:build"` | 🟡 MEDIUM - Script name different |
+| **Package Command** | `"package:zip"` | `"zip"` | 🟡 MEDIUM - Script name different |
+| **Build Tools** | `npx wp-scripts build` | `wp-scripts build` | 🟢 LOW - Both use wp-scripts |
+| **Composer** | `--no-dev` | `--no-dev` | ✅ IDENTICAL |
+
+### Build Action Comparison
+
+#### Hello Theme Build Action Features
+```yaml
+# Sophisticated npm retry logic:
+- 3 retry attempts with exponential backoff
+- Multiple fallback strategies (npm install, public registry, no-lock)
+- Advanced error handling and cache clearing
+- Registry fallback mechanisms
+
+# Package naming:
+- Creates: hello-elementor-${VERSION}.zip
+- Uses sophisticated exclusion patterns
+- Temp directory: /tmp/hello-theme-builds
+```
+
+#### Hello Commerce Build Action Features
+```yaml
+# Simpler npm installation:
+- Single npm ci attempt
+- Basic error handling
+- No retry logic or fallbacks
+
+# Package naming:
+- Creates: hello-commerce-${VERSION}.zip  
+- Similar exclusion patterns
+- Temp directory: /tmp/hello-commerce-builds
+```
+
+**RECOMMENDATION:** 🚨 **KEEP Hello Theme's Build Action** - It has superior error handling and retry logic that would benefit the release workflow.
+
+## 2. Version Management Comparison
+
+### Current Version Constants
+
+| Repository | Constant Name | Current Version | Location |
+|------------|---------------|----------------|----------|
+| Hello Commerce | `HELLO_COMMERCE_ELEMENTOR_VERSION` | `1.0.1` | functions.php:14 |
+| Hello Theme | `HELLO_ELEMENTOR_VERSION` | `3.4.4` | functions.php:12 |
+
+### Version Management Scripts
+
+#### Hello Theme Approach (JavaScript)
+```javascript
+// .github/scripts/update-version-in-files.js
+// Updates:
+- ./assets/scss/style.scss (Version: and Stable tag:)
+- ./functions.php (HELLO_ELEMENTOR_VERSION)  
+- ./readme.txt (Version: and Stable tag:)
+
+// Uses replace-in-file package
+// Regex-based replacements
+```
+
+#### Hello Commerce Approach (Bash)  
+```bash
+# .github/actions/bump-theme-version/action.yml
+# Updates:
+- package.json (npm version command)
+- functions.php (sed replacement)
+- style.css (sed replacement) 
+- readme.txt (sed replacement)
+
+# Uses sed commands
+# More granular error handling per file
+```
+
+**KEY DIFFERENCE:** 🚨 Hello Theme updates `assets/scss/style.scss` while Hello Commerce updates `style.css`
+
+### Version Validation Scripts
+
+#### Hello Commerce: validate-versions.sh
+```bash
+# Validates consistency between:
+- package.json version
+- functions.php HELLO_COMMERCE_ELEMENTOR_VERSION
+- style.css Version header
+- readme.txt Stable tag
+
+# Uses grep and awk for extraction
+# Exits with error on mismatch
+```
+
+#### Hello Theme: No equivalent script
+**NEEDS TO BE CREATED** with Hello Theme specific patterns.
+
+## 3. File Structure Differences
+
+### Theme Naming Conventions
+
+| Repository | Theme Name in Files | Package Name | Zip Filename |
+|------------|-------------------|---------------|--------------|
+| Hello Commerce | "Hello Commerce" | hello-commerce | hello-commerce-{version}.zip |
+| Hello Theme | "Hello Elementor" | hello-elementor | hello-elementor-{version}.zip |
+
+**⚠️ CRITICAL:** Repository is `hello-theme` but theme name is `Hello Elementor`
+
+### Build Artifacts
+
+| Repository | Primary CSS | Secondary CSS | Build Output |
+|------------|-------------|---------------|--------------|
+| Hello Commerce | style.css | assets/css/* | Single zip |
+| Hello Theme | style.css | assets/css/* + assets/scss/* | Single zip |
+
+**Hello Theme has additional SCSS source files that may need version management**
+
+## 4. Dependency Comparison
+
+### Node Dependencies Analysis
+
+#### Hello Theme Unique Dependencies
+```json
+{
+  "@wordpress/components": "^29.9.0",
+  "@wordpress/env": "^10.26.0", 
+  "@wordpress/i18n": "^5.23.0",
+  "@wordpress/notices": "^5.23.0",
+  "@elementor/wp-lite-env": "^0.0.20",
+  "sass": "^1.89.0"  // SCSS compilation
+}
+```
+
+#### Hello Commerce Unique Dependencies
+```json
+{
+  "composer": "^4.1.0",
+  "prettier": "^3.6.2",
+  "path": "^0.12.7",
+  "eslint-import-resolver-typescript": "^3.10.1"
+}
+```
+
+**BUILD IMPACT:** 🟡 Hello Theme has SCSS compilation requirements that Hello Commerce lacks.
+
+### Composer Dependencies
+Both repositories use similar PHP dependencies - no significant compatibility issues expected.
+
+## 5. Workflow Integration Points
+
+### Existing Hello Theme Workflows
+
+| Workflow | Purpose | Status | Action Required |
+|----------|---------|---------|-----------------|
+| publish-release.yml | Legacy release process | 🟡 ACTIVE | Decide: Replace/Coexist/Deprecate |
+| publish-patch.yml | Patch releases | 🟡 ACTIVE | Decide: Replace/Coexist/Deprecate |  
+| publish-beta.yml | Beta releases | 🟡 ACTIVE | Decide: Replace/Coexist/Deprecate |
+| build.yml | Build testing | ✅ COMPATIBLE | Keep as-is |
+
+### Secrets Requirements
+
+| Secret | Hello Commerce | Hello Theme | Status |
+|--------|---------------|-------------|---------|
+| DEVOPS_TOKEN | ✅ Required | ❓ Unknown | Needs verification |
+| CLOUD_DEVOPS_TOKEN | ✅ Required | ❓ Unknown | Needs verification |
+| SLACK_BOT_TOKEN | ✅ Required | ❓ Unknown | Needs verification |
+| MAINTAIN_TOKEN | ❌ Not used | ✅ Used in legacy workflows | Different approach |
+
+## 6. Critical Adaptation Requirements
+
+### High Priority (Must Fix)
+
+1. **Version Constant Renaming**
+   ```bash
+   # In all scripts and actions:
+   HELLO_COMMERCE_ELEMENTOR_VERSION → HELLO_ELEMENTOR_VERSION
+   ```
+
+2. **Build Script Integration**
+   ```yaml
+   # Adapt hello-commerce workflow to use:
+   BUILD_SCRIPT_PATH: "npm run zip"  # Instead of "npm run package:zip"
+   ```
+
+3. **Package Naming**
+   ```bash
+   # Update all references:
+   hello-commerce-{version}.zip → hello-elementor-{version}.zip
+   /tmp/hello-commerce-builds/ → /tmp/hello-elementor-builds/
+   ```
+
+4. **SCSS File Handling**
+   ```javascript
+   // Ensure assets/scss/style.scss version is updated
+   // Either adapt bash scripts or keep JS approach
+   ```
+
+### Medium Priority (Should Fix)
+
+5. **Repository References**
+   ```yaml
+   # Update all references:
+   elementor/hello-commerce → elementor/hello-theme
+   ```
+
+6. **Legacy Workflow Strategy**
+   - Document migration path from publish-*.yml workflows
+   - Provide clear guidance on which workflow to use
+
+### Low Priority (Nice to Have)
+
+7. **Build Action Enhancement**
+   - Consider adopting Hello Theme's superior retry logic in hello-commerce
+   - Standardize error handling across all theme repositories
+
+## 7. Integration Testing Requirements
+
+### Build Compatibility Tests
+```bash
+# Test these specific scenarios:
+1. npm ci with Hello Theme's complex dependencies
+2. SCSS compilation during build
+3. Version management across all files (including SCSS)
+4. Package creation with correct naming
+5. Build artifact validation
+```
+
+### Version Management Tests
+```bash
+# Test these version update scenarios:
+1. package.json → functions.php sync
+2. package.json → style.css sync  
+3. package.json → readme.txt sync
+4. package.json → assets/scss/style.scss sync (Hello Theme specific)
+```
+
+### Workflow Coexistence Tests
+```bash
+# Test these integration scenarios:
+1. New release-preparation.yml alongside existing workflows
+2. Secret sharing between workflows
+3. Build artifact naming conflicts
+4. Git branch management compatibility
+```
+
+## 8. Recommended Integration Approach
+
+### Phase 1: Direct Adaptation (Low Risk)
+1. Copy GitHub actions with name/constant changes
+2. Copy scripts with Hello Theme specific adaptations
+3. Copy main workflow with repository references updated
+
+### Phase 2: Build Process Integration (Medium Risk) 
+1. Adapt workflow to use Hello Theme's build-theme action
+2. Integrate SCSS version management
+3. Test build compatibility thoroughly
+
+### Phase 3: Legacy Workflow Migration (High Risk)
+1. Document new workflow usage
+2. Plan deprecation of legacy workflows  
+3. Train team on new process
+
+## 9. Success Criteria
+
+### Technical Success
+- [ ] All version files stay synchronized (including SCSS)
+- [ ] Build process produces correct hello-elementor-{version}.zip
+- [ ] No conflicts with existing workflows
+- [ ] All Hello Theme specific dependencies handled correctly
+
+### Process Success  
+- [ ] Team can successfully use new release workflow
+- [ ] Clear documentation for migration from legacy workflows
+- [ ] Rollback plan available if issues arise
+
+## 10. Risk Mitigation
+
+### High Risk: Build Process Differences
+**Mitigation:** Extensive testing with dry_run mode, keep Hello Theme's proven build-theme action
+
+### Medium Risk: Version Management Integration
+**Mitigation:** Thorough validation scripts, test all file updates
+
+### Low Risk: Legacy Workflow Conflicts
+**Mitigation:** Clear documentation, staged rollout approach
+
+---
+
+*This analysis provides the technical foundation for successful Hello Commerce to Hello Theme workflow migration. All identified differences must be addressed for successful implementation.*
diff --git a/.github/CLONE-RELEASE-PREPARATION.md b/.github/CLONE-RELEASE-PREPARATION.md
new file mode 100644
index 00000000..afe79568
--- /dev/null
+++ b/.github/CLONE-RELEASE-PREPARATION.md
@@ -0,0 +1,392 @@
+# Product Requirements Document (PRD)
+# Cloning Release Preparation Workflow from Hello Commerce to Hello Theme
+
+## Executive Summary
+
+This document outlines the requirements for cloning the `release-preparation.yml` workflow from `hello-commerce` to `hello-theme`. The workflow automates version bumping, building, GitHub release creation, and notification processes for theme releases. This implementation follows the same systematic approach used for Hello Biz, with specific adaptations for Hello Theme's unique requirements.
+
+## Current State Analysis
+
+### What Already Exists in Hello Theme
+- ✅ `.github/config/release.json` - Pre-configured for hello-elementor
+- ✅ `.github/workflows/build-theme/action.yml` - Custom build action (NEEDS COMPARISON)
+- ✅ Legacy release workflows: publish-release.yml, publish-patch.yml, publish-beta.yml  
+- ✅ Existing version management scripts: update-version-in-files.js
+- ✅ Build workflow with npm/composer integration
+- ✅ Package.json with proper scripts (different from hello-commerce)
+
+### What Needs to Be Created/Adapted
+
+#### Required GitHub Actions (8 total)
+1. **`.github/actions/install-dependencies/action.yml`** - Dependency installation
+2. **`.github/actions/bump-theme-version/action.yml`** - Version bumping in multiple files  
+3. **`.github/actions/get-changelog-from-readme/action.yml`** - Changelog extraction
+4. **`.github/actions/create-pr-with-bumped-theme-version/action.yml`** - PR creation
+5. **`.github/actions/update-main-branch-version/action.yml`** - Main branch version sync
+6. **`.github/actions/theme-slack-notification/action.yml`** - Slack notifications
+7. **Replace existing build-theme action** with hello-commerce version (AFTER COMPARISON)
+8. **`.github/actions/create-theme-release/action.yml`** - GitHub release creation
+
+#### Required Scripts (2 critical)
+1. **`.github/scripts/validate-versions.sh`** - Version consistency validation
+2. **`.github/scripts/generate-upload-instructions.sh`** - Upload instruction generation
+
+## Detailed Requirements
+
+### 1. Repository-Specific Changes Required
+
+#### A. Theme Name References
+- **From:** `hello-commerce` → **To:** `hello-elementor` (note: not hello-theme!)
+- **From:** `Hello Commerce` → **To:** `Hello Elementor`  
+- **From:** `HELLO_COMMERCE_ELEMENTOR_VERSION` → **To:** `HELLO_ELEMENTOR_VERSION`
+
+#### B. Repository URLs
+- **From:** `elementor/hello-commerce` → **To:** `elementor/hello-theme`
+- **From:** `https://github.com/elementor/hello-commerce` → **To:** `https://github.com/elementor/hello-theme`
+
+#### C. Package Configuration
+- **From:** Package name `hello-commerce` → **To:** `hello-elementor`
+- **From:** Theme slug `hello-commerce` → **To:** `hello-elementor`
+- **From:** WordPress.org URL `wordpress.org/themes/hello-commerce/` → **To:** `wordpress.org/themes/hello-elementor/`
+
+#### D. File Naming Patterns
+- **From:** `hello-commerce-{version}.zip` → **To:** `hello-elementor-{version}.zip`
+- **From:** `/tmp/hello-commerce-builds/` → **To:** `/tmp/hello-elementor-builds/`
+
+### 2. Critical Compatibility Analysis
+
+#### A. Build Process Differences
+**Hello Theme Build Commands:**
+```json
+{
+  "zip": "npm run clean:build && npm run build:prod && rsync -av --exclude-from=.buildignore . $npm_package_name && zip -r $npm_package_name.$npm_package_version.zip $npm_package_name/*",
+  "build:prod": "composer install --no-dev && wp-scripts build --env=production",
+  "clean:build": "rm -rf assets && rm -rf $npm_package_name"
+}
+```
+
+**Hello Commerce Build Commands:**
+```json
+{
+  "package:zip": "npm run package && zip -r $npm_package_name.$npm_package_version.zip ./$npm_package_name/*",
+  "build": "composer install --no-dev && npx wp-scripts build --env=production",
+  "clean": "rm -rf assets && rm -rf $npm_package_name"
+}
+```
+
+**⚠️ CRITICAL ADAPTATION REQUIRED:**
+- Hello Theme uses `zip` script vs Hello Commerce `package:zip`
+- Hello Theme uses `wp-scripts` directly vs Hello Commerce `npx wp-scripts`
+- Hello Theme has more complex build process with sass dependencies
+
+#### B. Version Constant Differences
+**Hello Theme:**
+```php
+define( 'HELLO_ELEMENTOR_VERSION', '3.4.4' );
+```
+
+**Hello Commerce:**
+```php
+define( 'HELLO_COMMERCE_ELEMENTOR_VERSION', '1.0.1' );
+```
+
+#### C. Existing Version Management Scripts
+Hello Theme already has `.github/scripts/update-version-in-files.js` which updates:
+- `./assets/scss/style.scss` 
+- `./functions.php`
+- `./readme.txt`
+
+**⚠️ INTEGRATION DECISION NEEDED:**
+- Keep existing JS-based version management OR replace with hello-commerce bash approach
+- Current JS script targets `assets/scss/style.scss` instead of `style.css`
+
+### 3. GitHub Actions Adaptation Requirements
+
+#### Action 1: install-dependencies
+```yaml
+# Current hello-commerce implementation covers:
+- PHP 7.4 setup with shivammathur/setup-php
+- Composer OAuth with DEVOPS_TOKEN
+- Node.js 18 setup with npm registry configuration  
+- NPM authentication with CLOUD_DEVOPS_TOKEN
+
+# Hello Theme adaptation needed: 
+# - Verify compatibility with Hello Theme's more complex dependencies (sass, webpack)
+# - May need enhanced npm retry logic (Hello Theme build-theme action has sophisticated retry logic)
+```
+
+#### Action 2: bump-theme-version  
+```yaml
+# Files to update with new version:
+- package.json (version field)
+- functions.php (HELLO_ELEMENTOR_VERSION constant) # CHANGED
+- style.css (Version: header)
+- readme.txt (Stable tag: field)
+
+# CRITICAL: Hello Theme has assets/scss/style.scss that may also need updating
+# Integration decision: Use existing update-version-in-files.js OR adapt hello-commerce bash approach
+```
+
+#### Action 3: get-changelog-from-readme
+```yaml
+# Functionality:
+- Extract changelog section for specific version from readme.txt
+- Create temporary changelog file
+- Validate changelog exists and is not empty
+- Set environment variable with changelog file path
+
+# Hello Theme adaptation: No changes needed - can copy directly
+```
+
+#### Action 4: build-theme
+```yaml
+# REQUIRES DETAILED COMPARISON AND POTENTIAL REPLACEMENT:
+
+# Hello Theme current build-theme features:
+- Sophisticated npm retry logic with multiple fallbacks
+- Advanced error handling
+- Package naming: hello-elementor-${VERSION}.zip
+- Uses "npm run build:prod" by default
+
+# Hello Commerce build-theme features:
+- Simpler npm installation
+- Uses "npm run build" by default
+- Package naming: hello-commerce-${VERSION}.zip
+
+# RECOMMENDATION: Keep Hello Theme's build-theme action but update:
+- Change package naming from hello-elementor to match repository context
+- Verify script compatibility with hello-commerce workflow
+```
+
+#### Action 5: create-pr-with-bumped-theme-version
+```yaml
+# Functionality:
+- Create PR with version-bumped files
+- Auto-configure git user as github-actions[bot]
+- Use peter-evans/create-pull-request action
+- Include specific files: package.json, functions.php, style.css, readme.txt
+
+# Hello Theme adaptation: No changes needed - can copy directly
+```
+
+#### Action 6: update-main-branch-version
+```yaml
+# Functionality:
+- Compare new version with main branch version
+- Only update if new version > main version
+- Auto-detect default branch (main vs master)
+- Handle version comparison logic
+
+# Hello Theme adaptation: No changes needed - can copy directly
+```
+
+#### Action 7: theme-slack-notification
+```yaml
+# Customization needed for hello-theme:
+- Update header text: "🚀 Hello Elementor v{version} Released!" # Note: Hello Elementor, not Hello Theme
+- Update description: "*Hello Elementor theme* has been successfully released"
+- Update manual upload instructions for hello-elementor context
+- Keep same Slack formatting and structure
+```
+
+### 4. Script Adaptation Requirements
+
+#### Script 1: validate-versions.sh
+```bash
+# Current hello-commerce version checks:
+FUNC_VERSION=$(grep -E "define\( 'HELLO_COMMERCE_ELEMENTOR_VERSION'" functions.php)
+
+# Hello Theme adaptation needed:
+FUNC_VERSION=$(grep -E "define\( 'HELLO_ELEMENTOR_VERSION'" functions.php)
+
+# All other logic remains the same:
+- Check package.json version
+- Check style.css Version header  
+- Check readme.txt Stable tag
+- Ensure all versions match
+```
+
+#### Script 2: generate-upload-instructions.sh
+```bash
+# Customizations needed for hello-theme:
+echo "📋 **Hello Elementor v${PACKAGE_VERSION} - Manual Upload Instructions**"
+echo "   - Theme: Hello Elementor"
+echo "   - Go to GitHub Releases page"  
+echo "   - Navigate to Hello Elementor theme page"
+echo "   - GitHub Release: https://github.com/elementor/hello-theme/releases/tag/v${PACKAGE_VERSION}"
+echo "   - WordPress.org: https://wordpress.org/themes/hello-elementor/"
+
+# All other instruction logic remains the same
+```
+
+### 5. Configuration Updates Required
+
+#### Update .github/config/release.json
+```json
+{
+  "repository": {
+    "name": "hello-elementor",  // ✅ Already correct
+    "owner": "elementor",       // ✅ Already correct
+    "main_branch": "main",      // ✅ Already correct
+    "release_branches": ["3.4"] // ✅ Already correct
+  },
+  "security": {
+    "allowed_repositories": ["elementor/hello-theme"], // ✅ Already correct
+  },
+  "release": {
+    "wordpress_org": {
+      "theme_slug": "hello-elementor"  // ✅ Already correct
+    }
+  }
+}
+```
+
+#### Secrets Verification Required
+```yaml
+# Verify these secrets exist in hello-theme repository:
+- DEVOPS_TOKEN              # ❓ Needs verification
+- CLOUD_DEVOPS_TOKEN        # ❓ Needs verification
+- SLACK_BOT_TOKEN           # ❓ Needs verification
+- CLOUD_SLACK_BOT_TOKEN     # ❓ Needs verification
+- GITHUB_TOKEN              # ✅ Automatically provided
+```
+
+### 6. Legacy Workflow Migration
+
+#### Current Hello Theme Workflows to Consider
+- **publish-release.yml** - Should this be replaced or kept alongside?
+- **publish-patch.yml** - Should this be replaced or kept alongside?  
+- **publish-beta.yml** - Should this be replaced or kept alongside?
+
+**RECOMMENDATION:**
+- Keep legacy workflows for backward compatibility
+- Add new release-preparation.yml as the primary release workflow
+- Document which workflow should be used going forward
+
+### 7. Version Management Integration Decision
+
+#### Option A: Keep Existing JS-based Version Management
+**Pros:**
+- Maintains consistency with existing Hello Theme approach
+- No disruption to current processes
+- JS script already handles assets/scss/style.scss
+
+**Cons:**
+- Different from Hello Commerce/Hello Biz approach
+- Requires adapting bump-theme-version action significantly
+
+#### Option B: Adopt Hello Commerce Bash Approach
+**Pros:**
+- Consistent with Hello Commerce/Hello Biz
+- Minimal adaptation of bump-theme-version action
+- Proven workflow in production
+
+**Cons:**
+- May not handle assets/scss/style.scss (Hello Theme specific)
+- Disrupts existing Hello Theme version management
+
+**RECOMMENDATION:** Option A - Keep existing JS approach but integrate it into the GitHub Actions workflow
+
+### 8. Testing Strategy
+
+#### Pre-deployment Testing
+1. **Build compatibility test**: Verify hello-theme builds correctly with cloned workflow
+2. **Version management test**: Ensure all files are updated consistently
+3. **Legacy workflow coexistence**: Test that new workflow doesn't conflict with existing ones
+4. **Dependency test**: Verify all npm/composer dependencies install correctly
+
+#### Post-deployment Testing  
+1. **End-to-end test**: Complete release process on test branch
+2. **Build artifact validation**: Verify hello-elementor-{version}.zip is created correctly
+3. **Version synchronization**: Ensure all version fields are updated properly
+4. **Legacy workflow test**: Ensure existing workflows still function
+
+### 9. Risk Analysis
+
+#### High Risk Items
+- **Build process differences**: Hello Theme has more complex build with sass/webpack
+- **Version management integration**: Two different approaches (JS vs Bash)
+- **Legacy workflow conflicts**: New workflow might interfere with existing ones
+- **Package naming confusion**: hello-elementor vs hello-theme naming
+
+#### Mitigation Strategies
+- Thorough build compatibility testing with dry_run mode
+- Careful integration of existing version management scripts
+- Clear documentation of workflow migration path
+- Comprehensive testing of all build artifacts
+
+### 10. Questions for Clarification
+
+#### Critical Questions:
+1. **Build Action Strategy**: Should we replace the existing build-theme action with hello-commerce version, or adapt hello-commerce workflow to use hello-theme's more sophisticated build action?
+
+2. **Version Management Approach**: Should we keep Hello Theme's existing `update-version-in-files.js` approach or adopt Hello Commerce's bash-based approach?
+
+3. **Legacy Workflows**: Should the existing publish-*.yml workflows be deprecated, kept alongside, or replaced entirely?
+
+4. **Package Naming**: The repository is `hello-theme` but the theme name is `hello-elementor` - confirm that build artifacts should be named `hello-elementor-{version}.zip`?
+
+5. **SCSS Handling**: Hello Theme has `assets/scss/style.scss` that needs version updates - how should this be integrated?
+
+6. **Release Branch Strategy**: Hello Theme uses branch "3.4" - should this be updated to match Hello Commerce pattern?
+
+#### Build Process Questions:
+7. **Build Script**: Should we use Hello Theme's `zip` script or adapt to Hello Commerce's `package:zip` pattern?
+
+8. **Dependency Complexity**: Hello Theme has more complex dependencies (sass, webpack) - any specific adaptations needed?
+
+#### Workflow Integration Questions:
+9. **Slack Notifications**: Theme display name should be "Hello Elementor" not "Hello Theme" - confirm?
+
+10. **WordPress.org Integration**: Should Hello Theme adopt Hello Commerce's auto-deploy feature or keep manual upload?
+
+### 11. Implementation Checklist
+
+#### GitHub Actions Creation
+- [ ] Copy and adapt install-dependencies from hello-commerce
+- [ ] Copy and adapt bump-theme-version from hello-commerce (integrate with existing JS version management)
+- [ ] Copy and adapt get-changelog-from-readme from hello-commerce
+- [ ] Copy and adapt create-pr-with-bumped-theme-version from hello-commerce
+- [ ] Copy and adapt update-main-branch-version from hello-commerce
+- [ ] Copy and adapt theme-slack-notification from hello-commerce (customize for hello-elementor)
+- [ ] **DECISION REQUIRED:** Replace or adapt build-theme with hello-commerce version
+- [ ] Copy create-theme-release from hello-commerce
+
+#### Scripts Creation
+- [ ] Copy and adapt validate-versions.sh (update HELLO_COMMERCE → HELLO_ELEMENTOR)
+- [ ] Copy and adapt generate-upload-instructions.sh (customize for hello-elementor)
+
+#### Workflow Setup
+- [ ] Copy release-preparation.yml and customize all references
+- [ ] **DECISION REQUIRED:** Deprecate or maintain existing publish-*.yml workflows
+- [ ] Test with dry_run: true
+- [ ] Verify all secrets are available
+- [ ] Test complete end-to-end flow
+
+#### Version Management Integration
+- [ ] **DECISION REQUIRED:** Choose version management approach (JS vs Bash)
+- [ ] Ensure assets/scss/style.scss is handled properly
+- [ ] Test version consistency across all files
+
+#### Compatibility Testing
+- [ ] Test build process compatibility
+- [ ] Verify all dependencies install correctly
+- [ ] Test build artifact creation (hello-elementor-{version}.zip)
+- [ ] Validate version synchronization
+
+#### Documentation
+- [ ] Update team documentation with new process
+- [ ] Create migration guide from legacy workflows
+- [ ] Document manual fallback procedures
+
+## Conclusion
+
+This PRD provides a comprehensive roadmap for cloning the hello-commerce release-preparation workflow to hello-theme. The primary complexity lies in the integration of different version management approaches and build processes. Critical decisions are needed around build action replacement and version management integration.
+
+**Estimated Implementation Time**: 6-8 hours (more complex than Hello Biz due to build process differences)
+**Primary Risk**: Version management integration and build process compatibility  
+**Key Dependencies**: Build action strategy decision, version management approach decision
+
+---
+
+*This PRD serves as the authoritative guide for implementing the release preparation workflow in hello-theme. All implementation should follow this specification after critical decisions are resolved.*
diff --git a/.github/CRITICAL-QUESTIONS-FOR-IMPLEMENTATION.md b/.github/CRITICAL-QUESTIONS-FOR-IMPLEMENTATION.md
new file mode 100644
index 00000000..31743901
--- /dev/null
+++ b/.github/CRITICAL-QUESTIONS-FOR-IMPLEMENTATION.md
@@ -0,0 +1,383 @@
+# Critical Questions for Hello Commerce → Hello Theme Workflow Clone
+
+## Overview
+Before proceeding with the workflow cloning, these critical questions must be answered to ensure successful implementation. Each question impacts the implementation approach and requires stakeholder input.
+
+---
+
+## 1. Build Process Strategy Questions
+
+### Q1: Build Action Replacement Strategy
+**Context:** Hello Theme has a more sophisticated build-theme action with retry logic and error handling, while Hello Commerce has a simpler approach.
+
+**Question:** Should we:
+- **Option A:** Replace Hello Theme's build-theme action with Hello Commerce version?
+- **Option B:** Keep Hello Theme's build-theme action and adapt Hello Commerce workflow to use it?
+- **Option C:** Merge the best features from both actions?
+
+**Current State:**
+- Hello Theme: 72-line sophisticated build action with retry logic
+- Hello Commerce: 68-line simpler build action  
+
+**Impact:** Medium - affects build reliability and error handling
+
+**Recommendation:** Option B - Keep Hello Theme's superior build action
+
+HVV: For all duplicate files or folder names, add the suffix '-release', e.g. 'build-theme-release'. Use the workflows and actions from Hello Commerce if possible. Logic: I would like to clone existing files as much possible, so that we can't break the workflows with new implementations.
+
+---
+
+### Q2: Build Script Naming Strategy
+**Context:** Different script names between repositories
+
+**Hello Theme:** `npm run zip` (creates hello-elementor-{version}.zip)  
+**Hello Commerce:** `npm run package:zip` (creates hello-commerce-{version}.zip)
+
+**Question:** Should we:
+- **Option A:** Update Hello Theme package.json to use `package:zip` script name?
+- **Option B:** Adapt workflow to use Hello Theme's `zip` script?
+- **Option C:** Create alias script for backward compatibility?
+
+**Impact:** Low - cosmetic change but affects script consistency
+
+**Recommendation:** Option B - Use Hello Theme's existing script names
+
+HVV: Use option A. Add the option to use 'package:zip'. Don't remove any existing options.
+
+---
+
+## 2. Version Management Integration Questions
+
+### Q3: Version Management Approach
+**Context:** Two different approaches for version management
+
+**Hello Theme Current:** JavaScript-based `update-version-in-files.js`
+- Updates: `assets/scss/style.scss`, `functions.php`, `readme.txt`
+- Uses replace-in-file package
+- Already integrated into existing workflows
+
+**Hello Commerce:** Bash-based approach in GitHub Actions
+- Updates: `package.json`, `functions.php`, `style.css`, `readme.txt`
+- Uses sed commands
+- Integrated into release-preparation workflow
+
+**Question:** Should we:
+- **Option A:** Replace Hello Theme's JS approach with Hello Commerce bash approach?
+- **Option B:** Keep Hello Theme's JS approach and adapt GitHub Actions to call it?
+- **Option C:** Hybrid approach - use bash for some files, JS for SCSS-specific files?
+
+**Impact:** High - affects version synchronization reliability
+
+**Recommendation:** Option B - Keep Hello Theme's existing approach for continuity
+
+HVV: Option A. But don't delete any existing functionality.
+
+---
+
+### Q4: SCSS File Version Management
+**Context:** Hello Theme has `assets/scss/style.scss` that needs version management
+
+**Question:** How should version updates be handled for SCSS files?
+- **Option A:** Add SCSS handling to Hello Commerce's bash approach
+- **Option B:** Keep Hello Theme's JS approach which already handles SCSS
+- **Option C:** Manual SCSS version management (not recommended)
+
+**Current Hello Theme JS script updates:**
+```javascript
+files: './assets/scss/style.scss',
+from: /Version:.*$/m,
+to: `Version: ${ VERSION }`,
+```
+
+**Impact:** High - SCSS files must have correct versions for WordPress.org compliance
+
+**Recommendation:** Option B - Leverage existing JS script capability
+
+HVV: Use option A.
+
+---
+
+## 3. Repository and Theme Naming Questions
+
+### Q5: Theme Display Name Confirmation
+**Context:** Repository name vs theme display name confusion
+
+**Repository:** `elementor/hello-theme`  
+**Theme Name:** "Hello Elementor"  
+**Package Name:** `hello-elementor`  
+**Build Artifact:** `hello-elementor-{version}.zip`
+
+**Question:** Confirm the correct naming for all workflow messages:
+- Slack notifications should say "Hello Elementor" (not "Hello Theme")?
+- Build artifacts should be named `hello-elementor-{version}.zip`?
+- WordPress.org references should use `hello-elementor`?
+
+**Impact:** Medium - affects user communication and artifact naming
+
+**Recommendation:** Use "Hello Elementor" for all user-facing messages
+
+HVV: Compary with the 'Publish Release Version' workflow.
+'hello-elementor' seems correct.
+WordPress url: https://en-za.wordpress.org/themes/hello-elementor/
+Github url: https://github.com/elementor/hello-theme
+
+---
+
+### Q6: Repository Reference Strategy
+**Context:** GitHub repository references throughout workflow
+
+**Question:** Should workflow references point to:
+- **Option A:** `elementor/hello-theme` (actual repository)
+- **Option B:** Update any hardcoded references to be dynamic
+- **Option C:** Mix of repository and theme names where contextually appropriate
+
+**Examples:**
+- GitHub release URLs: `github.com/elementor/hello-theme/releases`
+- Action references: `.github/actions/build-theme` (repository context)
+- Theme references: WordPress.org URLs use `hello-elementor`
+
+**Impact:** Low - mainly affects URLs and references
+
+**Recommendation:** Option A - Use actual repository name for all GitHub references
+
+HVV: Option A.
+
+---
+
+## 4. Legacy Workflow Migration Questions
+
+### Q7: Legacy Workflow Coexistence Strategy
+**Context:** Hello Theme has existing release workflows
+
+**Existing Workflows:**
+- `publish-release.yml` - Full release process
+- `publish-patch.yml` - Patch releases  
+- `publish-beta.yml` - Beta releases
+
+**Question:** What should happen to these workflows when release-preparation.yml is added?
+- **Option A:** Keep all workflows active (coexistence)
+- **Option B:** Deprecate legacy workflows with migration timeline
+- **Option C:** Immediately replace/disable legacy workflows
+- **Option D:** Keep beta workflow, replace others
+
+**Impact:** High - affects team workflow and potential conflicts
+
+**Recommendation:** Option A initially, then Option B with documented migration plan
+
+HVV: Option A.
+
+---
+
+### Q8: Workflow Migration Timeline
+**Context:** Team needs clear guidance on workflow transition
+
+**Question:** What should be the migration strategy?
+- **Option A:** Immediate switch to new workflow for all releases
+- **Option B:** Parallel operation for 1-2 release cycles, then deprecate old workflows
+- **Option C:** Feature branch testing first, then gradual rollout
+- **Option D:** Team choice per release type
+
+**Impact:** High - affects team adoption and risk management
+
+**Recommendation:** Option C - Feature branch testing, then Option B parallel operation
+
+HVV: Option D: Keep both options in parellel. We don't want a single change to the existing functionality.
+
+---
+
+## 5. Secret and Configuration Questions
+
+### Q9: GitHub Secrets Verification
+**Context:** New workflow requires specific secrets
+
+**Required Secrets:**
+- `DEVOPS_TOKEN` - For composer authentication
+- `CLOUD_DEVOPS_TOKEN` - For NPM registry access  
+- `SLACK_BOT_TOKEN` - For release notifications
+- `CLOUD_SLACK_BOT_TOKEN` - For build notifications
+
+**Question:** Which of these secrets are already available in hello-theme repository?
+
+**Current Hello Theme Workflows Use:**
+- `MAINTAIN_TOKEN` (for publish-*.yml workflows)
+- Other secrets TBD
+
+**Action Required:** Verify secret availability and configure missing ones
+
+HVV: GITHUB_TOKEN, CLOUD_DEVOPS_TOKEN. Ignore the slack issues for now.
+
+---
+
+### Q10: Slack Notification Configuration
+**Context:** Release notifications need proper channel configuration
+
+**Question:** What are the correct Slack settings for Hello Theme releases?
+- **Channel:** Which Slack channel should receive notifications?
+- **Format:** Should notifications distinguish Hello Elementor from other Elementor themes?
+- **Frequency:** All releases, or only major/minor releases?
+
+**Current Default:** `#release` (from config)
+
+**Impact:** Medium - affects team communication
+
+HVV: Leave as is for now.
+
+---
+
+## 6. WordPress.org Integration Questions
+
+### Q11: WordPress.org Release Process
+**Context:** Different WordPress.org integration approaches
+
+**Hello Commerce:** Auto-deploy to WordPress.org (in config)  
+**Hello Theme:** Manual upload process (in config)
+
+**Question:** Should Hello Theme adopt auto-deploy or keep manual process?
+- **Option A:** Keep manual upload (current Hello Theme approach)
+- **Option B:** Adopt auto-deploy (Hello Commerce approach)
+- **Option C:** Configurable per release type
+
+**Impact:** Medium - affects release automation level
+
+**Recommendation:** Option A - Keep manual for safety, consider Option B later
+
+HVV: Follow Hello Commerce for now.
+
+---
+
+## 7. Technical Integration Questions
+
+### Q12: Release Branch Strategy
+**Context:** Different branching approaches
+
+**Hello Commerce:** Release branches `["1.0"]`  
+**Hello Theme:** Release branches `["3.4"]`
+
+**Question:** Should Hello Theme:
+- **Option A:** Keep current "3.4" branch approach
+- **Option B:** Adopt Hello Commerce pattern
+- **Option C:** Update to next major version pattern (e.g., "3.5")
+
+**Impact:** Low - affects branch validation in workflow
+
+**Recommendation:** Option A - Keep existing approach
+
+HVV: Option A.
+
+---
+
+### Q13: Testing and Validation Strategy
+**Context:** Ensuring workflow compatibility
+
+**Question:** What testing approach should we use?
+- **Option A:** Create test branch and run full dry_run workflow
+- **Option B:** Test individual actions separately, then full workflow
+- **Option C:** Test on fork repository first
+- **Option D:** All of the above
+
+**Required Tests:**
+- Build process compatibility
+- Version management accuracy  
+- Secret availability
+- Legacy workflow coexistence
+
+**Impact:** High - affects implementation success
+
+**Recommendation:** Option D - Comprehensive testing approach
+
+HVV: I will test manually.
+
+---
+
+## 8. Documentation and Training Questions
+
+### Q14: Team Training Requirements
+**Context:** New workflow requires team education
+
+**Question:** What documentation/training is needed?
+- **Option A:** Written documentation only
+- **Option B:** Team walkthrough session
+- **Option C:** Both documentation and training session
+- **Option D:** Gradual rollout with mentoring
+
+**Documentation Needs:**
+- Migration guide from legacy workflows
+- New workflow usage instructions
+- Troubleshooting guide
+- Rollback procedures
+
+**Impact:** Medium - affects adoption success
+
+**Recommendation:** Option C - Both written docs and training
+
+HVV: None.
+
+---
+
+## 9. Priority and Timeline Questions
+
+### Q15: Implementation Priority
+**Context:** Resource allocation and timeline planning
+
+**Question:** What is the priority and timeline for this implementation?
+- **High Priority:** Implement immediately (1-2 weeks)
+- **Medium Priority:** Implement in next sprint (3-4 weeks)  
+- **Low Priority:** Implement when convenient (1-2 months)
+
+**Factors to Consider:**
+- Current Hello Theme release schedule
+- Team availability
+- Upcoming releases that could benefit from new workflow
+
+HVV: Today
+
+---
+
+### Q16: Rollback Strategy
+**Context:** Risk mitigation planning
+
+**Question:** What should be the rollback plan if issues arise?
+- **Option A:** Revert to legacy workflows immediately
+- **Option B:** Fix issues in new workflow
+- **Option C:** Hybrid approach - use working parts, fallback for broken parts
+
+**Impact:** High - affects risk management
+
+**Recommendation:** Option A with documented quick rollback procedures
+
+HVV: We won't update any existing worfklows. There is no risk.
+
+---
+
+## Decision Matrix Summary
+
+| Question | Impact | Urgency | Recommended Option |
+|----------|--------|---------|-------------------|
+| Q1: Build Action Strategy | Medium | High | Keep Hello Theme's build action |
+| Q2: Script Names | Low | Medium | Use Hello Theme's scripts |
+| Q3: Version Management | High | High | Keep Hello Theme's JS approach |
+| Q4: SCSS Handling | High | High | Use existing JS script |
+| Q5: Theme Names | Medium | High | Use "Hello Elementor" |
+| Q6: Repository References | Low | Medium | Use actual repository names |
+| Q7: Legacy Workflows | High | Medium | Coexistence then migration |
+| Q8: Migration Timeline | High | High | Feature testing → Parallel |
+| Q9: Secrets | High | High | Verify availability |
+| Q10: Slack Config | Medium | Medium | Confirm channel/format |
+| Q11: WordPress.org | Medium | Low | Keep manual process |
+| Q12: Branch Strategy | Low | Low | Keep "3.4" approach |
+| Q13: Testing Strategy | High | High | Comprehensive testing |
+| Q14: Training | Medium | Medium | Docs + training session |
+| Q15: Priority | High | High | TBD by stakeholders |
+| Q16: Rollback Plan | High | High | Quick revert procedures |
+
+---
+
+## Next Steps
+
+1. **Answer high-impact questions** (Q3, Q4, Q7, Q8, Q9, Q13, Q16)
+2. **Verify technical requirements** (secrets, build compatibility)
+3. **Create implementation timeline** based on priorities
+4. **Begin Phase 1 implementation** with answered questions
+5. **Schedule team training** once workflow is ready
+
+**All questions marked as "High Impact" must be answered before implementation begins.**
diff --git a/.github/actions/build-theme-release/action.yml b/.github/actions/build-theme-release/action.yml
new file mode 100644
index 00000000..3329bb5c
--- /dev/null
+++ b/.github/actions/build-theme-release/action.yml
@@ -0,0 +1,72 @@
+name: 'Build Theme (Release)'
+description: 'Build Hello Elementor theme with specified version using Hello Commerce approach'
+
+inputs:
+  PACKAGE_VERSION:
+    description: 'The package version to build (e.g. 3.4.4)'
+    required: true
+  BUILD_SCRIPT_PATH:
+    description: 'Path to build script'
+    required: false
+    default: "npm run package:zip"
+
+runs:
+  using: "composite"
+  steps:
+    - name: Install npm dependencies
+      shell: bash
+      run: |
+        export PUPPETEER_SKIP_DOWNLOAD=true
+        export PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1
+        npm ci
+
+    - name: Install composer dependencies
+      shell: bash
+      run: |
+        composer install --no-dev --no-scripts --optimize-autoloader
+
+    - name: Set package version
+      shell: bash
+      env:
+        PACKAGE_VERSION: ${{ inputs.PACKAGE_VERSION }}
+      run: |
+        echo "PACKAGE_VERSION=${PACKAGE_VERSION}" >> $GITHUB_ENV
+        echo "Building Hello Elementor theme version: ${PACKAGE_VERSION}"
+
+    - name: Build theme
+      shell: bash
+      run: |
+        if [[ "${{ inputs.BUILD_SCRIPT_PATH }}" == npm* ]]; then
+          ${{ inputs.BUILD_SCRIPT_PATH }}
+        else
+          bash "${{ inputs.BUILD_SCRIPT_PATH }}"
+        fi
+
+    - name: Create theme build directory
+      shell: bash
+      run: |
+        mkdir -p /tmp/hello-elementor-builds
+        
+    - name: Package theme
+      shell: bash
+      env:
+        PACKAGE_VERSION: ${{ inputs.PACKAGE_VERSION }}
+      run: |
+        # Create zip file with proper naming (hello-elementor instead of hello-theme)
+        zip -r "/tmp/hello-elementor-builds/hello-elementor-${PACKAGE_VERSION}.zip" . \
+          -x "node_modules/*" "test-results/*" "tests/*" ".git/*" "*.zip" \
+             "playwright-report/*" ".wp-env.json.*" ".wp-env"
+
+    - name: Move build to workspace
+      shell: bash
+      env:
+        PACKAGE_VERSION: ${{ inputs.PACKAGE_VERSION }}
+      run: |
+        mv "/tmp/hello-elementor-builds/hello-elementor-${PACKAGE_VERSION}.zip" \
+           "./hello-elementor-${PACKAGE_VERSION}.zip"
+        
+        echo "✅ Hello Elementor theme build complete: hello-elementor-${PACKAGE_VERSION}.zip"
+        ls -la hello-elementor-*.zip
+        
+        # Set build path for downstream actions
+        echo "BUILD_ZIP_PATH=hello-elementor-${PACKAGE_VERSION}.zip" >> $GITHUB_ENV
diff --git a/.github/actions/bump-theme-version-release/action.yml b/.github/actions/bump-theme-version-release/action.yml
new file mode 100644
index 00000000..a39f70ea
--- /dev/null
+++ b/.github/actions/bump-theme-version-release/action.yml
@@ -0,0 +1,164 @@
+name: 'Bump Theme Version (Release)'
+description: 'Updates version across all Hello Elementor theme files including SCSS'
+
+inputs:
+  CLEAN_PACKAGE_VERSION:
+    required: true
+    description: 'Current clean version (without v prefix)'
+  VERSION_TYPE:
+    required: true
+    description: 'Version bump type (current|patch|minor|major)'
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Calculate new version
+      shell: bash
+      run: |
+        CURRENT_VERSION="${{ inputs.CLEAN_PACKAGE_VERSION }}"
+        IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
+        
+        case "${{ inputs.VERSION_TYPE }}" in
+          "current")
+            # Keep version as-is for first release
+            NEW_VERSION="$CURRENT_VERSION"
+            ;;
+          "major")
+            NEW_MAJOR=$((MAJOR + 1))
+            NEW_VERSION="$NEW_MAJOR.0.0"
+            ;;
+          "minor")
+            NEW_MINOR=$((MINOR + 1))
+            NEW_VERSION="$MAJOR.$NEW_MINOR.0"
+            ;;
+          "patch")
+            NEW_PATCH=$((PATCH + 1))
+            NEW_VERSION="$MAJOR.$MINOR.$NEW_PATCH"
+            ;;
+        esac
+        
+        echo "NEW_VERSION=$NEW_VERSION" >> $GITHUB_ENV
+        echo "CURRENT_VERSION=$CURRENT_VERSION" >> $GITHUB_ENV
+        echo "Version will be: $CURRENT_VERSION → $NEW_VERSION"
+
+    - name: Update functions.php version
+      shell: bash
+      run: |
+        sed -i.bak "s/define( 'HELLO_ELEMENTOR_VERSION', '[^']*' );/define( 'HELLO_ELEMENTOR_VERSION', '$NEW_VERSION' );/" functions.php
+        rm functions.php.bak
+        # Verify functions.php was actually updated
+        if ! grep -q "HELLO_ELEMENTOR_VERSION.*$NEW_VERSION" functions.php; then
+          echo "Error: Failed to update version in functions.php"
+          exit 1
+        fi
+        echo "✅ Updated functions.php HELLO_ELEMENTOR_VERSION to $NEW_VERSION"
+
+    - name: Update package.json version
+      shell: bash
+      run: |
+        if [ "$NEW_VERSION" = "$CURRENT_VERSION" ]; then
+          echo "Version unchanged ($CURRENT_VERSION), skipping npm version bump."
+        else
+          npm version --no-git-tag-version $NEW_VERSION
+        fi
+
+    - name: Update style.css version
+      shell: bash
+      run: |
+        sed -i.bak "s/Version: .*/Version: $NEW_VERSION/" style.css
+        rm style.css.bak
+        # Verify style.css was actually updated
+        if ! grep -q "Version: $NEW_VERSION" style.css; then
+          echo "Error: Failed to update version in style.css"
+          echo "Current content:"
+          grep -A2 -B2 "Version:" style.css || echo "No Version: field found"
+          exit 1
+        fi
+        echo "✅ Updated style.css Version to $NEW_VERSION"
+
+    - name: Update assets/scss/style.scss version (Hello Theme specific)
+      shell: bash
+      run: |
+        if [ -f "assets/scss/style.scss" ]; then
+          sed -i.bak -e "s/Version: .*/Version: $NEW_VERSION/" -e "s/Stable tag: .*/Stable tag: $NEW_VERSION/" assets/scss/style.scss
+          rm assets/scss/style.scss.bak
+          
+          # Verify that SCSS file was updated
+          VALIDATION_PASSED=true
+          
+          # Check Version field
+          if grep -q "Version:" assets/scss/style.scss; then
+            if ! grep -q "Version: $NEW_VERSION" assets/scss/style.scss; then
+              echo "Error: Failed to update Version in assets/scss/style.scss"
+              VALIDATION_PASSED=false
+            else
+              echo "✅ Updated assets/scss/style.scss Version to $NEW_VERSION"
+            fi
+          else
+            echo "ℹ️ No 'Version:' field found in assets/scss/style.scss"
+          fi
+          
+          # Check Stable tag field  
+          if grep -q "Stable tag:" assets/scss/style.scss; then
+            if ! grep -q "Stable tag: $NEW_VERSION" assets/scss/style.scss; then
+              echo "Error: Failed to update Stable tag in assets/scss/style.scss"
+              VALIDATION_PASSED=false
+            else
+              echo "✅ Updated assets/scss/style.scss Stable tag to $NEW_VERSION"
+            fi
+          else
+            echo "ℹ️ No 'Stable tag:' field found in assets/scss/style.scss"
+          fi
+          
+          if [ "$VALIDATION_PASSED" = "false" ]; then
+            echo "❌ assets/scss/style.scss version update failed"
+            exit 1
+          fi
+        else
+          echo "ℹ️ No assets/scss/style.scss file found, skipping SCSS version update"
+        fi
+
+    - name: Update readme.txt stable tag and version
+      shell: bash
+      run: |
+        # Update fields that exist in the file
+        sed -i.bak -e "s/^Stable tag: .*/Stable tag: $NEW_VERSION/" -e "s/^Version: .*/Version: $NEW_VERSION/" readme.txt
+        rm readme.txt.bak
+        
+        # Verify that fields were updated (check each field independently)
+        VALIDATION_PASSED=true
+        
+        # Check if Stable tag field exists and was updated
+        if grep -q "^Stable tag:" readme.txt; then
+          if ! grep -q "^Stable tag: $NEW_VERSION" readme.txt; then
+            echo "Error: Found 'Stable tag:' field but failed to update it to $NEW_VERSION"
+            VALIDATION_PASSED=false
+          else
+            echo "✅ Updated readme.txt Stable tag to $NEW_VERSION"
+          fi
+        else
+          echo "ℹ️ No 'Stable tag:' field found in readme.txt"
+        fi
+        
+        # Check if Version field exists and was updated
+        if grep -q "^Version:" readme.txt; then
+          if ! grep -q "^Version: $NEW_VERSION" readme.txt; then
+            echo "Error: Found 'Version:' field but failed to update it to $NEW_VERSION"
+            VALIDATION_PASSED=false
+          else
+            echo "✅ Updated readme.txt Version to $NEW_VERSION"
+          fi
+        else
+          echo "ℹ️ No 'Version:' field found in readme.txt"
+        fi
+        
+        if [ "$VALIDATION_PASSED" = "false" ]; then
+          echo "❌ readme.txt version update failed"
+          exit 1
+        fi
+        
+        echo "✅ readme.txt version update completed successfully" 
+
+    - name: Set PACKAGE_VERSION from NEW_VERSION
+      shell: bash
+      run: echo "PACKAGE_VERSION=$NEW_VERSION" >> $GITHUB_ENV
diff --git a/.github/actions/create-pr-with-bumped-theme-version-release/action.yml b/.github/actions/create-pr-with-bumped-theme-version-release/action.yml
new file mode 100644
index 00000000..6d69ebfb
--- /dev/null
+++ b/.github/actions/create-pr-with-bumped-theme-version-release/action.yml
@@ -0,0 +1,40 @@
+name: 'Create PR With Bumped Theme Version (Release)'
+description: 'Creates a pull request with the bumped Hello Elementor theme version'
+
+inputs:
+  base_branch:
+    required: true
+    description: 'The base branch for the PR'
+  package_version:
+    required: true
+    description: 'The new package version'
+  token:
+    required: true
+    description: 'GitHub token for authentication'
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Configure Git
+      shell: bash
+      run: |
+        git config user.name "github-actions[bot]"
+        git config user.email "github-actions[bot]@users.noreply.github.com"
+
+    - name: Create Pull Request
+      uses: peter-evans/create-pull-request@v5
+      with:
+        token: ${{ inputs.token }}
+        commit-message: "chore: bump Hello Elementor version to v${{ inputs.package_version }}"
+        branch: release/v${{ inputs.package_version }}
+        title: "Release Hello Elementor v${{ inputs.package_version }}"
+        body: "Automated PR to bump Hello Elementor version for release."
+        base: ${{ inputs.base_branch }}
+        add-paths: |
+          package.json
+          package-lock.json
+          functions.php
+          style.css
+          theme.json
+          readme.txt
+          assets/scss/style.scss
diff --git a/.github/actions/create-theme-release-release/action.yml b/.github/actions/create-theme-release-release/action.yml
new file mode 100644
index 00000000..dd70aae7
--- /dev/null
+++ b/.github/actions/create-theme-release-release/action.yml
@@ -0,0 +1,68 @@
+name: 'Create Theme Release (Release)'
+description: 'Create GitHub release for Hello Elementor theme'
+inputs:
+  PACKAGE_VERSION:
+    required: true
+    description: 'Release version'
+  BUILD_ZIP_PATH:
+    required: true
+    description: 'Path to theme zip file'
+  CHANGELOG_FILE:
+    required: true
+    description: 'Path to changelog file'
+  PRE_RELEASE:
+    required: false
+    default: 'false'
+    description: 'Is this a pre-release?'
+  GITHUB_TOKEN:
+    required: true
+    description: 'GitHub token for creating releases'
+
+outputs:
+  RELEASE_URL:
+    description: 'URL of the created GitHub release'
+    value: ${{ steps.create-release.outputs.html_url }}
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Verify files exist
+      shell: bash
+      run: |
+        if [ ! -f "${{ inputs.BUILD_ZIP_PATH }}" ]; then
+          echo "Error: Build zip file not found: ${{ inputs.BUILD_ZIP_PATH }}"
+          exit 1
+        fi
+        
+        if [ ! -f "${{ inputs.CHANGELOG_FILE }}" ]; then
+          echo "Error: Changelog file not found: ${{ inputs.CHANGELOG_FILE }}"
+          exit 1
+        fi
+        
+        echo "✅ Build zip: ${{ inputs.BUILD_ZIP_PATH }}"
+        echo "✅ Changelog: ${{ inputs.CHANGELOG_FILE }}"
+    
+    - name: Create GitHub release
+      id: create-release
+      uses: softprops/action-gh-release@v1
+      with:
+        tag_name: v${{ inputs.PACKAGE_VERSION }}
+        name: Hello Elementor v${{ inputs.PACKAGE_VERSION }}
+        files: |
+          ${{ inputs.BUILD_ZIP_PATH }}
+          ${{ inputs.CHANGELOG_FILE }}
+        body_path: ${{ inputs.CHANGELOG_FILE }}
+        prerelease: ${{ inputs.PRE_RELEASE }}
+        token: ${{ inputs.GITHUB_TOKEN }}
+        generate_release_notes: false
+    
+    - name: Release summary
+      shell: bash
+      run: |
+        echo "🚀 **Release Created Successfully!**"
+        echo "📋 **Release Details:**"
+        echo "   - Version: v${{ inputs.PACKAGE_VERSION }}"
+        echo "   - Pre-release: ${{ inputs.PRE_RELEASE }}"
+        echo "   - Build file: ${{ inputs.BUILD_ZIP_PATH }}"
+        echo "   - Release URL: ${{ steps.create-release.outputs.html_url }}"
+        echo "RELEASE_URL=${{ steps.create-release.outputs.html_url }}" >> $GITHUB_ENV
diff --git a/.github/actions/get-changelog-from-readme-release/action.yml b/.github/actions/get-changelog-from-readme-release/action.yml
new file mode 100644
index 00000000..fd912cc4
--- /dev/null
+++ b/.github/actions/get-changelog-from-readme-release/action.yml
@@ -0,0 +1,33 @@
+name: 'Get changelog from readme.txt (Release)'
+description: 'Get changelog from readme.txt file - Hello Elementor release validation'
+
+inputs:
+  VERSION:
+    description: 'Theme Version'
+    required: true
+
+outputs:
+  CHANGELOG_FILE:
+    description: 'Path to the extracted changelog file'
+    value: temp-changelog-from-readme.txt
+
+runs:
+  using: "composite"
+  steps:
+    - name: Extract changelog from readme.txt
+      shell: bash
+      env:
+        VERSION: ${{ inputs.VERSION }}
+      run: |
+        node ./.github/scripts/get-changelog-from-readme-release.js
+        
+    - name: Verify changelog file
+      shell: bash
+      run: |
+        if [ ! -f "temp-changelog-from-readme.txt" ]; then
+          echo "Error: Failed to create changelog file"
+          exit 1
+        fi
+        
+        echo "✅ Changelog extracted successfully for version ${{ inputs.VERSION }}"
+        echo "CHANGELOG_FILE=temp-changelog-from-readme.txt" >> $GITHUB_ENV
diff --git a/.github/actions/install-dependencies-release/action.yml b/.github/actions/install-dependencies-release/action.yml
new file mode 100644
index 00000000..b92df46b
--- /dev/null
+++ b/.github/actions/install-dependencies-release/action.yml
@@ -0,0 +1,49 @@
+name: 'Install Dependencies for Hello Elementor (Release)'
+description: 'Install PHP, Composer, and npm dependencies for release workflow'
+inputs:
+  DEVOPS_TOKEN:
+    description: 'GitHub token for Composer authentication'
+    required: true
+  CLOUD_DEVOPS_TOKEN:
+    description: 'npm registry access token'
+    required: true
+runs:
+  using: 'composite'
+  steps:
+    - name: Set up PHP
+      uses: shivammathur/setup-php@v2
+      with:
+        php-version: '7.4'
+    
+    - name: OAuth Composer Authentication
+      shell: bash
+      run: composer config -g github-oauth.github.com ${{ inputs.DEVOPS_TOKEN }}
+    
+    - name: Install Composer dependencies (cache)
+      uses: ramsey/composer-install@v2
+      with:
+        custom-cache-key: cache-${{ hashFiles('composer.lock') }}
+    
+    - name: Install Composer dependencies (production)
+      shell: bash
+      run: composer install --no-dev
+    
+    - name: Set up Node.js
+      uses: actions/setup-node@v4
+      with:
+        node-version: '20.x'
+        registry-url: 'https://npm.pkg.github.com'
+        scope: '@elementor'
+        cache: 'npm'
+    
+    - name: Install npm dependencies
+      shell: bash
+      run: |
+        if npm ci; then
+          echo "✅ npm ci succeeded"
+        else
+          echo "⚠️ npm ci failed, falling back to npm install --legacy-peer-deps"
+          npm install --legacy-peer-deps
+        fi
+      env:
+        NODE_AUTH_TOKEN: ${{ inputs.CLOUD_DEVOPS_TOKEN }}
diff --git a/.github/actions/theme-slack-notification-release/action.yml b/.github/actions/theme-slack-notification-release/action.yml
new file mode 100644
index 00000000..a599ccbf
--- /dev/null
+++ b/.github/actions/theme-slack-notification-release/action.yml
@@ -0,0 +1,144 @@
+name: 'Theme Slack Notification (Release)'
+description: 'Send Slack notification for Hello Elementor release'
+inputs:
+  SLACK_BOT_TOKEN:
+    required: true
+    description: 'Slack bot token'
+  PACKAGE_VERSION:
+    required: true
+    description: 'Release version'
+  BUILD_ZIP_PATH:
+    required: true
+    description: 'Path to theme zip file'
+  GITHUB_RELEASE_URL:
+    required: true
+    description: 'GitHub release URL'
+  SLACK_CHANNEL:
+    required: false
+    default: '#general'
+    description: 'Slack channel to send notification to'
+  WPORG_DEPLOYMENT_STATUS:
+    required: false
+    default: 'skipped'
+    description: 'WordPress.org deployment status (deployed|skipped|disabled)'
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Prepare deployment message
+      id: deployment-message
+      shell: bash
+      run: |
+        case "${{ inputs.WPORG_DEPLOYMENT_STATUS }}" in
+          "deployed")
+            MESSAGE="📦 *WordPress.org Deployment*\\n• ✅ Automatically deployed to WordPress.org\\n• Theme available at: https://wordpress.org/themes/hello-elementor/\\n• No manual upload required! 🎉"
+            ;;
+          "disabled")
+            MESSAGE="📦 *WordPress.org Deployment*\\n• ⚠️ Disabled in configuration\\n• Manual upload required to WordPress.org\\n• Download zip from GitHub release below"
+            ;;
+          *)
+            MESSAGE="📦 *WordPress.org Deployment*\\n• ⚠️ Skipped (deploy_to_wporg: false)\\n• Manual upload required to WordPress.org\\n• Download zip from GitHub release below"
+            ;;
+        esac
+        echo "DEPLOYMENT_MESSAGE=$MESSAGE" >> $GITHUB_ENV
+    
+    - name: Get file info
+      id: file-info
+      shell: bash
+      run: |
+        if [ -f "${{ inputs.BUILD_ZIP_PATH }}" ]; then
+          FILE_SIZE=$(stat -c%s "${{ inputs.BUILD_ZIP_PATH }}" 2>/dev/null || stat -f%z "${{ inputs.BUILD_ZIP_PATH }}")
+          FILE_SIZE_MB=$(echo "scale=2; $FILE_SIZE / 1024 / 1024" | bc -l 2>/dev/null || echo "$((FILE_SIZE / 1024 / 1024)).0")
+          echo "FILE_SIZE=$FILE_SIZE" >> $GITHUB_ENV
+          echo "FILE_SIZE_MB=${FILE_SIZE_MB}MB" >> $GITHUB_ENV
+        else
+          echo "FILE_SIZE_MB=Unknown" >> $GITHUB_ENV
+        fi
+
+    - name: Post to Slack
+      uses: slackapi/slack-github-action@v1.23.0
+      with:
+        channel-id: ${{ inputs.SLACK_CHANNEL }}
+        payload: |
+          {
+            "blocks": [
+              {
+                "type": "header",
+                "text": {
+                  "type": "plain_text",
+                  "text": "🚀 Hello Elementor v${{ inputs.PACKAGE_VERSION }} Released!"
+                }
+              },
+              {
+                "type": "section",
+                "text": {
+                  "type": "mrkdwn",
+                  "text": "*Hello Elementor theme* has been successfully released and is ready for distribution."
+                }
+              },
+              {
+                "type": "section",
+                "fields": [
+                  {
+                    "type": "mrkdwn",
+                    "text": "*Version:*\nv${{ inputs.PACKAGE_VERSION }}"
+                  },
+                  {
+                    "type": "mrkdwn",
+                    "text": "*Package Size:*\n${{ env.FILE_SIZE_MB }}"
+                  }
+                ]
+              },
+              {
+                "type": "section",
+                "text": {
+                  "type": "mrkdwn",
+                  "text": "${{ env.DEPLOYMENT_MESSAGE }}"
+                }
+              },
+              {
+                "type": "actions",
+                "elements": [
+                  {
+                    "type": "button",
+                    "text": {
+                      "type": "plain_text",
+                      "text": "📥 Download Release"
+                    },
+                    "url": "${{ inputs.GITHUB_RELEASE_URL }}",
+                    "style": "primary"
+                  }
+                ]
+              },
+              {
+                "type": "context",
+                "elements": [
+                  {
+                    "type": "mrkdwn",
+                    "text": "Build: ${{ inputs.BUILD_ZIP_PATH }}"
+                  }
+                ]
+              }
+            ]
+          }
+      env:
+        SLACK_BOT_TOKEN: ${{ inputs.SLACK_BOT_TOKEN }}
+
+    - name: Notification summary
+      shell: bash
+      run: |
+        echo "📢 Slack notification sent!"
+        echo "   - Channel: ${{ inputs.SLACK_CHANNEL }}"
+        echo "   - Version: v${{ inputs.PACKAGE_VERSION }}"
+        echo "   - Release: ${{ inputs.GITHUB_RELEASE_URL }}"
+        case "${{ inputs.WPORG_DEPLOYMENT_STATUS }}" in
+          "deployed")
+            echo "   - WordPress.org: ✅ Automatically deployed"
+            ;;
+          "disabled")
+            echo "   - WordPress.org: ⚠️ Disabled in configuration"
+            ;;
+          *)
+            echo "   - WordPress.org: ⚠️ Skipped (deploy_to_wporg: false)"
+            ;;
+        esac
diff --git a/.github/actions/update-main-branch-version-release/action.yml b/.github/actions/update-main-branch-version-release/action.yml
new file mode 100644
index 00000000..2d5558cb
--- /dev/null
+++ b/.github/actions/update-main-branch-version-release/action.yml
@@ -0,0 +1,249 @@
+name: 'Update Main Branch Version (Release)'
+description: 'Updates main branch version only if new version is greater than current main version (Hello Elementor)'
+
+inputs:
+  new_version:
+    required: true
+    description: 'The new version to potentially update to'
+  token:
+    required: true
+    description: 'GitHub token for authentication'
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Auto-detect default branch
+      shell: bash
+      run: |
+        # Auto-detect the default branch (supports both 'master' and 'main')
+        DEFAULT_BRANCH=""
+
+        # Check if main exists, then master, then fallback
+        if git ls-remote --heads origin main | grep -q "refs/heads/main"; then
+          DEFAULT_BRANCH="main"
+        elif git ls-remote --heads origin master | grep -q "refs/heads/master"; then
+          DEFAULT_BRANCH="main"
+        else
+          # Use git symbolic-ref to get the actual default branch
+          DEFAULT_BRANCH=$(git ls-remote --symref origin HEAD | head -n1 | cut -d$'\t' -f2 | sed 's|refs/heads/||')
+          if [ -z "$DEFAULT_BRANCH" ]; then
+            echo "Error: Could not determine default branch"
+            exit 1
+          fi
+        fi
+        
+        echo "DEFAULT_BRANCH=$DEFAULT_BRANCH" >> $GITHUB_ENV
+        echo "Detected default branch: $DEFAULT_BRANCH"
+
+    - name: Get current default branch version
+      shell: bash
+      run: |
+        DEFAULT_BRANCH="${{ env.DEFAULT_BRANCH }}"
+        
+        # Extract package.json first, then parse it with proper error checking
+        git show "origin/$DEFAULT_BRANCH:package.json" > /tmp/package_temp.json 2>/dev/null || {
+          echo "Error: Could not extract package.json from $DEFAULT_BRANCH branch"
+          echo "This is expected if the branch doesn't exist or package.json is missing"
+          exit 1
+        }
+        
+        # Parse the JSON file with proper error handling
+        if ! DEFAULT_BRANCH_VERSION=$(node -p "JSON.parse(require('fs').readFileSync('/tmp/package_temp.json', 'utf8')).version" 2>/dev/null); then
+          echo "Error: Could not parse version from $DEFAULT_BRANCH branch package.json"
+          echo "The file exists but JSON parsing failed"
+          rm -f /tmp/package_temp.json
+          exit 1
+        fi
+        
+        # Clean up temporary file
+        rm -f /tmp/package_temp.json
+        
+        echo "DEFAULT_BRANCH_VERSION=$DEFAULT_BRANCH_VERSION" >> $GITHUB_ENV
+        echo "Current $DEFAULT_BRANCH version: $DEFAULT_BRANCH_VERSION"
+
+    - name: Compare versions (simple numeric comparison)
+      shell: bash
+      run: |
+        NEW_VERSION="${{ inputs.new_version }}"
+        DEFAULT_BRANCH_VERSION="${{ env.DEFAULT_BRANCH_VERSION }}"
+        
+        # Simple version comparison for numeric versions (e.g., 1.2.3)
+        # Note: This project only uses numeric releases, so we keep this simple
+        # If comparison fails, we exit early (fail-safe approach)
+        version_compare() {
+          local v1="$1"
+          local v2="$2"
+          
+          # Parse version numbers (assumes X.Y.Z format)
+          IFS='.' read -r v1_major v1_minor v1_patch <<< "$v1"
+          IFS='.' read -r v2_major v2_minor v2_patch <<< "$v2"
+          
+          # Set defaults and validate numeric
+          v1_major=${v1_major:-0}
+          v1_minor=${v1_minor:-0}
+          v1_patch=${v1_patch:-0}
+          v2_major=${v2_major:-0}
+          v2_minor=${v2_minor:-0}
+          v2_patch=${v2_patch:-0}
+          
+          # Simple numeric comparison
+          if [ "$v1_major" -gt "$v2_major" ]; then return 0; fi
+          if [ "$v1_major" -lt "$v2_major" ]; then return 1; fi
+          if [ "$v1_minor" -gt "$v2_minor" ]; then return 0; fi
+          if [ "$v1_minor" -lt "$v2_minor" ]; then return 1; fi
+          if [ "$v1_patch" -gt "$v2_patch" ]; then return 0; fi
+          return 1
+        }
+        
+        if version_compare "$NEW_VERSION" "$DEFAULT_BRANCH_VERSION"; then
+          echo "✅ New version ($NEW_VERSION) > Default branch version ($DEFAULT_BRANCH_VERSION)"
+          echo "SHOULD_UPDATE=true" >> $GITHUB_ENV
+        else
+          echo "⏭️ New version ($NEW_VERSION) <= Default branch version ($DEFAULT_BRANCH_VERSION)"
+          echo "Skipping default branch update to preserve higher version"
+          echo "SHOULD_UPDATE=false" >> $GITHUB_ENV
+        fi
+
+    - name: Create safe branch name
+      if: env.SHOULD_UPDATE == 'true'
+      shell: bash
+      run: |
+        NEW_VERSION="${{ inputs.new_version }}"
+        DEFAULT_BRANCH="${{ env.DEFAULT_BRANCH }}"
+        
+        # Sanitize version for branch name
+        # Note: This project only uses numeric versions (e.g., 1.2.3) so minimal sanitization needed
+        SAFE_VERSION=$(echo "$NEW_VERSION" | sed 's/[^a-zA-Z0-9.-]/-/g')
+        echo "BRANCH_NAME=update-$DEFAULT_BRANCH-to-v$SAFE_VERSION" >> $GITHUB_ENV
+
+    - name: Extract and update files from default branch
+      if: env.SHOULD_UPDATE == 'true'
+      shell: bash
+      run: |
+        NEW_VERSION="${{ inputs.new_version }}"
+        DEFAULT_BRANCH="${{ env.DEFAULT_BRANCH }}"
+        
+        # Simple approach: Extract files directly, fail if any step fails
+        # Since PRs are manually reviewed, we don't need complex error handling
+        
+        # Extract package.json and update version
+        git show "origin/$DEFAULT_BRANCH:package.json" > package.json || exit 1
+        node -e "
+          const fs = require('fs');
+          const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8'));
+          pkg.version = '$NEW_VERSION';
+          fs.writeFileSync('package.json', JSON.stringify(pkg, null, 2) + '\n');
+        " || exit 1
+        
+        # Extract and update functions.php (Hello Elementor specific)
+        git show "origin/$DEFAULT_BRANCH:functions.php" > functions.php || exit 1
+        sed -i.bak "s/define( 'HELLO_ELEMENTOR_VERSION', '[^']*'/define( 'HELLO_ELEMENTOR_VERSION', '$NEW_VERSION' /" functions.php || exit 1
+        rm -f functions.php.bak
+        # Verify functions.php was actually updated
+        if ! grep -q "HELLO_ELEMENTOR_VERSION.*$NEW_VERSION" functions.php; then
+          echo "Error: Failed to update version in functions.php"
+          exit 1
+        fi
+        
+        # Extract and update style.css
+        git show "origin/$DEFAULT_BRANCH:style.css" > style.css || exit 1
+        sed -i.bak "s/Version: .*/Version: $NEW_VERSION/" style.css || exit 1
+        rm -f style.css.bak
+        # Verify style.css was actually updated
+        if ! grep -q "Version: $NEW_VERSION" style.css; then
+          echo "Error: Failed to update version in style.css"
+          exit 1
+        fi
+        
+        # Extract and update assets/scss/style.scss if it exists (Hello Theme specific)
+        if git show "origin/$DEFAULT_BRANCH:assets/scss/style.scss" > assets/scss/style.scss 2>/dev/null; then
+          mkdir -p assets/scss
+          sed -i.bak -e "s/Version: .*/Version: $NEW_VERSION/" -e "s/Stable tag: .*/Stable tag: $NEW_VERSION/" assets/scss/style.scss || exit 1
+          rm -f assets/scss/style.scss.bak
+          echo "✅ Updated assets/scss/style.scss"
+        else
+          echo "ℹ️ No assets/scss/style.scss found in $DEFAULT_BRANCH branch"
+        fi
+        
+        # Extract and update readme.txt
+        git show "origin/$DEFAULT_BRANCH:readme.txt" > readme.txt || exit 1
+        # Update fields that exist in the file
+        sed -i.bak -e "s/^Stable tag: .*/Stable tag: $NEW_VERSION/" -e "s/^Version: .*/Version: $NEW_VERSION/" readme.txt || exit 1
+        rm -f readme.txt.bak
+        
+        # Verify that fields were updated (check each field independently)
+        VALIDATION_PASSED=true
+        
+        # Check if Stable tag field exists and was updated
+        if grep -q "^Stable tag:" readme.txt; then
+          if ! grep -q "^Stable tag: $NEW_VERSION" readme.txt; then
+            echo "Error: Found 'Stable tag:' field but failed to update it to $NEW_VERSION"
+            VALIDATION_PASSED=false
+          else
+            echo "✅ Updated Stable tag to $NEW_VERSION"
+          fi
+        else
+          echo "ℹ️ No 'Stable tag:' field found in readme.txt"
+        fi
+        
+        # Check if Version field exists and was updated
+        if grep -q "^Version:" readme.txt; then
+          if ! grep -q "^Version: $NEW_VERSION" readme.txt; then
+            echo "Error: Found 'Version:' field but failed to update it to $NEW_VERSION"
+            VALIDATION_PASSED=false
+          else
+            echo "✅ Updated Version to $NEW_VERSION"
+          fi
+        else
+          echo "ℹ️ No 'Version:' field found in readme.txt"
+        fi
+        
+        if [ "$VALIDATION_PASSED" = "false" ]; then
+          echo "❌ readme.txt version update failed"
+          exit 1
+        fi
+        
+        echo "✅ readme.txt version update completed successfully"
+        
+        # Generate package-lock.json
+        npm install --package-lock-only || {
+          echo "Warning: npm install failed, continuing without package-lock.json update"
+          echo "This may be due to network issues, registry timeouts, or dependency conflicts"
+          echo "The version update will proceed without regenerating package-lock.json"
+        }
+        
+        echo "Successfully updated all files"
+
+    - name: Create pull request
+      if: env.SHOULD_UPDATE == 'true'
+      uses: peter-evans/create-pull-request@v5
+      with:
+        token: ${{ inputs.token }}
+        commit-message: "chore: update ${{ env.DEFAULT_BRANCH }} version to v${{ inputs.new_version }}"
+        branch: ${{ env.BRANCH_NAME }}
+        title: "Update ${{ env.DEFAULT_BRANCH }} version to v${{ inputs.new_version }}"
+        body: |
+          Update ${{ env.DEFAULT_BRANCH }} branch version to v${{ inputs.new_version }}
+          
+          **Version Update:**
+          - New version: v${{ inputs.new_version }}
+          - Previous ${{ env.DEFAULT_BRANCH }} version: v${{ env.DEFAULT_BRANCH_VERSION }}
+          
+          **Files updated:**
+          - package.json
+          - functions.php (HELLO_ELEMENTOR_VERSION)
+          - style.css
+          - readme.txt
+          - assets/scss/style.scss (if exists)
+          - package-lock.json
+          
+          Auto-generated by Hello Elementor release preparation workflow.
+          **Please review manually before merging.**
+        base: ${{ env.DEFAULT_BRANCH }}
+        add-paths: |
+          package.json
+          package-lock.json
+          functions.php
+          style.css
+          readme.txt
+          assets/scss/style.scss
diff --git a/.github/scripts/generate-upload-instructions-release.sh b/.github/scripts/generate-upload-instructions-release.sh
new file mode 100755
index 00000000..55291da2
--- /dev/null
+++ b/.github/scripts/generate-upload-instructions-release.sh
@@ -0,0 +1,69 @@
+#!/bin/bash
+
+# generate-upload-instructions-release.sh - Generate manual upload instructions for Hello Elementor theme
+
+set -e
+
+# Get current version
+PACKAGE_VERSION=$(node -p "require('./package.json').version")
+THEME_SLUG=$(node -p "require('./package.json').name")
+BUILD_ZIP="${THEME_SLUG}-${PACKAGE_VERSION}.zip"
+
+echo "📋 **Hello Elementor v${PACKAGE_VERSION} - Manual Upload Instructions**"
+echo ""
+echo "==================================================================="
+echo "🚀 RELEASE PREPARATION COMPLETE!"
+echo "==================================================================="
+echo ""
+echo "📦 **Package Details:**"
+echo "   - Theme: Hello Elementor"
+echo "   - Version: v${PACKAGE_VERSION}"
+echo "   - Build File: ${BUILD_ZIP}"
+echo "   - Theme Slug: ${THEME_SLUG}"
+echo ""
+echo "📋 **Manual Upload Steps:**"
+echo ""
+echo "1. **Download Release Package:**"
+echo "   - Go to GitHub Releases page"
+echo "   - Download: ${BUILD_ZIP}"
+echo "   - Verify file integrity and size"
+echo ""
+echo "2. **WordPress.org Upload:**"
+echo "   - Log into WordPress.org developer account"
+echo "   - Navigate to Hello Elementor theme page"
+echo "   - Upload the ${BUILD_ZIP} file"
+echo "   - Update theme description and changelog"
+echo ""
+echo "3. **Update Theme Repository:**"
+echo "   - Update theme directory README"
+echo "   - Verify theme screenshots and assets"
+echo "   - Update theme tags and compatibility"
+echo ""
+echo "4. **Post-Release Tasks:**"
+echo "   - Test theme installation from WordPress.org"
+echo "   - Update documentation and support materials"
+echo "   - Announce release on social media and forums"
+echo "   - Monitor for user feedback and issues"
+echo ""
+echo "⚠️  **Important Notes:**"
+echo "   - WordPress.org themes cannot be auto-published"
+echo "   - Manual review may be required by WordPress.org team"
+echo "   - Allow 24-48 hours for theme directory updates"
+echo "   - Keep GitHub release as backup distribution method"
+echo ""
+echo "✅ **Verification Checklist:**"
+echo "   □ Package downloaded successfully"
+echo "   □ Theme uploaded to WordPress.org"
+echo "   □ Theme description updated"
+echo "   □ Changelog entries correct"
+echo "   □ Theme tags and compatibility updated"
+echo "   □ Installation tested from WordPress.org"
+echo "   □ Release announced on appropriate channels"
+echo ""
+echo "🔗 **Quick Links:**"
+echo "   - GitHub Release: https://github.com/elementor/hello-theme/releases/tag/v${PACKAGE_VERSION}"
+echo "   - WordPress.org: https://wordpress.org/themes/hello-elementor/"
+echo ""
+echo "==================================================================="
+echo "For questions or issues, contact the development team."
+echo "==================================================================="
diff --git a/.github/scripts/get-changelog-from-readme-release.js b/.github/scripts/get-changelog-from-readme-release.js
new file mode 100644
index 00000000..4771dc4e
--- /dev/null
+++ b/.github/scripts/get-changelog-from-readme-release.js
@@ -0,0 +1,88 @@
+/* eslint-disable no-console */
+'use strict';
+
+// get-changelog-from-readme-release.js - Extract changelog from readme.txt for Hello Elementor releases
+
+const fs = require( 'fs' );
+const { VERSION } = process.env;
+
+if ( ! VERSION ) {
+	console.error( 'missing VERSION env var' );
+	process.exit( 1 );
+}
+
+// Try to load marked, fallback to simple parsing if not available
+let marked;
+try {
+	marked = require( 'marked' );
+} catch ( error ) {
+	console.log( 'marked not available, using simple parsing' );
+	marked = null;
+}
+
+// Simple changelog parser fallback
+function simpleParseChangelog( content, version ) {
+	const lines = content.split( '\n' );
+	let inChangelog = false;
+	let foundVersion = false;
+	const changelog = [];
+
+	for ( const line of lines ) {
+		if ( line.includes( '== Changelog ==' ) ) {
+			inChangelog = true;
+			continue;
+		}
+
+		if ( inChangelog ) {
+			if ( line.includes( `= ${ version } -` ) ) {
+				foundVersion = true;
+				changelog.push( line );
+				continue;
+			}
+
+			if ( foundVersion ) {
+				if ( line.startsWith( '=' ) && line.includes( '-' ) ) {
+					// Found next version, stop
+					break;
+				}
+				if ( line.trim() ) {
+					changelog.push( line );
+				}
+			}
+		}
+	}
+
+	return foundVersion ? changelog.join( '\n' ) : null;
+}
+
+// Main execution
+const readmeContent = fs.readFileSync( 'readme.txt', 'utf8' );
+
+let changelog;
+if ( marked ) {
+	// Use marked parser (original logic would go here)
+	console.log( 'Using marked parser' );
+	// For now, fallback to simple parser even with marked
+	changelog = simpleParseChangelog( readmeContent, VERSION );
+} else {
+	// Use simple parser
+	changelog = simpleParseChangelog( readmeContent, VERSION );
+}
+
+if ( ! changelog ) {
+	console.error( `❌ Changelog for version ${ VERSION } is missing` );
+	process.exit( 1 ); // Always fail if version is missing
+}
+
+// Write changelog to temp file only if it exists
+const changelogFile = 'temp-changelog-from-readme.txt';
+if ( changelog ) {
+  fs.writeFileSync( changelogFile, changelog );
+} else {
+  fs.writeFileSync( changelogFile, '' );
+}
+
+if ( changelog ) {
+  console.log( `✅ Successfully extracted Hello Elementor changelog for version ${ VERSION }` );
+  console.log( `Changelog saved to: ${ changelogFile }` );
+}
diff --git a/.github/scripts/validate-versions-release.sh b/.github/scripts/validate-versions-release.sh
new file mode 100755
index 00000000..65f4bdbd
--- /dev/null
+++ b/.github/scripts/validate-versions-release.sh
@@ -0,0 +1,70 @@
+#!/bin/bash
+set -eo pipefail
+
+# validate-versions-release.sh - Validate version consistency across Hello Elementor theme files
+
+echo "🔍 Validating Hello Elementor theme version consistency..."
+
+# Get expected version from package.json
+EXPECTED_VERSION=$(node -p "require('./package.json').version")
+echo "Expected version: $EXPECTED_VERSION"
+
+# Validate functions.php (Hello Theme uses HELLO_ELEMENTOR_VERSION)
+FUNC_VERSION=$(grep -E "define\( 'HELLO_ELEMENTOR_VERSION'" functions.php | awk -F"'" '{print $4}')
+if [ "$FUNC_VERSION" != "$EXPECTED_VERSION" ]; then
+  echo "❌ Version mismatch: functions.php ($FUNC_VERSION) != package.json ($EXPECTED_VERSION)"
+  exit 1
+fi
+echo "✅ functions.php HELLO_ELEMENTOR_VERSION: $FUNC_VERSION"
+
+# Validate style.css
+CSS_VERSION=$(grep -E "Version:" style.css | awk '{print $2}')
+if [ "$CSS_VERSION" != "$EXPECTED_VERSION" ]; then
+  echo "❌ Version mismatch: style.css ($CSS_VERSION) != package.json ($EXPECTED_VERSION)"
+  exit 1
+fi
+echo "✅ style.css Version: $CSS_VERSION"
+
+# Validate assets/scss/style.scss if it exists (Hello Theme specific)
+if [ -f "assets/scss/style.scss" ]; then
+  SCSS_VERSION=$(grep -E "Version:" assets/scss/style.scss | awk '{print $2}')
+  if [ "$SCSS_VERSION" != "$EXPECTED_VERSION" ]; then
+    echo "❌ Version mismatch: assets/scss/style.scss ($SCSS_VERSION) != package.json ($EXPECTED_VERSION)"
+    exit 1
+  fi
+  echo "✅ assets/scss/style.scss Version: $SCSS_VERSION"
+  
+  # Also check Stable tag in SCSS file
+  SCSS_STABLE_TAG=$(grep -E "Stable tag:" assets/scss/style.scss | awk '{print $3}')
+  if [ "$SCSS_STABLE_TAG" != "$EXPECTED_VERSION" ]; then
+    echo "❌ Version mismatch: assets/scss/style.scss Stable tag ($SCSS_STABLE_TAG) != package.json ($EXPECTED_VERSION)"
+    exit 1
+  fi
+  echo "✅ assets/scss/style.scss Stable tag: $SCSS_STABLE_TAG"
+else
+  echo "ℹ️ No assets/scss/style.scss found, skipping SCSS validation"
+fi
+
+# Validate readme.txt stable tag
+README_VERSION=$(grep -E "Stable tag:" readme.txt | awk '{print $3}')
+if [ "$README_VERSION" != "$EXPECTED_VERSION" ]; then
+  echo "❌ Version mismatch: readme.txt Stable tag ($README_VERSION) != package.json ($EXPECTED_VERSION)"
+  exit 1
+fi
+echo "✅ readme.txt Stable tag: $README_VERSION"
+
+# Validate readme.txt version field if it exists
+if grep -q "^Version:" readme.txt; then
+  README_VERSION_FIELD=$(grep -E "^Version:" readme.txt | awk '{print $2}')
+  if [ "$README_VERSION_FIELD" != "$EXPECTED_VERSION" ]; then
+    echo "❌ Version mismatch: readme.txt Version field ($README_VERSION_FIELD) != package.json ($EXPECTED_VERSION)"
+    exit 1
+  fi
+  echo "✅ readme.txt Version field: $README_VERSION_FIELD"
+else
+  echo "ℹ️ No Version field found in readme.txt"
+fi
+
+echo ""
+echo "🎉 All versions match: $EXPECTED_VERSION"
+echo "✅ Hello Elementor theme version validation passed!"
diff --git a/.github/workflows/release-preparation.yml b/.github/workflows/release-preparation.yml
new file mode 100644
index 00000000..31373fb4
--- /dev/null
+++ b/.github/workflows/release-preparation.yml
@@ -0,0 +1,350 @@
+name: 'Release Preparation (Hello Elementor)'
+
+on:
+  workflow_dispatch:
+    inputs:
+      release_branch:
+        type: string
+        description: 'Branch to create release from (e.g., main, 3.4, feature/xyz)'
+        required: true
+      version_type:
+        required: true
+        type: choice
+        description: 'Version increment type'
+        options:
+          - current  # For first release - keeps version as-is (3.4.4)
+          - patch    # 3.4.4 → 3.4.5
+          - minor    # 3.4.4 → 3.5.0  
+          - major    # 3.4.4 → 4.0.0
+      dry_run:
+        type: boolean
+        description: 'Dry run (test without creating actual release)?'
+        required: false
+        default: false
+      slack_channel:
+        type: string
+        description: 'Slack channel for notifications'
+        required: false
+        default: '#release'
+
+permissions:
+  contents: write
+  pull-requests: write
+  issues: write
+
+env:
+  NODE_VERSION: '18'
+  PHP_VERSION: '7.4'
+  COMPOSER_VERSION: '2'
+
+jobs:
+  release:
+    runs-on: ubuntu-22.04
+    # Workflow design: version files are bumped early, used for build/release, then automatically restored
+    # by peter-evans/create-pull-request action. Error cleanup ensures consistent state on any failure.
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          ref: ${{ inputs.release_branch }}
+          fetch-depth: 0
+      
+      - name: Load Release Configuration
+        id: config
+        run: |
+          echo "📋 Loading Hello Elementor release configuration..."
+          CONFIG_FILE=".github/config/release.json"
+          
+          if [ ! -f "$CONFIG_FILE" ]; then
+            echo "❌ Error: Release configuration file not found: $CONFIG_FILE"
+            exit 1
+          fi
+          
+          # Validate JSON syntax
+          if ! jq empty "$CONFIG_FILE" 2>/dev/null; then
+            echo "❌ Error: Invalid JSON in release configuration"
+            exit 1
+          fi
+          
+          # Load configuration values
+          ALLOWED_REPOS=$(jq -r '.security.allowed_repositories[]' "$CONFIG_FILE" | tr '\n' ' ')
+          BLOCKED_ACTORS=$(jq -r '.security.blocked_actors[]' "$CONFIG_FILE" | tr '\n' ' ')
+          RELEASE_BRANCHES=$(jq -r '.repository.release_branches[]' "$CONFIG_FILE" | tr '\n' ' ')
+          CONFIG_THEME_SLUG=$(jq -r '.release.wordpress_org.theme_slug' "$CONFIG_FILE")
+          
+          echo "ALLOWED_REPOS=$ALLOWED_REPOS" >> $GITHUB_ENV
+          echo "BLOCKED_ACTORS=$BLOCKED_ACTORS" >> $GITHUB_ENV
+          echo "RELEASE_BRANCHES=$RELEASE_BRANCHES" >> $GITHUB_ENV
+          echo "CONFIG_THEME_SLUG=$CONFIG_THEME_SLUG" >> $GITHUB_ENV
+          
+          echo "✅ Hello Elementor release configuration loaded successfully"
+      
+      - name: Pre-flight checks
+        run: |
+          echo "🔍 Pre-flight checks..."
+          echo "Release Branch: ${{ inputs.release_branch }}"
+          echo "Current Branch: ${{ github.ref_name }}"
+          echo "Version Type: ${{ inputs.version_type }}"
+          echo "Dry Run: ${{ inputs.dry_run }}"
+          echo "Repository: ${{ github.repository }}"
+          echo "Actor: ${{ github.actor }}"
+          
+          if [ "${{ inputs.dry_run }}" == "true" ]; then
+            echo "🧪 **DRY RUN MODE** - No actual release will be created"
+          fi
+          
+          # Repository permissions validation
+          REPO_ALLOWED=false
+          for allowed_repo in ${{ env.ALLOWED_REPOS }}; do
+            if [ "${{ github.repository }}" == "$allowed_repo" ]; then
+              REPO_ALLOWED=true
+              break
+            fi
+          done
+          
+          if [ "$REPO_ALLOWED" != "true" ]; then
+            echo "⚠️  Warning: Running on unauthorized repository: ${{ github.repository }}"
+          fi
+          
+          # Check actor permissions (basic validation)
+          for blocked_actor in ${{ env.BLOCKED_ACTORS }}; do
+            if [ "${{ github.actor }}" == "$blocked_actor" ]; then
+              echo "❌ Error: Blocked actor cannot create releases: ${{ github.actor }}"
+              exit 1
+            fi
+          done
+          
+          # Check if the specified branch exists
+          if ! git show-ref --verify --quiet refs/remotes/origin/${{ inputs.release_branch }}; then
+            echo "❌ Error: Branch '${{ inputs.release_branch }}' does not exist"
+            echo "💡 Available branches:"
+            git branch -r --format='%(refname:short)' | sed 's/origin\///' | head -10
+            exit 1
+          fi
+          
+          # Check if selected release branch is allowed (if configured)
+          if [ -n "${{ env.RELEASE_BRANCHES }}" ]; then
+            BRANCH_ALLOWED=false
+            for release_branch in ${{ env.RELEASE_BRANCHES }}; do
+              if [ "${{ inputs.release_branch }}" == "$release_branch" ]; then
+                BRANCH_ALLOWED=true
+                break
+              fi
+            done
+            
+            if [ "$BRANCH_ALLOWED" != "true" ]; then
+              echo "⚠️  Warning: Branch '${{ inputs.release_branch }}' is not in configured release branches"
+              echo "📋 Configured release branches: ${{ env.RELEASE_BRANCHES }}"
+              echo "🔄 Continuing anyway - remove this branch from release.json if releases should be blocked"
+            fi
+          fi
+          
+          # Check for uncommitted changes
+          if ! git diff --quiet; then
+            echo "❌ Error: Uncommitted changes found"
+            exit 1
+          fi
+          
+          echo "✅ Pre-flight checks passed"
+      
+      - name: Install Dependencies
+        uses: ./.github/actions/install-dependencies-release
+        with:
+          DEVOPS_TOKEN: ${{ secrets.DEVOPS_TOKEN }}
+          CLOUD_DEVOPS_TOKEN: ${{ secrets.CLOUD_DEVOPS_TOKEN }}
+      
+      - name: Get current version
+        id: current-version
+        run: |
+          PACKAGE_VERSION=$(node -p "require('./package.json').version")
+          echo "CLEAN_PACKAGE_VERSION=$PACKAGE_VERSION" >> $GITHUB_ENV
+          echo "Current Hello Elementor version: $PACKAGE_VERSION"
+      
+      - name: Bump Theme Version (Dry Run)
+        if: ${{ inputs.dry_run == true }}
+        run: |
+          echo "🧪 DRY RUN: Would bump Hello Elementor version from ${{ env.CLEAN_PACKAGE_VERSION }}"
+          
+          CURRENT_VERSION="${{ env.CLEAN_PACKAGE_VERSION }}"
+          IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
+          
+          case "${{ inputs.version_type }}" in
+            "current")
+              NEW_VERSION="$CURRENT_VERSION"
+              ;;
+            "major")
+              NEW_MAJOR=$((MAJOR + 1))
+              NEW_VERSION="$NEW_MAJOR.0.0"
+              ;;
+            "minor")
+              NEW_MINOR=$((MINOR + 1))
+              NEW_VERSION="$MAJOR.$NEW_MINOR.0"
+              ;;
+            "patch")
+              NEW_PATCH=$((PATCH + 1))
+              NEW_VERSION="$MAJOR.$MINOR.$NEW_PATCH"
+              ;;
+          esac
+          
+          echo "DRY_RUN_VERSION=$NEW_VERSION" >> $GITHUB_ENV
+          echo "PACKAGE_VERSION=$NEW_VERSION" >> $GITHUB_ENV
+          echo "🧪 DRY RUN: Version would be: $CURRENT_VERSION → $NEW_VERSION"
+          echo "🧪 DRY RUN: Changelog validation will use current version: $CURRENT_VERSION"
+      
+      - name: Bump Theme Version (Actual)
+        if: ${{ inputs.dry_run == false }}
+        uses: ./.github/actions/bump-theme-version-release
+        with:
+          CLEAN_PACKAGE_VERSION: ${{ env.CLEAN_PACKAGE_VERSION }}
+          VERSION_TYPE: ${{ inputs.version_type }}
+
+      - name: Validate current versions (Dry Run)
+        if: ${{ inputs.dry_run == true }}
+        run: |
+          CURRENT_VERSION=$(node -p "require('./package.json').version")
+          echo "🔍 Validating CURRENT versions ($CURRENT_VERSION)..."
+          bash .github/scripts/validate-versions-release.sh
+
+      - name: Validate changelog for updated version (Dry Run)
+        if: ${{ inputs.dry_run == true }}
+        uses: ./.github/actions/get-changelog-from-readme-release
+        with:
+          VERSION: ${{ env.DRY_RUN_VERSION }}
+
+      - name: Validate changelog for new version (Actual)
+        if: ${{ inputs.dry_run == false }}
+        uses: ./.github/actions/get-changelog-from-readme-release
+        with:
+          VERSION: ${{ env.PACKAGE_VERSION }}
+      
+      # Build with version-bumped files to ensure release assets contain correct versions
+      - name: Build Hello Elementor Theme
+        id: build
+        uses: ./.github/actions/build-theme-release
+        with:
+          PACKAGE_VERSION: ${{ env.PACKAGE_VERSION }}
+          BUILD_SCRIPT_PATH: "npm run package:zip"
+
+      - name: Create GitHub Release (Dry Run)
+        if: ${{ inputs.dry_run == true }}
+        run: |
+          echo "🧪 DRY RUN: Would create GitHub release"
+          echo "   - Tag: v${{ env.PACKAGE_VERSION }}"
+          echo "   - Build file: ${{ env.BUILD_ZIP_PATH }}"
+          echo "   - Changelog: ${{ env.CHANGELOG_FILE }}"
+          echo "RELEASE_URL=https://github.com/elementor/hello-theme/releases/tag/v${{ env.PACKAGE_VERSION }}" >> $GITHUB_ENV
+      
+      # Create GitHub release with version-bumped assets before repository cleanup
+      # This ensures the published release contains the correct version numbers
+      - name: Create GitHub Release (Actual)
+        if: ${{ inputs.dry_run == false }}
+        id: create-release
+        uses: softprops/action-gh-release@v1
+        with:
+          tag_name: v${{ env.PACKAGE_VERSION }}
+          name: Hello Elementor v${{ env.PACKAGE_VERSION }}
+          body_path: ${{ env.CHANGELOG_FILE }}
+          files: ${{ env.BUILD_ZIP_PATH }}
+          prerelease: false
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      # Repository maintenance steps happen after release creation
+      # Note: peter-evans/create-pull-request automatically restores working directory
+      # This design ensures release assets are created before any git cleanup occurs
+      
+      # Skip PR creation for 'current' version type since no version bump occurs
+      - name: Create PR With Bumped Version
+        if: ${{ inputs.dry_run == false && inputs.version_type != 'current' }}
+        uses: ./.github/actions/create-pr-with-bumped-theme-version-release
+        with:
+          base_branch: ${{ inputs.release_branch }}
+          # Use NEW_VERSION (bumped version) instead of CLEAN_PACKAGE_VERSION (old version)
+          # This ensures PR title/branch reflects the actual new version (e.g., "Release v3.4.5")
+          # Fallback to CLEAN_PACKAGE_VERSION for safety if NEW_VERSION is not set
+          package_version: ${{ env.NEW_VERSION || env.CLEAN_PACKAGE_VERSION }}
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      # Update main branch version if new version > main version
+      - name: Update Main Branch Version
+        if: ${{ inputs.dry_run == false && inputs.version_type != 'current' }}
+        uses: ./.github/actions/update-main-branch-version-release
+        with:
+          new_version: ${{ env.NEW_VERSION }}
+          token: ${{ secrets.GITHUB_TOKEN }}
+      
+      - name: Set Release URL
+        if: ${{ inputs.dry_run == false }}
+        run: |
+          echo "RELEASE_URL=${{ steps.create-release.outputs.html_url }}" >> $GITHUB_ENV
+      
+      - name: Send Slack Notification (Dry Run)
+        if: false
+        run: |
+          echo "🧪 DRY RUN: Would send Slack notification"
+          echo "   - Channel: ${{ inputs.slack_channel }}"
+          echo "   - Version: v${{ env.PACKAGE_VERSION }}"
+          echo "   - Message: Hello Elementor release preparation complete (DRY RUN)"
+      
+      - name: Slack Notification Skipped
+        if: ${{ inputs.dry_run == true }}
+        run: |
+          echo "📢 Slack notification skipped (release-preparation workflow)"
+          echo "   - Only full releases with WordPress.org deployment trigger Slack notifications"
+      
+      - name: Send Slack Notification (Actual)
+        if: false
+        uses: ./.github/actions/theme-slack-notification-release
+        with:
+          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
+          PACKAGE_VERSION: ${{ env.PACKAGE_VERSION }}
+          BUILD_ZIP_PATH: ${{ env.BUILD_ZIP_PATH }}
+          GITHUB_RELEASE_URL: ${{ env.RELEASE_URL }}
+          SLACK_CHANNEL: ${{ inputs.slack_channel }}
+          WPORG_DEPLOYMENT_STATUS: 'skipped'
+      
+      - name: Manual Upload Instructions
+        run: |
+          if [ "${{ inputs.dry_run }}" == "true" ]; then
+            echo "🧪 **DRY RUN COMPLETE!**"
+            echo ""
+            echo "📋 **This was a test run - no actual release was created**"
+            echo ""
+            echo "🔍 **What would have happened:**"
+            echo "1. Version would be bumped to: v${{ env.PACKAGE_VERSION }}"
+            echo "2. Hello Elementor theme would be built: ${{ env.BUILD_ZIP_PATH }}"
+            echo "3. GitHub release would be created: ${{ env.RELEASE_URL }}"
+            echo "4. Slack notification would be sent to #release"
+            echo ""
+            echo "✅ **Dry run validation passed - ready for actual release!**"
+          else
+            bash .github/scripts/generate-upload-instructions-release.sh
+          fi
+      
+      # Error recovery: restore repository to clean state on any workflow failure
+      # Design principle: always return to original branch state for consistency
+      # This prevents partial updates and ensures repository remains in sync with branch
+      - name: Cleanup on Error
+        if: ${{ always() && !inputs.dry_run && failure() }}
+        run: |
+          echo "🧹 Workflow failed - restoring to original state..."
+          
+          # Restore all version-bumped files to their original branch state
+          # This maintains consistency between working directory and remote branch
+          if ! git diff --quiet; then
+            echo "⚠️ Found modified files, restoring original versions..."
+            
+            # Restore specific files that were version-bumped earlier in workflow
+            git checkout -- package.json functions.php style.css readme.txt 2>/dev/null || true
+            git checkout -- assets/scss/style.scss 2>/dev/null || true
+            
+            echo "✅ Files restored to original state"
+          else
+            echo "ℹ️ Working directory already clean"
+          fi
+          
+          # Remove temporary files generated during workflow execution
+          rm -f temp-changelog-from-readme.txt 2>/dev/null || true
+          rm -f *.bak 2>/dev/null || true
+          
+          echo "🔍 Final state check:"
+          git status --porcelain || true

From 18615a198a03cde74eb9991b6e42ed3c1c7ef39f Mon Sep 17 00:00:00 2001
From: Hein van Vlastuin <hein@obox.co.za>
Date: Thu, 4 Sep 2025 14:13:18 +0200
Subject: [PATCH 2/3] Update build ignore

---
 .buildignore | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.buildignore b/.buildignore
index aeb894f6..e3e90448 100644
--- a/.buildignore
+++ b/.buildignore
@@ -11,6 +11,7 @@ npm-debug.log
 package-lock.json
 package.json
 phpcs.xml
+phpunit.xml
 README.md
 webpack.config.js
 .DS_Store
@@ -29,3 +30,5 @@ tests/
 test-results/
 tsconfig.json
 .wp-env.json
+.phpunit.result.cache
+temp-changelog-from-readme.txt

From d5e4d32c5dd5e64676738f37c49ec85a78fb22d3 Mon Sep 17 00:00:00 2001
From: Hein van Vlastuin <hein@obox.co.za>
Date: Thu, 4 Sep 2025 14:23:24 +0200
Subject: [PATCH 3/3] Fix: Make existing shell scripts executable

- Add execute permissions to Hello Theme shell scripts
- Resolves potential workflow execution issues
- Standard best practice for .sh files in repositories

Scripts updated:
- commit-push-bump.sh
- create-git-tag.sh
- get-release-branch-name.sh
- set-git-user.sh
- sync-branches.sh
---
 .github/scripts/commit-push-bump.sh        | 0
 .github/scripts/create-git-tag.sh          | 0
 .github/scripts/get-release-branch-name.sh | 0
 .github/scripts/set-git-user.sh            | 0
 .github/scripts/sync-branches.sh           | 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 .github/scripts/commit-push-bump.sh
 mode change 100644 => 100755 .github/scripts/create-git-tag.sh
 mode change 100644 => 100755 .github/scripts/get-release-branch-name.sh
 mode change 100644 => 100755 .github/scripts/set-git-user.sh
 mode change 100644 => 100755 .github/scripts/sync-branches.sh

diff --git a/.github/scripts/commit-push-bump.sh b/.github/scripts/commit-push-bump.sh
old mode 100644
new mode 100755
diff --git a/.github/scripts/create-git-tag.sh b/.github/scripts/create-git-tag.sh
old mode 100644
new mode 100755
diff --git a/.github/scripts/get-release-branch-name.sh b/.github/scripts/get-release-branch-name.sh
old mode 100644
new mode 100755
diff --git a/.github/scripts/set-git-user.sh b/.github/scripts/set-git-user.sh
old mode 100644
new mode 100755
diff --git a/.github/scripts/sync-branches.sh b/.github/scripts/sync-branches.sh
old mode 100644
new mode 100755