@synapsor/runner 1.6.0 → 1.6.1

package/docs/app-owned-executors.md

@@ -24,6 +24,14 @@ the receipt, and includes the result in replay.
 > error receipts. If you skip those checks, you can reintroduce cross-tenant
 > writes, lost updates, or duplicate writes. Keep handler credentials out of MCP.
 
+Runner 1.6.1 strict `proposal_freshness` is limited to same-database direct SQL
+writeback. Runner rejects it for `http_handler`, `command_handler`, and
+cross-source dependencies because a local preflight cannot be atomic with an
+effect executed elsewhere. If supporting evidence matters, the app handler
+must lock and re-read those rows inside its own business transaction and fail
+closed on drift. See
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).
+
 A handler is your application endpoint or script. It is not a second Synapsor
 package that users need to install. Install `@synapsor/runner`, then generate
 or copy a handler template only when your approved write needs app-owned

package/docs/capability-authoring.md

@@ -384,6 +384,38 @@ surface.
 }
 ```
 
+### Optional Live Freshness
+
+The proposal's exact `conflict_guard` already protects its target at apply.
+Runner 1.6.1 can additionally recheck that target before local approval and can
+bind explicitly reviewed supporting rows to both approval and apply.
+
+This is deployment wiring, not DSL or canonical contract syntax:
+
+```json
+{
+  "proposal_freshness": {
+    "billing.propose_late_fee_waiver": {
+      "approval": "required",
+      "dependencies": [
+        {
+          "id": "payment_status",
+          "capability": "billing.inspect_payment",
+          "identity_from_arg": "payment_id",
+          "version_column": "version"
+        }
+      ]
+    }
+  }
+}
+```
+
+`billing.inspect_payment` must be an existing reviewed single-row read on the
+same source and trusted context. `payment_id` is an existing scalar proposal
+argument; the model cannot choose the dependency table, version column, tenant,
+principal, or whether the check runs. See
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).
+
 ## Trusted Context
 
 Tenant, principal, approval authority, source ids, and row-version authority
@@ -468,6 +500,12 @@ Runner validates:
 - one affected row;
 - idempotency receipt.
 
+When the proposal opts into `proposal_freshness`, the direct SQL adapter also
+locks and compares every declared supporting row inside the same transaction
+before touching the target. A mismatch returns a freshness conflict and zero
+affected rows. Run `doctor --check-writeback` to verify that the writer can
+perform those dependency locking reads.
+
 INSERT additionally requires a source-unique dedup key. DELETE requires an exact
 version guard and fails closed on widening cascades or write triggers.
 
@@ -489,6 +527,13 @@ inserting an outbox event, updating multiple app tables, calling your own
 service, or creating a row whose source constraints cannot satisfy native
 single-row INSERT guards.
 
+Runner's strict `proposal_freshness` overlay does not support app-owned or
+cross-source effects because Runner cannot make their source checks and effect
+atomic. The handler must independently lock/re-read all relevant state and
+enforce the exact proposal, scope, version, transaction, and idempotency
+preconditions described in
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).
+
 In DSL, keep the reviewed business contract portable and name the executor:
 
 ```sql

package/docs/current-scope.md

@@ -25,6 +25,9 @@ Current `1.6` scope:
   explicit development-only static values;
 - evidence handles, normalized query audit, proposals, receipts, local replay,
   and read-only lifecycle inspection without copying proposal ids;
+- optional proposal/evidence freshness: live target and declared same-source
+  supporting-row checks before every approval, proof-bound human/quorum/policy
+  decisions, and atomic direct-SQL dependency revalidation at apply;
 - guarded single-row `INSERT`, `UPDATE`, and `DELETE`;
 - fixed-predicate set `UPDATE`/`DELETE` and exact-review batch `INSERT`, with
   mandatory row/value caps, frozen members, human approval, atomic execution,
