Rollback procedure documented

Severity: Critical

A documented rollback procedure ensures anyone on the team can quickly revert a bad deployment without figuring it out under pressure.

Check automatically:

1. Look for rollback documentation:

# Search docs for rollback procedures
grep -riE "rollback|revert|roll back" docs/ README.md CLAUDE.md runbooks/ --include="*.md" 2>/dev/null

# Check deployment scripts for rollback commands
grep -riE "rollback|revert" deploy/ .github/ scripts/ --include="*.sh" --include="*.yml" 2>/dev/null

2. Check if using platforms with built-in rollback:

# Vercel - instant rollback via dashboard
grep -E "vercel" package.json vercel.json 2>/dev/null

# Railway - instant rollback via dashboard
grep -E "railway" package.json railway.json 2>/dev/null

# Fly.io - `fly releases rollback`
find . -name "fly.toml" 2>/dev/null

# Kubernetes - `kubectl rollout undo`
find . -name "*.yaml" -exec grep -l "kind: Deployment" {} \; 2>/dev/null

Ask user:

• "Is the rollback procedure documented?"
• "Who can perform a rollback?"
• "Does everyone on the team know how to do it?"

Cross-reference with:

• RR-003 (rollback speed) - documented procedure enables fast execution
• Section 10/11 (deployment) - rollback is part of deployment workflow
• Section 35 (incident response) - rollback may be in runbooks

Pass criteria:

• Written procedure for how to rollback a bad deploy
• Documents who can do it and how
• OR uses platform with built-in rollback (Vercel, Railway, etc.) and team knows how

Fail criteria:

• No documentation
• Only verbal knowledge ("ask Bob")
• Platform has rollback but nobody knows how to use it

Evidence to capture:

• Location of rollback docs
• Platform being used and its rollback capabilities
• Who has access to trigger rollback

---