production-deployment-phase

<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>

Check workflow state for staging validation approval:

# 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:

# 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:

# 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>