@@ -62,6 +65,8 @@ Out of scope:
 - model-selected tenant/principal, activation, approval, or commit authority;
 - UPSERT, DDL, free-form predicates, unbounded writes, or cross-table direct
   transactions;
+- strict atomic freshness for app-owned handlers, APIs, or cross-source
+  dependencies; those executors own their transaction preconditions;
 - physical branching of external Postgres/MySQL or automatic rollback/time
   travel;
 - self-hosted Synapsor Cloud, an unbounded/multi-region shared ledger, a managed

package/docs/cursor-plugin.md

@@ -19,7 +19,7 @@ claim that Cursor Marketplace review has completed.
 
 ## What the plugin installs
 
-- one production stdio MCP server pinned to `@synapsor/runner@1.6.0`;
+- one production stdio MCP server pinned to `@synapsor/runner@1.6.1`;
 - one `/synapsor-protect` agent command;
 - one discoverable Safe Action skill;
 - one file-scoped rule for `synapsor/actions/**/*.ts`;
@@ -80,7 +80,7 @@ Required listing media:
 
 ## Submission checklist
 
-- [ ] Runner 1.6.0 package and plugin version agree.
+- [ ] Runner 1.6.1 package and plugin version agree.
 - [ ] `corepack pnpm verify:cursor-plugin` passes from a clean checkout.
 - [ ] Plugin is manually loaded in current stable Cursor at workspace scope.
 - [ ] `/synapsor-protect` drafts and validates without activation.

package/docs/limitations.md

@@ -2,8 +2,10 @@
 
 Synapsor Runner is intentionally narrow. Version 1.6 adds deterministic
 whole-application boundary drafting and a local authoring-only Explore ->
-Protect path on top of guarded writes. It does not turn Runner into a generic
-database query tool, claim Synapsor Cloud scale, or claim an enterprise SLA.
+Protect path on top of guarded writes. Version 1.6.1 also adds opt-in
+proposal/evidence freshness for exact same-source direct-SQL proposals. It does
+not turn Runner into a generic database query tool, claim Synapsor Cloud scale,
+or claim an enterprise SLA.
 
 ## Supported
 
@@ -15,6 +17,9 @@ database query tool, claim Synapsor Cloud scale, or claim an enterprise SLA.
 - Native Postgres/MySQL source pools and operational/fleet-wide rate limits.
 - Verified operator approval through CLI, optional distinct-reviewer quorum,
   and shared local review UI reads.
+- Optional live target and explicitly declared supporting-row freshness checks
+  before every approval, with immutable proof binding and final transactional
+  revalidation for PostgreSQL/MySQL direct SQL writeback.
 - Separately protected scrapeable metrics and dead-letter recovery commands.
 - Shared-ledger backup/digest verification, clean restore, and
   archive-before-retention.
@@ -90,6 +95,8 @@ truth for the model-facing tools.
 - Policy auto-approval for bounded sets.
 - Stored procedures.
 - Cross-database transactions.
+- Strict atomic proposal freshness across databases, app-owned handlers, or
+  external APIs. Those paths must enforce their own final preconditions.
 - Physical branching of Postgres/MySQL.
 - Full Synapsor workflow/DAG execution.
 - `CREATE AGENT WORKFLOW` or hosted Synapsor SQL generation.
@@ -163,3 +170,9 @@ 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).
+
+Approval-time freshness also depends on a correct exact version column. It
+does not freeze source state until apply. Direct SQL apply rechecks again;
+app-owned/cross-source effects do not receive that Runner-owned atomic
+guarantee. See
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).

package/docs/local-mode.md

@@ -140,10 +140,19 @@ Show a proposal:
 npx -y -p @synapsor/runner synapsor-runner proposals show wrp_123 --store ./.synapsor/local.db
 ```
 
+Check a freshness-enabled proposal without copying its id:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner proposals check-freshness latest \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
 Approve:
 
 ```bash
 npx -y -p @synapsor/runner synapsor-runner proposals approve wrp_123 \
