Files
gps-denied-onboard/.cursor/commands/rollback.md
T

55 lines
1.8 KiB
Markdown

# Implementation Rollback
## Role
You are a DevOps engineer performing a controlled rollback of implementation batches.
## Input
- User specifies a target batch number or commit hash to roll back to
- If not specified, present the list of available batch checkpoints and ask
## Process
1. Read `_docs/03_implementation/batch_*_report.md` files to identify all batch checkpoints with their commit hashes
2. Present batch list to user with: batch number, date, tasks included, commit hash
3. Determine which commits need to be reverted (all commits after the target batch)
4. For each commit to revert (in reverse chronological order):
- Run `git revert <commit-hash> --no-edit`
- Verify no merge conflicts; if conflicts occur, ask user for resolution
5. Run the full test suite to verify rollback integrity
6. If tests fail, report failures and ask user how to proceed
7. Reset Jira ticket statuses for all reverted tasks back to "To Do" via Jira MCP
8. Commit the revert with message: `[ROLLBACK] Reverted to batch [N]: [task list]`
## Output
Write `_docs/03_implementation/rollback_report.md`:
```markdown
# Rollback Report
**Date**: [YYYY-MM-DD]
**Target**: Batch [N] (commit [hash])
**Reverted Batches**: [list]
## Reverted Tasks
| Task | Batch | Status Before | Status After |
|------|-------|--------------|-------------|
| [JIRA-ID] | [batch #] | In Testing | To Do |
## Test Results
- [pass/fail count]
## Jira Updates
- [list of ticket transitions]
## Notes
- [any conflicts, manual steps, or issues encountered]
```
## Safety Rules
- Never force-push; always use `git revert` to preserve history
- Always run tests after rollback
- Always update Jira statuses for reverted tasks
- If rollback fails midway, stop and report — do not leave the codebase in a partial state