diff --git a/RELEASE_IMPLEMENTATION.md b/RELEASE_IMPLEMENTATION.md
new file mode 100644
index 00000000..3af3c020
--- /dev/null
+++ b/RELEASE_IMPLEMENTATION.md
@@ -0,0 +1,509 @@
+# Release Strategy Implementation Guide
+
+This guide walks you through implementing the tagging and release strategy for KROW Workforce.
+
+---
+
+## 📍 Phase 1: Initial Setup (Do This First)
+
+### Step 1: Review and Approve Strategy
+
+1. Read [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+2. Get team feedback
+3. Customize if needed (adjust cadence, naming, etc.)
+4. Commit to this approach
+
+### Step 2: Verify Current State
+
+Check current versions of all products:
+
+```bash
+# Mobile
+cat apps/mobile/apps/staff_app/pubspec.yaml | grep "^version:"
+cat apps/mobile/apps/client_app/pubspec.yaml | grep "^version:"
+
+# Web
+cat apps/web/package.json | grep '"version"'
+
+# Backend
+cat backend/command-api/package.json | grep '"version"'
+cat backend/core-api/package.json | grep '"version"'
+```
+
+Current expected state:
+```
+Staff Mobile: 0.1.0+?
+Client Mobile: 0.1.0+?
+Web Dashboard: 0.0.0
+Command API: 0.1.0
+Core API: 0.1.0
+```
+
+### Step 3: Create Initial Dev Tags
+
+Create retrospective tags for the current state. This establishes a baseline.
+
+```bash
+# Navigate to repo
+cd /Users/achintha/Documents/GitHub/krow-workforce
+
+# Create tags for current development versions
+# (These mark the current checkpoint, not retrospective releases)
+
+git tag -a staff-mobile/dev-v0.1.0 -m "Staff Mobile v0.1.0 - Initial development release"
+git tag -a client-mobile/dev-v0.1.0 -m "Client Mobile v0.1.0 - Initial development release"
+git tag -a web-dashboard/dev-v0.0.0 -m "Web Dashboard v0.0.0 - Pre-release"
+git tag -a command-api/dev-v0.1.0 -m "Command API v0.1.0 - Initial development release"
+git tag -a core-api/dev-v0.1.0 -m "Core API v0.1.0 - Initial development release"
+
+# Push all tags to remote
+git push origin --tags
+
+# Verify tags were created
+git tag -l "*" --sort=-version:refname
+```
+
+Expected output:
+```
+core-api/dev-v0.1.0
+command-api/dev-v0.1.0
+client-mobile/dev-v0.1.0
+staff-mobile/dev-v0.1.0
+web-dashboard/dev-v0.0.0
+```
+
+---
+
+## 📍 Phase 2: GitHub Configuration
+
+### Step 1: Enable Branch Protection for Production Tags
+
+1. Go to your GitHub repo → Settings → Branches
+2. Click "Add rule"
+3. Configure as follows:
+
+```
+Branch name pattern: */prod-v*
+
+Require a pull request before merging: ✅ ON
+Require approvals: ✅ ON (1+ approvals)
+Dismiss stale pull request approvals: ✅ ON
+Require status checks to pass: ✅ ON
+Require branches to be up to date before merging: ✅ ON
+Include administrators: ✅ ON
+Allow force pushes: ❌ OFF
+Allow deletions: ❌ OFF
+```
+
+4. Click "Create"
+
+### Step 2: Configure Required Status Checks
+
+Status checks that must pass before merging:
+- `build / test` - Unit and integration tests
+- `build / lint` - Code quality checks
+- `build / security-scan` - Security validation
+
+(These should already exist from your CI/CD pipeline)
+
+### Step 3: Setup Release Notes Template
+
+1. Go to Settings → Releases → Set up a release
+2. Add this template:
+
+```markdown
+## Release Notes: [Product] v[Version]
+
+**Release Date**: [Date]
+**Environment**: [dev/staging/prod]
+
+### 🎯 What's New
+
+### ✨ Features
+- Feature 1
+- Feature 2
+
+### 🔧 Improvements
+- Improvement 1
+- Improvement 2
+
+### 🐛 Bug Fixes
+- Bug fix 1
+- Bug fix 2
+
+### 📦 Dependencies & Compatibility
+
+**Requires:**
+- Backend API v[X.X.X] or higher
+- [Other dependencies]
+
+**Compatible with:**
+- [Previous version compatibility]
+
+### 📥 Installation
+
+[Download links and installation instructions]
+
+### ⚠️ Known Issues & Workarounds
+
+- Issue 1: [description] (Workaround: ...)
+
+### 🔄 Migration Guide
+
+[Steps for upgrading from previous version]
+
+### 📞 Support
+
+For issues: support@krow-workforce.com
+```
+
+---
+
+## 📍 Phase 3: CI/CD Integration (CodeMagic)
+
+### Update CodeMagic for Automated Tagging (Optional)
+
+Edit `codemagic.yaml` to automatically create tags on successful builds:
+
+```yaml
+workflows:
+  mobile-client-build:
+    on:
+      push:
+        branches:
+          - main
+    # ... existing config ...
+    
+    # Add this section
+    on_success:
+      - |
+        if [ "$CI_BRANCH" = "main" ]; then
+          VERSION=$(grep "^version:" apps/mobile/apps/client_app/pubspec.yaml | cut -d' ' -f2)
+          git tag -a client-mobile/dev-${VERSION} \
+            -m "Client Mobile ${VERSION} - Development build from CodeMagic"
+          git push origin client-mobile/dev-${VERSION}
+        fi
+```
+
+(Optional - can be done manually initially)
+
+---
+
+## 📍 Phase 4: Create Release Documentation
+
+### Copy Release Checklist Template
+
+Create a file for release planning:
+
+```bash
+mkdir -p docs/releases
+```
+
+Create `docs/releases/RELEASE_TEMPLATE.md`:
+
+```markdown
+# Release Plan: [Product] v[Version]
+
+**Status**: Draft / In Progress / Completed
+**Target Date**: [Date]
+**Release Manager**: [Name]
+
+## Scope
+
+[Description of features/fixes in this release]
+
+## Pre-Release Tasks (48h before)
+
+- [ ] All PRs merged and code reviewed
+- [ ] All tests green (unit, integration, E2E)
+- [ ] No lint/type errors
+- [ ] Mobile builds succeed on CodeMagic
+- [ ] Performance benchmarks acceptable
+- [ ] Security scan passed
+- [ ] CHANGELOG.md updated with all changes
+- [ ] Documentation updated
+- [ ] Staging environment prepared for testing
+
+## Release Day Tasks
+
+- [ ] Create release branch: `release/[product]-v[version]`
+- [ ] Update version in all relevant files
+- [ ] Commit and push release branch
+- [ ] Create git tags (staging)
+- [ ] Deploy to staging environment
+- [ ] Run smoke tests
+- [ ] Get sign-off from product owner
+
+## Post-Release Tasks (24h after)
+
+- [ ] Monitor error logs
+- [ ] Verify all features work end-to-end
+- [ ] Performance is acceptable
+- [ ] Create production tags
+- [ ] Deploy to production
+- [ ] Final verification
+- [ ] Create GitHub Release page
+- [ ] Announce release to users
+
+## Rollback Plan (if needed)
+
+```
+Issue Found: [description]
+Severity: Critical / High / Medium
+Action: Rollback to v[previous-version]
+Hotfix: [version bump plan]
+```
+
+## Outcomes
+
+**Release Date**: [Actual date]
+**Status**: ✅ Successful / ⚠️ Issues / 🚫 Rolled back
+
+[Additional notes]
+```
+
+---
+
+## 📍 Phase 5: Team Training
+
+### Create Runbook for Team
+
+Share [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) with your team
+
+### Conduct Training Session
+
+**Agenda (30 minutes):**
+1. Explain versioning strategy (5 min)
+2. Walk through release workflow (10 min)
+3. Demo: Create a test tag (10 min)
+4. Q&A (5 min)
+
+### Sample Demo Commands
+
+```bash
+# Everyone runs these to practice
+
+# 1. See existing tags
+git tag -l
+
+# 2. Create a test tag (won't push)
+git tag -a test/demo-v0.0.1 -m "Demo tag for training"
+
+# 3. View tag details
+git show test/demo-v0.0.1
+
+# 4. Delete test tag
+git tag -d test/demo-v0.0.1
+```
+
+---
+
+## 📍 Phase 6: First Real Release
+
+### Plan Your First Staging Release
+
+Let's do: **Staff Mobile v0.2.0** (next development version)
+
+### 1. Prepare Changes
+
+```bash
+# Make your feature/fix commits normally
+git checkout main
+git pull origin main
+
+# Create feature branches as usual
+git checkout -b feature/some-feature
+# ... make changes ...
+git commit -m "feat(staff-mobile): Add new feature"
+
+git push origin feature/some-feature
+# Create PR, review, merge
+```
+
+### 2. Create Release Branch
+
+```bash
+# Start release
+git checkout main
+git pull origin main
+git checkout -b release/staff-mobile-v0.2.0
+```
+
+### 3. Bump Version
+
+```bash
+# Edit: apps/mobile/apps/staff_app/pubspec.yaml
+# Change: version: 0.1.0+5 → version: 0.2.0+6
+
+nano apps/mobile/apps/staff_app/pubspec.yaml
+```
+
+### 4. Update CHANGELOG
+
+```bash
+nano CHANGELOG.md
+
+# Add at top:
+# | 2026-03-05 | Staff Mobile 0.2.0 | Feature: [description] |
+```
+
+### 5. Commit & Tag
+
+```bash
+git add .
+git commit -m "chore(staff-mobile): bump version to 0.2.0"
+git push origin release/staff-mobile-v0.2.0
+
+# Create and push tag
+git tag -a staff-mobile/staging-v0.2.0 -m "Staff Mobile v0.2.0 - Staging release"
+git push origin staff-mobile/staging-v0.2.0
+
+# Verify
+git tag -l "staff-mobile/*" --sort=-version:refname
+```
+
+### 6. Deploy & Test
+
+```bash
+# Deploy to staging environment
+# (Use your deployment scripts or manual process)
+
+# Run tests
+make test-mobile-staff
+
+# Get team QA approval
+```
+
+### 7. Promote to Production
+
+```bash
+# Create production tag
+git tag -a staff-mobile/prod-v0.2.0 -m "Staff Mobile v0.2.0 - Production release"
+git push origin staff-mobile/prod-v0.2.0
+
+# Deploy to production
+# (Use your deployment scripts)
+```
+
+### 8. Create GitHub Release
+
+1. Go to https://github.com/[your-org]/krow-workforce/releases
+2. Click "Draft a new release"
+3. Fill in:
+   - Tag: `staff-mobile/prod-v0.2.0`
+   - Title: `Staff Mobile v0.2.0`
+   - Description: Copy from CHANGELOG
+   - Add APK/AAB as attachments (if available)
+4. Click "Publish release"
+
+---
+
+## 📋 Communication Plan
+
+### For Each Release
+
+1. **Announcement** (release day)
+   ```
+   📱 Staff Mobile v0.2.0 released!
+   
+   Includes: [feature summary]
+   Available: [iOS/Android app stores]
+   ```
+
+2. **Status Updates** (during staging QA)
+   ```
+   🔄 Staff Mobile v0.2.0 in staging for testing
+   Expected production release: [date]
+   ```
+
+3. **Post-Release** (24h after)
+   ```
+   ✅ Staff Mobile v0.2.0 now in production
+   All systems normal. No issues reported.
+   ```
+
+4. **If Issues**
+   ```
+   ⚠️ Staff Mobile v0.2.0 - Hotfix in progress
+   Rollback to v0.1.0 - No impact to users
+   ETA for fix: [time]
+   ```
+
+---
+
+## 🔧 Troubleshooting
+
+### Problem: Tag Already Exists
+
+```bash
+# If you try to create a tag that exists:
+error: **/prod-v0.1.0 already exists
+
+# Solution: Delete and recreate
+git tag -d staff-mobile/dev-v0.1.0
+git push origin --delete staff-mobile/dev-v0.1.0
+git tag -a staff-mobile/dev-v0.1.0 -m "New message"
+git push origin staff-mobile/dev-v0.1.0
+```
+
+### Problem: Can't Push Tags
+
+```bash
+# Error: remote permission denied
+
+# Solution: Ensure you have push access
+git credential-osxkeychain erase host=github.com  # Re-authenticate
+# Then try again
+git push origin --tags
+```
+
+### Problem: Version Not Updated Everywhere
+
+```bash
+# Verify all locations have same version
+grep -r "0.2.0" apps/mobile/apps/*/pubspec.yaml
+grep '"0.2.0"' apps/web/package.json
+grep '"0.2.0"' backend/*/package.json
+grep 'build_version: "0.2.0"' codemagic.yaml
+
+# Update any missing locations
+```
+
+---
+
+## ✅ Validation Checklist
+
+After implementing this strategy, verify:
+
+- [ ] Initial dev tags created (v0.1.0 for all products)
+- [ ] GitHub branch protection configured for prod tags
+- [ ] Release template documented in repo
+- [ ] Team trained on release process
+- [ ] CHANGELOG.md in place and tracked
+- [ ] First staging release completed successfully
+- [ ] GitHub Release page created for first release
+- [ ] Communication plan working
+
+---
+
+## 🎯 Next Steps
+
+1. ✅ Review RELEASE_STRATEGY.md with team
+2. ✅ Complete Phase 1 setup (create initial tags)
+3. ✅ Configure GitHub (Phase 2)
+4. ⏳ First release (Staff Mobile v0.2.0) planned for [date]
+5. ⏳ Establish release cadence (weekly dev, bi-weekly staging, monthly prod)
+
+---
+
+## 📞 Questions?
+
+Reference documents:
+- [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) - Full strategy
+- [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) - Step-by-step workflows
+- [CHANGELOG.md](./CHANGELOG.md) - Version history
+
+---
+
+**Created**: 2026-03-05
+**Status**: Ready for Implementation
diff --git a/RELEASE_INDEX.md b/RELEASE_INDEX.md
new file mode 100644
index 00000000..1874c655
--- /dev/null
+++ b/RELEASE_INDEX.md
@@ -0,0 +1,411 @@
+# Release Documentation Index
+
+**🎯 Start here!** This page helps you find the right document for your needs.
+
+---
+
+## 🔍 Find What You Need
+
+### "I want to understand the release strategy"
+1. Start: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (15 min read)
+2. Visualize: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (10 min read)
+3. Deep dive: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
+
+### "I need to perform a release right now"
+1. Quick: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) (2 min scan)
+2. Execute: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) (find your scenario)
+3. Reference: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (which files to edit)
+
+### "I'm setting up the release process for the first time"
+1. Follow: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (Phase by phase)
+2. Configure: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) → GitHub section
+3. Train: Use [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) for team
+
+### "I need to train my team"
+1. Overview: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+2. Visuals: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (show diagrams)
+3. Hands-on: Walk through [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) together
+4. Reference: Give each [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+
+### "I'm doing a specific type of release"
+
+#### **Releasing Staff Mobile v0.2.0 (Single Product)**
+1. Steps: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Release a single product"
+2. Files: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) → "Staff Mobile App"
+3. Checklist: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Pre-tag checklist"
+
+#### **Coordinated Release All Products v1.0.0**
+1. Plan: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) → "Release Cadence"
+2. Execute: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Multi-Product Coordinated"
+3. Deploy: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → "Deployment Order"
+
+#### **Emergency Hotfix (Critical Bug)**
+1. Steps: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Hotfix Release"
+2. Fast: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Common Tasks"
+3. Order: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → "Hotfix Flow"
+
+### "I need to update version numbers"
+→ [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (Product-by-product guide)
+
+### "I need git commands"
+→ [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Quick Commands"
+
+### "I'm troubleshooting an issue"
+→ [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Troubleshoot"
+
+### "I need to communicate a release to stakeholders"
+→ [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → "Status Page Template"
+
+### "I want to automate releases"
+→ [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Automation Scripts"
+
+---
+
+## 📚 Document Overview
+
+### [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+**The Master Document**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | Canonical strategy reference |
+| **Audience** | Technical leads, architects |
+| **Length** | ~300 lines |
+| **Read Time** | 15-20 min |
+| **Key Topics** | Versioning, naming, cadence, dependency order, rollback |
+| **Use When** | Making strategic decisions |
+
+**Sections:**
+- Semantic Versioning strategy
+- Tag naming convention
+- Release cadence (dev/staging/prod)
+- Product dependencies
+- Release checklist
+- Protected tags setup
+- Rollback procedures
+
+---
+
+### [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
+**The Execution Guide**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | Step-by-step release instructions |
+| **Audience** | Developers, release engineers |
+| **Length** | ~400 lines |
+| **Read Time** | 20-30 min (skim) / 60 min (full) |
+| **Key Topics** | Quick start, multi-product, hotfix, git commands |
+| **Use When** | Actually performing a release |
+
+**Sections:**
+- Quick start (single product)
+- Multi-product coordinated release
+- Hotfix procedure with steps
+- Git commands reference
+- Useful scripts to create
+- Release checklist template
+
+---
+
+### [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
+**The Setup Guide**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | First-time setup and implementation |
+| **Audience** | DevOps, release engineering |
+| **Length** | ~500 lines |
+| **Read Time** | 30-45 min (planning) / 2-4 hours (execution) |
+| **Key Topics** | Initial setup, GitHub config, CI/CD, team training |
+| **Use When** | Setting up process for the first time |
+
+**Phases:**
+1. Initial setup (create baseline tags)
+2. GitHub configuration (branch protection)
+3. CI/CD integration
+4. Release documentation
+5. Team training
+6. First real release walkthrough
+
+---
+
+### [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
+**The Diagram Reference**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | Visual flows and process diagrams |
+| **Audience** | Everyone (visual learners) |
+| **Length** | ~400 lines |
+| **Read Time** | 15-20 min |
+| **Key Topics** | Pipelines, dependencies, timelines, templates |
+| **Use When** | Understanding processes, presentations |
+
+**Diagrams:**
+- Release pipeline overview
+- Product dependency & order
+- Git tag timeline
+- Release branch structure
+- Multi-product coordination
+- Hotfix flow
+- Version matrix dashboard
+
+---
+
+### [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+**The One-Page Reference**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | Quick lookup while working |
+| **Audience** | All team members |
+| **Length** | ~200 lines |
+| **Read Time** | 5 min (scan) |
+| **Key Topics** | Commands, naming, checklist, steps |
+| **Use When** | Quick lookup, print & pin to desk |
+
+**Includes:**
+- ⚡ Quick commands
+- 🏷️ Tag naming format
+- 📝 Pre-tag checklist
+- 🚀 Quick release steps
+- 📍 Version file locations
+- 🔄 Release timeline table
+- 📞 Common tasks
+
+**💡 Print this one!**
+
+---
+
+### [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
+**The File Locations Guide**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | Exact file locations and how to update |
+| **Audience** | Developers doing version bumps |
+| **Length** | ~350 lines |
+| **Read Time** | 5-10 min per product |
+| **Key Topics** | File paths, format, examples per product |
+| **Use When** | Updating version numbers |
+
+**Per Product:**
+- Staff Mobile App
+- Client Mobile App
+- Web Dashboard
+- Command API Backend
+- Core API Backend
+- DataConnect Schema
+- CHANGELOG.md
+
+---
+
+### [RELEASE_PACKAGE_SUMMARY.md](./RELEASE_PACKAGE_SUMMARY.md)
+**This Package Overview**
+
+| Aspect | Details |
+|--------|---------|
+| **Purpose** | Overview of all 6 documents |
+| **Audience** | New team members, anyone |
+| **Length** | ~400 lines |
+| **Read Time** | 15 min |
+| **Key Topics** | Package contents, usage paths, next steps |
+| **Use When** | Understanding what documents exist |
+
+**Includes:**
+- Complete package description
+- How to use each document
+- Current baseline versions
+- Immediate next steps
+- Feature checklist
+- Success metrics
+
+---
+
+## 🎯 Reading Paths by Role
+
+### Developer (Contributing Code)
+1. skim: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (5 min)
+2. keep: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) at desk
+3. when needed: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
+
+### Release Engineer
+1. read: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (full)
+2. master: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) (full)
+3. reference: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+4. check: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
+
+### Technical Lead / Architect
+1. read: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (full)
+2. review: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
+3. approve: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
+4. maintain: Update [RELEASE_PACKAGE_SUMMARY.md](./RELEASE_PACKAGE_SUMMARY.md)
+
+### Product Manager / Business Lead
+1. understand: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) → Release Cadence section
+2. visualize: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Status Page Template
+3. track: Version matrix dashboard
+4. share: Communicate timelines to users
+
+### New Team Member
+1. start: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (overview)
+2. watch: Team walkthrough of [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
+3. practice: Follow [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) with mentor
+4. reference: Keep [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) handy
+
+---
+
+## 🔗 Quick Links
+
+| Need | Go To |
+|------|-------|
+| Version numbers for all products | [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) |
+| How to release a single product | [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Quick Start |
+| Git commands | [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → Quick Commands |
+| Branch structure | [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Git Tag Timeline |
+| Hotfix steps | [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Hotfix Release |
+| Release checklist | [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → Checklist |
+| Automation scripts | [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Automation Scripts |
+| Dependency order | [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Dependency Diagram |
+| GitHub setup | [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) → Phase 2 |
+| Team training | [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) → Phase 5 |
+| Status communication | [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Status Page Template |
+
+---
+
+## 📅 Implementation Timeline
+
+```
+Week 1 (2026-03-05)
+├─ Read: RELEASE_STRATEGY.md
+├─ Review: RELEASE_VISUAL_GUIDE.md
+└─ Decide: Approve strategy with team
+
+Week 2 (2026-03-08)
+├─ Follow: RELEASE_IMPLEMENTATION.md Phase 1-2
+├─ Create: Initial dev tags (v0.1.0)
+└─ Configure: GitHub branch protection
+
+Week 3 (2026-03-15)
+├─ Plan: First staging release
+├─ Use: RELEASE_WORKFLOW.md
+├─ Reference: VERSION_FILES_REFERENCE.md
+└─ Check: RELEASE_QUICK_REFERENCE.md
+
+Week 4 (2026-03-22)
+├─ Execute: First production release
+├─ Monitor: 24 hours post-release
+└─ Document: Learnings in process
+
+Month 2+
+└─ Repeat: Establish release rhythm
+```
+
+---
+
+## ✅ Before You Start
+
+Make sure you have:
+
+- [ ] Read at least 2 documents from your reading path
+- [ ] Understood tag naming convention
+- [ ] Know location of version files for your product
+- [ ] Have git/GitHub access
+- [ ] Know deployment procedure for your environment
+- [ ] Know your team's approval process
+
+---
+
+## 🎓 Learning Path by Goal
+
+### "I want to perform a release in the next hour"
+1. skim: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) (5 min)
+2. reference: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (2 min)
+3. follow: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → your scenario (30 min)
+
+**Time: 40 minutes**
+
+### "I want to understand the full strategy"
+1. read: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (20 min)
+2. visualize: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (10 min)
+3. deep dive: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (30 min)
+4. reference: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (10 min)
+
+**Time: 70 minutes**
+
+### "I want to teach others"
+1. prep: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (20 min)
+2. visuals: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (10 min)
+3. demo: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Quick Start (30 min)
+4. handout: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+
+**Time: 60 minutes prep + 30 min teaching**
+
+---
+
+## 📞 Where to Find Things
+
+| Question | Document |
+|----------|----------|
+| What's our versioning scheme? | RELEASE_STRATEGY.md |
+| How do I name tags? | RELEASE_QUICK_REFERENCE.md |
+| What files do I need to edit? | VERSION_FILES_REFERENCE.md |
+| How do I release a product? | RELEASE_WORKFLOW.md |
+| Where do I get started? | RELEASE_IMPLEMENTATION.md |
+| Show me diagrams | RELEASE_VISUAL_GUIDE.md |
+| Quick git commands | RELEASE_QUICK_REFERENCE.md |
+| Deployment order? | RELEASE_VISUAL_GUIDE.md |
+| Hotfix steps? | RELEASE_WORKFLOW.md |
+| Team training? | RELEASE_IMPLEMENTATION.md |
+
+---
+
+## 🎯 Success Criteria
+
+After reading appropriate docs, you should know:
+
+- ✅ What semantic versioning means
+- ✅ How to name a git tag
+- ✅ Which files control versions for each product
+- ✅ The three environment levels (dev/staging/prod)
+- ✅ The product deployment order
+- ✅ Where to find version files
+- ✅ How to execute a release
+- ✅ What to do if something goes wrong
+- ✅ How to communicate a release
+
+---
+
+## 💡 Pro Tips
+
+1. **Bookmark** this index page
+2. **Print** [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+3. **Share** [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) in presentations
+4. **Reference** [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) every release
+5. **Update** as your process evolves
+
+---
+
+## 📞 Questions?
+
+1. **How?** → Look in [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
+2. **What file?** → Look in [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
+3. **Git command?** → Look in [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+4. **Strategy?** → Look in [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+5. **Diagram?** → Look in [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
+6. **Can't find it?** → Ask in #releases on Slack
+
+---
+
+## 🚀 Ready?
+
+Pick your path above and start reading. You've got this! 
+
+**Questions? Ask in #releases**
+
+---
+
+**Created**: 2026-03-05  
+**Last Updated**: 2026-03-05  
+**Version**: 1.0
diff --git a/RELEASE_PACKAGE_SUMMARY.md b/RELEASE_PACKAGE_SUMMARY.md
new file mode 100644
index 00000000..5557874e
--- /dev/null
+++ b/RELEASE_PACKAGE_SUMMARY.md
@@ -0,0 +1,507 @@
+# Release Strategy - Complete Package Summary
+
+**Created**: 2026-03-05  
+**Status**: Ready for Implementation  
+**Document Set**: Complete & Integrated
+
+---
+
+## 📚 What Was Created
+
+A complete, production-ready release and tagging strategy for the KROW Workforce monorepo with 5 independent products.
+
+### Documents Included
+
+#### 1. **RELEASE_STRATEGY.md** 📖
+**Purpose**: The canonical strategy document  
+**Contents**:
+- Semantic versioning approach (SemVer)
+- Git tag naming convention
+- Release cadence (dev/staging/prod)
+- Deployment dependency order
+- Release checklist
+- Protected tag rules
+- Version file locations
+- Rollback procedures
+
+**Audience**: Technical leads, team members planning releases  
+**Length**: ~300 lines  
+**Use When**: Making strategic decisions about releases
+
+---
+
+#### 2. **RELEASE_WORKFLOW.md** 🔧
+**Purpose**: Step-by-step execution guide  
+**Contents**:
+- Quick start release (single product)
+- Multi-product coordinated release
+- Hotfix procedure
+- Useful git commands
+- Automation scripts to create
+- Release checklist template
+
+**Audience**: Developers and release engineers executing releases  
+**Length**: ~400 lines  
+**Use When**: Actually performing a release
+
+---
+
+#### 3. **RELEASE_IMPLEMENTATION.md** 🚀
+**Purpose**: Setup and first-release guide  
+**Contents**:
+- Phase 1: Initial setup (create baseline tags)
+- Phase 2: GitHub configuration (branch protection)
+- Phase 3: CI/CD integration
+- Phase 4: Release documentation
+- Phase 5: Team training
+- Phase 6: First real release walkthrough
+- Communication plan
+- Troubleshooting
+
+**Audience**: DevOps/Release engineering team  
+**Length**: ~500 lines  
+**Use When**: Setting up the release process for the first time
+
+---
+
+#### 4. **RELEASE_VISUAL_GUIDE.md** 📊
+**Purpose**: ASCII diagrams and visual references  
+**Contents**:
+- Release pipeline overview (flowchart)
+- Product dependency diagram
+- Git tag timeline example
+- Release branch structure diagram
+- Multi-product release coordination
+- Hotfix flow diagram
+- Version matrix dashboard template
+- Release timeline template
+- Status page template
+
+**Audience**: Everyone (visual learners, quick reference)  
+**Length**: ~400 lines  
+**Use When**: Understanding the flow, presentations, team communication
+
+---
+
+#### 5. **RELEASE_QUICK_REFERENCE.md** 🎯
+**Purpose**: One-page quick reference (print-friendly)  
+**Contents**:
+- Quick commands
+- Tag naming format
+- Pre-tag checklist
+- Quick release steps
+- Version file locations
+- Release timeline table
+- Common tasks with code examples
+- Deployment order
+- Red flags to avoid
+- Troubleshooting
+
+**Audience**: All team members  
+**Length**: ~200 lines  
+**Use When**: Quick lookup while working
+
+**💡 Tip**: Print this and pin to your desk!
+
+---
+
+#### 6. **VERSION_FILES_REFERENCE.md** 📝
+**Purpose**: Exact file locations and update instructions  
+**Contents**:
+- Staff Mobile pubspec.yaml location
+- Client Mobile pubspec.yaml location
+- Web Dashboard package.json location
+- Command API package.json location
+- Core API package.json location
+- DataConnect schema version (if applicable)
+- CHANGELOG.md (all products)
+- Release checklist per product
+- Version update template script
+- Common mistakes
+- Pro tips
+
+**Audience**: Developers doing version bumps  
+**Length**: ~350 lines  
+**Use When**: Updating version numbers for a release
+
+---
+
+## 🎯 How to Use This Package
+
+### For Your First Release
+
+1. **Read** [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (strategic overview)
+2. **Follow** [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (Phase 1-6 setup)
+3. **Reference** [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (exact files to update)
+4. **Execute** [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) (step-by-step)
+5. **Check** [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (understand the flow)
+6. **Keep** [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) handy
+
+### For Ongoing Releases
+
+**Quick path:**
+1. [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) - Commands & checklist
+2. [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) - Which files to update
+3. [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) - Copy the relevant section
+4. [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) - Verify deployment order
+
+### For Team Training
+
+1. **Share** [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) with team
+2. **Show** [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) diagrams
+3. **Walk through** [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) quick start
+4. **Provide** [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) as handout
+5. **Reference** [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) when needed
+
+### For CI/CD Setup
+
+1. Review automation sections in [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
+2. Set up GitHub branch protection per [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
+3. Configure CodeMagic per [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+
+---
+
+## 🏷️ Quick Reference: Tag Naming
+
+```
+Format: <product>/<environment>-v<version>
+
+Staff Mobile Example:     staff-mobile/prod-v1.0.0
+Client Mobile Example:    client-mobile/prod-v1.0.0
+Web Dashboard Example:    web-dashboard/staging-v0.1.0
+Command API Example:      command-api/dev-v0.2.0
+Core API Example:         core-api/prod-v0.1.0
+
+Environments:
+  dev      → Development releases (daily/weekly)
+  staging  → Pre-production releases (bi-weekly)
+  prod     → Production releases (monthly)
+```
+
+---
+
+## 📊 Current Baseline Versions
+
+Based on your repository state (2026-03-05):
+
+| Product | Current Version | Status |
+|---------|-----------------|--------|
+| Staff Mobile | 0.1.0 | Development |
+| Client Mobile | 0.1.0 | Development |
+| Web Dashboard | 0.0.0 | Pre-release |
+| Command API | 0.1.0 | Development |
+| Core API | 0.1.0 | Development |
+
+**Next Releases**:
+- Q1 2026: v0.2.0 (staging)
+- Q2 2026: v1.0.0 (production)
+
+---
+
+## 🚀 Immediate Next Steps
+
+### This Week (2026-03-05)
+
+- [ ] Read [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+- [ ] Review with team
+- [ ] Get approval to proceed
+
+### Next Week (2026-03-08)
+
+- [ ] Follow [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) Phase 1-2
+- [ ] Create initial dev tags (baseline v0.1.0)
+- [ ] Configure GitHub branch protection for prod tags
+- [ ] Train team on new process
+
+### Week of Release (2026-03-15)
+
+- [ ] Plan first staging release (Staff Mobile v0.2.0)
+- [ ] Update version all files per [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
+- [ ] Execute release using [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
+- [ ] Deploy to staging and test
+
+### Within 30 Days
+
+- [ ] First production release (any product)
+- [ ] Establish release cadence
+- [ ] Document any customizations
+- [ ] Refine process based on learnings
+
+---
+
+## ✅ Feature Checklist
+
+This release strategy includes:
+
+- ✅ **Semantic Versioning (SemVer)** - Industry standard
+- ✅ **Product-specific Tags** - Independent version tracking
+- ✅ **Environment Separation** - dev/staging/prod releases
+- ✅ **Dependency Management** - Clear deployment order
+- ✅ **Rollback Procedures** - Handling production issues
+- ✅ **Hotfix Process** - Emergency fixes
+- ✅ **Branch Protection** - GitHub security rules
+- ✅ **Documentation** - Comprehensive guides
+- ✅ **Templates** - Checklists and scripts
+- ✅ **Visual Diagrams** - Process flows
+- ✅ **Quick Reference** - Print-friendly guide
+- ✅ **Version File Map** - Exact file locations
+- ✅ **Communication Plan** - Stakeholder updates
+- ✅ **Team Training** - Learning materials
+- ✅ **Automation Scripts** - CI/CD integration
+
+---
+
+## 📋 File Structure
+
+```
+Repository Root
+├── RELEASE_STRATEGY.md              ← Strategic overview
+├── RELEASE_WORKFLOW.md              ← Step-by-step execution
+├── RELEASE_IMPLEMENTATION.md        ← Setup guide
+├── RELEASE_VISUAL_GUIDE.md          ← Diagrams & flows
+├── RELEASE_QUICK_REFERENCE.md       ← One-page reference
+├── VERSION_FILES_REFERENCE.md       ← File locations
+│
+├── CHANGELOG.md                     ← Version history (existing)
+├── codemagic.yaml                   ← CI/CD config (existing)
+│
+└── apps/
+    ├── mobile/
+    │   ├── apps/
+    │   │   ├── staff_app/pubspec.yaml      ← Staff Mobile version
+    │   │   └── client_app/pubspec.yaml     ← Client Mobile version
+    │   └── ...
+    │
+    └── web/
+        └── package.json             ← Web Dashboard version
+
+backend/
+├── command-api/package.json         ← Command API version
+└── core-api/package.json            ← Core API version
+```
+
+---
+
+## 🔐 Security & Best Practices
+
+### Branch Protection
+- Production tags (`prod-v*`) require pull request review
+- Require status checks to pass
+- Require branches up-to-date
+- Prevent force pushes
+
+### Rollback Safety
+- Always keep previous version available
+- Test rollback procedure regularly
+- Document rollback steps
+- Communicate with users
+
+### Change Tracking
+- CHANGELOG.md for all product updates
+- Git history for code changes
+- Tags for release checkpoints
+- GitHub Releases for user communication
+
+---
+
+## 💡 Tips for Success
+
+### 1. Start Small
+Begin with a single product release (e.g., Staff Mobile v0.2.0) to practice the process.
+
+### 2. Establish Rhythm
+Consistent release cadence makes it easier for everyone:
+- Dev: Weekly
+- Staging: Bi-weekly
+- Prod: Monthly
+
+### 3. Automate Wisely
+Start manual to understand the process, then automate repetitive tasks.
+
+### 4. Communicate Early
+Announce release plans before deployment, not after.
+
+### 5. Monitor Actively
+24-hour post-release monitoring catches issues early.
+
+### 6. Document Learnings
+Update these guides based on real experience with your releases.
+
+---
+
+## 🐛 Troubleshooting
+
+### I'm confused about which file to edit
+→ See [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
+
+### I need step-by-step release instructions
+→ See [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
+
+### I need git commands
+→ See [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+
+### I need to understand the overall strategy
+→ See [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+
+### I need to set up the process for the first time
+→ See [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
+
+### I need visual diagrams
+→ See [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
+
+---
+
+## 📞 Additional Resources
+
+### Related Documentation
+- [CHANGELOG.md](./CHANGELOG.md) - Current version history
+- [codemagic.yaml](./codemagic.yaml) - CI/CD configuration
+- [docs/ARCHITECTURE/system-bible.md](./docs/ARCHITECTURE/system-bible.md) - System design
+- [README.md](./README.md) - Project overview
+
+### External References
+- [Semantic Versioning 2.0.0](https://semver.org)
+- [Git Tagging](https://git-scm.com/docs/git-tag)
+- [GitHub Releases](https://docs.github.com/en/repositories/releasing-projects-on-github)
+- [Git Workflow Best Practices](https://git-scm.com/book/en/v2)
+
+---
+
+## 👥 Team Roles
+
+### Release Manager
+- Plans release schedule
+- Creates tags
+- Coordinates deployment
+- Monitors post-release
+
+### Developers
+- Ensure code is release-ready
+- Update version files per checklist
+- Update CHANGELOG
+- Test releases
+
+### DevOps/Infrastructure
+- Configure branch protection
+- Set up CI/CD automations
+- Deploy to environments
+- Monitor infrastructure
+
+### Product Owner
+- Approves staging releases
+- Signs off before production
+- Communicates with users
+- Handles rollback decisions
+
+### QA Team
+- Tests staged releases
+- Verifies production deployments
+- Reports issues
+- Validates rollbacks
+
+---
+
+## 📊 Success Metrics
+
+Track these metrics for each release:
+
+- **Lead Time**: Time from commit to production
+- **Deployment Frequency**: How often you release
+- **Change Failure Rate**: % of releases needing rollback
+- **Mean Time to Recovery**: Time to fix issues
+- **Automation Coverage**: % of tasks automated
+- **User Adoption**: % of users on latest version
+- **Issue Detection**: Time from deployment to issue detection
+
+---
+
+## 🎓 Knowledge Sharing
+
+### For New Team Members
+1. Have them read [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
+2. Run through [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) together
+3. Have them perform a dev release under supervision
+4. Give them [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) as reference
+
+### For Leadership
+Share [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) status page template to track releases across products.
+
+### For Stakeholders
+Use templates provided to communicate:
+- Release announcements
+- Feature summaries
+- Deployment windows
+- Known issues
+
+---
+
+## 📅 Release Calendar Template
+
+```
+March 2026
+┌─────────────────────────────────────┐
+│ 01 (Sun)  Code Freeze              │
+│ 05 (Thu)  Staging Release (0.2.0)  │
+│ 08 (Sun)  QA Complete              │
+│ 15 (Sun)  Production Release       │
+│ 22 (Sun)  Monitoring & Stability   │
+│ 29 (Sun)  Next Cycle Begins        │
+└─────────────────────────────────────┘
+
+Every Monday: Release Sync Meeting
+Every Friday: Status Update
+Rolling: Release documentation updates
+```
+
+---
+
+## ✨ Next Phase
+
+Once this strategy is implemented and proven with 2-3 releases:
+
+1. **Automation**: GitHub Actions to auto-tag on version change
+2. **Metrics**: Dashboard tracking deployment metrics
+3. **Communication**: Slack/email bot announcing releases
+4. **Deployment**: Fully automated deployments per product
+5. **Analytics**: Track adoption and issue post-release
+
+---
+
+## 📝 Document Maintenance
+
+**When to update these guides:**
+- After every major release (capture learnings)
+- When process changes
+- When team feedback warrants updates
+- When new tools are integrated
+- When scaling to new products
+
+**Who maintains:**
+- DevOps/Release engineering team
+- Approved by: Technical leads, Product management
+
+**Review Cycle:**
+- Quarterly review of all documents
+- Monthly: CHANGELOG.md updates
+- As-needed: Bug fixes, clarifications
+
+---
+
+## 🎉 You're Ready!
+
+This complete release strategy is ready to implement. Start with [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) and follow the phases.
+
+**Questions?**
+- Review the relevant guide above
+- Consult [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
+- Ask your DevOps team
+
+**Let's ship v1.0.0! 🚀**
+
+---
+
+**Package Version**: 1.0  
+**Created**: 2026-03-05  
+**Last Updated**: 2026-03-05  
+**Status**: Ready for Production  
+**Maintainer**: DevOps/Release Engineering Team
diff --git a/RELEASE_QUICK_REFERENCE.md b/RELEASE_QUICK_REFERENCE.md
new file mode 100644
index 00000000..b1dfbe88
--- /dev/null
+++ b/RELEASE_QUICK_REFERENCE.md
@@ -0,0 +1,267 @@
+# Release Quick Reference Card
+
+**Print this and pin it to your desk! 📌**
+
+---
+
+## ⚡ Quick Commands
+
+### View All Tags
+```bash
+git tag -l "*" --sort=-version:refname
+```
+
+### View Tags for One Product
+```bash
+git tag -l "staff-mobile/*" --sort=-version:refname
+```
+
+### Create a Tag
+```bash
+git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"
+git push origin staff-mobile/dev-v0.2.0
+```
+
+### See What's in a Tag
+```bash
+git show staff-mobile/prod-v0.1.0
+git log staff-mobile/prod-v0.1.0 -5 --oneline
+```
+
+### Delete a Tag
+```bash
+git tag -d staff-mobile/dev-v0.1.0      # Local
+git push origin --delete staff-mobile/dev-v0.1.0  # Remote
+```
+
+---
+
+## 🏷️ Tag Naming Format
+
+```
+<product>/<environment>-v<major>.<minor>.<patch>
+
+Examples:
+  staff-mobile/dev-v0.2.0
+  client-mobile/staging-v0.2.0
+  web-dashboard/prod-v1.0.0
+  command-api/prod-v0.1.1
+```
+
+**Products:**
+- `staff-mobile` / `client-mobile`
+- `web-dashboard`
+- `command-api` / `core-api`
+- `dataconnect`
+
+**Environments:**
+- `dev` (development, unstable)
+- `staging` (pre-production, testing)
+- `prod` (production, stable)
+
+---
+
+## 📝 Checklist: Before You Tag
+
+- [ ] Code review completed
+- [ ] All tests passing locally
+- [ ] CHANGELOG.md updated
+- [ ] Version numbers updated in:
+  - [ ] `apps/mobile/apps/*/pubspec.yaml` (if mobile)
+  - [ ] `apps/web/package.json` (if web)
+  - [ ] `backend/*/package.json` (if backend)
+  - [ ] `codemagic.yaml` (if mobile)
+- [ ] Committed and pushed changes
+- [ ] Ready to merge release branch
+
+---
+
+## 🚀 Create a Release (Quick Steps)
+
+```
+1. Update version numbers
+   (See "Version File Locations" below)
+
+2. Update CHANGELOG.md
+   Add line at top with date and version
+
+3. Commit & push
+   git commit -m "chore: bump to v0.2.0"
+   git push origin release/branch-name
+
+4. Create tag
+   git tag -a product/env-v0.2.0 -m "Description"
+   git push origin product/env-v0.2.0
+
+5. Create GitHub Release
+   Go to Releases → Draft new release
+   Select tag → Fill in details → Publish
+
+6. Deploy
+   (Follow your deployment script)
+
+7. Monitor
+   Check logs for 24 hours
+```
+
+---
+
+## 📍 Version File Locations
+
+**Quick edit list for version bumps:**
+
+### Mobile (Staff & Client)
+- [ ] `apps/mobile/apps/staff_app/pubspec.yaml`
+- [ ] `apps/mobile/apps/client_app/pubspec.yaml`
+
+Format: `version: X.Y.Z+N` (N = build number)
+
+### Web
+- [ ] `apps/web/package.json`
+
+Format: `"version": "X.Y.Z"`
+
+### Backend
+- [ ] `backend/command-api/package.json`
+- [ ] `backend/core-api/package.json`
+
+Format: `"version": "X.Y.Z"`
+
+### CI/CD
+- [ ] `codemagic.yaml`
+
+Format: `build_version: "X.Y.Z"`
+
+**Also update CHANGELOG.md!**
+
+---
+
+## 🔄 Release Timeline At-a-Glance
+
+| Stage | Duration | Environment | Status | Next Step |
+|-------|----------|-------------|--------|-----------|
+| **Feature Dev** | 1-2 weeks | Local | 👨‍💻 In progress | Code review |
+| **Code Review** | 1-3 days | GitHub | 👀 Reviewing | Merge to main |
+| **Dev Release** | Same day | Dev env | ✅ Deployed | Weekly |
+| **Staging Release** | 1 week | Staging | 🧪 Testing | QA sign-off |
+| **Prod Release** | 2-3 hours | Production | 🚀 Deploying | 24h monitoring |
+
+---
+
+## 📞 Common Tasks
+
+### I want to release Staff Mobile v0.2.0
+```bash
+git checkout -b release/staff-mobile-v0.2.0
+# Edit: apps/mobile/apps/staff_app/pubspec.yaml (0.1.0 → 0.2.0)
+# Edit: CHANGELOG.md (add entry)
+git add .
+git commit -m "chore: staff mobile v0.2.0"
+git push origin release/staff-mobile-v0.2.0
+# Create PR, get approved, merge
+git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"
+git push origin staff-mobile/dev-v0.2.0
+```
+
+### I found a critical bug in production
+```bash
+git checkout -b hotfix/staff-mobile-v0.1.1 staff-mobile/prod-v0.1.0
+# Fix the bug
+# Bump version 0.1.0 → 0.1.1 in pubspec.yaml
+git commit -m "fix: [critical issue]"
+git tag -a staff-mobile/prod-v0.1.1 -m "Hotfix: [issue]"
+git push origin staff-mobile/prod-v0.1.1
+# Deploy immediately, monitor 24h
+```
+
+### I want to see all production versions
+```bash
+git tag -l "*/prod-v*" --sort=-version:refname
+```
+
+### I want to compare two versions
+```bash
+git log staff-mobile/prod-v0.1.0...staff-mobile/prod-v0.2.0 --oneline
+```
+
+---
+
+## 🎯 Deployment Order (Multi-Product Release)
+
+Always deploy in this order:
+
+1. **DataConnect** (if schema changed)
+2. **Command API** + **Core API** (can be parallel)
+3. **Web Dashboard**
+4. **Staff Mobile** + **Client Mobile** (can be parallel)
+
+Verify each step completes before moving to next.
+
+---
+
+## ⚠️ Red Flags 🚫
+
+**DON'T tag if:**
+- ❌ Tests are failing
+- ❌ Code review not approved
+- ❌ CHANGELOG not updated
+- ❌ Version numbers not bumped
+- ❌ Breaking changes not documented
+- ❌ Staging not tested yet
+- ❌ Team not notified
+
+**DO tag if:**
+- ✅ All tests passing
+- ✅ Code reviewed + approved
+- ✅ CHANGELOG updated
+- ✅ Version numbers consistent
+- ✅ Staged and tested
+- ✅ Team aware
+
+---
+
+## 🆘 Troubleshoot
+
+**Tag won't push:**
+```bash
+# Make sure you have push permissions
+git config --list | grep remote.origin.url
+# Re-authenticate if needed
+git credential-osxkeychain erase host=github.com
+```
+
+**Wrong tag created:**
+```bash
+git tag -d wrong-tag
+git push origin --delete wrong-tag
+git tag -a correct-tag -m "message"
+git push origin correct-tag
+```
+
+**Need to see what changed:**
+```bash
+git log v0.1.0..v0.2.0 --oneline
+git diff v0.1.0..v0.2.0 -- apps/mobile/
+```
+
+---
+
+## 📚 Full Documentation
+
+For complete details, see:
+- 📖 [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) - Full strategy
+- 🔧 [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) - Step-by-step
+- 🚀 [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) - Setup guide
+- 📊 [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) - Diagrams
+
+---
+
+## 📞 Contact
+
+**Release Questions?** Slack: #releases
+**Need Help?** Check RELEASE_WORKFLOW.md or ask DevOps team
+
+---
+
+**Last Updated**: 2026-03-05
+**Bookmark this page! 🔖**
diff --git a/RELEASE_STRATEGY.md b/RELEASE_STRATEGY.md
new file mode 100644
index 00000000..a220e8db
--- /dev/null
+++ b/RELEASE_STRATEGY.md
@@ -0,0 +1,425 @@
+# KROW Workforce Release Strategy & Tagging Plan
+
+## 📋 Overview
+
+This document establishes a systematic approach to versioning, tagging, and releasing across the KROW Workforce monorepo, which contains 5 distinct products with interdependencies.
+
+**Products:**
+1. **Staff Mobile App** - Flutter (iOS/Android)
+2. **Client Mobile App** - Flutter (iOS/Android)
+3. **Web Dashboard** - React/Vite
+4. **Backend Services** - Node.js (Command API, Core API)
+5. **Database/DataConnect** - Firebase Data Connect with PostgreSQL
+
+---
+
+## 🔗 Versioning Strategy
+
+### Semantic Versioning (SemVer)
+
+All products follow **Semantic Versioning 2.0.0**:
+- **MAJOR.MINOR.PATCH** (e.g., `1.2.3`)
+- **MAJOR**: Breaking changes, major features
+- **MINOR**: Backward-compatible new features
+- **PATCH**: Bug fixes, minor improvements
+
+### Version Independence
+
+Each product maintains its own version:
+- Products can release independently
+- No requirement for synchronized versions across products
+- Allows flexibility in release schedules
+
+### Current Baseline (as of 2026-03-05)
+
+| Product | Current Version | Status |
+|---------|-----------------|--------|
+| Staff Mobile App | 0.1.0 | Development |
+| Client Mobile App | 0.1.0 | Development |
+| Web Dashboard | 0.0.0 | Pre-release |
+| Backend (Command API) | 0.1.0 | Development |
+| Backend (Core API) | 0.1.0 | Development |
+| DataConnect | N/A | Schema-driven |
+
+---
+
+## 🏷️ Git Tag Naming Convention
+
+### Format
+
+```
+<product>/<environment>-v<version>
+```
+
+### Products
+- `staff-mobile` - Staff mobile application
+- `client-mobile` - Client mobile application
+- `web-dashboard` - Web dashboard
+- `command-api` - Backend command API
+- `core-api` - Backend core API
+- `dataconnect` - Database/DataConnect schema
+
+### Environments
+- `dev` - Development release (unstable, for testing)
+- `staging` - Staging release (pre-production)
+- `prod` - Production release (stable, customer-facing)
+
+### Examples
+```
+staff-mobile/dev-v0.1.0
+client-mobile/staging-v0.1.0
+web-dashboard/prod-v1.0.0
+command-api/dev-v0.2.1
+dataconnect/prod-v0.3.0
+```
+
+### Release Candidate Suffix (Optional)
+For pre-release versions:
+```
+staff-mobile/staging-v0.1.0-rc.1
+web-dashboard/prod-v1.0.0-rc.2
+```
+
+---
+
+## 📅 Release Cadence
+
+### Development Releases (`dev`)
+- **Frequency**: Weekly or as-needed
+- **Trigger**: Completed feature branches, bug fixes
+- **Duration**: Not stable, for internal testing
+- **Deployment**: Dev environment only
+
+### Staging Releases (`staging`)
+- **Frequency**: Bi-weekly
+- **Trigger**: Completion of sprint/feature milestone
+- **Duration**: Should maintain stability for 1-2 weeks
+- **Deployment**: Staging environment for QA
+
+### Production Releases (`prod`)
+- **Frequency**: Monthly or sprint-based (typically end of month)
+- **Trigger**: Successful staging validation + product sign-off
+- **Duration**: Maintain for 2+ months
+- **Deployment**: Production environment for customers
+
+---
+
+## 🔄 Release Dependency Order
+
+### Critical Path (Recommended)
+
+**For synchronized releases:**
+
+1. **DataConnect Schema** (if schema changes) - Deploy first
+2. **Backend Services** (Command API → Core API)
+3. **Web Dashboard**
+4. **Mobile Apps** (Staff first, then Client)
+
+**Rationale:**
+- DataConnect schema changes must be deployed before APIs consume new fields
+- Backend APIs must be stable before frontend depends on new endpoints
+- Web can be deployed independently but should test against new backend
+- Mobile apps can be released independently but won't have full features until matching backend is live
+
+### Independent Releases
+
+Products can release independently if they don't introduce breaking changes:
+- Mobile apps can release without backend changes
+- Web dashboard can release bug fixes independently
+- Backend can release non-breaking API changes independently
+
+---
+
+## 📦 Release Checklist
+
+### Pre-Release (48 hours before)
+
+- [ ] Code review complete on all changes
+- [ ] All tests passing (unit, integration, E2E)
+- [ ] Mobile app builds succeed on CodeMagic
+- [ ] No lint/type errors
+- [ ] Performance benchmarks acceptable
+- [ ] Security scan completed
+- [ ] Documentation updated
+- [ ] CHANGELOG.md updated with changes
+
+### Release Day
+
+- [ ] Create release branch from main: `release/v<version>`
+- [ ] Update version numbers in all relevant files:
+  - Mobile: `pubspec.yaml` version + build number
+  - Web: `package.json` version
+  - Backend: `package.json` version
+  - Backend: Update `codemagic.yaml` version refs
+- [ ] Create git tag with appropriate name
+- [ ] Merge release branch back to main
+- [ ] Deploy to target environment
+- [ ] Smoke tests run successfully
+- [ ] Create GitHub Release with:
+  - Release notes from CHANGELOG
+  - Build artifacts (APK/AAB for mobile)
+  - Deployment checklist items
+  - Known issues
+
+### Post-Release
+
+- [ ] Verify in target environment (staging → prod)
+- [ ] Monitor error logs for 24 hours
+- [ ] Notify users of deployment
+- [ ] Update status page if applicable
+- [ ] Tag next development version as beginning
+
+---
+
+## 🔐 Protected Tags
+
+### Rules
+
+- **Production tags (`prod-v*`)**: Require pull request review
+- **Staging tags (`staging-v*`)**: Require at least 1 approval
+- **Dev tags (`dev-v*`)**: No restrictions
+
+### Implementation in GitHub
+
+1. Go to Repo Settings → Branches → Add rule
+2. Apply to tag name pattern: `**/prod-v*`
+3. Require pull request reviews before merging
+4. Require status checks to pass
+
+---
+
+## 📝 Version File Locations
+
+### Mobile Apps (Staff & Client)
+
+**File**: `/apps/mobile/apps/staff_app/pubspec.yaml` (and client_app)
+```yaml
+version: 0.1.0+1
+```
+- First number = version
+- After `+` = build number (increment for each release)
+
+### Web Dashboard
+
+**File**: `/apps/web/package.json`
+```json
+{
+  "version": "0.0.0"
+}
+```
+
+### Backend Services
+
+**Files**: 
+- `/backend/command-api/package.json`
+- `/backend/core-api/package.json`
+
+```json
+{
+  "version": "0.1.0"
+}
+```
+
+### CodeMagic Configuration
+
+**File**: `/codemagic.yaml`
+```yaml
+workflows:
+  mobile-client-build:
+    environment:
+      flutter: stable
+    settings:
+      build_version: "0.1.0" # Update this
+```
+
+---
+
+## 📊 Release Timeline Example: v1.0.0
+
+**Timeline for coordinated production release:**
+
+```
+Day 1 (Monday)
+├─ Code freeze announced
+├─ All feature branches merged to main
+└─ QA begins testing
+
+Day 6 (Saturday)
+├─ All tests pass
+├─ Release manager creates release/v1.0.0 branch
+└─ Version numbers bumped to 1.0.0 everywhere
+
+Day 7 (Sunday)
+├─ Tags created:
+│  ├─ web-dashboard/staging-v1.0.0
+│  ├─ command-api/staging-v1.0.0
+│  ├─ core-api/staging-v1.0.0
+│  ├─ staff-mobile/staging-v1.0.0
+│  ├─ client-mobile/staging-v1.0.0
+│  └─ dataconnect/staging-v1.0.0 (if schema changes)
+├─ Deploy to staging environment
+├─ QA smoke tests
+└─ Product owner sign-off
+
+Day 13 (Saturday) - Production Release
+├─ Create production tags:
+│  ├─ web-dashboard/prod-v1.0.0
+│  ├─ command-api/prod-v1.0.0
+│  └─ [other products]
+├─ Deploy to production (following dependency order)
+├─ Verify in production
+└─ Release GitHub Release page
+```
+
+---
+
+## 🛠️ Git Commands
+
+### Create a Tag
+
+```bash
+# Create annotated tag
+git tag -a staff-mobile/dev-v0.1.0 -m "Staff mobile v0.1.0 - [feature description]"
+
+# Push tag to remote
+git push origin staff-mobile/dev-v0.1.0
+
+# Or push all tags
+git push origin --tags
+```
+
+### List Tags for a Product
+
+```bash
+# Show all staff-mobile tags
+git tag -l "staff-mobile/*" --sort=-version:refname
+
+# Show tags in specific environment
+git tag -l "*/prod-v*"
+```
+
+### Delete a Tag
+
+```bash
+# Local deletion
+git tag -d staff-mobile/dev-v0.1.0
+
+# Remote deletion
+git push origin --delete staff-mobile/dev-v0.1.0
+```
+
+---
+
+## 🔍 Rollback Procedures
+
+### If Critical Issue Found in Prod
+
+1. **Identify**: Determine which product caused the issue
+2. **Revert**: 
+   ```bash
+   git revert <commit-hash> -m 1
+   git push origin main
+   ```
+3. **Tag**: Create hotfix tag
+   ```bash
+   git tag -a staff-mobile/prod-v0.1.1 -m "Hotfix: [issue description]"
+   git push origin staff-mobile/prod-v0.1.1
+   ```
+4. **Deploy**: Follow deployment checklist
+5. **Communication**: Notify users and stakeholders
+
+### If Staging Issue Found
+
+Similar to rollback but to staging environment. No customer impact.
+
+---
+
+## 📋 Release Notes Template
+
+Create a GitHub Release with the following:
+
+```markdown
+# Staff Mobile v0.1.0 Release
+
+**Release Date**: 2026-03-15
+
+## What's New
+
+### Features
+- [ ] Feature 1 description
+- [ ] Feature 2 description
+
+### Improvements
+- [ ] Improvement 1 description
+
+### Bug Fixes
+- [ ] Bug fix 1 description
+
+## Dependencies
+
+- ✅ Requires Backend API v0.1.0 or higher
+- ✅ Requires DataConnect schema v0.3.0 or higher
+
+## Installation
+
+[iOS/Android download links]
+
+## Known Issues
+
+- [ ] Issue 1: Description (Workaround: ...)
+
+## Migration Guide (if needed)
+
+Steps for users to migrate from previous version.
+
+## Support
+
+For issues, contact support@krow-workforce.com or [GitHub Issues Link]
+```
+
+---
+
+## 📊 Monitoring & Metrics
+
+### Track Per Release
+
+- [ ] Time to release
+- [ ] Number of bugs in production
+- [ ] User adoption rate
+- [ ] Performance changes
+- [ ] Rollback rate
+- [ ] Deploy success rate
+
+### Dashboard
+
+Consider setting up a tool to track:
+- Deploy frequency
+- Lead time for changes
+- Mean time to recovery (MTTR)
+- Change failure rate
+
+---
+
+## 🔗 Related Documents
+
+- [CHANGELOG.md](./CHANGELOG.md) - Historical version logs
+- [docs/01-backend-api-specification.md](./docs/01-backend-api-specification.md) - API contract
+- [docs/ARCHITECTURE/system-bible.md](./docs/ARCHITECTURE/system-bible.md) - System design
+- [codemagic.yaml](./codemagic.yaml) - CI/CD pipeline
+
+---
+
+## ✅ Next Steps
+
+1. **Approve this strategy** with the team
+2. **Configure GitHub branch protection** for tag patterns
+3. **Set up release automation** in CI/CD (GitHub Actions or CodeMagic)
+4. **Create the v1.0.0 milestone** with all planned features
+5. **Establish communication cadence** for releases (weekly status, release announcements)
+6. **Train team members** on release process
+
+---
+
+**Last Updated**: 2026-03-05
+**Owner**: DevOps/Release Engineering
+**Status**: ✅ Active
diff --git a/RELEASE_VISUAL_GUIDE.md b/RELEASE_VISUAL_GUIDE.md
new file mode 100644
index 00000000..f7646d11
--- /dev/null
+++ b/RELEASE_VISUAL_GUIDE.md
@@ -0,0 +1,382 @@
+# Release Process Visual Guide
+
+## 🔄 Release Pipeline Overview
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                    KROW WORKFORCE RELEASE PIPELINE              │
+└─────────────────────────────────────────────────────────────────┘
+
+┌─ DEVELOPMENT PHASE ────────────────────────────────────────────┐
+│                                                                  │
+│  Feature Branch Development                                      │
+│        ↓                                                          │
+│  Code Review & Testing                                           │
+│        ↓                                                          │
+│  Merge to Main                                                   │
+│        ↓                                                          │
+│  Automated Builds & Tests (GitHub Actions / CodeMagic)         │
+│        ↓                                                          │
+│  ✅ Main is always deployment-ready                             │
+│                                                                  │
+└──────────────────────────────────────────────────────────────────┘
+                           ↓
+┌─ STAGING RELEASE ──────────────────────────────────────────────┐
+│                                                                  │
+│  1. Create Release Branch (release/[product]-v[version])       │
+│  2. Bump Version Numbers                                        │
+│  3. Update CHANGELOG                                             │
+│  4. Create Git Tags: */staging-v[version]                      │
+│  5. Deploy to Staging Environment                               │
+│  6. Run QA Tests                                                 │
+│  7. Product Owner Sign-off                                       │
+│                                                                  │
+│  Duration: 1 week minimum                                        │
+│  Cadence: Bi-weekly                                              │
+│                                                                  │
+└──────────────────────────────────────────────────────────────────┘
+                           ↓
+          ┌─ ISSUE? ──────────────────┐
+          │                            ↓
+          │                    Create Hotfix
+          │                    Branch/Tag
+          │                    (*/staging-v[X+1])
+          └─ FIX & RETEST ────────────┘
+                           ↓
+┌─ PRODUCTION RELEASE ───────────────────────────────────────────┐
+│                                                                  │
+│  1. Final Verification in Staging                               │
+│  2. Create Production Tags: */prod-v[version]                  │
+│  3. Deploy in Dependency Order:                                 │
+│     • DataConnect Schema (if applicable)                        │
+│     • Command API                                                │
+│     • Core API                                                   │
+│     • Web Dashboard                                              │
+│     • Staff Mobile                                               │
+│     • Client Mobile                                              │
+│  4. Smoke Tests in Production                                    │
+│  5. Create GitHub Release Page                                   │
+│  6. Announce to Users                                            │
+│  7. Monitor for 24 hours                                         │
+│                                                                  │
+│  Duration: 1-2 hours deployment, 24-48 hours monitoring        │
+│  Cadence: Monthly or sprint-based                                │
+│                                                                  │
+└──────────────────────────────────────────────────────────────────┘
+
+Legend:
+  ✅ = Ready state
+  → = Next step
+  ↓ = Dependency
+```
+
+---
+
+## 📦 Product Dependency & Release Order
+
+```
+                    ┌──────────────────────┐
+                    │  DataConnect Schema  │
+                    │  (if applicable)     │
+                    └──────────┬───────────┘
+                               │
+                    ┌──────────▼──────────┐
+                    │  Backend Services   │
+                    │                     │
+                    ├─ Command API        │
+                    └─ Core API           │
+                               │
+                ┌──────────────┼──────────────┐
+                │              │              │
+         ┌──────▼────┐  ┌──────▼────┐  ┌────▼──────┐
+         │ Web       │  │   Staff   │  │  Client   │
+         │ Dashboard │  │  Mobile   │  │  Mobile   │
+         │           │  │   App     │  │   App     │
+         └───────────┘  └───────────┘  └───────────┘
+
+Critical Path (Staging → Production):
+  1. DataConnect (if schema changes)
+  2. APIs (Command + Core)  [parallel OK]
+  3. Web Dashboard         [can wait for API confirmation]
+  4. Mobile Apps           [independent, can deploy anytime]
+
+Parallel Deployments (when safe):
+  • Both backend APIs can deploy in parallel
+  • Mobile apps can deploy in parallel
+  • Web + Mobile can deploy in parallel (if APIs stable)
+
+Non-Blocking:
+  • Mobile can release without web changes
+  • Web can release without mobile changes
+  • Backend can release non-breaking API changes independently
+```
+
+---
+
+## 🏷️ Git Tag Timeline Example
+
+```
+                    Release v1.0.0 Timeline (Coordinated)
+                    
+2026-03-01          2026-03-08              2026-03-15          2026-03-22
+│                   │                       │                   │
+├─ Code Freeze      ├─ Staging Release      ├─ Production        ├─ Next Sprint
+│                   │                       │  Release           │
+├─ Feature Branches ├─ */staging-v1.0.0     ├─ */prod-v1.0.0    │
+│  → main           │                       │                   │
+│                   ├─ QA Testing           ├─ Deploy & Verify  │
+├─ All Tests #      ├─ 24h Monitoring       ├─ 48h Monitoring   │
+│  Green #          │                       │                   │
+│                   ├─ Product Sign-off ✓   ├─ Users Notified   │
+└─ Ready ✓          └─ Approved for Prod    └─ Stable ✓         │
+
+Key Milestones:
+  # = All automated tests passing
+  ✓ = Manual approval/sign-off
+```
+
+---
+
+## 🔄 Release Branch Structure
+
+```
+┌─────────────────── main (Protected) ──────────────────┐
+│                                                        │
+│  feature/auth             feature/payments             │
+│       ↓                         ↓                      │
+│  ──●──●──●──  ──●──●──●──  ──●──●──●──   ← Feature  │
+│       │            │            │          Branches   │
+│       ├──────┬─────┤     ┬──────┤                     │
+│       ↓      │     ↓     │      ↓                     │
+│   ────●──────●─────●─────●──────●─────  ← Merge PRs │
+│       │                                               │
+│       ↓                                               │
+│  release/staff-mobile-v0.2.0  ← Release Branch       │
+│       │                                               │
+│       ├─ Bump version                                 │
+│       ├─ Update CHANGELOG                             │
+│       ├─ Commit & merge back                          │
+│       │                                               │
+│  ────●●──────────────────  ← Merge back to main      │
+│       │                                               │
+│       ↓                                               │
+│   TAG: staff-mobile/staging-v0.2.0  ← Staging Tag   │
+│   TAG: staff-mobile/prod-v0.2.0     ← Prod Tag      │
+│       │                                               │
+│   (Deploy from tags)                                  │
+│                                                        │
+└────────────────────────────────────────────────────────┘
+
+Key Points:
+  • main is always clean and deployable
+  • Feature branches never go to staging/prod
+  • Tags point to main (after merge)
+  • Releases == Git tags, not branches
+  • Hotfix branches created from prod tags
+```
+
+---
+
+## 📋 Multi-Product Release Coordination
+
+```
+Product Release States (Example: v1.0.0)
+
+Staff Mobile:
+  ├─ Dev build:      ✅ staff-mobile/dev-v1.0.0 (deployed)
+  ├─ Staging:        ✅ staff-mobile/staging-v1.0.0 (testing)
+  └─ Production:     🔄 staff-mobile/prod-v1.0.0 (deploying)
+
+Client Mobile:
+  ├─ Dev build:      ✅ client-mobile/dev-v1.0.0 (deployed)
+  ├─ Staging:        ✅ client-mobile/staging-v1.0.0 (testing)
+  └─ Production:     🔄 client-mobile/prod-v1.0.0 (deploying)
+
+Web Dashboard:
+  ├─ Dev build:      ✅ web-dashboard/dev-v1.0.0 (deployed)
+  ├─ Staging:        ✅ web-dashboard/staging-v1.0.0 (testing)
+  └─ Production:     ✅ web-dashboard/prod-v1.0.0 (live)
+
+Command API:
+  ├─ Dev build:      ✅ command-api/dev-v1.0.0 (deployed)
+  ├─ Staging:        ✅ command-api/staging-v1.0.0 (testing)
+  └─ Production:     ✅ command-api/prod-v1.0.0 (live)
+
+Core API:
+  ├─ Dev build:      ✅ core-api/dev-v1.0.0 (deployed)
+  ├─ Staging:        ✅ core-api/staging-v1.0.0 (testing)
+  └─ Production:     ✅ core-api/prod-v1.0.0 (live)
+
+Legend:
+  ✅ = Released and stable
+  🔄 = In progress
+  ⏳ = Waiting for approval
+  ⛔ = Blocked/awaiting fix
+
+
+Sync Points (when to coordinate):
+  1. Before moving staging → prod (all ready?)
+  2. During prod deployment (follow order)
+  3. Post-release (all working?)
+  4. If hotfix needed (which products affected?)
+```
+
+---
+
+## 🚨 Hotfix Release Flow
+
+```
+Production Issue Detected
+         │
+         ↓
+    ┌─────────────────┐
+    │ Is it critical? │
+    └────┬────────┬───┘
+         │ YES    │ NO
+         ↓        └─→ Plan for next release
+    
+    ┌─────────────────────────┐
+    │ Create Hotfix Branch    │
+    │ (from prod tag)         │
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    │ Make Fix                │
+    │ Test locally            │
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    ├─ Bump PATCH version     │
+    │  (e.g., 0.1.0 → 0.1.1) │
+    ├─ Update CHANGELOG       │
+    ├─ Commit to hotfix branch│
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    │ Code Review (expedited) │
+    │ Approval + merge        │
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    │ Create Tag              │
+    │ */prod-v0.1.1           │
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    │ Deploy to Production    │
+    │ (High priority)         │
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    │ Verify Fix              │
+    │ Monitor 24h             │
+    └──────────┬──────────────┘
+               │
+               ↓
+    ┌─────────────────────────┐
+    │ Communicate to Users    │
+    │ Incident Report         │
+    └──────────┬──────────────┘
+               │
+               ↓
+        ✅ Resolved
+
+Speed target: 4-8 hours total (from detection to production verification)
+```
+
+---
+
+## 📊 Version Matrix Dashboard
+
+Create in your team wiki/notion:
+
+```
+╔════════════════════════════════╦═══════════╦═══════════╦═══════════╗
+║ Product                        ║ Dev       ║ Staging   ║ Prod      ║
+╠════════════════════════════════╬═══════════╬═══════════╬═══════════╣
+║ Staff Mobile                   ║ 0.2.1     ║ 0.2.0     ║ 0.1.0     ║
+║ Client Mobile                  ║ 0.2.1     ║ 0.2.0     ║ 0.1.0     ║
+║ Web Dashboard                  ║ 0.1.0     ║ 0.0.0     ║ —         ║
+║ Command API                    ║ 0.2.0     ║ 0.2.0-rc1 ║ 0.1.0     ║
+║ Core API                       ║ 0.2.0     ║ 0.2.0-rc1 ║ 0.1.0     ║
+║ DataConnect                    ║ 0.4.0     ║ 0.3.0     ║ 0.3.0     ║
+╚════════════════════════════════╩═══════════╩═══════════╩═══════════╝
+
+Last updated: 2026-03-05
+Updated by: DevOps Team
+Next release planning: 2026-03-08
+```
+
+---
+
+## ⏱️ Release Timeline Template
+
+For every release, create this timeline:
+
+```
+Release: [Product] v[Version]
+Target: [date]
+
+Milestones:
+├─ Feb 28 (T-7):   Code freeze
+├─ Mar  1 (T-6):   Staging release + QA testing
+├─ Mar  5 (T-2):   Final staging verification
+├─ Mar  6 (T-1):   Production deployment readiness
+├─ Mar  7 (T-0):   Production deployment 14:00-16:00 UTC
+├─ Mar  8 (T+1):   Monitoring & verification
+└─ Mar  9 (T+2):   Release celebration 🎉
+
+Deployment Windows:
+  Testing:  Anytime
+  Staging:  Anytime
+  Prod:     14:00-16:00 UTC on release day
+           (Off-peak time in all timezones)
+
+Rollback Window: 4 hours post-deployment
+```
+
+---
+
+## 🎯 Status Page Template
+
+Share with stakeholders:
+
+```
+🚀 KROW Workforce Release Status
+
+📅 Week of March 5, 2026
+
+Current Production Versions:
+├── Staff Mobile:     0.1.0 ✅
+├── Client Mobile:    0.1.0 ✅
+├── Web Dashboard:    TBD  ⏳
+├── Command API:      0.1.0 ✅
+└── Core API:         0.1.0 ✅
+
+In Staging (Testing):
+├── Staff Mobile:     0.2.0 🔄 (50% through QA)
+├── Client Mobile:    0.2.0 🔄 (50% through QA)
+└── Web Dashboard:    0.1.0 🔄 (30% through QA)
+
+Next Production Release:
+├── Target Date:      March 15, 2026
+├── Products:         All 5 products
+├── Focus:            Shift booking, payments, mobile improvements
+└── Expected Impact:  2-3 hour deployment window
+
+Risks & Blockers: None current
+
+Recent Incidents: None
+```
+
+---
+
+**Document Version**: 1.0
+**Created**: 2026-03-05
+**Maintain**: DevOps / Release Manager
diff --git a/RELEASE_WORKFLOW.md b/RELEASE_WORKFLOW.md
new file mode 100644
index 00000000..8bac0b80
--- /dev/null
+++ b/RELEASE_WORKFLOW.md
@@ -0,0 +1,382 @@
+# Release Workflow Guide
+
+Quick reference for executing releases in the KROW Workforce monorepo.
+
+## 🚀 Quick Start Release (for a single product)
+
+### Example: Release Staff Mobile v0.2.0
+
+```bash
+# 1. Start from main branch
+git checkout main
+git pull origin main
+
+# 2. Create release branch
+git checkout -b release/staff-mobile-v0.2.0
+
+# 3. Update version numbers
+# File: apps/mobile/apps/staff_app/pubspec.yaml
+# Change: version: 0.1.0+5 → version: 0.2.0+6
+
+# 4. Update CHANGELOG.md
+nano CHANGELOG.md
+# Add entry at top:
+# | 2026-03-05 | Staff Mobile 0.2.0 | [Feature/fix descriptions] |
+
+# 5. Commit changes
+git add .
+git commit -m "chore(staff-mobile): bump version to 0.2.0"
+
+# 6. Push release branch
+git push origin release/staff-mobile-v0.2.0
+
+# 7. Create pull request on GitHub
+# (GitHub CLI: gh pr create --title "Release: Staff Mobile v0.2.0" --body "See RELEASE_STRATEGY.md")
+
+# 8. Merge to main after approval
+git checkout main
+git pull origin main
+git merge --ff-only release/staff-mobile-v0.2.0
+
+# 9. Create git tag
+git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0 - [Feature description]"
+
+# 10. Push tag
+git push origin staff-mobile/dev-v0.2.0
+
+# 11. Create GitHub Release
+# - Go to Releases → Draft a new release
+# - Tag: staff-mobile/dev-v0.2.0
+# - Title: "Staff Mobile v0.2.0"
+# - Description: Copy from CHANGELOG
+# - Attach APK/AAB if available
+# - Publish
+```
+
+---
+
+## 🔄 Multi-Product Coordinated Release
+
+### Step-by-Step for v1.0.0 Release (all products)
+
+#### Phase 1: Preparation (48 hours before)
+
+```bash
+# Check all tests pass
+make test
+make test-backend
+make test-web
+
+# Verify builds
+make build-mobile-dev
+make build-web
+
+# No lint errors
+make lint
+```
+
+#### Phase 2: Version Bumping
+
+**File locations to update:**
+
+1. **Mobile Apps**: `apps/mobile/apps/staff_app/pubspec.yaml` (and client_app)
+   ```yaml
+   version: 1.0.0+1  # Increment build number
+   ```
+
+2. **Web Dashboard**: `apps/web/package.json`
+   ```json
+   "version": "1.0.0"
+   ```
+
+3. **Command API**: `backend/command-api/package.json`
+   ```json
+   "version": "1.0.0"
+   ```
+
+4. **Core API**: `backend/core-api/package.json`
+   ```json
+   "version": "1.0.0"
+   ```
+
+5. **CodeMagic**: `codemagic.yaml`
+   ```yaml
+   build_version: "1.0.0"
+   ```
+
+6. **CHANGELOG.md**: Add entry at top
+   ```markdown
+   | 2026-03-15 | 1.0.0 | Full feature v1.0.0 release [all products] |
+   ```
+
+```bash
+# Commit all version bumps
+git add -A
+git commit -m "chore: bump all products to v1.0.0"
+```
+
+#### Phase 3: Staging Release
+
+```bash
+# Create release branch
+git checkout -b release/v1.0.0-staging
+
+# Push and merge (or direct commit to release branch)
+git push origin release/v1.0.0-staging
+
+# Tag all products with staging
+git tag -a web-dashboard/staging-v1.0.0 -m "v1.0.0 staging release"
+git tag -a command-api/staging-v1.0.0 -m "v1.0.0 staging release"
+git tag -a core-api/staging-v1.0.0 -m "v1.0.0 staging release"
+git tag -a staff-mobile/staging-v1.0.0 -m "v1.0.0 staging release"
+git tag -a client-mobile/staging-v1.0.0 -m "v1.0.0 staging release"
+
+# Push all staging tags
+git push origin --tags
+
+# Deploy to staging environment
+./scripts/deploy-staging.sh  # (create if needed)
+```
+
+#### Phase 4: QA & Testing
+
+- [ ] Smoke test all features
+- [ ] Performance tests
+- [ ] Security scan
+- [ ] API contract verification
+
+#### Phase 5: Production Release
+
+```bash
+# Create production tags (after staging approval)
+git tag -a web-dashboard/prod-v1.0.0 -m "v1.0.0 production release"
+git tag -a command-api/prod-v1.0.0 -m "v1.0.0 production release"
+git tag -a core-api/prod-v1.0.0 -m "v1.0.0 production release"
+git tag -a staff-mobile/prod-v1.0.0 -m "v1.0.0 production release"
+git tag -a client-mobile/prod-v1.0.0 -m "v1.0.0 production release"
+
+# Push tags
+git push origin --tags
+
+# Deploy in dependency order
+./scripts/deploy-prod-dataconnect.sh
+./scripts/deploy-prod-backend.sh
+./scripts/deploy-prod-web.sh
+./scripts/deploy-prod-mobile.sh
+```
+
+---
+
+## 🔥 Hotfix Release (Emergency Production Fix)
+
+### Example: Critical bug in Staff Mobile v1.0.0 → v1.0.1
+
+```bash
+# 1. Create hotfix branch from production tag
+git checkout -b hotfix/staff-mobile-v1.0.1 staff-mobile/prod-v1.0.0
+
+# 2. Fix the bug
+git add <fixed-files>
+git commit -m "fix: [critical bug description]"
+
+# 3. Update version (PATCH bump only)
+# apps/mobile/apps/staff_app/pubspec.yaml
+# Change: 1.0.0+1 → 1.0.1+2
+
+# 4. Update CHANGELOG
+nano CHANGELOG.md
+# Add: | 2026-03-15 | Staff Mobile 1.0.1 | Hotfix: [bug description] |
+
+# 5. Push hotfix branch
+git push origin hotfix/staff-mobile-v1.0.1
+
+# 6. Create PR for review (expedited)
+gh pr create --title "Hotfix: Staff Mobile v1.0.1" \
+  --body "EMERGENCY: Critical issue fix\n\nSee CHANGELOG.md for details"
+
+# 7. Merge to main (fast-track approval)
+git checkout main
+git pull origin main
+git merge --ff-only hotfix/staff-mobile-v1.0.1
+
+# 8. Tag production immediately
+git tag -a staff-mobile/prod-v1.0.1 -m "Hotfix: [description]"
+git push origin staff-mobile/prod-v1.0.1
+
+# 9. Deploy to production
+./scripts/deploy-prod-mobile-staff.sh
+
+# 10. Create GitHub Release with "HOTFIX" in title
+```
+
+---
+
+## 📊 Useful Git Commands
+
+### View all tags for a product
+```bash
+git tag -l "staff-mobile/*" --sort=-version:refname
+git tag -l "*/prod-v*" --sort=-version:refname
+```
+
+### View tag details
+```bash
+git show staff-mobile/prod-v1.0.0
+git log staff-mobile/prod-v1.0.0...staff-mobile/prod-v0.9.0  # Changes between versions
+```
+
+### List tags created in last week
+```bash
+git log --oneline --decorate --tags --since="1 week ago"
+```
+
+### See all commits since last tag
+```bash
+git log <last-tag>..HEAD --oneline
+```
+
+### Delete a tag (if mistake)
+```bash
+# Local
+git tag -d staff-mobile/dev-v0.1.0
+
+# Remote
+git push origin --delete staff-mobile/dev-v0.1.0
+```
+
+### Create lightweight tag (simpler, no message)
+```bash
+git tag staff-mobile/dev-v0.1.0
+```
+
+---
+
+## 🤖 Automation Scripts (Create These)
+
+### Create: `scripts/tag-all-products.sh`
+
+```bash
+#!/bin/bash
+# Usage: ./scripts/tag-all-products.sh prod 1.0.0
+
+ENV=$1  # dev, staging, prod
+VERSION=$2  # e.g., 1.0.0
+
+if [ -z "$ENV" ] || [ -z "$VERSION" ]; then
+  echo "Usage: $0 <env> <version>"
+  echo "Example: $0 prod 1.0.0"
+  exit 1
+fi
+
+PRODUCTS=(
+  "staff-mobile"
+  "client-mobile"
+  "web-dashboard"
+  "command-api"
+  "core-api"
+)
+
+for product in "${PRODUCTS[@]}"; do
+  TAG="${product}/${ENV}-v${VERSION}"
+  echo "Creating tag: $TAG"
+  git tag -a "$TAG" -m "$product v$VERSION - $ENV release"
+done
+
+echo "Pushing all tags..."
+git push origin --tags
+
+echo "✅ All products tagged for $ENV-v$VERSION"
+```
+
+### Create: `scripts/show-version-matrix.sh`
+
+```bash
+#!/bin/bash
+# Show version matrix of all products
+
+echo "📦 KROW Workforce Version Matrix"
+echo "================================"
+echo ""
+
+PRODUCTS=(
+  "staff-mobile"
+  "client-mobile"
+  "web-dashboard"
+  "command-api"
+  "core-api"
+)
+
+ENVS=("dev" "staging" "prod")
+
+for env in "${ENVS[@]}"; do
+  echo "=== $ENV Environment ==="
+  for product in "${PRODUCTS[@]}"; do
+    TAGS=$(git tag -l "${product}/${env}-v*" --sort=-version:refname | head -1)
+    if [ -z "$TAGS" ]; then
+      echo "  $product: (no tags)"
+    else
+      echo "  $product: $TAGS"
+    fi
+  done
+  echo ""
+done
+```
+
+---
+
+## ✅ Release Checklist Template
+
+Copy this for each release:
+
+```markdown
+## Release: [Product] v[Version]
+
+**Release Date**: [Date]
+**Release Manager**: [Name]
+
+### Pre-Release (48h before)
+- [ ] All PRs merged and reviewed
+- [ ] Tests passing (unit + integration)
+- [ ] No lint/type errors
+- [ ] Mobile builds succeed on CodeMagic
+- [ ] Performance benchmarks acceptable
+- [ ] Security scan passed
+- [ ] CHANGELOG.md updated
+- [ ] Documentation updated
+
+### Release Day
+- [ ] Create release branch: `release/[product]-v[version]`
+- [ ] Bump version numbers in all files
+- [ ] Commit: `chore: bump [product] to v[version]`
+- [ ] Create tag: `[product]/staging-v[version]`
+- [ ] Deploy to staging
+- [ ] Smoke tests passed
+- [ ] Create GitHub Release page
+
+### Post-Release (24h after)
+- [ ] Monitor error logs
+- [ ] Verify features work end-to-end
+- [ ] Create production tag (if approved)
+- [ ] Deploy to production
+- [ ] Final verification
+- [ ] Notify users
+
+### Rollback Plan (if needed)
+- [ ] Identified issue
+- [ ] Created hotfix branch
+- [ ] Tagged hotfix version
+- [ ] Deployed rollback
+- [ ] Post-mortem created
+```
+
+---
+
+## 🔗 Related Files
+
+- [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) - Full strategy document
+- [CHANGELOG.md](./CHANGELOG.md) - Version history
+- [codemagic.yaml](./codemagic.yaml) - CI/CD configuration
+
+---
+
+**Last Updated**: 2026-03-05
diff --git a/VERSION_FILES_REFERENCE.md b/VERSION_FILES_REFERENCE.md
new file mode 100644
index 00000000..2def7643
--- /dev/null
+++ b/VERSION_FILES_REFERENCE.md
@@ -0,0 +1,406 @@
+# Version File Locations Reference
+
+When releasing a product, update version numbers in **all applicable files**. Use this checklist to ensure nothing is missed.
+
+---
+
+## 📱 Staff Mobile App Release
+
+**All files to update when releasing staff mobile app:**
+
+### 1. Pubspec.yaml
+**File**: `/apps/mobile/apps/staff_app/pubspec.yaml`
+
+```yaml
+# Current state (example)
+version: 0.1.0+5
+
+# Change to (example for v0.2.0)
+version: 0.2.0+6
+```
+
+**Rules**:
+- Format: `MAJOR.MINOR.PATCH+BUILD_NUMBER`
+- Always increment BUILD_NUMBER
+- For each new version, start BUILD_NUMBER at +1
+
+### 2. CodeMagic Configuration
+**File**: `/codemagic.yaml`
+
+Find the `mobile-client-build` workflow section:
+
+```yaml
+workflows:
+  mobile-client-build:
+    name: Mobile Client Build
+    
+    environment:
+      # ... other env vars ...
+      groups:
+        - default
+        - mobile-staff-build  # ← This group might have version
+      
+    on_success:
+      - |
+        VERSION=$(grep "^version:" apps/mobile/apps/staff_app/pubspec.yaml | cut -d' ' -f2)
+        echo "Version: $VERSION"  # This auto-reads from pubspec
+```
+
+**Note**: CodeMagic typically reads version from pubspec.yaml automatically. Update only if you have hardcoded version strings.
+
+### 3. CHANGELOG.md
+**File**: `/CHANGELOG.md`
+
+Add entry at **very top** of the table:
+
+```markdown
+| Date | Version | Change |
+|---|---|---|
+| 2026-03-05 | Staff Mobile 0.2.0 | [Feature descriptions] |
+| 2026-03-01 | 0.1.25 | Previous entry... |
+```
+
+---
+
+## 📱 Client Mobile App Release
+
+**All files to update when releasing client mobile app:**
+
+### 1. Pubspec.yaml
+**File**: `/apps/mobile/apps/client_app/pubspec.yaml`
+
+```yaml
+# Update format same as staff app
+version: 0.2.0+6
+```
+
+### 2. CodeMagic Configuration
+**File**: `/codemagic.yaml`
+
+Find the `mobile-staff-build` workflow (NOT client-build):
+
+```yaml
+workflows:
+  mobile-staff-build:  # ← Staff app config
+    # ... update pubspec reference for staff ...
+    
+  mobile-client-build:  # ← Client app config (if separate)
+    # ... update pubspec reference for client ...
+```
+
+### 3. CHANGELOG.md
+**File**: `/CHANGELOG.md`
+
+```markdown
+| Date | Version | Change |
+|---|---|---|
+| 2026-03-05 | Client Mobile 0.2.0 | [Feature descriptions] |
+```
+
+---
+
+## 🌐 Web Dashboard Release
+
+**All files to update when releasing web dashboard:**
+
+### 1. Package.json
+**File**: `/apps/web/package.json`
+
+```json
+{
+  "name": "web",
+  "private": true,
+  "version": "0.1.0",  ← Update this
+  // ... other fields ...
+}
+```
+
+**Format**: `X.Y.Z` (semantic versioning)
+
+### 2. CHANGELOG.md
+**File**: `/CHANGELOG.md`
+
+```markdown
+| Date | Version | Change |
+|---|---|---|
+| 2026-03-05 | Web Dashboard 0.1.0 | [Feature descriptions] |
+```
+
+### 3. Environment/Build Files (Optional)
+Check if there are any other version references:
+
+```bash
+# Search for version strings
+grep -r "0.0.0" apps/web/
+grep -r "VERSION" apps/web/
+```
+
+---
+
+## 🔧 Command API Backend Release
+
+**All files to update when releasing command API:**
+
+### 1. Package.json
+**File**: `/backend/command-api/package.json`
+
+```json
+{
+  "name": "@krow/command-api",
+  "version": "0.2.0",  ← Update this
+  // ... other fields ...
+}
+```
+
+### 2. Docker Configuration (if applicable)
+**File**: `/backend/command-api/Dockerfile`
+
+If you tag Docker images:
+
+```dockerfile
+FROM node:20-alpine
+
+# Add label with version
+LABEL version="0.2.0"
+LABEL description="KROW Command API v0.2.0"
+```
+
+### 3. CHANGELOG.md
+**File**: `/CHANGELOG.md`
+
+```markdown
+| Date | Version | Change |
+|---|---|---|
+| 2026-03-05 | Command API 0.2.0 | [Feature descriptions] |
+```
+
+### 4. Environment Configuration (if applicable)
+If there's a `.env` or config file:
+
+```bash
+# Check for any version references
+grep -r "VERSION\|version" backend/command-api/
+```
+
+---
+
+## 🔧 Core API Backend Release
+
+**All files to update when releasing core API:**
+
+### 1. Package.json
+**File**: `/backend/core-api/package.json`
+
+```json
+{
+  "name": "@krow/core-api",
+  "version": "0.2.0",  ← Update this
+  // ... other fields ...
+}
+```
+
+### 2. CHANGELOG.md
+**File**: `/CHANGELOG.md`
+
+```markdown
+| Date | Version | Change |
+|---|---|---|
+| 2026-03-05 | Core API 0.2.0 | [Feature descriptions] |
+```
+
+### Other Files
+Same as Command API (Docker, config files, etc.)
+
+---
+
+## 🗄️ DataConnect Database Schema Release
+
+**Note**: DataConnect versions are typically managed separately through schema versioning.
+
+### 1. Schema Version File (if exists)
+**File**: Check in `/backend/dataconnect/`
+
+```yaml
+# Example structure
+schema_version: 0.3.0
+created_at: 2026-03-05
+description: "Schema version 0.3.0 - [description]"
+```
+
+### 2. CHANGELOG.md
+**File**: `/CHANGELOG.md`
+
+```markdown
+| Date | Version | Change |
+|---|---|---|
+| 2026-03-05 | DataConnect Schema 0.3.0 | [Schema changes] |
+```
+
+---
+
+## ✅ Release Checklist: Version File Updates
+
+### When releasing Staff Mobile v0.2.0
+
+- [ ] `/apps/mobile/apps/staff_app/pubspec.yaml` → `0.2.0+X`
+- [ ] `/codemagic.yaml` → version string (if hardcoded)
+- [ ] `/CHANGELOG.md` → Add entry with date + version
+- [ ] Commit: `git add . && git commit -m "chore: staff mobile v0.2.0"`
+- [ ] Tag: `git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"`
+- [ ] Verify: `git show staff-mobile/dev-v0.2.0`
+
+### When releasing Client Mobile v0.2.0
+
+- [ ] `/apps/mobile/apps/client_app/pubspec.yaml` → `0.2.0+X`
+- [ ] `/codemagic.yaml` → version string (if hardcoded)
+- [ ] `/CHANGELOG.md` → Add entry
+- [ ] Complete release process (commit → tag → verify)
+
+### When releasing Web Dashboard v0.1.0
+
+- [ ] `/apps/web/package.json` → `"version": "0.1.0"`
+- [ ] `/CHANGELOG.md` → Add entry
+- [ ] Complete release process
+
+### When releasing Command API v0.2.0
+
+- [ ] `/backend/command-api/package.json` → `"version": "0.2.0"`
+- [ ] `/backend/command-api/Dockerfile` → Label update (optional)
+- [ ] `/CHANGELOG.md` → Add entry
+- [ ] Complete release process
+
+### When releasing Core API v0.2.0
+
+- [ ] `/backend/core-api/package.json` → `"version": "0.2.0"`
+- [ ] `/backend/core-api/Dockerfile` → Label update (optional)
+- [ ] `/CHANGELOG.md` → Add entry
+- [ ] Complete release process
+
+### When releasing All Products (Synchronized Release)
+
+- [ ] Staff Mobile: Update pubspec + codemagic
+- [ ] Client Mobile: Update pubspec + codemagic
+- [ ] Web: Update package.json
+- [ ] Command API: Update package.json + docker
+- [ ] Core API: Update package.json + docker
+- [ ] **CHANGELOG.md**: Add comprehensive entry with all products
+- [ ] Single commit: `git commit -m "chore: release all products v1.0.0"`
+- [ ] Multiple tags (one per product):
+  ```bash
+  git tag -a staff-mobile/prod-v1.0.0 -m "v1.0.0"
+  git tag -a client-mobile/prod-v1.0.0 -m "v1.0.0"
+  git tag -a web-dashboard/prod-v1.0.0 -m "v1.0.0"
+  git tag -a command-api/prod-v1.0.0 -m "v1.0.0"
+  git tag -a core-api/prod-v1.0.0 -m "v1.0.0"
+  git push origin --tags
+  ```
+
+---
+
+## 🔍 Verify All Updates
+
+After updating versions, verify nothing was missed:
+
+```bash
+# Search for old version strings still remaining
+grep -r "0.1.0" apps/mobile/ --include="*.yaml" --include="*.yml" --include="*.json"
+grep -r "0.0.0" apps/web/ --include="*.json"
+grep -r "0.1.0" backend/ --include="*.json"
+
+# Check CHANGELOG was updated
+head -5 CHANGELOG.md
+
+# Verify git status shows all changes
+git status
+
+# Review exact changes before committing
+git diff CHANGELOG.md
+git diff apps/mobile/apps/staff_app/pubspec.yaml
+git diff apps/web/package.json
+```
+
+---
+
+## 📝 Version Update Template
+
+Copy this template for each release:
+
+```bash
+#!/bin/bash
+# Release: [Product] v[Version]
+# Date: [Date]
+
+# Update Staff Mobile
+sed -i '' 's/version: 0.1.0+5/version: 0.2.0+6/' apps/mobile/apps/staff_app/pubspec.yaml
+
+# Update CHANGELOG
+# (Manual: Add entry at top with date and version)
+
+# Verify
+grep "^version:" apps/mobile/apps/staff_app/pubspec.yaml
+head -3 CHANGELOG.md
+
+# Commit
+git add -A
+git commit -m "chore: bump staff mobile to v0.2.0"
+
+# Tag
+git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"
+git push origin staff-mobile/dev-v0.2.0
+
+# Done!
+echo "✅ Release complete. Tag: staff-mobile/dev-v0.2.0"
+```
+
+---
+
+## 🚨 Common Mistakes
+
+❌ **Forgot to update pubspec.yaml**
+- Result: Version mismatch between code and git tag
+
+❌ **Updated CHANGELOG but forgot to update package.json**
+- Result: Version inconsistency, harder to debug
+
+❌ **Updated version but didn't increment build number (mobile)**
+- Result: Build tools may fail or warn
+
+❌ **Forgot to update codemagic.yaml**
+- Result: CI/CD may deploy old version
+
+❌ **Updated multiple files but forgot to commit CHANGELOG**
+- Result: Historical record lost
+
+✅ **Always:**
+1. Update ALL version files
+2. Update CHANGELOG.md
+3. Commit ALL changes together
+4. Tag after commit
+5. Verify with `git show <tag>`
+
+---
+
+## 🎯 Pro Tips
+
+**Tip 1**: Use a script to update all versions at once
+
+```bash
+# Create update-version.sh
+VERSION="0.2.0"
+sed -i '' "s/version:.*/version: $VERSION/" apps/mobile/apps/staff_app/pubspec.yaml
+sed -i '' "s/\"version\".*/\"version\": \"$VERSION\"/" apps/web/package.json
+# ... etc for all files
+```
+
+**Tip 2**: Automate version bumping based on git commit messages
+
+Use conventional commits (`feat:`, `fix:`, `BREAKING CHANGE:`) to auto-determine MAJOR/MINOR/PATCH
+
+**Tip 3**: Use GitHub Actions to auto-create tags
+
+Create an action that tags on PR merge with version from package.json
+
+---
+
+**Last Updated**: 2026-03-05
+**Maintain**: DevOps Team
diff --git a/apps/mobile/apps/client/pubspec.yaml b/apps/mobile/apps/client/pubspec.yaml
index f9e3d656..677133d7 100644
--- a/apps/mobile/apps/client/pubspec.yaml
+++ b/apps/mobile/apps/client/pubspec.yaml
@@ -1,7 +1,7 @@
 name: krowwithus_client
 description: "KROW Client Application"
 publish_to: "none"
-version: 0.0.1-IlianaClientM3
+version: 0.0.1-m4
 resolution: workspace
 
 environment:
diff --git a/apps/mobile/apps/staff/pubspec.yaml b/apps/mobile/apps/staff/pubspec.yaml
index 457446fd..21c19091 100644
--- a/apps/mobile/apps/staff/pubspec.yaml
+++ b/apps/mobile/apps/staff/pubspec.yaml
@@ -1,7 +1,7 @@
 name: krowwithus_staff
 description: "KROW Staff Application"
 publish_to: 'none'
-version: 0.0.1-IlianaStaffM3
+version: 0.0.1-m4
 resolution: workspace
 
 environment:
diff --git a/docs/RELEASE/HOTFIX_PROCESS.md b/docs/RELEASE/HOTFIX_PROCESS.md
new file mode 100644
index 00000000..313b9be6
--- /dev/null
+++ b/docs/RELEASE/HOTFIX_PROCESS.md
@@ -0,0 +1,343 @@
+# Hotfix Process
+
+**For Emergency Production Fixes**
+
+---
+
+## 🚨 When to Hotfix
+
+Use hotfix when:
+- ✅ Critical bug in production affecting users
+- ✅ Data loss or security vulnerability
+- ✅ Service unavailable or major feature broken
+- ✅ Customer-blocking issue
+
+**Don't use hotfix for:**
+- ❌ Minor bugs (can wait for next release)
+- ❌ Feature requests
+- ❌ Nice-to-have improvements
+- ❌ Styling issues
+
+---
+
+## 🔄 Hotfix Process
+
+### Step 1: Assess & Declare Emergency
+
+```
+Issue: [Brief description]
+Severity: CRITICAL / HIGH / MEDIUM
+Product: [Staff Mobile / Client Mobile / Web / Backend]
+Environment: Production
+Impact: [How many users affected]
+```
+
+Once severity confirmed → Start hotfix immediately.
+
+---
+
+### Step 2: Create Hotfix Branch
+
+```bash
+# From production tag
+git checkout -b hotfix/krow-withus-worker-mobile-v0.1.1 \
+  krow-withus-worker-mobile/prod-v0.1.0
+
+# Verify you're on the right tag
+git log -1 --oneline
+```
+
+**Format**: `hotfix/<product>-v<PATCH+1>`
+
+---
+
+### Step 3: Fix the Bug
+
+```bash
+# Make your fix
+# Edit files, test locally
+
+# Commit with clear message
+git commit -m "fix: [issue description]
+
+HOTFIX for production
+Issue: [what happened]
+Solution: [what was fixed]
+Tested: [how was it tested locally]"
+```
+
+**Keep it minimal:**
+- Only fix the specific bug
+- Don't refactor or optimize
+- Don't add new features
+
+---
+
+### Step 4: Update Version
+
+Update PATCH version only (0.1.0 → 0.1.1):
+
+**For Mobile** (`apps/mobile/apps/*/pubspec.yaml`):
+```yaml
+# Old
+version: 0.1.0+5
+
+# New
+version: 0.1.1+6  # Only PATCH changed
+```
+
+**For Web** (`apps/web/package.json`):
+```json
+"version": "0.1.1"
+```
+
+**For Backend** (`backend/*/package.json`):
+```json
+"version": "0.1.1"
+```
+
+---
+
+### Step 5: Update CHANGELOG
+
+Add entry to **top** of appropriate CHANGELOG:
+
+```markdown
+| 2026-03-05 | 0.1.1 | HOTFIX: [Issue fixed] |
+
+(previous entries below...)
+```
+
+---
+
+### Step 6: Code Review (Expedited)
+
+```bash
+# Push hotfix branch
+git push origin hotfix/krow-withus-worker-mobile-v0.1.1
+
+# Create PR on GitHub with URGENT label
+gh pr create --title "HOTFIX: [Issue description]" \
+  --body "**URGENT PRODUCTION FIX**
+
+Issue: [What was broken]
+Impact: [Users affected]
+Solution: [What was fixed]
+Testing: [Local verification]"
+```
+
+**Get approval within 15 minutes if possible.**
+
+---
+
+### Step 7: Merge to Main
+
+```bash
+# Review complete - merge
+git checkout main
+git pull origin main
+git merge --ff-only hotfix/krow-withus-worker-mobile-v0.1.1
+git push origin main
+```
+
+---
+
+### Step 8: Create Production Tag
+
+```bash
+# Create tag from main
+git tag -a krow-withus-worker-mobile/prod-v0.1.1 \
+  -m "HOTFIX: [Issue fixed]"
+
+git push origin krow-withus-worker-mobile/prod-v0.1.1
+```
+
+---
+
+### Step 9: Deploy to Production
+
+```bash
+# Follow your deployment procedure
+# Higher priority than normal releases
+
+./scripts/deploy-mobile-production.sh krow-withus-worker-mobile/prod-v0.1.1
+```
+
+**Deployment time**: Within 30 minutes of approval
+
+---
+
+### Step 10: Verify & Monitor
+
+```bash
+# Smoke tests
+- App launches
+- Core features work
+- No new errors
+
+# Monitor for 2 hours
+- Watch error logs
+- Check user reports
+- Verify fix worked
+```
+
+---
+
+### Step 11: Communicate
+
+**Immediately after deployment:**
+
+```markdown
+🚨 PRODUCTION HOTFIX DEPLOYED
+
+Product: Worker Mobile
+Version: 0.1.1
+Issue: [Fixed issue]
+Impact: [Resolved for X users]
+Status: ✅ Deployed & verified
+
+No user action required.
+Service restored to normal.
+```
+
+**24 hours later:**
+
+```markdown
+✅ HOTFIX STATUS UPDATE
+
+Production hotfix v0.1.1 deployed 24 hours ago.
+Zero errors reported post-deployment.
+System stable.
+
+Thank you for your patience!
+```
+
+---
+
+## ⏱️ Timeline
+
+```
+T-0:    Issue detected & reported
+T+5min: Severity assessed, hotfix branch created
+T+15:   Fix implemented, code review started
+T+30:   Approved & merged, tag created
+T+45:   Deployed to production
+T+60:   Smoke tests pass, monitoring enabled
+T+120:  Declare emergency resolved, communicate
+T+1day: Follow-up communication
+```
+
+**Total time: 2-4 hours from detection to resolution**
+
+---
+
+## 🚫 Common Mistakes to Avoid
+
+❌ **Don't**:
+- Skip code review (even in emergency)
+- Add multiple unrelated fixes in one hotfix
+- Forget to update version number
+- Forget CHANGELOG entry
+- Deploy without testing
+- Forget to communicate with users
+
+✅ **Do**:
+- Keep hotfix minimal and focused
+- Test every fix locally first
+- Get at least one approval
+- Update all version files
+- Deploy immediately after approval
+- Monitor actively for 2+ hours
+
+---
+
+## 📋 Hotfix Checklist
+
+Copy for each emergency:
+
+```
+Hotfix: [Product] v[Old Version] → v[New Version]
+
+□ Severity assessed & documented
+□ Branch created from production tag
+□ Bug fixed & tested locally
+□ Version number updated (PATCH only)
+□ CHANGELOG entry added
+□ Commit message clear
+□ Code review requested (marked URGENT)
+□ Approval obtained
+□ Merged to main
+□ Production tag created
+□ Tag pushed to remote
+□ Deployed to production
+□ Smoke tests passed
+□ Error logs monitored (2+ hours)
+□ Users notified
+□ GitHub Release created
+□ Incident documented
+
+Total Time: ___ minutes
+```
+
+---
+
+## 🔍 Post-Incident
+
+After emergency is resolved:
+
+1. **Document what happened**
+   - Root cause analysis
+   - Why it wasn't caught before
+   - What testing was missed
+
+2. **Schedule postmortem** (within 24 hours)
+   - Review what went wrong
+   - Discuss prevention
+   - Update processes if needed
+
+3. **Plan prevention**
+   - Add test coverage
+   - Update CI/CD checks
+   - Improve monitoring
+
+4. **Communicate findings**
+   - Share with team
+   - Update documentation
+   - Prevent recurrence
+
+---
+
+## 📞 Emergency Contacts
+
+When issue detected:
+
+1. **Notify**: 
+   - Release Engineer
+   - DevOps
+   - Product Owner
+   - Affected Team
+
+2. **Communication Channel**:
+   - Slack: #emergency-releases
+   - Time-sensitive decisions on call
+
+3. **Decision Maker**:
+   - Product Owner approves rollback vs hotfix
+   - Release Engineer executes
+   - DevOps monitors infrastructure
+
+---
+
+## 🔗 Related
+
+- [OVERALL_RELEASE_PLAN.md](./OVERALL_RELEASE_PLAN.md) - Main release strategy
+- [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) - Mobile-specific process
+- [../../CHANGELOG.md](../../CHANGELOG.md) - Version history
+
+---
+
+**Last Updated**: 2026-03-05  
+**Severity Levels**:
+- 🔴 CRITICAL: Service down, data loss, security (< 1 hour)
+- 🟠 HIGH: Major feature broken, workaround available (< 4 hours)
+- 🟡 MEDIUM: Minor feature affected (next release OK)
diff --git a/docs/RELEASE/MOBILE_RELEASE_PLAN.md b/docs/RELEASE/MOBILE_RELEASE_PLAN.md
new file mode 100644
index 00000000..c37dcc5b
--- /dev/null
+++ b/docs/RELEASE/MOBILE_RELEASE_PLAN.md
@@ -0,0 +1,564 @@
+# Mobile App Release Plan
+
+**For Staff Mobile & Client Mobile Apps**
+
+---
+
+## 📱 Overview
+
+This document covers release procedures for:
+
+- **Staff Mobile App** (aka "Worker Mobile") - `krow-withus-worker-mobile`
+- **Client Mobile App** - `krow-withus-client-mobile`
+
+Both apps:
+- Built with Flutter
+- Distributed to iOS & Android app stores
+- Maintain independent versions
+- Have independent CHANGELOGs
+- Share backend infrastructure
+
+---
+
+## 🏷️ Tag & Release Naming
+
+### Tag Format
+
+```
+krow-withus-<app>-mobile/<environment>-v<major>.<minor>.<patch>
+```
+
+### Examples
+
+**Staff Mobile (Worker Mobile)**
+```
+krow-withus-worker-mobile/dev-v0.1.0
+krow-withus-worker-mobile/stage-v0.2.0
+krow-withus-worker-mobile/prod-v1.0.0
+krow-withus-worker-mobile/prod-v1.0.1-hotfix.1
+```
+
+**Client Mobile**
+```
+krow-withus-client-mobile/dev-v0.1.0
+krow-withus-client-mobile/stage-v0.2.0
+krow-withus-client-mobile/prod-v1.0.0
+```
+
+### GitHub Release Names
+
+```
+Krow With Us - Worker Mobile - DEV - v0.1.0
+Krow With Us - Worker Mobile - STAGE - v0.2.0
+Krow With Us - Worker Mobile - PROD - v1.0.0
+
+Krow With Us - Client Mobile - DEV - v0.1.0
+Krow With Us - Client Mobile - STAGE - v0.2.0
+Krow With Us - Client Mobile - PROD - v1.0.0
+```
+
+---
+
+## 📝 CHANGELOG Management
+
+### Location
+
+Each app has its own CHANGELOG in the `apps/mobile/` directory structure:
+
+```
+apps/mobile/
+├── packages/
+│   ├── features/
+│   │   ├── staff/
+│   │   │   ├── authentication/CHANGELOG.md
+│   │   │   ├── home/CHANGELOG.md
+│   │   │   ├── payments/CHANGELOG.md
+│   │   │   ├── shifts/CHANGELOG.md
+│   │   │   └── ... (other staff features)
+│   │   └── client/
+│   │       ├── dashboard/CHANGELOG.md
+│   │       ├── orders/CHANGELOG.md
+│   │       └── ... (other client features)
+│   └── ... (other packages)
+├── apps/
+│   ├── staff_app/CHANGELOG.md              ← Staff app root
+│   └── client_app/CHANGELOG.md             ← Client app root
+└── CHANGELOG.md                            ← Consolidated (optional)
+```
+
+### App-Level CHANGELOG Format
+
+**File**: `apps/mobile/apps/staff_app/CHANGELOG.md`
+
+```markdown
+# Staff Mobile App - Change Log
+
+## [0.2.0] - 2026-03-15
+
+### Added
+- Feature X implementation
+- Feature Y enhancement
+- New UI component Z
+
+### Fixed
+- Bug fix for issue #123
+- Crash when loading payments
+
+### Changed
+- Updated design system
+- Improved performance
+
+### Deprecated
+- Removed old API endpoint
+
+## [0.1.0] - 2026-03-01
+
+### Added
+- Initial release
+- Authentication with phone & OTP
+- Shift browsing and booking
+- Clock in/out functionality
+- Payment history view
+```
+
+### Consolidated CHANGELOG (Optional)
+
+**File**: `apps/mobile/CHANGELOG.md` (at root of mobile folder)
+
+High-level overview of both apps:
+
+```markdown
+# Krow Workforce - Mobile Apps - Change Log
+
+## Staff Mobile v0.2.0 + Client Mobile v0.1.0 - 2026-03-15
+
+### Staff Mobile v0.2.0
+- Feature improvements
+- Bug fixes
+
+### Client Mobile v0.1.0
+- Initial release
+
+## Previous versions...
+```
+
+---
+
+## 📝 Version Files
+
+### Staff Mobile App
+
+**Primary Version File**: `apps/mobile/apps/staff_app/pubspec.yaml`
+
+```yaml
+name: staff_app
+description: "Krow With Us - Staff App"
+
+# Version format: MAJOR.MINOR.PATCH+BUILD_NUMBER
+version: 0.1.0+1
+
+environment:
+  sdk: '>=3.10.0 <4.0.0'
+  flutter: '>=3.38.0 <4.0.0'
+```
+
+**Rules**:
+- Update version before each release
+- Bump build number (+1) every build
+- SemVer only for version part (before +)
+
+### Client Mobile App
+
+**Primary Version File**: `apps/mobile/apps/client_app/pubspec.yaml`
+
+```yaml
+name: client_app
+description: "Krow With Us - Client App"
+
+version: 0.1.0+1
+
+environment:
+  sdk: '>=3.10.0 <4.0.0'
+  flutter: '>=3.38.0 <4.0.0'
+```
+
+---
+
+## 🚀 Release Workflow
+
+### Step 1: Create Release Branch
+
+```bash
+cd /Users/achintha/Documents/GitHub/krow-workforce
+
+# For Staff Mobile
+git checkout -b release/staff-mobile-v0.2.0
+
+# For Client Mobile
+git checkout -b release/client-mobile-v0.2.0
+```
+
+---
+
+### Step 2: Update Version Numbers
+
+#### Staff Mobile Example (v0.1.0 → v0.2.0)
+
+**File**: `apps/mobile/apps/staff_app/pubspec.yaml`
+
+```yaml
+# Old
+version: 0.1.0+5
+
+# New
+version: 0.2.0+6
+```
+
+#### Client Mobile Example (v0.1.0 → v0.2.0)
+
+**File**: `apps/mobile/apps/client_app/pubspec.yaml`
+
+```yaml
+# Old
+version: 0.1.0+3
+
+# New
+version: 0.2.0+4
+```
+
+---
+
+### Step 3: Update CHANGELOG
+
+**File**: `apps/mobile/apps/staff_app/CHANGELOG.md`
+
+Add entry at **top**:
+
+```markdown
+# Staff Mobile App - Change Log
+
+## [0.2.0] - 2026-03-05
+
+### Added
+- New shift details page with profile gating
+- Benefits overview section
+- Auto-match functionality
+
+### Fixed
+- Payment history display bug
+- Clock-in location verification
+
+### Changed
+- Updated design system components
+- Improved shift booking flow
+
+## [0.1.0] - 2026-02-15
+...
+```
+
+---
+
+### Step 4: Commit Changes
+
+```bash
+cd /Users/achintha/Documents/GitHub/krow-workforce
+
+# Stage changes
+git add apps/mobile/apps/staff_app/pubspec.yaml
+git add apps/mobile/apps/staff_app/CHANGELOG.md
+
+# Commit
+git commit -m "chore(staff-mobile): bump version to 0.2.0
+
+- Updated pubspec.yaml version: 0.1.0 → 0.2.0
+- Updated build number: 5 → 6
+- Updated CHANGELOG.md with v0.2.0 changes"
+```
+
+---
+
+### Step 5: Create Pull Request
+
+```bash
+# Push release branch
+git push origin release/staff-mobile-v0.2.0
+
+# Create PR (GitHub CLI)
+gh pr create \
+  --title "Release: Staff Mobile v0.2.0" \
+  --body "## Release: Staff Mobile v0.2.0
+
+### Changes
+- See CHANGELOG.md for full list
+
+### Testing
+- [ ] All tests passing
+- [ ] Manual testing complete
+- [ ] CodeMagic build successful
+
+### Checklist
+- [x] Version updated
+- [x] CHANGELOG updated
+- [x] Branch created from main
+- [ ] Approved by team lead"
+```
+
+---
+
+### Step 6: Merge to Main
+
+Once PR is approved:
+
+```bash
+# Switch to main
+git checkout main
+git pull origin main
+
+# Merge (fast-forward only)
+git merge --ff-only release/staff-mobile-v0.2.0
+
+# Push to remote
+git push origin main
+
+# Delete release branch
+git push origin --delete release/staff-mobile-v0.2.0
+```
+
+---
+
+### Step 7: Create Git Tag
+
+```bash
+# For DEV release
+git tag -a krow-withus-worker-mobile/dev-v0.2.0 \
+  -m "Staff Mobile v0.2.0 - Dev Release
+
+Features:
+- Shift details improvements
+- Benefits overview
+- Auto-match functionality
+
+Testing:
+- All unit tests passing
+- Manual QA on dev environment"
+
+# For STAGE release
+git tag -a krow-withus-worker-mobile/stage-v0.2.0 \
+  -m "Staff Mobile v0.2.0 - Stage Release"
+
+# For PROD release
+git tag -a krow-withus-worker-mobile/prod-v0.2.0 \
+  -m "Staff Mobile v0.2.0 - Production Release"
+```
+
+**Push tags**:
+
+```bash
+git push origin krow-withus-worker-mobile/dev-v0.2.0
+git push origin krow-withus-worker-mobile/stage-v0.2.0
+git push origin krow-withus-worker-mobile/prod-v0.2.0
+```
+
+---
+
+### Step 8: Create GitHub Release
+
+1. Go to: GitHub → Releases → Draft a new release
+2. Fill in:
+
+```
+Tag version: krow-withus-worker-mobile/dev-v0.2.0
+
+Release title:
+Krow With Us - Worker Mobile - DEV - v0.2.0
+
+Description:
+
+## 🎯 What's New in v0.2.0
+
+### ✨ Features
+- Shift details page with profile completion gating
+- Benefits overview with sick leave tracking
+- Auto-match shift recommendations
+
+### 🔧 Improvements
+- Faster payment history loading
+- Better shift booking UX
+- Improved clock-in reliability
+
+### 🐛 Bug Fixes
+- Fixed payment display date issue
+- Fixed location verification on iOS 15+
+- Fixed crash when no shifts available
+
+## 📦 Installation
+
+**iOS**: Download via TestFlight (internal) or App Store
+**Android**: Download via Play Store
+
+## 🔗 Dependencies
+
+Requires:
+- Backend API v0.1.0+
+- DataConnect schema v0.3.0+
+
+## ⚠️ Known Issues
+
+- Location permissions take 5-10 seconds on first install
+- Workaround: Grant permissions in Settings app
+
+## 📝 Notes for QA
+
+- Test on actual device, not emulator
+- Verify clock-in with GPS enabled
+- Test all payment history edge cases
+
+---
+
+Release Date: 2026-03-05
+Build Number: 6
+```
+
+3. **Optional**: Attach build artifacts (APK/AAB from CodeMagic)
+4. **Click**: "Publish release"
+
+---
+
+## 🔄 Deployment Flow
+
+### Dev Release → Staging
+
+After dev is tested:
+
+```bash
+# Create stage tag from same commit
+git tag -a krow-withus-worker-mobile/stage-v0.2.0 \
+  krow-withus-worker-mobile/dev-v0.2.0 \
+  -m "Staff Mobile v0.2.0 - Stage Release"
+
+git push origin krow-withus-worker-mobile/stage-v0.2.0
+
+# Deploy using CodeMagic or manual process
+```
+
+### Staging Release → Production
+
+After QA approval:
+
+```bash
+# Create prod tag from same commit
+git tag -a krow-withus-worker-mobile/prod-v0.2.0 \
+  krow-withus-worker-mobile/stage-v0.2.0 \
+  -m "Worker Mobile v0.2.0 - Production Release"
+
+git push origin krow-withus-worker-mobile/prod-v0.2.0
+
+# Deploy to production
+```
+
+---
+
+## 📱 App Store Distribution
+
+### iOS App Store
+
+**Version Name**: Match pubspec.yaml version (0.2.0)  
+**Build Number**: Match pubspec.yaml build number (+6)
+
+**Steps**:
+1. Ensure TestFlight build passed
+2. Submit to App Review
+3. Apple reviews (3-5 days)
+4. Release to users (can be phased)
+
+### Google Play Store
+
+**Version Name**: Match pubspec.yaml version (0.2.0)  
+**Version Code**: Match pubspec.yaml build number (6)
+
+**Steps**:
+1. Upload APK/AAB from CodeMagic
+2. Fill in release notes (from CHANGELOG)
+3. Submit for review
+4. Google reviews (hours to 24h)
+5. Release to users (can be phased, e.g., 10% then 100%)
+
+---
+
+## 🔧 Pre-Release Checklist
+
+Before creating tags:
+
+- [ ] All PRs merged to main
+- [ ] Code review complete
+- [ ] Tests passing (unit, widget, integration)
+- [ ] No lint/analysis errors: `flutter analyze`
+- [ ] Pubspec.yaml version updated
+- [ ] Build number incremented
+- [ ] CHANGELOG.md updated with date
+- [ ] Screenshots prepared (fresh)
+- [ ] Release notes drafted
+- [ ] No hardcoded strings (use translations)
+- [ ] No debug prints remaining
+- [ ] Performance acceptable (app launch < 3 seconds)
+- [ ] Screen lock/unlock works
+- [ ] Deep links tested
+- [ ] Notifications working
+- [ ] GPS/location working
+- [ ] Camera permissions working
+- [ ] All user-facing text reviewed
+
+---
+
+## 🎯 Release Cadence
+
+### Development Releases (dev)
+
+- **Frequency**: Weekly
+- **Day**: Monday 10:00 UTC
+- **Process**: Quick, test in dev only
+
+### Staging Releases (stage)
+
+- **Frequency**: Bi-weekly (on sprint/feature completion)
+- **Day**: Wednesday before production
+- **Process**: Full QA testing, 1 week in staging
+
+### Production Releases (prod)
+
+- **Frequency**: Monthly (end of sprint)
+- **Day**: Sunday/Monday morning (low traffic)
+- **Process**: Full validation, market distribution
+
+---
+
+## 🔗 Related
+
+- [OVERALL_RELEASE_PLAN.md](./OVERALL_RELEASE_PLAN.md) - General strategy
+- [HOTFIX_PROCESS.md](./HOTFIX_PROCESS.md) - Emergency procedures
+- [../../CHANGELOG.md](../../CHANGELOG.md) - Root-level history
+
+---
+
+## 📞 Common Questions
+
+**Q: What if I need to release just one app (not both)?**
+A: Completely fine! Each app is independent. Release when ready.
+
+**Q: Do I need to update the root CHANGELOG?**
+A: Optional. If you do, keep it high-level and reference app-specific CHANGELOGs.
+
+**Q: What about shared packages inside mobile/?**
+A: If shared package updated, mention in both app CHANGELOGs.
+
+**Q: How do I handle breaking changes?**
+A: MAJOR version bump (0.x → 1.x) and clearly document in CHANGELOG.
+
+**Q: Can I release dev and stage on different days?**
+A: Yes, no fixed schedule for dev/stage. Prod should be consistent (Sundays).
+
+---
+
+**Last Updated**: 2026-03-05  
+**Owner**: Mobile Engineering Team  
+**Status**: Active
diff --git a/docs/RELEASE/OVERALL_RELEASE_PLAN.md b/docs/RELEASE/OVERALL_RELEASE_PLAN.md
new file mode 100644
index 00000000..9ef4785f
--- /dev/null
+++ b/docs/RELEASE/OVERALL_RELEASE_PLAN.md
@@ -0,0 +1,452 @@
+# KROW Workforce - Overall Release Plan
+
+**Document Version**: 1.0  
+**Created**: 2026-03-05  
+**Last Updated**: 2026-03-05  
+**Product Scope**: All products (Mobile, Web, Backend, Database)
+
+---
+
+## 📋 Overview
+
+This document outlines the release strategy for KROW Workforce monorepo containing 5 products:
+
+1. **Staff Mobile App** (Flutter - iOS/Android)
+2. **Client Mobile App** (Flutter - iOS/Android)
+3. **Web Dashboard** (React/Vite)
+4. **Backend Services** (Node.js - Command API, Core API)
+5. **Database** (Firebase Data Connect with PostgreSQL)
+
+---
+
+## 🔗 Versioning Strategy
+
+### Semantic Versioning (SemVer)
+
+All products use **Semantic Versioning 2.0.0**:
+
+```
+MAJOR.MINOR.PATCH-QUALIFIER
+0.1.0
+1.2.3-rc.1
+```
+
+- **MAJOR** (0→1): Breaking changes, major features
+- **MINOR** (1→2): Backward-compatible new features
+- **PATCH** (3→4): Bug fixes, minor improvements
+- **QUALIFIER** (optional): `-rc.1`, `-beta.1`, `-hotfix.1`
+
+### Version Independence
+
+Each product maintains **independent versioning**:
+- Products release on their own schedule
+- No requirement to synchronize versions
+- Can release major updates independently
+
+---
+
+## 🏷️ Git Tag Naming Convention
+
+### Standard Format
+
+```
+<product>/<environment>-v<major>.<minor>.<patch>
+```
+
+### Products & Environments
+
+| Product | Tag Prefix | Environments |
+|---------|-----------|---------------|
+| Staff Mobile | `krow-withus-worker-mobile` | dev, stage, prod |
+| Client Mobile | `krow-withus-client-mobile` | dev, stage, prod |
+| Web Dashboard | `web-dashboard` | dev, stage, prod |
+| Command API | `command-api` | dev, stage, prod |
+| Core API | `core-api` | dev, stage, prod |
+| DataConnect | `dataconnect` | stage, prod |
+
+### Environments
+
+- **dev**: Development releases (daily/weekly), unstable
+- **stage**: Staging releases (bi-weekly), pre-production testing
+- **prod**: Production releases (monthly), stable, customer-facing
+
+### Examples
+
+```
+krow-withus-worker-mobile/dev-v0.1.0
+krow-withus-client-mobile/stage-v0.2.0
+web-dashboard/prod-v1.0.0
+command-api/dev-v0.2.1
+core-api/prod-v0.1.0
+```
+
+---
+
+## 📅 Release Cadence
+
+### Development Releases (dev)
+
+- **Frequency**: Weekly or as-needed
+- **Scope**: Feature completions, bug fixes
+- **Duration**: Not guaranteed stable
+- **Deployment**: Dev environment only
+- **Who**: Development team
+
+### Staging Releases (stage)
+
+- **Frequency**: Bi-weekly (typically mid/end of sprint)
+- **Scope**: Sprint completion, feature milestones
+- **Duration**: 1-2 weeks stability expected
+- **Deployment**: Staging environment for QA
+- **Who**: QA team validates
+
+### Production Releases (prod)
+
+- **Frequency**: Monthly or sprint-based
+- **Scope**: Feature milestone completion, critical fixes
+- **Duration**: 4+ weeks standard support
+- **Deployment**: Production environment (customer-facing)
+- **Who**: Product owner approves, DevOps deploys
+
+---
+
+## 🔄 Product Dependency & Deployment Order
+
+### Critical Path (for synchronized releases)
+
+Deploy in this order:
+
+1. **DataConnect Schema** (if schema changed)
+   - Deploy schema changes first
+   - All APIs depend on schema availability
+
+2. **Backend Services** (parallel OK)
+   - Command API
+   - Core API
+   - Both can deploy simultaneously
+
+3. **Web Dashboard**
+   - Can deploy once backend ready
+   - Test API endpoints stable
+
+4. **Mobile Apps** (parallel OK)
+   - Staff Mobile
+   - Client Mobile
+   - Both can deploy simultaneously, independent of web
+
+### Independent Releases
+
+Products **can release independently** if:
+- No backend schema changes
+- No breaking API changes
+- No data migrations required
+
+Example: Staff Mobile can release UI improvements without web/backend changes.
+
+---
+
+## 📝 CHANGELOG Management
+
+### Location & Structure
+
+Each major product maintains its own CHANGELOG:
+
+```
+apps/mobile/packages/features/staff/*/CHANGELOG.md
+apps/mobile/packages/features/client/*/CHANGELOG.md
+apps/web/CHANGELOG.md
+backend/command-api/CHANGELOG.md
+backend/core-api/CHANGELOG.md
+CHANGELOG.md (root - high-level overview)
+```
+
+### Format
+
+```markdown
+| Date | Version | Change |
+|------|---------|--------|
+| 2026-03-05 | 0.1.0 | Initial release - [feature list] |
+```
+
+### What to Track
+
+- Features added
+- Bugs fixed
+- Breaking changes (clearly marked ⚠️)
+- Dependencies upgraded
+- Migration steps (if applicable)
+
+---
+
+## ✅ Release Checklist
+
+### Pre-Release (48 hours before)
+
+- [ ] All PRs merged to main
+- [ ] Code review complete
+- [ ] All tests passing (unit, integration, E2E)
+- [ ] No lint/type errors
+- [ ] Mobile builds succeed (CodeMagic)
+- [ ] Performance benchmarks acceptable
+- [ ] Security scan completed
+- [ ] CHANGELOG.md updated with all changes
+- [ ] Documentation updated
+- [ ] Team notified of pending release
+
+### Release Day
+
+- [ ] Update version numbers in all relevant files
+- [ ] Update CHANGELOG with date
+- [ ] Git commit: `git commit -m "chore: bump version to X.Y.Z"`
+- [ ] Git push changes to main
+- [ ] Create git tag: `git tag -a <product>/<env>-v<version> -m "Release message"`
+- [ ] Push tags: `git push origin <tag-name>`
+- [ ] Deploy to target environment
+- [ ] Smoke tests pass
+- [ ] Create GitHub Release page
+- [ ] Notify stakeholders
+
+### Post-Release (24 hours)
+
+- [ ] Monitor error logs
+- [ ] Verify all features work end-to-end
+- [ ] Performance is acceptable
+- [ ] No regressions reported
+- [ ] Users updated if needed
+- [ ] Document any issues
+
+---
+
+## 🔐 Protected Tags
+
+### Branch Protection Rules
+
+**Production tags require approval:**
+
+- Tag pattern: `*/prod-v*`
+- Require pull request review (1+ approval)
+- Require status checks to pass
+- Prevent force pushes
+- Disable deletions
+
+**Staging tags recommended:**
+
+- Tag pattern: `*/stage-v*`
+- Consider: Require at least 1 approval
+- Status checks should pass
+
+**Dev tags open:**
+
+- Tag pattern: `*/dev-v*`
+- No restrictions
+- Allow fast iteration
+
+---
+
+## 🚨 Rollback Procedures
+
+### For Production Issues
+
+**If critical issue detected:**
+
+1. **Identify** the product and issue
+2. **Assess** impact and severity
+3. **Decide** rollback vs hotfix
+   - Rollback: Undo entire release
+   - Hotfix: Fix and re-release (see HOTFIX_PROCESS.md)
+4. **Execute** rollback:
+   ```bash
+   # Revert commit
+   git revert <commit-hash> -m 1
+   git push origin main
+   
+   # Or switch traffic back to previous version
+   # (depends on deployment infrastructure)
+   ```
+5. **Communicate** with users
+6. **Plan** hotfix or next release
+
+### Time Windows
+
+- **Awareness**: 15-30 minutes (monitoring)
+- **Decision**: 15-30 minutes (severity assessment)
+- **Execution**: 15-60 minutes (rollback deployment)
+- **Verification**: 30-60 minutes (smoke tests)
+- **Communication**: Immediate + 24h updates
+
+**Total**: 2-4 hours from detection to stable state
+
+---
+
+## 📊 Release Templates & Tools
+
+### Git Commands
+
+```bash
+# Create tag
+git tag -a krow-withus-worker-mobile/dev-v0.1.0 \
+  -m "Staff Mobile v0.1.0 - Feature X"
+
+# Push tag
+git push origin krow-withus-worker-mobile/dev-v0.1.0
+
+# View tags for product
+git tag -l "krow-withus-worker-mobile/*" --sort=-version:refname
+
+# See what's in a tag
+git show krow-withus-worker-mobile/dev-v0.1.0
+
+# Delete tag (if mistake)
+git tag -d krow-withus-worker-mobile/dev-v0.1.0
+git push origin --delete krow-withus-worker-mobile/dev-v0.1.0
+```
+
+### GitHub Release Template
+
+```markdown
+# Krow With Us - Worker Mobile - DEV - v0.1.0
+
+**Release Date**: [Date]
+**Environment**: Development
+
+## What's New
+
+### ✨ Features
+- Feature 1 description
+- Feature 2 description
+
+### 🔧 Improvements
+- Improvement 1
+- Improvement 2
+
+### 🐛 Bug Fixes
+- Bug fix 1
+- Bug fix 2
+
+## Dependencies
+
+Requires:
+- Backend API v0.1.0 or higher
+- DataConnect schema v0.3.0 (if updated)
+
+## Installation
+
+[Download links & instructions]
+
+## Known Issues
+
+- Issue 1: [desc] (Workaround: ...)
+
+## Support
+
+contact: support@krow-workforce.com
+```
+
+---
+
+## 🔄 Hotfix Releases
+
+See [HOTFIX_PROCESS.md](./HOTFIX_PROCESS.md) for emergency procedures.
+
+Quick summary:
+1. Branch from production tag
+2. Fix the issue
+3. Bump PATCH version only
+4. Test and deploy immediately
+5. Create hotfix tag
+
+---
+
+## 📱 Mobile-Specific Release Process
+
+See [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) for detailed mobile app process including:
+- Staff Mobile vs Client Mobile differences
+- Build number management
+- CodeMagic integration
+- App store distribution
+- CHANGELOG per app
+
+---
+
+## 🎯 Release Coordination
+
+### Single Product Release
+
+1. Update version files
+2. Update CHANGELOG
+3. Commit & push
+4. Create tag
+5. Deploy
+6. Create GitHub Release
+
+**Time**: 30-45 minutes (excluding testing)
+
+### Multi-Product Release (e.g., v1.0.0)
+
+**Pre-release phase** (1 week before):
+- Code freeze announced
+- QA testing begins
+- No new features merged
+
+**Release phase** (2-3 days):
+- Staging release (all products)
+- QA validation
+- Product owner sign-off
+
+**Production phase** (1 day):
+- Deploy in dependency order
+- Smoke tests each product
+- Monitor 24 hours
+- User communication
+
+**Time**: 5-7 days total, 4 hours active deployment
+
+---
+
+## 📞 Roles & Responsibilities
+
+| Role | Responsibility |
+|------|-----------------|
+| **Developer** | Keep code release-ready, update versions |
+| **QA** | Test staging releases, validate prod |
+| **Release Engineer** | Create tags, manage deployment, monitor |
+| **Product Owner** | Approve releases, communicate timeline |
+| **DevOps** | Infrastructure ready, deployment scripts |
+
+---
+
+## 📊 Success Metrics
+
+Track these per release:
+
+- **Lead Time**: Time from code commit to production
+- **Deployment Frequency**: How often you release
+- **Change Failure Rate**: % of releases needing rollback
+- **Time to Recovery**: Time to fix production issues
+- **User Adoption**: % of users on latest version
+
+---
+
+## 📚 Related Documentation
+
+- [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) - Mobile app releases
+- [HOTFIX_PROCESS.md](./HOTFIX_PROCESS.md) - Emergency procedures
+- [../../RELEASE_STRATEGY.md](../../RELEASE_STRATEGY.md) - Original detailed guide
+- [../../CHANGELOG.md](../../CHANGELOG.md) - Root version history
+
+---
+
+## ✅ Implementation Status
+
+- ✅ Versioning strategy: SemVer
+- ✅ Environments: dev, stage, prod
+- ✅ Tag naming: Product-specific with brand prefix
+- ✅ Product dependencies: Defined
+- ✅ Release cadence: 3 levels
+- ⏳ GitHub Actions: To be set up
+- ⏳ Deployment automation: To be set up
+
+---
+
+**Next Step**: Review [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) for app-specific process.
+