/sdd:story-rollback

Meta

• Version: 2.0
• Category: workflow
• Complexity: comprehensive
• Purpose: Critical rollback procedure for failed deployments or production issues

Definition

Purpose: Execute comprehensive rollback procedure for a deployed story experiencing critical issues in production. Revert code changes, database migrations, configuration, and restore system stability.

Syntax: /sdd:story-rollback <story_id> [--severity=critical|high|medium] [--rollback-type=full|code|database|config]

Parameters

Parameter	Type	Required	Default	Description	Validation
story_id	string	Yes	-	Story identifier (e.g., "STORY-2025-001")	Must match pattern STORY-\d{4}-\d{3}
--severity	enum	No	high	Issue severity level	critical, high, medium, low
--rollback-type	enum	No	full	Type of rollback to perform	full, code, database, config, partial

INSTRUCTION: Execute Critical Rollback

INPUTS

• story_id: Story identifier (usually in /docs/stories/completed/ or /docs/stories/qa/)
• Issue severity and scope
• Rollback plan from story file
• Project context from /docs/project-context/

PROCESS

Phase 1: Story Location and Context

1. LOCATE story file:

   • SEARCH /docs/stories/completed/[story-id].md first
   • IF NOT FOUND: CHECK /docs/stories/qa/[story-id].md
   • IF NOT FOUND: CHECK /docs/stories/review/[story-id].md
   • IF NOT FOUND: CHECK /docs/stories/development/[story-id].md
   • IF STORY NOT FOUND:
     • EXIT with error message
     • SUGGEST checking story ID

2. READ story file and extract:

   • Rollback plan section (if documented)
   • Deployment version/tag
   • Database migrations applied
   • Configuration changes made
   • Dependencies and integrations affected
   • Technical changes summary

3. IDENTIFY deployment details:

   • GET current git tag/commit
   • GET previous stable tag/commit
   • IDENTIFY files changed
   • NOTE database migrations run
   • LIST configuration changes

4. DISPLAY context:

   📋 ROLLBACK CONTEXT
   ═══════════════════
   
   Story: [STORY-ID] - [Title]
   Current Location: /docs/stories/[directory]/
   Deployed Version: [version]
   Previous Version: [previous-version]
   Deployment Time: [timestamp]
   Time Since Deploy: [duration]
   
   Changes Made:
   - Code: [X] files changed
   - Database: [Y] migrations applied
   - Config: [Z] changes
   - Dependencies: [list]
   

Phase 2: Situation Assessment

1. PROMPT user for incident details (if not provided):

   • What is the issue?
   • How many users are affected?
   • What features are broken?
   • Is there data corruption risk?
   • What is the business impact?

2. ASSESS severity (use --severity if provided):

   • CRITICAL: Data loss, security breach, complete outage
   • HIGH: Major features broken, many users affected
   • MEDIUM: Some features degraded, limited user impact
   • LOW: Minor issues, cosmetic problems

3. DETERMINE rollback strategy:

   • FULL ROLLBACK: Revert all changes (code + database + config)
   • CODE ONLY: Revert code, keep database changes
   • DATABASE ONLY: Rollback migrations, keep code
   • CONFIG ONLY: Revert configuration changes
   • PARTIAL: Selective rollback of specific changes
   • HOTFIX: Fix forward instead of rolling back

4. GENERATE assessment report:

   🚨 ROLLBACK ASSESSMENT
   ══════════════════════
   
   Severity: [CRITICAL/HIGH/MEDIUM/LOW]
   
   IMPACT:
   - Users affected: [estimate or percentage]
   - Features broken: [list of broken features]
   - Data corruption risk: [YES/NO - details]
   - Revenue impact: [description if applicable]
   - SLA breach: [YES/NO]
   
   ROOT CAUSE:
   - [Identified or suspected issue]
   - [Contributing factors]
   
   ROLLBACK OPTIONS:
   1. ✅ Full rollback to v[previous] (RECOMMENDED)
      - Reverts all changes
      - Restores known stable state
      - Requires database rollback
      - ETA: [X] minutes
   
   2. Code-only rollback
      - Keeps database changes
      - Faster rollback
      - May cause compatibility issues
      - ETA: [Y] minutes
   
   3. Hotfix forward
      - Fix specific issue
      - No rollback needed
      - Takes longer to implement
      - ETA: [Z] minutes
   
   4. Partial rollback
      - Revert specific changes
      - Keep working features
      - Complex to execute
      - ETA: [W] minutes
   
   RECOMMENDATION: [Strategy based on severity and impact]
   