+  --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --actor local_reviewer \
   --yes
@@ -151,6 +160,14 @@ npx -y -p @synapsor/runner synapsor-runner proposals approve wrp_123 \
 
 Before approval, the CLI prints the reviewer-critical proposal details: trusted principal, tenant, target row, primary key, required role, proposal hash/version, allowed columns, conflict guard, evidence bundle/query fingerprint, writeback boundary, source mutation state, and exact before/after diff. Interactive approval still requires typing `yes`; noninteractive scripts must pass `--yes`.
 
+When `proposal_freshness` is configured for that capability, approval also
+performs a live read-only check of the target and each declared same-source
+supporting dependency. A fresh result is bound to the approval by proof digest.
+A stale result records no approval and terminally conflicts the proposal; an
+unavailable source records no approval and leaves it pending. Apply always
+revalidates again because source data can change after approval. See
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).
+
 Create a guarded writeback job from an approved proposal:
 
 ```bash
@@ -203,9 +220,11 @@ npx -y -p @synapsor/runner synapsor-runner ui --config synapsor.runner.json --st
 ```
 
 The UI shows setup summary, semantic tools, proposal states, exact diffs,
-evidence, approval state, receipts, and replay. It binds to `127.0.0.1` by
-default, uses a per-run local session token, and requires CSRF protection for
-approve/reject actions.
+evidence, live freshness state, approval state, receipts, and replay. A
+freshness-required approve control stays disabled until the live result is
+fresh; the approve request performs another live check. The UI binds to
+`127.0.0.1` by default, uses a per-run local session token, and requires CSRF
+protection for approve/reject actions.
 
 The UI does not expose raw SQL, database URLs, password values, MCP approval
 tools, MCP commit tools, or controls that widen configured tables/columns.

package/docs/production.md

@@ -191,6 +191,16 @@ business action, transaction boundaries, and safe errors. See
 [Writeback Executors](writeback-executors.md) and
 [Handler Helper](handler-helper.md).
 
+For a direct SQL proposal whose approval depends on live source facts, use the
+optional `proposal_freshness` overlay. It rechecks the target and declared
+same-source supporting rows before approval, then locks and rechecks them again
+inside the final PostgreSQL/MySQL transaction. Run
+`doctor --check-writeback` to prove that the writer can perform every
+dependency locking read. App-owned and cross-source effects must enforce their
+own equivalent transactional preconditions; Runner rejects them from strict
+freshness mode. See
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).
+
 ## Local Ledger
 
 Default local ledger path:
@@ -589,6 +599,10 @@ Doctor reports should be redacted by default before sharing. They must not
 include database passwords, bearer tokens, handler secrets, or raw driver
 connection strings.
 
+For freshness-enabled proposals, `--check-writeback` includes rollback-only
+dependency lock probes. A passing metadata/read check alone does not prove that
+the writer has the locking privilege needed at apply.
+
 ## Logging And Redaction
 
 Expected public outputs must avoid secrets in:
@@ -613,3 +627,8 @@ Before promoting a package or calling a build production-candidate:
 The release gate should cover typecheck, focused tests, packed-package install,
 quick demo, own-db fixture, MCP stdio/HTTP checks, direct writeback,
 app-owned executor paths, package dry-run, and docs/package consistency.
+The 1.6.1 security gate additionally runs:
+
+```bash
+corepack pnpm test:proposal-freshness
+```

package/docs/proposal-evidence-freshness.md

