production-deployment-phase

<objective>
Execute production deployment workflow by promoting validated staging builds to production with semantic versioning, health checks, release tagging, and comprehensive monitoring.
</objective>

<quick_start>
<production_deployment_workflow>
**Prerequisite-driven production promotion:**

1. **Verify staging validation**: Check state.yaml manual_gates.staging_validation.status = approved
2. **Bump semantic version**: Update package.json/version files (major.minor.patch)
3. **Create release tag**: Tag git commit with new version
4. **Deploy to production**: Push to production branch or trigger deployment
5. **Run health checks**: Verify endpoints, databases, services operational
6. **Generate ship report**: Document deployment artifacts and metadata
7. **Monitor post-deploy**: Watch logs, metrics, alerts for 15-30 minutes

**Example workflow:**

```
Verifying staging validation complete... ✅
Current version: 2.6.0
Bump type: minor (new features added)
New version: 2.7.0

Creating git tag v2.7.0... ✅
Pushing to production branch... ✅
Triggering production deployment... ✅

Health checks:
  API endpoints: 200 OK ✅
  Database connections: healthy ✅
  Cache: operational ✅
  CDN: propagated ✅

Production deployment successful!
Release: https://github.com/user/repo/releases/tag/v2.7.0
Ship report: specs/NNN-slug/production-ship-report.md
```

</production_deployment_workflow>

<trigger_conditions>
**Auto-invoke when:**

- `/ship-prod` command executed
- User mentions "deploy to production", "ship to prod", "production release"
- state.yaml shows current_phase: ship-prod

**Prerequisites required:**

- Staging validation approved (manual_gates.staging_validation.status = approved)
- Rollback gate passed (quality_gates.rollback.status = passed)
- Git repository has remote configured
- Production deployment configuration exists
  </trigger_conditions>
  </quick_start>

<workflow>
<step_1_verify_staging>
**1. Verify Staging Validation Complete**

Check workflow state for staging validation approval:

```bash
# Read workflow state
STATE_FILE="specs/$(ls -t specs/ | head -1)/state.yaml"

STAGING_STATUS=$(grep -A2 "staging_validation:" "$STATE_FILE" | grep "status:" | awk '{print $2}')

if [ "$STAGING_STATUS" != "approved" ]; then
  echo "❌ BLOCKED: Staging validation not approved"
  echo "Current status: $STAGING_STATUS"
  echo "Run: /validate-staging to complete manual validation"
  exit 1
fi

echo "✅ Staging validation approved"
```

**Blocking conditions:**

- Staging validation status ≠ approved
- Rollback gate status ≠ passed
- No staging deployment exists
  </step_1_verify_staging>

<step_2_bump_version>
**2. Bump Semantic Version**

Determine version bump type and update version files:

```bash
# Read current version
CURRENT_VERSION=$(node -p "require('./package.json').version")

# Determine bump type from CHANGELOG or git commits
# - major: Breaking changes
# - minor: New features (backward compatible)
# - patch: Bug fixes only

# Use npm version or manual update
npm version minor -m "chore: bump version to %s for production release"

NEW_VERSION=$(node -p "require('./package.json').version")

echo "Version bumped: $CURRENT_VERSION → $NEW_VERSION"
```

**Semantic versioning rules:**

- **Major (X.0.0)**: Breaking changes, API contract changes
- **Minor (0.X.0)**: New features, backward compatible
- **Patch (0.0.X)**: Bug fixes, no new features

**Files to update:**

- package.json (version field)
- CHANGELOG.md (unreleased → version section)
- Any version constants in code
  </step_2_bump_version>

<step_3_create_release_tag>
**3. Create Git Release Tag**

Tag the commit and push to remote:

```bash
# Create annotated tag
git tag -a "v${NEW_VERSION}" -m "Release v${NEW_VERSION}

$(sed -n "/## \[${NEW_VERSION}\]/,/## \[/p" CHANGELOG.md | head -n -1)"

# Push tag to remote
git push origin "v${NEW_VERSION}"

echo "✅ Tag created and pushed: v${NEW_VERSION}"
```

**Tag format:**

- Annotated tags required (not lightweight)
- Prefix with "v" (e.g., v2.7.0)
- Include CHANGELOG excerpt in tag message
  </step_3_create_release_tag>

<step_4_deploy_production>
**4. Deploy to Production**

Trigger production deployment based on deployment model:

```bash
# Model 1: Git push to production branch
git push origin main:production

# Model 2: GitHub Actions deployment
gh workflow run deploy-production.yml \
  -f version="${NEW_VERSION}" \
  -f environment=production

# Model 3: Direct deployment platform (Vercel, Netlify, etc.)
vercel --prod --yes
```

**Deployment verification:**

- Wait for deployment to complete
- Check deployment platform status
- Verify deployment ID/URL returned
- Record deployment metadata
  </step_4_deploy_production>

<step_5_health_checks>
**5. Run Production Health Checks**

Verify all critical services operational:

```bash
echo "Running production health checks..."

# API endpoints
for ENDPOINT in /health /api/status /api/version; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://production.example.com$ENDPOINT")
  if [ "$STATUS" = "200" ]; then
    echo "  ✅ $ENDPOINT: $STATUS OK"
  else
    echo "  ❌ $ENDPOINT: $STATUS FAILED"
    HEALTH_FAILED=true
  fi
done

# Database connectivity
# (Run via deployment platform or SSH to production)

# Cache/Redis
# CDN propagation
# Background jobs

if [ "$HEALTH_FAILED" = "true" ]; then
  echo "❌ Health checks failed - initiate rollback"
  exit 1
fi

echo "✅ All health checks passed"
```

**Critical checks:**

- API endpoints return 200 OK
- Database connections healthy
- Cache/Redis operational
- CDN serving latest assets
- Background jobs processing
  </step_5_health_checks>

<step_6_generate_ship_report>
**6. Generate Production Ship Report**

Create production-ship-report.md with deployment metadata:

```bash
cat > specs/$FEATURE_SLUG/production-ship-report.md <<EOF
# Production Ship Report: $FEATURE_SLUG

## Deployment Summary
- **Version**: v${NEW_VERSION}
- **Deployed at**: $(date -Iseconds)
- **Deployment ID**