Start here
What can be reversed
gmonk's pitch is "an undo button for AI agents". This is the honest scope of that button — what is reversible, how, and where the edges are, so there are no surprises in production.
The rule everywhere: fail toward flagged. Anything gmonk
can't reverse with certainty is recorded and surfaced for a human — never
silently undone, never silently dropped.
Reversibility by effect
| Effect | Reversible? | How | Edges |
|---|---|---|---|
| File create / modify / delete | Yes | Restore, recreate or delete from a captured content snapshot | A rename is captured as delete + create and reverses fine; there is no dedicated move-back |
| SQL row insert / update / delete single table with a primary key | Yes | Before-image restore, or a concurrency-preserving inverse operation | Additive, multiplicative, jsonb-merge and array-append undo preserve concurrent writes; absolute assignments are state-based and drift-aware |
| SQL multi-statement / CTE / cascade / join / range update | Yes — but only with a trigger | A capture trigger (or WAL) records the actual row changes by observation | Not captured by the wire proxy. The proxy finds the affected rows by parsing the statement, and parsing can't prove the row set for a join or a CTE — so on a table with no trigger these are flag-only, whichever channel they arrive through. |
| SQL on a table with no primary key | No | — | There is no way to target a row to reverse it → flag-only, and refused under guarantee |
DDL — DROP, TRUNCATE, ALTER | No | — | No row before-image exists; blocked by the default guardrail and refused under guarantee |
| Object storage (S3) put / delete | Yes | Restore the prior version on a versioned bucket, or re-PUT a byte snapshot | Capture-then-conditional-write: a failed capture aborts the write |
| External effect — charge, email, SaaS resource | Only if declared | A compensating call you define | Needs both a registered compensation and an executor; otherwise flag-only |
Opaque — Bash, unknown tools | No | — | Not generically reversible → recorded and flagged for a human |
Databases
| Engine | Reversal | Guarantee (prove-then-commit) | Notes |
|---|---|---|---|
| PostgreSQL | Full | Full | The primary, best-supported path |
| MySQL | Yes | Advise-fallback | Rollback plumbing is Postgres-only for now; multi-row and non-auto-increment INSERT are flag-only; blast-radius minRows is Postgres-only |
| MongoDB / SQLite / SQL Server | Not built | — | Not supported |
What gmonk sees
- On a protected table, gmonk captures every write — even one that bypasses the gateway — and can reverse it. See enforcement & anti-bypass.
- On an unprotected table, gmonk only sees writes that flow through its proxy or gateway. A direct write is neither captured nor reversible. Protect the tables that matter.
Stated up front, not discovered later
The reversibility oracle scores every action before it runs — automatic, assisted, manual or impossible. The guarantee gate can refuse to commit anything it can't prove reversible. The recoverability monitor re-checks over time and alerts when an action's undo decays. So the scope above isn't just documented: gmonk tells you, per action, which bucket you're in.
Known limits
- Multi-statement and complex SQL is reversible via trigger protection, but flag-only via the parser-only path.
- MySQL guarantee is an advise-fallback.
- Dependency-graph edges cover SQL foreign-key values and file same-paths, not tool-result→arg or object-key links — so causal excise is exact for database and file changes, conservative elsewhere.
- No live end-to-end tests against real S3/MinIO or real Slack (unit and integration tested).