@synapsor/runner 1.1.1 → 1.4.1

package/docs/release-notes.md

@@ -10,7 +10,110 @@ 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.1 (prepared, not published)
+
+### Bounded-set digest compatibility patch
+
+- Contract-authored bounded-set proposals now use deterministic recursive
+  object-key ordering for member and set digest material.
+- Valid proposals created by `1.4.0` remain applyable; the compatibility path
+  accepts only the known deterministic `1.4.0` serializations reconstructed
+  from the complete stored reviewed data.
+- Genuine member, version, value, aggregate, membership, or tenant drift still
+  fails closed before source mutation on PostgreSQL and MySQL.
+- The Runner package now includes the linked bounded-set guide and validates
+  all shipped local Markdown links while packaging.
+- The DSL package description and README no longer label the current `1.4.x`
+  package as a `0.1 preview`. Canonical contract `spec_version: "0.1"` is
+  unchanged.
+- Adds an honest prompt-and-application-guardrails decision guide covering SQL
+  authority, hand-built semantic tools, structural enforcement, build-vs-adopt
+  fit, and regulated-data boundaries.
+
+Prepared package versions: `@synapsor/dsl@1.4.1` and
+`@synapsor/runner@1.4.1`. `@synapsor/spec` remains `1.4.0`.
+
+## 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 +130,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-v3.md

@@ -0,0 +1,43 @@
+# Result Envelope V3
+
+Protocol v3 is used only for bounded set direct writeback. Protocol v1 and v2
+remain accepted for legacy UPDATE and guarded single-row CRUD.
+
+The public artifacts are:
+
+- `synapsor.change-set.v3`;
+- `synapsor.writeback-job.v3`;
+- `synapsor.execution-receipt.v3`.
+
+Each v3 object names one operation: `set_update`, `set_delete`, or
+`batch_insert`. It carries the same frozen-set authority:
+
+```json
+{
+  "max_rows": 10,
+  "row_count": 2,
+  "aggregate_bounds": [
+    { "column": "balance_cents", "measure": "before", "maximum": 20000, "actual": 15000 }
+  ],
+  "members": [
+    {
+      "primary_key": { "column": "id", "value": "INV-1" },
+      "expected_version": { "column": "version", "value": 1 },
+      "before_digest": "sha256:...",
+      "after_digest": "sha256:..."
+    }
+  ],
+  "set_digest": "sha256:..."
+}
+```
+
+The complete protocol fixtures live in [`fixtures/protocol`](../fixtures/protocol)
+and the JSON Schemas live in [`schemas`](../schemas). The execution receipt
+reports every `target_identity` and matching `member_effect`, plus receipt
+authority, set digest, exact affected count, safe status/error, and receipt
+hash. An applied result is invalid unless its affected count and member-effect
+count match the frozen identity count.
+
+`runner_ledger` may return `reconciliation_required` with an intent ID when a
+cross-database crash window prevents proof of commit. That is a terminal
+operator state, not a retry instruction or an `already_applied` guess.

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.

package/docs/rfcs/004-guarded-crud-receipt-authority.md