5. CONFIRM rollback decision:

   • DISPLAY assessment
   • PROMPT user to confirm strategy
   • WARN about consequences
   • REQUIRE explicit confirmation for critical operations

Phase 3: Pre-Rollback Backup

1. CREATE safety backup:

   • BACKUP current database state
   • SNAPSHOT current code state (git commit)
   • SAVE current configuration
   • ARCHIVE application logs
   • RECORD current metrics

2. DOCUMENT rollback start:

   • TIMESTAMP rollback initiation
   • LOG user who initiated
   • RECORD rollback strategy
   • NOTE current application state

3. NOTIFY stakeholders (if configured):

   • ALERT that rollback is starting
   • PROVIDE expected downtime
   • SHARE rollback progress channel

4. DISPLAY backup confirmation:

   💾 PRE-ROLLBACK BACKUP
   ══════════════════════
   
   ✅ Database backed up: [location]
   ✅ Code state saved: [commit-hash]
   ✅ Configuration saved: [location]
   ✅ Logs archived: [location]
   ✅ Metrics captured: [timestamp]
   
   Safe to proceed with rollback.
   

Phase 4: Code Rollback

1. VERIFY current branch:

   • CHECK on main branch
   • PULL latest changes
   • CONFIRM clean working directory

2. IDENTIFY rollback target:

   • GET previous stable tag: git describe --tags --abbrev=0 [current-tag]^
   • OR: USE previous commit from story history
   • VERIFY target commit exists

3. EXECUTE code rollback:

   • IF full rollback:
     • REVERT merge commit: git revert -m 1 [merge-commit]
   • IF selective rollback:
     • REVERT specific commits
   • PUSH revert to remote: git push origin main

4. REMOVE problematic release tag:

   • DELETE local tag: git tag -d [current-tag]
   • DELETE remote tag: git push origin --delete [current-tag]

5. DISPLAY code rollback status:

   ↩️ CODE ROLLBACK
   ════════════════
   
   ✅ Reverted to: v[previous-version]
   ✅ Revert commit: [commit-hash]
   ✅ Tag removed: [current-tag]
   ✅ Changes pushed to remote
   
   Files reverted: [count]
   

Phase 5: Database Rollback

1. IDENTIFY migrations to rollback:

   • GET migrations applied in story
   • LIST from most recent to oldest
   • CHECK for data loss risk

2. WARN about data loss:

   • IF migrations drop columns/tables:
     • DISPLAY data loss warning
     • REQUIRE explicit confirmation
     • SUGGEST data export if needed

3. EXECUTE database rollback:

   • IF Laravel project:
     • RUN: php artisan migrate:rollback --step=[count]
   • IF Django project:
     • RUN: python manage.py migrate [app] [previous-migration]
   • IF Rails project:
     • RUN: rails db:rollback STEP=[count]
   • IF custom migrations:
     • EXECUTE rollback scripts from story

4. VERIFY database state:

   • CHECK migration status
   • VALIDATE schema integrity
   • TEST database connectivity
   • VERIFY data integrity

5. DISPLAY database rollback status:

   🗄️ DATABASE ROLLBACK
   ═══════════════════
   
   ✅ Migrations rolled back: [count]
   ✅ Schema restored to: [previous state]
   ✅ Data integrity: Verified
   ⚠️ Data loss: [description if any]
   
   Migrations reversed:
   - [migration-1]
   - [migration-2]
   - [migration-3]
   

Phase 6: Configuration Rollback

1. IDENTIFY configuration changes:

   • ENV variables modified
   • Config files changed
   • Feature flags toggled
   • API keys rotated
   • Service endpoints updated

2. REVERT configuration:

   • RESTORE previous ENV variables
   • REVERT config files from git
   • DISABLE feature flags
   • RESTORE previous API credentials
   • RESET service endpoints

3. CLEAR application caches:

   • IF Laravel: php artisan cache:clear && php artisan config:clear
   • IF Node.js: Clear Redis/Memcached
   • IF Django: python manage.py clear_cache
   • Clear CDN caches if applicable