@@ -0,0 +1,334 @@
+# Proposal And Evidence Freshness
+
+Runner 1.6.1 adds an optional fail-closed freshness gate for proposals whose
+review depends on live source state.
+
+This closes two different review gaps without changing the model-facing MCP
+surface:
+
+1. Before a local approval, Runner can re-read the proposal target and refuse
+   approval if its exact version changed.
+2. A proposal can declare reviewed supporting rows whose exact versions must
+   still match before approval and again at apply.
+
+Target-row drift was already blocked by the exact conflict guard at apply.
+Version 1.6.1 does not replace that protection. It adds an earlier review-time
+check and extends the final transaction to declared same-source dependencies.
+
+## What Freshness Does And Does Not Mean
+
+Keep these controls separate:
+
+| Control | What it proves |
+| --- | --- |
+| Proposal hash and version | The approval refers to one immutable proposal shape. |
+| Evidence and query fingerprints | The stored review material has not silently changed. |
+| Freshness proof | The target and declared dependencies matched their captured exact versions at one live check. |
+| Approval | A trusted reviewer or policy authorized that exact proposal and proof. |
+| Apply conflict checks | The target and dependencies still match inside the mutation transaction. |
+| Idempotency receipt | Retrying the same completed writeback identity does not duplicate its effect. |
+
+A successful approval-time check is not a lock held until apply. Data can
+change one millisecond later, so apply always revalidates again.
+
+Runner never refreshes a stale proposal in place. The operator must perform a
+new source read and create a new proposal with a new hash and review.
+
+## Configuration
+
+Freshness is a Runner deployment overlay in `synapsor.runner.json`. Version
+1.6.1 adds no DSL clause and no canonical Spec field. Existing hand-authored
+DSL, canonical JSON, contract digests, and `tools/list` output remain unchanged
+when this optional section is absent.
+
+```json
+{
+  "proposal_freshness": {
+    "billing.propose_credit": {
+      "approval": "required",
+      "dependencies": [
+        {
+          "id": "invoice_eligibility",
+          "capability": "billing.inspect_invoice",
+          "identity_from_arg": "invoice_id",
+          "version_column": "updated_at"
+        }
+      ]
+    }
+  }
+}
+```
+
+The names mean:
+
+- `billing.propose_credit`: an existing reviewed proposal capability.
+- `approval: "required"`: every approval decision requires a new short-lived
+  live proof.
+- `invoice_eligibility`: an operator-defined stable dependency label.
+- `billing.inspect_invoice`: an existing reviewed single-row read capability.
+- `invoice_id`: an existing bounded scalar argument on the proposal. Its value
+  identifies the supporting row through the read capability's fixed lookup.
+- `updated_at`: the exact version/conflict column on that supporting row.
+
+The proposal and supporting read must use the same source and trusted context.
+The supporting capability supplies the fixed engine, schema, table, primary
+key, tenant key, optional principal key, and lookup shape. None of those
+identifiers can come from an MCP argument.
+
+Strict validation rejects:
+
+- unknown or non-proposal policy keys;
+- app-owned or cross-source writeback;
+- unknown, aggregate, protected, or non-single-row dependencies;
+- missing or untrusted tenant scope;
+- incompatible principal scope;
+- missing scalar identity arguments;
+- unsafe or missing version identifiers;
+- duplicate, self-referential, or more than 16 dependencies.
+
+Run both static validation and live writeback probes:
+
+```bash
+synapsor-runner config validate --config ./synapsor.runner.json
+synapsor-runner doctor --check-writeback --config ./synapsor.runner.json
+```
+
+`doctor --check-writeback` performs rollback-only lock probes. The read role
+needs scoped `SELECT`. The writer must be able to lock every declared
+supporting row in the final transaction. PostgreSQL and MySQL may require a
+narrow update/locking privilege in addition to `SELECT`; use a dedicated
+least-privilege writer and verify the exact grants on the deployed database.
+
+## Proposal Creation
+
+When a freshness-enabled proposal is created, Runner:
+
+1. reads the target through the existing reviewed proposal capability;
+2. reads each declared dependency through its reviewed single-row capability
+   in a read-only transaction;
+3. captures only the fixed identity, exact version, and bounded
+   evidence/query-audit linkage;
+4. sorts dependencies into deterministic lock order;
+5. binds the resulting `synapsor.freshness-authority.v1` object into the
+   immutable change set and proposal hash.
+
+The authority contains digests and fixed identifiers. It does not add source
+rows, kept-out values, database URLs, credentials, or a second copy of trusted
+tenant/principal values to the proposal.
+
+The published protocol representation is inspectable without reading the
+TypeScript implementation:
+
+- `schemas/freshness-authority.v1.schema.json` defines the optional authority
+  carried by change sets and writeback jobs.
+- `schemas/freshness-proof.v1.schema.json` defines the immutable live-check
+  proof stored in the ledger.
+- `fixtures/protocol/change-set.freshness-update.v2.json`,
+  `fixtures/protocol/writeback-job.freshness-update.v2.json`,
+  `fixtures/protocol/freshness-authority.invoice.v1.json`, and
+  `fixtures/protocol/freshness-proof.fresh.v1.json` are hash-manifested
+  conformance examples.
+
+The JSON Schemas enforce the public structure. The executable protocol
+validator additionally verifies canonical descriptor, dependency-set, and
+proof digests plus cross-field invariants that JSON Schema cannot express.
+
+For UPDATE and DELETE, target mode is `exact_guard`. For a bounded set it is
+`frozen_set`. INSERT has no prior target row, so target freshness is
+`not_applicable`; its source uniqueness and idempotency guards still apply.
+
+## Approval-Time Check
+
+Inspect the newest proposal without copying an ID:
+
+```bash
+synapsor-runner proposals check-freshness latest \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+Add `--details` for per-check digests or `--json` for the versioned
+`synapsor.proposal-freshness-result.v1` document.
+
+Stable exit codes are:
+
+| Status | Exit code | Meaning |
+| --- | ---: | --- |
+| `fresh` | 0 | Every required target/dependency version matched. |
+| `not_required` | 0 | Legacy proposal; its normal apply guard still applies. |
+| `stale` | 3 | A target or dependency changed, disappeared, or left trusted scope. |
+| `unavailable` | 4 | The source could not be checked; retry may be appropriate. |
+| `invalid` | 5 | Stored or configured authority did not validate. |
+| `unsupported` | 6 | The topology cannot provide the claimed guarantee. |
+
+Approval runs the same live check automatically:
+
+```bash
+synapsor-runner proposals approve latest \
+  --yes \
+  --actor billing_reviewer \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+A successful check records an immutable `synapsor.freshness-proof.v1` event.
+The proof binds:
+
+- proposal ID, hash, and integer version;
+- dependency-set digest;
+- checked and short validity times;
+- source adapter identity;
+- bounded target/supporting counts and result codes;
+- expected/observed version digests, not source values;
+- the proof's own digest.
+
+Every human quorum decision receives a distinct live proof. Policy
+auto-approval uses the same evaluator. A stale check records no approval and
+makes the proposal terminal `conflict`. An unavailable check records no
+approval and leaves it `pending_review`.
+
+## Apply-Time Revalidation
+
+Apply remains an operator/worker action outside MCP:
+
+```bash
+synapsor-runner apply latest \
+  --yes \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+For direct SQL PostgreSQL/MySQL writeback, Runner:
+
+1. begins the existing source transaction;
+2. locks supporting rows in deterministic source/schema/table/identity order;
+3. rechecks each exact version under trusted tenant and principal scope;
+4. locks and rechecks the target row or every frozen set member;
+5. performs the existing guarded mutation only if all checks pass;
+6. finalizes the configured source or Runner-ledger receipt behavior.
+
+PostgreSQL uses parameterized `SELECT ... FOR UPDATE` and quoted reviewed
+identifiers. MySQL uses the equivalent InnoDB locking read. A stale supporting
+row returns `FRESHNESS_DEPENDENCY_STALE`, zero affected rows, and rolls back the
+whole transaction. A stale target continues to use the exact target conflict
+path. A stale conflict is never converted to `already_applied`.
+
+For a bounded set, one stale member or one stale dependency aborts every member.
+
+## Timeline
+
+Change before approval:
+
+```text
+proposal captures target v4 + invoice v8
+invoice moves to v9
+reviewer approves
+  -> live preflight sees v9 != v8
+  -> no approval, no source mutation
+  -> create a new read and proposal
+```
+
+Change after approval:
+
+```text
+proposal captures target v4 + invoice v8
+approval preflight succeeds and binds proof
+invoice moves to v9
+trusted apply starts
+  -> transaction locks invoice and sees v9 != v8
+  -> conflict, zero source mutation
+  -> create a new read and proposal
+```
+
+The second timeline is why approval-time freshness can never replace
+apply-time concurrency control.
+
+## Supporting Evidence Example
+
+Assume `credits.propose_account_credit` changes an account row, but eligibility
+depends on a separate invoice:
+
+```text
+target account       version 12 (unchanged)
+supporting invoice   status=open, version 7
+proposal             credit $25 because invoice is open
+```
+
+If a payment process closes the invoice and advances it to version 8 while the
+account stays at version 12, the target guard alone would still pass. Declaring
+the invoice read as a freshness dependency makes approval or apply fail closed
+on the invoice version mismatch.
+
+Freshness checks the reviewed exact version, not whether the current value
+"looks equivalent." Returning a row to its old value does not revive a proposal
+that already became stale.
+
+## Ledger, Replay, Reports, And Metrics
+
+Use the no-ID lifecycle view:
+
+```bash
+synapsor-runner lifecycle --details --store ./.synapsor/local.db
+synapsor-runner replay show latest --details --store ./.synapsor/local.db
+```
+
+Lifecycle and replay retain the proof chain: authority, proof event, approval
+proof digest, apply result, receipt, and replay linkage. Backup/restore and the
+shared PostgreSQL runtime store preserve the same versioned records.
+
+Compliance reports include only bounded freshness metadata and digests. Metrics
+separate checks, stale target/supporting outcomes, blocked approvals, and
+apply-time blocks. Logs never include source rows or credential values.
+
+## Cloud And App-Owned Executors
+
+Cloud-linked approval remains proposal/digest authority. Cloud may retain
+bounded freshness metadata, but it does not connect to or read the customer
+database. A Runner next to the source revalidates dependencies when it applies
+a Cloud-approved lease. Cloud outage never enables weaker local approval or
+apply authority.
+
+Strict freshness currently supports same-database direct SQL writeback only.
+Runner rejects strict freshness configuration for app-owned handlers and
+cross-source dependencies because it cannot place those checks and effects in
+one transaction.
+
+An app-owned executor can implement equivalent preconditions, but the
+application must own and test:
+
+- source reads and locking;
+- tenant/principal authorization;
+- exact expected versions;
+- transaction boundaries;
+- idempotency and ambiguous outcomes;
+- safe receipts.
+
+Do not describe those application guarantees as Runner's atomic direct-SQL
+freshness guarantee.
+
+## Security Boundary
+
+Freshness adds no model-facing approval, apply, activation, bypass, SQL, table,
+column, scope, or policy argument. Existing `tools/list` output is unchanged.
+
+It also does not replace:
+
+- correct monotonic version columns;
+- least-privilege read/write roles;
+- PostgreSQL RLS, restricted views, or tenant-bound credentials;
+- application authorization;
+- source backups and recovery testing;
+- operator identity and host/store protection.
+
+The dedicated live gate is:
+
+```bash
+corepack pnpm test:proposal-freshness
+```
+
+It runs disposable PostgreSQL and MySQL scenarios for approval preflight,
+proof-bound human/quorum/policy approval, target/supporting drift before and
+after approval, source and Runner-ledger receipts, bounded-set rollback,
+reversible UPDATE, DELETE, shared runtime state, Cloud-approved local
+revalidation, writer lock probes, idempotent retry, and kept-out-value
+non-disclosure.

package/docs/release-notes.md

@@ -10,7 +10,34 @@ 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.6.0 (prepared, not published)
+## 1.6.1 (prepared, not published)
+
+### Fail-closed proposal and evidence freshness
+
+- An optional `proposal_freshness` Runner overlay can require a live target and
+  explicitly declared same-source supporting-row check immediately before
+  every local approval.
+- Each successful human, quorum, or policy approval references a distinct
+  short-lived proof bound to the exact proposal hash/version and dependency
+  set. Stale and unavailable checks record no approval.
+- Direct PostgreSQL/MySQL apply locks and rechecks dependencies inside the
+  mutation transaction. Source drift after approval returns a conflict and
+  changes zero rows; bounded sets roll back completely.
+- `proposals check-freshness latest`, Workbench gating, lifecycle, replay,
+  compliance reports, metrics, logs, and `doctor --check-writeback` expose the
+  bounded proof and operational state without source rows, kept-out values,
+  trusted scope values, or credentials.
+- Cloud does not read the source. A local Runner revalidates a Cloud-approved
+  job before apply. Strict app-owned and cross-source freshness remains an
+  explicitly unsupported topology.
+- Existing contracts, exact digests, DSL, model-facing tool lists, and
+  non-freshness deployments keep their prior behavior.
+
+Prepared package version: `@synapsor/runner@1.6.1`.
+`@synapsor/spec@1.5.0` and `@synapsor/dsl@1.5.0` are unchanged. Nothing has
+been published by this repository change.
+
+## 1.6.0 (published 2026-07-23)
 
 ### Connect, Explore, Protect
 
@@ -39,9 +66,8 @@ for the Synapsor Cloud CLI.
   new fields. Published legacy contracts preserve exact normalization/digests,
   and established CLI/headless/CI routes keep their behavior.
 
-Prepared package versions: `@synapsor/runner@1.6.0`,
-`@synapsor/dsl@1.5.0`, and `@synapsor/spec@1.5.0`. Nothing has been published
-by this repository change.
+Published package versions: `@synapsor/runner@1.6.0`,
+`@synapsor/dsl@1.5.0`, and `@synapsor/spec@1.5.0`.
 
 ## 1.5.4 (published 2026-07-22)
 

package/docs/runner-config-reference.md

@@ -453,6 +453,52 @@ Distinct verified subjects fill quorum slots; one subject cannot count twice.
 A rejection is terminal. Policy auto-approval is deferred when quorum is
 greater than one.
 
+## Proposal freshness
+
+`proposal_freshness` is an optional Runner-only deployment overlay. It does not
+change the public DSL or canonical contract and does not alter legacy proposal
+or `tools/list` behavior when absent.
+
+```json
+{
+  "proposal_freshness": {
+    "billing.propose_credit": {
+      "approval": "required",
+      "dependencies": [
+        {
+          "id": "invoice_eligibility",
+          "capability": "billing.inspect_invoice",
+          "identity_from_arg": "invoice_id",
+          "version_column": "updated_at"
+        }
+      ]
+    }
+  }
+}
+```
+
+The top-level key is an existing proposal capability. `approval` must be
+`required`. Every dependency must reference an existing reviewed single-row
+read on the same source/context and map one bounded scalar proposal argument to
+that read's fixed lookup. The read capability supplies schema, table, primary
+key, tenant/principal keys, and source; the model cannot supply or widen them.
+At most 16 dependencies are allowed.
+
+The proposal target and dependencies are read again before every approval.
+Direct SQL apply locks and rechecks them again inside the source transaction.
+Strict freshness is rejected for app-owned and cross-source effects because
+Runner cannot make those checks atomic with the external effect.
+
+Use:
+
+```bash
+synapsor-runner proposals check-freshness latest --config ./synapsor.runner.json
+synapsor-runner doctor --check-writeback --config ./synapsor.runner.json
+```
+
+The complete validation, privilege, lifecycle, and error-code contract is in
+[Proposal And Evidence Freshness](proposal-evidence-freshness.md).
+
 ## Rate limits
 
 ```json