@synapsor/runner 1.1.1 → 1.4.0

package/docs/limitations.md

@@ -1,7 +1,9 @@
 # Limitations
 
-Synapsor Runner is intentionally narrow. Version 1.1 adds a bounded small-fleet
-shape; it does not claim Synapsor Cloud scale or an enterprise SLA.
+Synapsor Runner is intentionally narrow. Version 1.4 adds opt-in reviewed
+compensation on top of guarded bounded-set writeback, single-row CRUD, and
+explicit receipt authority; it does not claim Synapsor Cloud scale or an
+enterprise SLA.
 
 ## Supported
 
@@ -20,8 +22,20 @@ shape; it does not claim Synapsor Cloud scale or an enterprise SLA.
   - `synapsor.change-set.v1`
   - `synapsor.writeback-job.v1`
   - `synapsor.execution-receipt.v1`
+  - backward-compatible operation-aware v2 change sets, jobs, and receipts
+  - bounded-set v3 change sets, jobs, and receipts
+  - compensation change sets and protocol-v4 jobs/receipts with bounded inverse
+    descriptors
   - `synapsor.runner-registration.v1`
-- Guarded single-row `UPDATE` for Postgres and MySQL.
+- Guarded single-row `INSERT`, `UPDATE`, and `DELETE` for Postgres and MySQL.
+- Fixed-predicate set `UPDATE`/`DELETE` and exact-review batch `INSERT` with
+  mandatory row/value caps, a hard 100-row ceiling, human approval, frozen
+  members, atomic apply, and exact receipts.
+- Opt-in reviewed compensation for direct SQL UPDATE, INSERT, soft-delete, and
+  exact frozen sets. Revert is a new operator proposal with independent
+  approval and a fresh conflict guard.
+- Atomic source receipts with precreated or auto-migrated tables, or
+  zero-source-schema Runner-ledger receipts with explicit reconciliation.
 - App/API handler writeback through approved `http_handler` executors.
 - Local script writeback through approved `command_handler` executors.
 - Primary-key guard.
@@ -49,17 +63,19 @@ truth for the model-facing tools.
 - Arbitrary SQL.
 - Model-generated SQL.
 - DDL.
-- INSERT.
-- DELETE.
 - UPSERT.
-- Multi-row UPDATE.
+- Model-generated/free-form set predicates or dynamic identifiers.
+- Unbounded set writes or more than 100 reviewed members.
+- Policy auto-approval for bounded sets.
 - Stored procedures.
 - Cross-database transactions.
 - Physical branching of Postgres/MySQL.
 - Full Synapsor workflow/DAG execution.
 - `CREATE AGENT WORKFLOW` or hosted Synapsor SQL generation.
 - Auto-merge or settlement policy semantics.
-- Automatic rollback of external database writes.
+- Automatic rollback, database time travel, or model-facing revert.
+- Inferred compensation for app-owned handlers or external effects.
+- General restoration of hard-deleted rows, cascades, or trigger side effects.
 - Model-callable approval or commit tools.
 - Generic MCP firewall behavior.
 - Prompt-injection prevention.
@@ -92,8 +108,9 @@ not a hosted central evidence service, organization RBAC/SSO, compliance
 retention system, or unbounded search engine. Each bridge operation serializes
 through an advisory lock and fails above configured `max_entries`.
 