4. RESTART application services:

   • RESTART web servers
   • RESTART queue workers
   • RESTART cache services
   • RESTART background jobs

5. DISPLAY configuration rollback status:

   ⚙️ CONFIGURATION ROLLBACK
   ════════════════════════
   
   ✅ ENV variables: Restored
   ✅ Config files: Reverted
   ✅ Feature flags: Disabled
   ✅ Caches: Cleared
   ✅ Services: Restarted
   
   Changes reverted:
   - [config-change-1]
   - [config-change-2]
   

Phase 7: Deployment Rollback

1. DETECT deployment system:

   • CHECK for deployment scripts
   • IDENTIFY deployment platform
   • READ /docs/project-context/technical-stack.md

2. EXECUTE deployment rollback:

   • IF automated deployment:
     • RUN deployment script with previous version
     • MONITOR deployment progress
   • IF manual deployment:
     • PROVIDE rollback instructions
     • CHECKLIST rollback steps
     • WAIT for user confirmation

3. VERIFY deployment:

   • CHECK application is running
   • VERIFY correct version deployed
   • VALIDATE services started
   • CONFIRM endpoints responding

4. DISPLAY deployment status:

   🚀 DEPLOYMENT ROLLBACK
   ══════════════════════
   
   ✅ Deployed: v[previous-version]
   ✅ Application: Running
   ✅ Services: Operational
   ✅ Endpoints: Responding
   
   Deployment method: [method]
   Rollback duration: [X] minutes
   

Phase 8: Verification and Validation

1. RUN smoke tests:

   • TEST homepage loads
   • VERIFY authentication works
   • CHECK core features functional
   • VALIDATE APIs responding
   • TEST critical user paths

2. CHECK application health:

   • VERIFY health endpoints
   • CHECK error rates
   • MONITOR response times
   • VALIDATE resource usage
   • CONFIRM database connectivity

3. VERIFY issue resolved:

   • TEST specific issue that caused rollback
   • CONFIRM users can access application
   • CHECK reported errors are gone
   • VALIDATE metrics are normal

4. MONITOR stability:

   • WATCH for 10 minutes minimum
   • CHECK for new errors
   • MONITOR user activity
   • TRACK key metrics

5. DISPLAY verification results:

   ✅ ROLLBACK VERIFICATION
   ════════════════════════
   
   Smoke Tests: [X/Y] passed
   Health Checks: All operational
   Error Rates: Normal (< threshold)
   Response Times: Normal
   Resource Usage: Normal
   
   Original Issue: ✅ RESOLVED
   Application Status: ✅ STABLE
   
   Safe to restore user access.
   

Phase 9: Post-Rollback Actions

1. COMPLETE post-rollback checklist:

   📋 POST-ROLLBACK CHECKLIST
   ══════════════════════════
   
   □ Production stable and verified
   □ Users notified of restoration
   □ Monitoring shows normal metrics
   □ No data loss confirmed
   □ Incident documented
   □ Team notified
   □ Stakeholders updated
   

2. NOTIFY users (if applicable):

   • ANNOUNCE service restored
   • APOLOGIZE for disruption
   • PROVIDE incident summary
   • SHARE preventive measures

3. UPDATE monitoring:

   • RESET alerting thresholds
   • RESUME normal monitoring
   • WATCH for residual issues
   • TRACK recovery metrics

Phase 10: Incident Documentation

1. CREATE incident report:

   📊 INCIDENT REPORT
   ══════════════════
   Story: [STORY-ID] - [Title]
   Incident ID: INC-[YYYY-MM-DD]-[number]
   
   TIMELINE:
   - Deployed: [timestamp]
   - Issue detected: [timestamp]
   - Rollback started: [timestamp]
   - Rollback completed: [timestamp]
   - Service restored: [timestamp]
   - Total duration: [X] minutes
   
   WHAT HAPPENED:
   [Detailed description of the issue that occurred]
   
   IMPACT:
   - Users affected: [estimate/percentage]
   - Features broken: [list]
   - Data loss: [YES/NO - details]
   - Business impact: [description]
   - Revenue impact: [if applicable]
   - SLA impact: [if applicable]
   
   ROOT CAUSE:
   - Primary: [Technical cause]
   - Contributing factors: [list]
   - Detection: [How issue was found]
   
   RESOLUTION:
   - Action taken: [Rollback strategy used]
   - Code: Reverted to v[previous]
   - Database: [Migrations rolled back or kept]
   - Configuration: [Changes reverted]
   - Verification: [How stability confirmed]
   
   LESSONS LEARNED:
   - What worked well: [list]
   - What didn't work: [list]
   - Gaps identified: [list]
   - Preventive measures: [list]
   
   ACTION ITEMS:
   - [ ] [Preventive measure 1]
   - [ ] [Preventive measure 2]
   - [ ] [Testing improvement 1]
   - [ ] [Monitoring enhancement 1]
   - [ ] [Process update 1]
   
   FOLLOW-UP STORY:
   Create fix story: /sdd:story-new [story-id-for-fix]
   Link to incident: INC-[YYYY-MM-DD]-[number]
   