@@ -0,0 +1,165 @@
+# RFC 004: Guarded CRUD Receipt Authority
+
+Status: implementation gate
+
+## Purpose
+
+Runner 1.2 adds guarded single-row INSERT and DELETE while making source receipt
+DDL optional. It must preserve the defining boundary: a reviewed, tenant-bound,
+one-row business effect with evidence, external approval, a receipt, and replay.
+
+This RFC is required before adapter expansion because receipt placement changes
+which outcomes can be proven after a crash.
+
+## Configuration Model
+
+Two decisions are orthogonal:
+
+```text
+receipt_authority: source_db | runner_ledger
+source_receipt_provisioning: precreated | auto_migrate
+```
+
+`source_receipt_provisioning` is valid only for `source_db`.
+
+For compatibility, omitted fields mean `source_db` plus `precreated`. A new
+wizard may recommend `auto_migrate`, but it must obtain explicit consent before
+granting Runner DDL authority. `runner_ledger` is opt-in and must explain its
+post-commit ambiguity.
+
+Receipt schema/table identifiers are operator config, validated as fixed safe
+identifiers. They are never contract fields or model arguments.
+
+## Terms
+
+- **Exactly-once classification:** Runner can prove whether this proposal was
+  applied, conflicted, or failed.
+- **At-most-once business effect:** the source cannot perform the reviewed
+  effect twice for the same deterministic identity.
+- **Idempotent effect:** repeating an operation converges on the same source
+  state, but may not prove who caused it.
+- **Ambiguous outcome:** the source may have committed, but Runner lacks an
+  atomic receipt proving that fact. This requires reconciliation.
+
+These terms are not interchangeable.
+
+## Claim Matrix
+
+The claims below apply equally to Postgres and MySQL. Engine-specific tests must
+prove them separately.
+
+| Operation | Authority | Source prerequisite | Normal result | Retry after completed receipt | Crash after source commit, before Runner completion |
+| --- | --- | --- | --- | --- | --- |
+| UPDATE | `source_db` | exact PK+tenant+version guard; source receipt table | atomic one-row UPDATE and receipt | `already_applied` | atomic transaction proves applied or rolled back |
+| INSERT | `source_db` | trusted tenant; reviewed insert columns; proposal-specific PK/UNIQUE dedup key; source receipt table | atomic one-row INSERT and receipt | `already_applied` | atomic transaction proves applied or rolled back |
+| DELETE | `source_db` | exact PK+tenant+version guard; no expanding cascade/write trigger; source receipt table | atomic one-row DELETE and receipt | `already_applied` | atomic transaction proves applied or rolled back |
+| UPDATE | `runner_ledger` | authoritative shared ledger for fleets; exact PK+tenant+version guard; monotonic version advancement in source transaction | intent, one-row UPDATE, terminal ledger receipt | completed matching receipt returns `already_applied` | advanced guard plus incomplete intent is `reconciliation_required` |
+| INSERT | `runner_ledger` | authoritative shared ledger for fleets; proposal-specific source PK/UNIQUE key | intent, one-row INSERT, terminal ledger receipt | completed matching receipt returns `already_applied` | matching unique row plus incomplete intent is reconciled only when provenance is provable; otherwise `reconciliation_required` |
+| DELETE | `runner_ledger` | authoritative shared ledger for fleets; exact PK+tenant+version guard; no expanding side effects | intent, one-row DELETE, terminal ledger receipt | completed matching receipt returns `already_applied` | missing row plus incomplete intent is `reconciliation_required`, not proof of this delete |
+
+## Failure and Crash Matrix
+
+| Point/outcome | `source_db` | `runner_ledger` |
+| --- | --- | --- |
+| ledger/source unavailable before intent | no source effect; retryable unavailable | no source effect; retryable unavailable |
+| crash before source BEGIN | no source effect | durable intent remains; safe retry only if no ambiguous attempt was entered |
+| crash after BEGIN, before mutation | transaction rolls back | source transaction rolls back; intent can be marked failed/retried by bounded operator/worker logic |
+| stale/version conflict | conflict receipt commits atomically | conflict terminal event is recorded; no source mutation |
+| crash after mutation, before source COMMIT | transaction rolls back | source transaction rolls back; no business effect |
+| crash after source COMMIT, before Runner completion | impossible as a split outcome because source receipt shares the transaction | terminal state is `reconciliation_required`; never auto-retry |
+| concurrent identical apply | source receipt serializes one outcome | ledger intent plus source guard/unique key permits at most one effect; ambiguous loser reconciles |
+| source unavailable after intent | no source effect | intent remains failed/retryable only while no source transaction could have committed |
+
+## Operation Proof Obligations
+
+### UPDATE
+
+Runner-ledger UPDATE requires a real version guard and monotonic advancement in
+the same source transaction. Accepted strategies are a Runner-generated integer
+increment or a database-generated version whose changed value is verified
+before commit. A name such as `updated_at` is not proof. Insufficient timestamp
+precision fails preflight.
+
+An advanced source version plus an incomplete intent is ambiguous, not
+`already_applied`.
+
+### INSERT
+
+INSERT requires a proposal-specific deterministic identity backed by an
+inspected PRIMARY KEY or UNIQUE constraint. The model cannot set tenant,
+identity/generated columns, or arbitrary columns. The contract declares the
+portable dedup mapping; Runner config declares receipt placement.
+
+Ledger memory by itself does not prevent a duplicate INSERT after a process
+crash. A source uniqueness constraint is mandatory.
+
+### DELETE
+
+DELETE targets one reviewed row by primary key, trusted tenant, and expected
+version. The proposal freezes allowlisted before evidence. A hard delete is
+refused when cascading foreign keys or write triggers can expand the reviewed
+effect. Soft delete remains the preferred path.
+
+A missing row after an incomplete Runner-ledger attempt proves only that the
+row is absent, not that this attempt deleted it.
+
+## Durable Runner-Ledger Intent
+
+Before touching the source, Runner durably stores:
+
+- proposal ID, version, and hash;
+- capability and operation;
+- trusted tenant and target/dedup identity;
+- expected guard;
+- bounded attempt number;
+- state and timestamps.
+
+Allowed states are:
+
+```text
+intent_recorded
+applying
+applied
+already_applied
+conflict
+failed
+reconciliation_required
+```
+
+Transitions append immutable events. An incomplete `applying` attempt is never
+automatically restarted if the source may have committed.
+
+## Reconciliation
+
+The operator command re-reads only the reviewed target under trusted tenant
+scope and displays expected versus observed allowlisted metadata. It never
+guesses. A verified operator can mark `applied`, `conflict`, or `failed` with a
+reason; Runner appends a reconciliation event and receipt. Production signed
+identity requirements apply unchanged.
+
+## Topology Rules
+
+- local SQLite Runner-ledger authority is allowed only for one local operator
+  process;
+- Streamable HTTP fleets and multiple workers require shared Postgres
+  `runtime_store` as the authoritative ledger;
+- `mirror` is not authoritative enough for Runner-ledger write intents;
+- unsafe topology fails at config/doctor/start preflight.
+
+## Security Invariants
+
+- raw SQL, receipt controls, identifiers, approval, apply, credentials, tenant,
+  and principal remain outside model-facing tools;
+- all identifiers are contract/config validated and all values are parameters;
+- unknown, stale, ambiguous, or multi-row effects fail closed;
+- kept-out fields are not persisted in intents, receipts, metrics, or replay;
+- local resource reads continue to reauthorize tenant and principal;
+- no claim of distributed atomic exactly-once is made for `runner_ledger`.
+
+## Bounded Set Gate
+
+This RFC does not authorize multi-row writes. Set operations require a separate
+RFC with fixed typed predicates, frozen exact targets, mandatory count/value
+bounds, deterministic row locking, one transaction, exact receipts, and all
+R1-R7 threat mitigations. `MAX ROWS` syntax alone is not shippable.
+