-Only homogeneous 1.1 fleet operation is currently verified. Mixed 1.0/1.1
-rolling operation is not claimed. See [Running A Small Runner
+Only homogeneous 1.4 fleet operation is claimed for protocol-v4 compensation
+jobs. Mixed-minor v3/v4 rolling compensation is not claimed.
+See [Running A Small Runner
 Fleet](running-a-runner-fleet.md).
 
 Use this wording:
@@ -108,3 +125,7 @@ Do not describe external approval as merge.
 ## Weak Conflict Guards
 
 A version/timestamp column is the preferred conflict guard. A weak row-hash guard can be acknowledged for local/dev use, but it should not be presented as equivalent to a durable version column.
+
+Runner-ledger UPDATE and DELETE require an exact guard; UPDATE must advance it
+inside the source transaction. INSERT requires a reviewed source-unique dedup
+identity. See [Guarded Single-Row CRUD Writeback](guarded-crud-writeback.md).

package/docs/oss-vs-cloud.md

@@ -21,7 +21,7 @@ and investigation surfaces for enabled design-partner deployments.
 | Capabilities | Local semantic MCP tools | Registry, version history, and capability inspection |
 | Evidence and replay | Local SQLite ledger by default; optional shared Postgres runtime store | Shared activity and evidence surfaces where enabled |
 | Approval | Local CLI or localhost UI | Team approval surfaces where enabled |
-| Writeback | Guarded one-row update or app-owned executor | Cloud-linked jobs with local execution; managed production orchestration is future work |
+| Writeback | Guarded one-row CRUD, fixed/frozen bounded sets, or app-owned executor | Cloud-linked jobs with local execution; managed production orchestration is future work |
 | MCP risk audit | Static local audit | Organization-wide continuous audit is future work |
 | Identity | Local operator boundary | Workspace RBAC where configured; SAML and SCIM are future work |
 | Operations | Customer-operated single node or bounded small fleet | Managed fleet remains Cloud work; no enterprise SLA in the current beta |

package/docs/production.md

@@ -10,7 +10,7 @@ MCP agent
 -> scoped Postgres/MySQL read
 -> evidence/query audit/proposal
 -> approval outside MCP
--> guarded one-row update or app-owned executor
+-> guarded one-row CRUD, bounded frozen set, or app-owned executor
 -> receipt/replay
 ```
 
@@ -58,7 +58,14 @@ Production-candidate OSS scope:
 - asymmetric RS256/ES256 session authentication, readiness probes, separately
   protected metrics, source pools, and fleet-wide rate limits;
 - distinct-reviewer approval quorum from the canonical contract;
-- direct guarded single-row `UPDATE` for simple approved edits;
+- direct guarded single-row `INSERT`, `UPDATE`, and `DELETE` for approved
+  operations whose source constraints satisfy the operation-specific guards;
+- fixed-predicate set `UPDATE`/`DELETE` and exact-review batch `INSERT`, with
+  human approval, mandatory row/value caps, a hard 100-row ceiling, frozen
+  members, atomic execution, and exact per-member receipts;
+- opt-in reviewed compensation for direct SQL UPDATE, INSERT, soft-delete, and
+  exact frozen sets, using a separate operator proposal, fresh guards, and
+  protocol-v4 receipts;
 - app-owned `http_handler` or `command_handler` executors for richer approved
   business transactions;
 - stdio MCP and Streamable HTTP MCP.
@@ -66,8 +73,12 @@ Production-candidate OSS scope:
 Out of scope:
 
 - raw `execute_sql` or model-generated SQL;
-- generic direct `INSERT`, `DELETE`, `UPSERT`, DDL, or multi-row SQL writeback;
+- direct `UPSERT`, DDL, model-generated predicates, unbounded set writes,
+  cross-table transactions, or INSERT/DELETE whose source constraints cannot
+  prove the reviewed effect;
 - physical branching of external Postgres/MySQL;
+- automatic rollback/time travel, hard-delete restoration, and inferred
+  compensation for app-owned or external effects;
 - workflow DAGs, auto-merge/settlement, hosted team administration, SSO/SCIM,
   multi-region ledger replication, or compliance retention;
 - making prompt injection impossible.
@@ -85,11 +96,12 @@ Read credential:
 
 Write credential for direct `sql_update`:
 
-- can update only the allowed business columns;
+- can use only the operation-specific business DML and reviewed columns;
 - cannot modify primary-key or tenant columns;
-- can `SELECT`/`INSERT`/`UPDATE` the administrator-created
-  `synapsor_writeback_receipts` table;
-- does not need schema `CREATE` during doctor or apply;
+- has source receipt-table `SELECT`/`INSERT`/`UPDATE` only when receipt
+  authority is `source_db`;
+- needs schema `CREATE` only for explicitly selected `auto_migrate` receipt
+  provisioning;
 - is never exposed to MCP clients.
 
 Example config:
@@ -110,10 +122,17 @@ Example config:
 `write_url_env`. `SYNAPSOR_DATABASE_URL` is only a legacy fallback for direct
 worker flows that do not pass a local config.
 
-## Receipt Table
+Set `statement_timeout_ms` on each production source. PostgreSQL direct
+writeback uses it for transaction-local statement and lock limits. MySQL uses
+it for preflight execution and InnoDB lock waits; because MySQL does not apply
+`max_execution_time` to general DML, keep bounded sets small and enforce
+source-side operational query limits too.
 
-Direct SQL writeback stores idempotency receipts in the source database. Runner
-expects an administrator to create this table before steady-state operation:
+## Receipt Authority
+
+Direct SQL writeback supports atomic `source_db` receipts and
+zero-source-schema `runner_ledger` receipts. For source receipts, choose an
+administrator-precreated table or explicit idempotent auto-migration:
 
 ```sql
 CREATE TABLE IF NOT EXISTS synapsor_writeback_receipts (...);
@@ -129,26 +148,36 @@ synapsor-runner doctor --config synapsor.runner.json --check-writeback
 
 For MySQL, replace `postgres` with `mysql`.
 
-Grant only receipt-table `SELECT`/`INSERT`/`UPDATE` and schema usage to the
-writer; schema `CREATE` is not required by doctor or apply. Use an app-owned
-executor when receipt storage belongs inside your application boundary.
+Grant only receipt-table `SELECT`/`INSERT`/`UPDATE` and schema usage in
+`precreated` mode. `auto_migrate` additionally needs bounded `CREATE`.
+`runner_ledger` needs neither source receipt-table grants nor `CREATE`, but an
+ambiguous crash after source commit requires operator reconciliation and is not
+distributed exactly-once. See
+[Guarded Single-Row CRUD Writeback](guarded-crud-writeback.md) for the complete
+mode, operation, and privilege matrix.
 
 ## Direct Writeback Vs App-Owned Executor
 
-Use direct `sql_update` when the approved change is:
+Use direct writeback when the approved change is either:
 
 ```text
-one existing row -> one allowed-column patch -> one guarded UPDATE
+one reviewed row -> one guarded INSERT/UPDATE/DELETE -> one exact effect
+
+or
+
+one fixed reviewed rule/item list -> <= 100 frozen rows -> one atomic bounded set
 ```
 
 Use an app-owned executor when the change is richer:
 
-- insert a credit/refund/review row;
-- update more than one row;
+- choose rows from a model-supplied predicate or exceed the reviewed cap;
 - touch more than one table;
 - emit an event or call another internal service;
 - enforce business logic that belongs in your app.
 
+Bounded sets must satisfy every invariant in [Bounded Set
+Writeback](bounded-set-writeback.md); otherwise they remain executor work.
+
 Handlers must re-check tenant/scope, expected version, idempotency, allowed
 business action, transaction boundaries, and safe errors. See
 [Writeback Executors](writeback-executors.md) and
@@ -336,9 +365,12 @@ synapsor-runner apply --all-approved --yes \
 ```
 
 Each proposal is independent: a stale-row conflict does not abort later jobs.
-The final summary reports applied, conflict, and skipped IDs. Re-running is
-idempotent through durable receipts. Do not schedule batch apply for a policy
-that has no reviewed aggregate limits.
+In `runtime_store` mode, the batch holds one authoritative bridge while every
+selected item applies, then syncs the resulting states, receipts, and events
+back together. The final summary reports applied, conflict, and skipped IDs;
+every skipped item includes a safe reason. Re-running is idempotent through
+durable receipts. Do not schedule batch apply for a policy that has no reviewed
+aggregate limits.
 
 Runner writes newline-delimited JSON events to stderr for model-facing tool
 rejections, operator decisions, and terminal writeback outcomes. These events

package/docs/release-notes.md

@@ -10,7 +10,87 @@ npx -y -p @synapsor/runner synapsor-runner demo --quick
 The OSS runner command is `synapsor-runner`. The `synapsor` command is reserved
 for the Synapsor Cloud CLI.
 
-## 1.1.0 (prepared, not published)
+## 1.4.0 (prepared, not published)
+
+### Reviewed Reversible Change Sets
+
+- Adds canonical and DSL opt-in reversibility for direct SQL operations with
+  human/operator approval and exact version/dedup guards.
+- Records only bounded, allowlisted inverse data after an unambiguous apply.
+- Adds operator-only `revert`, which creates a new independently reviewed
+  proposal and never writes, approves, or becomes model-facing.
+- Proves UPDATE, INSERT, soft-delete, and exact bounded-set compensation on
+  PostgreSQL and MySQL, including stale-state refusal, atomic set rollback,
+  crash reconciliation, inverse redaction, receipts, and replay.
+- Keeps hard DELETE restoration, app-owned handlers, payments, messages, and
+  other external effects outside Runner's automatic compensation claim.
+
+Prepared package versions: `@synapsor/spec@1.4.0`,
+`@synapsor/dsl@1.4.0`, and `@synapsor/runner@1.4.0`.
+
+## 1.3.0 (prepared, not published)
+
+### Bounded Set Writeback
+
+- Adds fixed-predicate set UPDATE/DELETE and exact-review batch INSERT for
+  PostgreSQL and MySQL, capped at 100 rows.
+- Requires mandatory row and aggregate-value bounds, a frozen exact target set,
+  integer version guards for set UPDATE, human/operator approval, atomic apply,
+  and per-member receipt/replay evidence.
+- Rejects cap overflow instead of truncating, rolls back the full transaction
+  on any stale or failing member, and refuses hard set DELETE when hidden
+  triggers or widening cascades are present.
+- Keeps model-generated predicates, policy auto-approval for sets, unbounded
+  batches, UPSERT, cross-table transactions, and external effects on the
+  app-owned executor path.
+- Adds `corepack pnpm test:bounded-set`, which runs the safety matrix and local
+  1/10/100-row measurements against disposable PostgreSQL and MySQL.
+
+Prepared package versions: `@synapsor/spec@1.3.0`,
+`@synapsor/dsl@1.3.0`, and `@synapsor/runner@1.3.0`.
+
+## 1.2.0 (prepared, not published)
+
+### Guarded CRUD And Receipt Authority
+
+- Adds canonical and DSL operation semantics for guarded single-row INSERT,
+  UPDATE, and DELETE while preserving legacy UPDATE contracts.
+- Adds atomic source receipts with precreated or auto-migrated tables and an
+  opt-in Runner-ledger mode that creates no source receipt table.
+- Adds durable writeback intents and a fail-closed operator reconciliation
+  workflow for ambiguous ledger/source crash windows.
+- Extends onboarding, doctor, preview, schema inspection, protocol v2,
+  Postgres/MySQL adapters, the support-plan-credit example, and disposable live
+  conformance tests.
+- Keeps multi-row writes, UPSERT, DDL, cross-table work, and external effects
+  on the app-owned executor path.
+
+Prepared package versions: `@synapsor/spec@1.2.0`,
+`@synapsor/dsl@1.2.0`, and `@synapsor/runner@1.2.0`.
+
+## 1.1.2 (prepared, not published)
+
+### Retry And Shared Batch Correctness
+
+- Makes transient source pool and recognized database saturation errors
+  consistently retryable with a bounded retry hint and safe normalized logs.
+- Fixes `apply --all-approved` in shared `runtime_store` mode so every selected
+  proposal uses the same authoritative bridge and durable outcome ledger.
+
+Prepared package version: `@synapsor/runner@1.1.2`. Canonical Spec and DSL stay
+at `1.1.0`.
+
+## 1.1.1
+
+### Resource Read Authorization
+
+- Reauthorizes local proposal, evidence, and replay resources against the
+  current trusted tenant and principal instead of treating opaque handles as
+  bearer authority.
+
+Released package version: `@synapsor/runner@1.1.1`.
+
+## 1.1.0
 
 ### Bounded Small-Fleet Runtime
 
@@ -27,7 +107,7 @@ for the Synapsor Cloud CLI.
 - Adds [Running A Small Runner Fleet](running-a-runner-fleet.md) and the
   `corepack pnpm test:fleet` synthetic two-Runner verification.
 
-Prepared package versions: `@synapsor/spec@1.1.0`,
+Released package versions: `@synapsor/spec@1.1.0`,
 `@synapsor/dsl@1.1.0`, and `@synapsor/runner@1.1.0`.
 
 ## 1.0.0

package/docs/release-policy.md

@@ -123,7 +123,7 @@ through the `1.x` line unless a release note marks a deprecation first:
 
 Stable does not promise production SLA, hosted Cloud features, compliance
 certification, physical Postgres/MySQL branching, generic SQL writeback,
-generic multi-row writes, or compatibility for undocumented local SQLite
+free-form/unbounded set writes, or compatibility for undocumented local SQLite
 internals. Local store migrations may happen inside `1.x` and later minor
 versions, but documented CLI inspection commands should remain the supported way
 to read the store.

package/docs/result-envelope-v2.md

@@ -86,6 +86,7 @@ database.
     "approval_required": true,
     "writeback": {
       "mode": "direct_update",
+      "operation": "update",
       "applied": false
     },
     "next": "A human must approve outside this model-facing tool surface; nothing is committed yet."
@@ -101,12 +102,22 @@ database.
 }
 ```
 
-For app-owned executors, `proposal.writeback.mode` is `app_handler`.
+For app-owned executors, `proposal.writeback.mode` is `app_handler`. Native
+guarded proposals use `direct_insert`, `direct_update`, or `direct_delete`, and
+`proposal.writeback.operation` is `insert`, `update`, or `delete`. Every
+proposal result still reports `source_database_changed: false` until external
+apply.
+
+For bounded sets, the same model-facing v2 envelope reports the operation,
+reviewed member count, row cap, aggregate values/maximums, set digest, and exact
+allowlisted member diffs. Protocol v3 is used behind the envelope for the
+frozen job and receipt; see [Result Envelope v3](result-envelope-v3.md).
 
 ## Error Result
 
-Model-facing errors are safe and stable. Raw driver details stay in local logs
-or ledger inspection, not in the MCP result.
+Model-facing errors are safe and stable. Structured tool-rejection logs also
+omit raw driver messages, hosts, and credentials; use operator-controlled
+readiness and database diagnostics to investigate the underlying dependency.
 
 ```json
 {
@@ -119,7 +130,8 @@ or ledger inspection, not in the MCP result.
   "error": {
     "code": "TEMPORARILY_UNAVAILABLE",
     "message": "The database is temporarily unavailable. Retry later.",
-    "retryable": true
+    "retryable": true,
+    "retry_after_ms": 1000
   },
   "evidence": null,
   "source_database_changed": false,
@@ -143,8 +155,10 @@ TEMPORARILY_UNAVAILABLE
 INTERNAL
 ```
 
-Current alpha implementation redacts raw connection and driver messages from v2
-MCP results. New `init` and `onboard db` configs write `result_format: 2` by
+Runner redacts raw connection and driver messages from v2 MCP results and
+structured operational logs. Recognized transient pool, PostgreSQL, MySQL, and
+network failures include a bounded `retry_after_ms`; unrelated database errors
+remain non-retryable. New `init` and `onboard db` configs write `result_format: 2` by
 default. Existing hand-written configs without `result_format` keep the legacy
 runtime default for compatibility; pass `--result-format v2` when serving an
 older config to force the v2 envelope, or `--result-format v1` for an older

package/docs/result-envelope-v4.md

@@ -0,0 +1,47 @@
+# Compensation Protocol v4
+
+Protocol v4 is used only for reviewed compensation. Existing v1 single-row,
+v2 CRUD, and v3 bounded-set objects keep their meaning.
+
+Public objects:
+
+- `synapsor.compensation-change-set.v1`;
+- `synapsor.inverse-descriptor.v1`;
+- `synapsor.writeback-job.v4`;
+- `synapsor.execution-receipt.v4`.
+
+The compensation change set is a normal proposal with a new proposal ID,
+principal, tenant scope, evidence, approval requirement, integrity hash, and a
+link to the exact applied forward receipt. It does not authorize execution.
+
+The inverse descriptor records:
+
+- `availability` plus specific `reason_codes` when unavailable;
+- `restore_update`, `remove_insert`, or `restore_insert`;
+- single-row or exact-set cardinality;
+- fixed source, table, tenant guard, and allowed columns;
+- exact primary-key members, expected forward state, and restore values;
+- original row/aggregate caps and integer version advancement;
+- root/parent/reverted proposal lineage and bounded depth.
+
+A v4 writeback job is created only after the compensation proposal is
+independently approved. The adapter locks and validates every member before
+mutation, applies in one source transaction, and emits a v4 receipt. A
+successful receipt contains the compensation's own bounded inverse. A stale or
+missing member returns conflict without a partial effect.
+
+With Runner-ledger receipt authority, an unacknowledged commit or rollback
+enters `reconciliation_required`; no inverse is synthesized until a verified
+operator resolves the outcome.
+
+Canonical JSON Schemas are under:
+
+```text
+schemas/inverse-descriptor.v1.schema.json
+schemas/compensation-change-set.v1.schema.json
+schemas/writeback-job.v4.schema.json
+schemas/execution-receipt.v4.schema.json
+```
+
+See [Reviewed Reversible Change Sets](reversible-change-sets.md) for the
+operator flow and supported operation matrix.

package/docs/reversible-change-sets.md

@@ -0,0 +1,151 @@
+# Reviewed Reversible Change Sets
+
+Synapsor Runner 1.4 can capture a bounded inverse for an opt-in direct database
+write. This is **reviewed compensation**, not rollback or database time travel.
+
+The operator flow is deliberately two separate approval loops:
+
+```text
+forward proposal -> approval -> guarded apply -> applied receipt with inverse
+                                                    |
+                                                    v
+operator runs revert -> new proposal -> independent approval -> guarded apply
+```
+
+`synapsor-runner revert` never writes, approves, or bypasses a guard. It is an
+operator CLI command and is not exposed as an MCP tool.
+
+## Authoring
+
+Add `REVERSIBLE` only to a direct SQL proposal whose inverse Runner can prove:
+
+```sql
+CREATE CAPABILITY billing.propose_plan_credit
+  USING CONTEXT trusted_operator
+  SOURCE billing_postgres
+  ON public.customers
+  PRIMARY KEY id
+  TENANT KEY tenant_id
+  CONFLICT GUARD version
+  LOOKUP customer_id BY id
+  ARG customer_id STRING REQUIRED MAX LENGTH 128
+  ARG amount_cents NUMBER REQUIRED MIN 1 MAX 2500
+  ALLOW READ id, tenant_id, plan_credit_cents, version
+  REQUIRE EVIDENCE
+  MAX ROWS 1
+  PROPOSE ACTION grant_plan_credit UPDATE
+  ALLOW WRITE plan_credit_cents
+  PATCH plan_credit_cents = ARG amount_cents
+  BOUND plan_credit_cents 0..2500
+  ADVANCE VERSION version USING INTEGER INCREMENT
+  APPROVAL ROLE support_reviewer
+  WRITEBACK DIRECT SQL
+  REVERSIBLE
+END
+```
+
+The canonical JSON equivalent is:
+
+```json
+{
+  "proposal": {
+    "reversibility": { "mode": "reviewed_inverse" }
+  }
+}
+```
+
+Validation rejects `REVERSIBLE` when writeback uses an app handler or Cloud
+worker, approval is policy-driven, or an UPDATE lacks exact integer version
+advancement. INSERT also requires a deterministic primary-key dedup component.
+
+## Operator Flow
+
+After an unambiguous forward apply:
+
+```bash
+synapsor-runner revert <forward_proposal_id> \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --reason "Correct the reviewed credit"
+
+synapsor-runner proposals show latest --details --store ./.synapsor/local.db
+synapsor-runner proposals approve latest --yes --store ./.synapsor/local.db
+synapsor-runner apply latest --config ./synapsor.runner.json --store ./.synapsor/local.db
+synapsor-runner replay show latest --store ./.synapsor/local.db
+```
+
+The compensation proposal inherits the original reviewer role and quorum. A
+signed operator identity is required when configured. The source remains
+unchanged until the compensation proposal is separately approved and applied.
+
+## Supported Inverses
+
+| Forward operation | Reviewed compensation |
+| --- | --- |
+| Single-row UPDATE | Restores only allowlisted prior values after checking the exact state and version left by the forward write. The version advances again; it is never decremented. |
+| Soft delete | Same as UPDATE when deletion is a reviewed status or timestamp patch. |
+| Single-row INSERT | Deletes only the exact Runner-created identity after checking current reviewed state, tenant, triggers, and foreign-key effects. |
+| Bounded set UPDATE | Restores exactly the original frozen members under the original count/value caps in one transaction. One stale member aborts all members. |
+| Exact-review batch INSERT | Removes exactly the inserted member identities, atomically, after the same safety preflight. |
+| Hard DELETE | Not generally restorable. The receipt reports specific unavailable reason codes instead of claiming a safe inverse. |
+
+Kept-out and non-writable fields are never captured just to make compensation
+possible. Each successful compensation captures its own bounded inverse, so an
+operator may propose a revert of the compensation. Lineage is linear, duplicate
+children are rejected, and traversal is capped at 16 proposals.
+
+## Fail-Closed Cases
+
+Runner refuses to create or apply compensation when:
+
+- the forward outcome is missing, failed, or requires reconciliation;
+- the applied receipt has no available inverse;
+- another active compensation already targets that receipt;
+- the tenant or operator identity does not match trusted authority;
+- the row changed after the forward write;
+- an inserted row is missing or has changed;
+- a new trigger, foreign-key dependent, or widening cascade prevents a bounded
+  effect proof;
+- any member of a bounded set is stale or missing;
+- lineage is invalid, cyclic, or beyond the depth limit.
+
+With `runner_ledger` receipt authority, a crash after source commit but before
+ledger completion remains ambiguous. Forward and compensation writes enter
+`reconciliation_required`; Runner does not call them reverted or retry them
+automatically. Reconcile the outcome first through the verified operator
+workflow.
+
+## Database Metadata Privileges
+
+Postgres uses catalog visibility available to the configured writer for
+trigger and foreign-key preflight.
+
+MySQL compensation that may delete a row, including reversal of INSERT,
+requires enough metadata visibility to prove no hidden widening effects:
+
+- scoped `TRIGGER` visibility on the target table;
+- global `PROCESS` visibility for incoming InnoDB foreign-key metadata.
+
+If those privileges are not acceptable, use a reversible soft-delete UPDATE or
+an explicitly reviewed app-owned compensation capability. Runner fails closed.
+
+## App-Owned Executors
+
+Runner does not infer compensation for `http_handler`, `command_handler`,
+payments, messages, or other external effects. The application must expose a
+separate reviewed compensation capability and enforce its own tenant, version,
+idempotency, and transaction rules. A handler returning a receipt does not make
+its side effect Runner-reversible.
+
+## Verification
+
+The disposable PostgreSQL/MySQL gate proves UPDATE, INSERT, soft-delete, exact
+bounded-set compensation, independent approval, stale-state refusal,
+hard-delete unavailability, inverse redaction, receipts, and replay:
+
+```bash
+corepack pnpm test:reversible
+```
+
+See [RFC 006](rfcs/006-reviewed-reversible-change-sets.md) for the normative
+safety design and [Current Limitations](limitations.md) for the wider boundary.