2. ADD incident to story file:

   • APPEND incident report to story
   • UPDATE lessons learned section
   • NOTE what needs fixing
   • MARK story as requiring fixes

Phase 11: Story Status Update

1. DETERMINE story destination:

   • IF issue needs code fixes: Move to /docs/stories/development/
   • IF issue needs testing: Move to /docs/stories/qa/
   • IF minor tweaks needed: Keep in /docs/stories/review/
   • IF investigation needed: Move to /docs/stories/development/

2. ENSURE target directory exists:

   • CREATE directory if missing
   • ADD .gitkeep if directory created

3. MOVE story file:

   • FROM: Current location (usually /docs/stories/completed/)
   • TO: Appropriate stage directory
   • VERIFY move successful

4. UPDATE story file:

   • CHANGE status to appropriate stage
   • ADD rollback incident to progress log
   • UPDATE lessons learned with incident findings
   • CREATE action items for fixes
   • NOTE what caused the rollback

5. COMMIT story move:

   • ADD moved file to git
   • COMMIT with message: "rollback: revert [story-id] due to [issue]"
   • PUSH to repository

Phase 12: Fix Story Creation

1. PROMPT user to create fix story:

   Do you want to create a fix story now? (y/n)
   

2. IF user confirms:

   • GENERATE new story ID
   • CREATE fix story file
   • LINK to original story and incident
   • INCLUDE incident details
   • ADD root cause analysis
   • SET high priority
   • POPULATE with fix requirements

3. DISPLAY fix story details:

   📝 FIX STORY CREATED
   ════════════════════
   
   Story ID: [FIX-STORY-ID]
   Title: Fix [Original Story] - [Issue Description]
   Priority: HIGH
   Location: /docs/stories/backlog/[fix-story-id].md
   
   Linked to:
   - Original: [STORY-ID]
   - Incident: INC-[YYYY-MM-DD]-[number]
   
   Next steps:
   1. Review incident report
   2. Investigate root cause
   3. /sdd:story-start [fix-story-id]
   4. Implement fix with additional testing
   5. /sdd:story-ship [fix-story-id] (with caution)
   

Phase 13: Final Summary

1. GENERATE rollback summary:

   ✅ ROLLBACK COMPLETE
   ════════════════════
   Story: [STORY-ID] - [Title]
   
   ROLLBACK SUMMARY:
   • Strategy: [Full/Partial/Code-only/etc.]
   • Duration: [X] minutes
   • Version: Reverted from v[current] to v[previous]
   • Impact: [Users affected during rollback]
   
   ACTIONS TAKEN:
   ✅ Code reverted to v[previous]
   ✅ Database rolled back ([X] migrations)
   ✅ Configuration restored
   ✅ Application redeployed
   ✅ Smoke tests passed
   ✅ Production stable
   
   CURRENT STATE:
   • Application: ✅ Running v[previous]
   • Health: ✅ All systems operational
   • Users: ✅ Full access restored
   • Monitoring: ✅ Normal metrics
   • Story: Moved to /docs/stories/[directory]/
   
   INCIDENT REPORT:
   Created: INC-[YYYY-MM-DD]-[number]
   Location: [story-file-path]
   
   FIX STORY:
   Created: [FIX-STORY-ID] (if created)
   Priority: HIGH
   Location: /docs/stories/backlog/[fix-story-id].md
   
   NEXT STEPS:
   1. Continue monitoring for 24 hours
   2. Review incident report with team
   3. Implement action items
   4. Start work on fix story: /sdd:story-start [fix-story-id]
   5. Add additional testing to prevent recurrence
   6. Update rollback procedures if needed
   
   POST-MORTEM:
   Schedule incident review meeting within 48 hours
   to discuss root cause and preventive measures.
   

