Ccc Rollback

/ccc-rollback — Revert + Redeploy

CC Commander · /ccc-rollback · Pick target → revert commits → deploy → verify

Use this when production is bad and the safest path is an atomic revert commit followed by a fresh deploy. This workflow preserves history and always redeploys through /ccc-deploy.

Response Shape

Always return these sections:

1. Brand header:

**CC Commander** · /ccc-rollback · Revert + redeploy

2. Current state strip:

Use Bash reads, silent on missing refs:

git rev-parse --abbrev-ref HEAD
git rev-parse --short HEAD
git status --short
git tag --sort=-creatordate | head -10
git log --oneline --decorate -12

Render:

Branch: `<branch>` · HEAD: `<short-sha>` · dirty files: `<N>` · latest tag: `<tag-or-none>`

If dirty files are present, warn before any rollback command. Do not proceed until the user confirms.

3. Rollback target picker — AskUserQuestion

question: "What should I roll back to?"
header: "CC Commander Rollback"
multiSelect: false
autocomplete: true
options:
  - label: "Last good commit"
    value: "last-good"
    description: "You provide or confirm the last known good commit sha."
    preview: "Creates revert commits for everything after that commit, then deploys."
  - label: "Specific tag"
    value: "tag"
    description: "Pick a release tag such as v4.0.0-beta.10."
    preview: "Reverts commits after the tag, pushes, then runs /ccc-deploy."
  - label: "N versions back"
    value: "n-back"
    description: "Choose how many release tags back to restore."
    preview: "Finds the older tag, warns about distance, reverts, then deploys."

Target Resolution

Last Good Commit

Ask for the commit sha if it was not supplied in the prompt. Validate it:

git cat-file -e <target-sha>^{commit}
git merge-base --is-ancestor <target-sha> HEAD
git rev-list --count <target-sha>..HEAD

If HEAD is more than 5 commits ahead of the target, warn:

Warning: HEAD is <N> commits ahead of <target>. This may need a surgical rollback instead of reverting everything after the target.

Ask the user to confirm before continuing.

Specific Tag

Show recent tags from:

git tag --sort=-creatordate | head -20

Ask for or autocomplete the tag. Validate it:

git rev-parse <tag>^{commit}
git merge-base --is-ancestor <tag> HEAD
git rev-list --count <tag>..HEAD

Apply the same more-than-5-commits warning before continuing.

N Versions Back

Ask for N, list tags in descending creation order, and resolve the target tag:

git tag --sort=-creatordate | head -50

Example: if N=1, target the previous tag before the current release tag. If N=2, target two release tags back.

Validate the resolved tag and apply the same more-than-5-commits warning.

Revert Procedure

Never rewrite public history. Create explicit revert commits.

For a single bad commit:

git revert <bad-sha>

For a range after the selected target:

git revert --no-commit <target>..HEAD
git commit -m "fix(rollback): revert to <target-label>"

If conflicts occur:

1. Stop immediately.
2. Show conflicted files from git status --short.
3. Explain that manual conflict resolution is required before continuing.
4. Do not attempt a deploy until the revert commit exists and tests or smoke checks pass.

After the revert commit:

git log --oneline -3
git status --short

If the working tree is not clean after committing, stop and report the remaining files.

Push + Redeploy

Before pushing, summarize:

Rollback target: <target-label>
Commits reverted: <N>
New revert commit: <sha>
Deploy command: /ccc-deploy

Ask for confirmation, then push:

git push origin <branch>

Immediately invoke /ccc-deploy with the platform context if it is known from the current repo. If the platform is unknown, run /ccc-deploy normally so it can detect and ask.

Verification

Use /ccc-deploy health verification as the source of truth. If a production URL is known, fetch it with WebFetch after deploy and report:

• URL checked
• HTTP status or platform status
• deploy id, run id, release id, or commit sha
• PASS, WARN, or FAIL

Post-Rollback Comms

After health verification, emit:

Rollback complete: <project>
- Restored target: <target-label>
- Revert commit: <sha>
- Deployment: <platform-and-url>
- Health check: <PASS-or-FAIL>
- Follow-up: investigate original bad deploy and add a regression test.

If Discord or Slack is configured through /ccc-connect, ask before posting the comms. Include incident context only if the user provided it.

Failure Mode

If rollback fails:

1. Surface the exact command and relevant error lines.
2. State whether failure happened during target resolution, revert, push, deploy, or health verification.
3. Preserve any partial revert state and tell the user the next safe command to inspect it, usually git status --short.
4. If a revert commit was pushed but deploy failed, suggest running /ccc-deploy again or escalating to the platform rollback command.

Anti-Patterns

• Do not rewrite history.
• Do not deploy with unresolved conflicts.
• Do not push without confirmation.
• Do not skip /ccc-deploy; rollback is only complete after redeploy and health verification.
• Do not post comms without user confirmation.

⚙️ Fable contract: plan before build · verifier ≠ worker · prove before alarm · loops need gates · leave durable state — rules/fable-method.md