---
name: irreversible-ops
description: Human-review gate for irreversible operations — deploys, database migrations, published artifact pushes, force pushes, and destructive deletes. Use in any workflow that touches infra, DB schema, or published artifacts. Classifies reversibility, injects a mandatory verification step, and blocks autonomous progression past the gate.
user-invocable: false
model-invocable: true
side-effects: file-writes
permission-profile: trusted
triggers:
  - build
  - repair
  - "*"
---

# Irreversible Ops

## Iron Law

```
BEFORE AN IRREVERSIBLE OP: STOP, CLASSIFY, GATE.
NO AUTONOMOUS AGENT CROSSES AN IRREVERSIBLE BOUNDARY WITHOUT AN EXPLICIT HUMAN GATE.
```

An operation is irreversible if rolling it back requires more than running one command. If you are not certain, treat it as irreversible.

## Recognize Your Own Rationalizations

- "It's a dev environment — I can always recreate it." → Development data and schemas that are not in source control are irreversible. Assume production semantics until proven otherwise.
- "The migration is small and I've done this before." → Size and familiarity do not reduce irreversibility. The gate is about the op class, not the op size.
- "Autonomous mode is enabled, so I can proceed." → Autonomous mode governs pace and interaction style. It does not remove irreversibility gates.
- "I'll add a rollback plan after." → Rollback plan comes first, before the gate can be passed.

## Irreversible Op Classification

### Class A — Always requires human gate

| Operation | Why irreversible |
|-----------|-----------------|
| Database migration (schema change) | Column drops, type changes, constraint adds — data loss risk |
| Published package version bump | npm/PyPI/GitHub Releases — cannot be un-published cleanly |
| Force push to protected branch | Rewrites shared history |
| Production deploy | Live traffic impact; rollback window may close |
| Secret/credential rotation | Old credentials may already be in use |
| Mass delete (files, records, buckets) | Data loss if incorrect |
| External service configuration change | May affect other consumers |

### Class B — Requires gate in autonomous mode, can proceed in assisted/manual

| Operation | Condition |
|-----------|-----------|
| Database migration (data backfill) | If revert is a compensating migration |
| Git tag creation | If CI/CD triggers on tags |
| API endpoint removal | If consumers may exist |
| Config change affecting behaviour | If not behind a feature flag |

### Class C — No gate required

- Adding new columns (no existing data affected)
- Creating new tables
- Adding new endpoints
- Adding new feature flags (not yet enabled)
- Writing tests
- Modifying local dev config

## Gate Protocol

Before any Class A or Class B op, produce in writing:

```
Op class:        <A | B>
Operation:       <exact description of what will happen>
Affected scope:  <which data, which services, which users>
Reversibility:   <how to undo this if it goes wrong — be specific>
Rollback plan:   <exact command(s) to roll back>
Verification:    <how will you know it succeeded?>
Gate:            BLOCKED — requires human confirmation before proceeding
```

Do NOT proceed until the human confirms. "Confirmed" means explicit approval of the exact operation described above, not a general "go ahead."

## Post-Gate Checklist

After the human gate passes:
- [ ] Backup taken (or confirmed unnecessary with reason)
- [ ] Rollback plan is still valid
- [ ] Monitoring/alerting is in place
- [ ] Operation executed exactly as described in the gate record
- [ ] Verification result recorded

If the actual operation deviates from the gate description, stop and re-gate.

## Completion Criteria

- [ ] Every irreversible op in the workflow has been classified
- [ ] All Class A ops have a gate record + human confirmation
- [ ] All Class B ops in autonomous mode have a gate record + human confirmation
- [ ] Post-gate checklist complete for each executed op