OUTPUTS

• Reverted git commits on main branch
• Deleted problematic release tag
• Rolled back database migrations (if applicable)
• Restored configuration files
• Moved story file to appropriate stage
• Incident report in story file
• Fix story (if created)
• Clean, stable production environment

RULES

• MUST locate story file before proceeding
• MUST assess severity and impact
• MUST create pre-rollback backup
• MUST confirm rollback strategy with user
• MUST revert code changes
• MUST rollback database if needed (with data loss warning)
• MUST restore configuration
• MUST verify application stability after rollback
• MUST complete post-rollback checklist
• MUST document incident comprehensively
• MUST update story status and location
• SHOULD create fix story for follow-up
• NEVER execute without confirmation for critical operations
• ALWAYS verify rollback success
• MUST notify stakeholders when configured

Examples

Example 1: Critical Full Rollback

INPUT:
/sdd:story-rollback STORY-2025-003 --severity=critical

PROCESS:
→ Locating story STORY-2025-003...
→ Found in /docs/stories/completed/STORY-2025-003.md
→ Loading rollback plan...

What issue are you experiencing?
> Payment processing completely broken, users cannot checkout

How many users are affected?
> All users attempting to purchase (estimated 100+ in last 10 mins)

→ Assessing situation...

OUTPUT:
🚨 ROLLBACK ASSESSMENT
══════════════════════

Severity: CRITICAL

IMPACT:
- Users affected: All users (100+ in 10 minutes)
- Features broken: Payment processing, checkout flow
- Data corruption risk: NO
- Revenue impact: Blocking all sales
- SLA breach: YES

ROOT CAUSE:
- Payment gateway integration broken
- API credential mismatch suspected

ROLLBACK OPTIONS:
1. ✅ Full rollback to v1.2.0 (RECOMMENDED)
   - Reverts all payment changes
   - Restores working checkout
   - Requires 2 migration rollbacks
   - ETA: 5 minutes

RECOMMENDATION: Full rollback (critical revenue impact)

Proceed with full rollback? (yes/no)
> yes

→ Creating pre-rollback backup...
💾 PRE-ROLLBACK BACKUP
✅ Database backed up
✅ Code state saved
✅ Configuration saved
✅ Logs archived

→ Executing code rollback...
↩️ CODE ROLLBACK
✅ Reverted to: v1.2.0
✅ Revert commit: def789
✅ Tag removed: v1.3.0

→ Executing database rollback...
🗄️ DATABASE ROLLBACK
✅ Migrations rolled back: 2
✅ Schema restored

→ Restoring configuration...
⚙️ CONFIGURATION ROLLBACK
✅ ENV variables restored
✅ Caches cleared
✅ Services restarted

→ Deploying previous version...
🚀 DEPLOYMENT ROLLBACK
✅ Deployed: v1.2.0
✅ Application: Running

→ Verifying rollback...
✅ ROLLBACK VERIFICATION
Smoke Tests: 12/12 passed
Original Issue: ✅ RESOLVED
Application Status: ✅ STABLE

→ Creating incident report...
→ Moving story to /docs/stories/development/

✅ ROLLBACK COMPLETE
════════════════════
Story: STORY-2025-003 - Payment Integration

ROLLBACK SUMMARY:
• Strategy: Full rollback
• Duration: 6 minutes
• Version: Reverted from v1.3.0 to v1.2.0
• Impact: Brief interruption during rollback

ACTIONS TAKEN:
✅ Code reverted to v1.2.0
✅ Database rolled back (2 migrations)
✅ Configuration restored
✅ Payment service restored

CURRENT STATE:
• Application: ✅ Running v1.2.0
• Checkout: ✅ Working normally
• Users: ✅ Can complete purchases
• Story: Moved to /docs/stories/development/

INCIDENT REPORT:
Created: INC-2025-03-16-001
Location: /docs/stories/development/STORY-2025-003.md

NEXT STEPS:
1. Monitor payment processing
2. Investigate API credential issue
3. Add payment integration tests
4. Implement with better validation
5. /sdd:story-start STORY-2025-003 when ready

Example 2: Code-Only Rollback

INPUT:
/sdd:story-rollback STORY-2025-004 --rollback-type=code

PROCESS:
→ Locating story...
→ Found in /docs/stories/completed/STORY-2025-004.md

What issue are you experiencing?
> UI rendering broken on mobile devices

→ Assessing situation...
→ Severity: HIGH
→ Rollback type: Code only (database changes OK)

→ Executing code rollback...
→ Keeping database migrations
→ Reverting frontend changes...

OUTPUT:
✅ ROLLBACK COMPLETE
════════════════════
Story: STORY-2025-004 - Mobile UI Update

ROLLBACK SUMMARY:
• Strategy: Code-only rollback
• Duration: 3 minutes
• Database: No changes (migrations kept)

ACTIONS TAKEN:
✅ Code reverted
✅ Frontend assets rebuilt
✅ Application redeployed
✅ Mobile UI: Restored to previous version

Database migrations were not rolled back
as they are compatible with previous code.

Example 3: Story Not Found

INPUT:
/sdd:story-rollback STORY-2025-999

PROCESS:
→ Searching for STORY-2025-999...
→ Not found in /docs/stories/completed/
→ Not found in /docs/stories/qa/
→ Not found in /docs/stories/review/
→ Not found in /docs/stories/development/

OUTPUT:
❌ STORY NOT FOUND
══════════════════

Story ID: STORY-2025-999

The story file was not found in any directory:
- /docs/stories/completed/
- /docs/stories/qa/
- /docs/stories/review/
- /docs/stories/development/
- /docs/stories/backlog/

Please verify the story ID and try again.

To see all stories: /sdd:project-status

Edge Cases

Database Data Loss Risk

• DETECT migrations that drop columns/tables
• CALCULATE potential data loss
• WARN user with specific details
• REQUIRE explicit confirmation
• OFFER to export data before rollback
• LOG data loss for incident report

Partial Rollback Complexity

• IDENTIFY dependencies between changes
• ASSESS compatibility of partial rollback
• WARN about potential issues
• SUGGEST full rollback if too complex
• PROVIDE option to proceed with caution

No Rollback Plan Documented

• WARN that rollback plan missing
• USE default rollback strategy
• GENERATE rollback steps from git history
• PROCEED with extra caution
• SUGGEST documenting rollback plans for future

Rollback Verification Failure

• DETECT continued issues after rollback
• ASSESS if rollback successful but different issue
• OFFER to rollback further (older version)
• SUGGEST investigating root cause
• PROVIDE emergency contact information

Multiple Stories Since Deployment

• DETECT other stories deployed after target
• WARN about reverting multiple changes
• LIST all stories that will be affected
• REQUIRE explicit confirmation
• SUGGEST selective rollback instead

Error Handling

• Story ID missing: Return "Error: Story ID required. Usage: /sdd:story-rollback <story_id>"
• Invalid story ID format: Return "Error: Invalid story ID format. Expected: STORY-YYYY-NNN"
• Story not found: Search all directories and report not found
• Rollback failure: Capture error, provide manual rollback steps, alert for help
• Database rollback error: Stop rollback, restore from backup, seek manual intervention
• Deployment failure: Attempt re-deployment, provide manual steps, escalate if needed
• Verification failure: Alert that issue persists, suggest further rollback or investigation

Performance Considerations

• Execute rollback steps in parallel when safe
• Stream rollback output in real-time
• Monitor application health continuously during rollback
• Generate incident report asynchronously after rollback

Related Commands

• /sdd:story-ship - Ship story (the opposite of rollback)
• /sdd:story-qa - Return story to QA for fixes
• /sdd:story-new - Create fix story for addressing issues
• /sdd:project-status - View all project stories

Constraints

• ✅ MUST locate story file before proceeding
• ✅ MUST assess severity and impact
• ✅ MUST create pre-rollback backup
• ✅ MUST confirm rollback strategy
• 🔄 MUST revert code changes
• 🗄️ MUST rollback database with caution
• ⚙️ MUST restore configuration
• ✔️ MUST verify application stability
• 📋 MUST complete post-rollback checklist
• 📊 MUST document incident
• 📝 SHOULD create fix story
• 🚫 NEVER execute without confirmation for critical operations
• ⚠️ ALWAYS warn about data loss
• 📣 MUST notify stakeholders