@synapsor/runner 0.1.16 → 1.1.0

package/docs/README.md

@@ -6,6 +6,16 @@ no-database demo, wire your database, then read deeper concepts.
 
 ## 01 Quickstart
 
+- Audit a deliberately risky database MCP surface without cloning the repo or
+  connecting a database:
+
+  ```bash
+  npx -y @synapsor/runner audit --example dangerous-db-mcp
+  ```
+
+  Then use [MCP Audit](mcp-audit.md) to inspect your own tool manifest, remote
+  MCP endpoint, or stdio server. The audit is useful independently of whether
+  you adopt Runner.
 - [README](../README.md): audit-first proof, no-database demo, safety diagram,
   and the shortest own-database path.
 - [Troubleshooting First Run](troubleshooting-first-run.md): common first-run
@@ -98,9 +108,12 @@ no-database demo, wire your database, then read deeper concepts.
 
 - [Current Scope](current-scope.md): compact v0.1 scope summary.
 - [Current Limitations](limitations.md): intentional safety limits.
-- [Production-Candidate Guide](production.md): single-node OSS deployment
-  scope, database roles, receipt grants, local ledger backup, restart behavior,
-  Docker/systemd shapes, TLS, and release-gate expectations.
+- [Production-Candidate Guide](production.md): single-node and bounded-fleet
+  OSS deployment scope, database roles, receipt grants, restart
+  behavior, Docker/systemd shapes, TLS, and release-gate expectations.
+- [Running A Small Runner Fleet](running-a-runner-fleet.md): tested two-Runner
+  topology, claim-bound sessions, pools, fleet rate limits, quorum, metrics,
+  dead letters, backup/restore/retention, and kill/recovery evidence.
 - [Cloud Mode](cloud-mode.md): what stays local and what Cloud-linked mode adds.
 - [OSS Runner Vs Synapsor Cloud](oss-vs-cloud.md): detailed product and
   operational boundary.

package/docs/capability-authoring.md

@@ -136,6 +136,7 @@ reviewed runner JSON capabilities. Current parity:
 | proposal `transition_guards` | `TRANSITION status ALLOW pending -> approved\|rejected` or `TRANSITION status FROM current_status ALLOW open -> closed` | 0.1.8 | Values are state strings; use `|` for multiple target states. |
 | proposal `conflict_guard` | `CONFLICT GUARD updated_at` | 0.1 | If omitted, DSL emits an explicit weak-guard acknowledgement. Prefer a real row-version column. |
 | proposal `approval` | `APPROVAL ROLE billing_lead` | 0.1 | Local mode records the required role; enforcement is still outside the model-facing MCP tool. |
+| proposal `approval.required_approvals` | `REQUIRE 2 APPROVALS` | 1.1 | Optional 1..10 distinct-reviewer quorum; defaults to 1. |
 | proposal `writeback` | `WRITEBACK DIRECT SQL`, `WRITEBACK APP HANDLER EXECUTOR name`, `WRITEBACK CLOUD WORKER`, `WRITEBACK NONE` | 0.1.7 | Handler URLs/tokens stay in `synapsor.runner.json`; contracts carry only the handler name. |
 | evidence options | `REQUIRE EVIDENCE` | 0.1 | Detailed evidence sources/handle prefixes are not expressible in DSL yet; use embedded JSON or generated contract JSON for those. |
 
@@ -285,7 +286,7 @@ surface.
     "late_fee_cents": { "minimum": 0, "maximum": 10000 }
   },
   "conflict_guard": { "column": "updated_at" },
-  "approval": { "mode": "human", "required_role": "billing_lead" }
+  "approval": { "mode": "human", "required_role": "billing_lead", "required_approvals": 2 }
 }
 ```
 

package/docs/conformance.md

@@ -26,10 +26,15 @@ Current fixture groups:
 - `proposal-capability`
 - `kept-out-fields`
 - `manual-approval`
+- `auto-approval`
+- `aggregate-policy-limits`
+- `numeric-bounds`
 
 The fixture set is intentionally small in 0.1. It covers the runner-supported
 semantic surface first: trusted context, scoped reads, evidence handles,
 proposal boundaries, kept-out fields, manual approval, and replay envelopes.
+The aggregate-policy fixture additionally proves that reviewed daily ceilings
+fall back to human review atomically and record the limit that tripped.
 
 Additional 0.1 parity coverage currently lives in tests and verification
 scripts rather than separate `cloud-push/` or `dsl-json-parity/` conformance

package/docs/current-scope.md

@@ -2,7 +2,7 @@
 
 The canonical scope page is [Current Limitations](limitations.md).
 
-Current `0.1.x` scope:
+Current `1.1` scope:
 
 - local semantic MCP tools for Postgres/MySQL-backed business actions;
 - schema inspection and guided config generation;
@@ -12,8 +12,11 @@ Current `0.1.x` scope:
 - app-owned `http_handler` and `command_handler` executors for richer approved
   business transactions;
 - stdio MCP, Streamable HTTP MCP, and a small JSON-RPC bridge.
+- a bounded small-fleet shape with asymmetric claim-bound sessions, shared
+  Postgres review state, source pools, fleet rate limits, readiness, protected
+  metrics, verified quorum review, dead letters, and backup/restore/retention;
 
-Stable `0.1.x` compatibility covers the documented `synapsor-runner` binary,
+Stable `1.x` compatibility covers the documented `synapsor-runner` binary,
 config schema version `1`, result envelope v2 with v1 opt-out, stdio/Streamable
 HTTP MCP surfaces, documented MCP client snippets, proposal/evidence/replay
 inspection commands, direct SQL writeback, and app-owned executor contracts.
@@ -26,4 +29,5 @@ Out of scope:
 - generic multi-row SQL writeback;
 - physical branching of external Postgres/MySQL;
 - self-hosted Synapsor Cloud;
+- unbounded or multi-region shared-ledger scale and a managed Runner fleet;
 - production SLA or compliance certification.

package/docs/dsl-reference.md

@@ -148,7 +148,10 @@ patched column. Values may be identifiers or quoted strings.
 
 ```sql
   APPROVAL ROLE billing_lead
+  REQUIRE 2 APPROVALS
   AUTO APPROVE WHEN amount_cents <= 2500
+  LIMIT 20 PER DAY
+  LIMIT TOTAL 100000 PER DAY
   WRITEBACK DIRECT SQL
 ```
 
@@ -156,10 +159,32 @@ patched column. Values may be identifiers or quoted strings.
 approval identity is operator-provided; enterprise identity/RBAC belongs to the
 Cloud boundary.
 
+`REQUIRE n APPROVALS` is optional and accepts 1 through 10. It compiles to the
+canonical `approval.required_approvals` field. The default is 1. Each slot
+requires a distinct verified subject; duplicate subjects fail with
+`APPROVER_ALREADY_COUNTED`. Apply/workers remain blocked until `n/N`, rejection
+is terminal, and policy auto-approval is deferred when `n > 1`.
+
 `AUTO APPROVE WHEN field <= non_negative_integer` is supported only for a
 numeric patched field and must follow `APPROVAL ROLE`. Its maximum cannot exceed
 the field's `BOUND`. Policy approval still does not apply the write.
 
+Aggregate limits follow the auto-approval clause:
+
+```sql
+LIMIT 20 PER DAY
+LIMIT TOTAL 100000 PER DAY
+```
+
+`LIMIT n PER DAY` caps policy approvals for the trusted tenant and policy in
+the UTC calendar day. `LIMIT TOTAL n PER DAY` sums the policy's numeric patch
+field over the same scope. Use `PER OBJECT DAY` instead of `PER DAY` to scope a
+limit to one trusted tenant, policy, and business object. The check and approval
+are one atomic ledger transaction. When any ceiling would be exceeded, Runner
+leaves the proposal in `pending_review` and records
+`policy_auto_approval_deferred` with observed, proposed, and projected values.
+It does not reject or auto-apply the proposal.
+
 Writeback forms:
 
 | Clause | Meaning |

package/docs/http-mcp.md

@@ -70,7 +70,50 @@ cors: disabled
 sessions: in-memory
 ```
 
-Use `/mcp` as the MCP endpoint. Health is available at `/healthz`.
+Use `/mcp` as the MCP endpoint. Cheap process liveness is available at
+`/healthz`; dependency readiness is available at `/readyz`. When separately
+enabled and authorized, OpenMetrics is available at `/metrics`.
+
+## TLS And mTLS
+
+For a non-local long-running service, terminate TLS at a trusted proxy or start
+Runner with env-backed PEM material:
+
+```bash
+export SYNAPSOR_TLS_CERT_PEM="$(cat ./server.crt)"
+export SYNAPSOR_TLS_KEY_PEM="$(cat ./server.key)"
+
+synapsor-runner mcp serve-streamable-http \
+  --host 0.0.0.0 \
+  --port 8766 \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
+  --tls-cert-env SYNAPSOR_TLS_CERT_PEM \
+  --tls-key-env SYNAPSOR_TLS_KEY_PEM
+```
+
+To require client certificates:
+
+```bash
+export SYNAPSOR_TLS_CA_PEM="$(cat ./client-ca.crt)"
+
+synapsor-runner mcp serve-streamable-http \
+  --host 0.0.0.0 \
+  --port 8766 \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
+  --tls-cert-env SYNAPSOR_TLS_CERT_PEM \
+  --tls-key-env SYNAPSOR_TLS_KEY_PEM \
+  --tls-ca-env SYNAPSOR_TLS_CA_PEM \
+  --require-client-cert
+```
+
+The CLI reads PEM contents from environment variables and never prints them.
+Runner-owned mTLS currently protects the Streamable HTTP MCP boundary. For
+app-owned `http_handler` executors, terminate mTLS in your service mesh/proxy
+or handler process and keep bearer/signature checks enabled in the handler.
 
 ## Start The JSON-RPC Bridge
 
@@ -106,6 +149,7 @@ variable name. It does not print token values or database URLs.
 ```bash
 curl -i http://127.0.0.1:8766/healthz
 curl -i http://127.0.0.1:8765/healthz
+curl -i http://127.0.0.1:8766/readyz
 ```
 
 The health endpoint is secret-free:

package/docs/limitations.md

@@ -1,13 +1,21 @@
 # Limitations
 
-Synapsor Runner is intentionally narrow in the current alpha.
+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.
 
 ## Supported
 
 - Stdio MCP server for semantic database capabilities.
 - Local read and proposal tools.
-- Local SQLite evidence/proposal/query-audit/replay store.
-- Human approval through CLI commands.
+- Local SQLite evidence/proposal/query-audit/replay store by default.
+- Optional shared Postgres proposal/evidence/replay runtime store for MCP serving.
+- Asymmetric claim-bound Streamable HTTP sessions and explicit readiness.
+- 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.
+- Separately protected scrapeable metrics and dead-letter recovery commands.
+- Shared-ledger backup/digest verification, clean restore, and
+  archive-before-retention.
 - Public protocol objects:
   - `synapsor.change-set.v1`
   - `synapsor.writeback-job.v1`
@@ -55,7 +63,8 @@ truth for the model-facing tools.
 - Model-callable approval or commit tools.
 - Generic MCP firewall behavior.
 - Prompt-injection prevention.
-- High availability, SLA, compliance certification, or production support guarantee.
+- Unbounded/high-throughput or multi-region ledger scale.
+- Managed fleet, SLA, compliance certification, or production support guarantee.
 
 ## Important External Database Semantics
 
@@ -77,9 +86,15 @@ It does not mean external Postgres/MySQL time travel. Runner cannot reconstruct
 arbitrary historical rows that were never captured as evidence, and it does not
 provide `AS OF` queries over an external source.
 
-Local search is single-node SQLite search over the local runner store. It is
-useful for local/dev/staging usage. It is not a hosted central evidence ledger,
-not cross-runner aggregation, not RBAC/SSO, and not compliance retention.
+Local search uses SQLite by default. In `runtime_store` mode, CLI/UI reads can
+inspect one bounded shared Postgres ledger across a small fleet. This is still
+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
+Fleet](running-a-runner-fleet.md).
 
 Use this wording:
 

package/docs/migrating-to-synapsor-spec.md

@@ -127,6 +127,27 @@ Then keep only local wiring in `synapsor.runner.json`.
 }
 ```
 
+## 1.1 Approval Quorum
+
+Existing contracts remain valid and require one approval. To require distinct
+verified reviewers, add the optional canonical field:
+
+```json
+{
+  "proposal": {
+    "approval": {
+      "mode": "human",
+      "required_role": "billing_lead",
+      "required_approvals": 2
+    }
+  }
+}
+```
+
+The equivalent DSL is `REQUIRE 2 APPROVALS` after `APPROVAL ROLE
+billing_lead`. Runner 1.0 does not understand this new optional semantic field;
+use Runner/spec/DSL 1.1 together. Omitted fields preserve 1.0 behavior.
+
 ## Validate
 
 ```bash

package/docs/oss-vs-cloud.md

@@ -6,7 +6,8 @@ contract, but they solve different operational problems.
 Runner is the open-source runtime that stays next to your application and
 database. It serves reviewed MCP tools, binds trusted context, stores local
 evidence and proposals, keeps approval outside MCP, applies or routes approved
-writeback, and records receipts and replay in a local SQLite ledger.
+writeback, and records receipts and replay in the default local SQLite ledger
+or an opt-in shared Postgres runtime store.
 
 Cloud is the team control plane. It stores versioned contracts, produces
 downloadable Runner bundles, and provides shared activity, evidence, approval,
@@ -18,12 +19,12 @@ and investigation surfaces for enabled design-partner deployments.
 | Contract source | Local files reviewed in Git | Shared registry with immutable versions and digests |
 | Trusted context | Local environment/session bindings | Registered bindings plus deployment-specific Cloud session context |
 | Capabilities | Local semantic MCP tools | Registry, version history, and capability inspection |
-| Evidence and replay | Local SQLite ledger | Shared activity and evidence surfaces where enabled |
+| 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 |
 | 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 | Design-partner operation; no enterprise SLA in the current beta |
+| Operations | Customer-operated single node or bounded small fleet | Managed fleet remains Cloud work; no enterprise SLA in the current beta |
 
 ## What Stays Local
 

package/docs/production.md

@@ -14,10 +14,36 @@ MCP agent
 -> receipt/replay
 ```
 
-Use this only for bounded database workflows where you can accept a single-node
-local ledger and local/operator approval. Use Synapsor Cloud when you need HA,
-central audit, RBAC/SSO, multi-reviewer approvals, hosted retention, managed
-runners, policy packs, or production support/SLA.
+Use this only for bounded database workflows using either the default
+single-node SQLite ledger or the tested, serialized small-fleet Postgres
+runtime store. Use Synapsor Cloud when you need a managed fleet, hosted central
+audit, organization administration, SSO/SCIM, compliance retention, or a
+production support/SLA. See [Running A Small Runner
+Fleet](running-a-runner-fleet.md) for the exact OSS fleet guarantees and limits.
+
+## Audit The Agent-Facing Surface First
+
+Before configuring writeback or connecting a production-like database, audit
+the MCP tools the agent can see. Start with Runner's built-in risky database MCP
+example:
+
+```bash
+npx -y @synapsor/runner audit --example dangerous-db-mcp
+```
+
+Then audit the actual manifest, remote MCP endpoint, or stdio server you intend
+to expose:
+
+```bash
+synapsor-runner audit ./tools-list.json
+synapsor-runner audit https://mcp.example.com --bearer-env MCP_AUDIT_TOKEN
+synapsor-runner audit 'stdio:node ./server.mjs'
+```
+
+Audit is a static risk review, not proof that an MCP server is secure. Treat
+generic SQL/query tools, model-controlled tenant or principal fields, and
+model-facing approval/apply tools as deployment blockers. See [MCP
+Audit](mcp-audit.md) for supported inputs, findings, and machine-readable output.
 
 ## Supported Scope
 
@@ -27,6 +53,11 @@ Production-candidate OSS scope:
 - trusted context from environment/session values, not model arguments;
 - local SQLite ledger for evidence, query audit, proposals, receipts, replay,
   and lifecycle events;
+- bounded shared Postgres runtime ledger for several claim-bound HTTP Runner
+  instances and verified reviewers;
+- 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;
 - app-owned `http_handler` or `command_handler` executors for richer approved
   business transactions;
@@ -37,8 +68,8 @@ Out of scope:
 - raw `execute_sql` or model-generated SQL;
 - generic direct `INSERT`, `DELETE`, `UPSERT`, DDL, or multi-row SQL writeback;
 - physical branching of external Postgres/MySQL;
-- workflow DAGs, auto-merge/settlement, RBAC/SSO, HA ledger, or compliance
-  retention;
+- workflow DAGs, auto-merge/settlement, hosted team administration, SSO/SCIM,
+  multi-region ledger replication, or compliance retention;
 - making prompt injection impossible.
 
 ## Database Roles
@@ -150,12 +181,172 @@ Useful commands:
 ```bash
 synapsor-runner store stats --store ./.synapsor/local.db
 synapsor-runner events tail --store ./.synapsor/local.db --follow
+synapsor-runner metrics show --store ./.synapsor/local.db
 synapsor-runner store prune --store ./.synapsor/local.db --older-than 30d --dry-run
 synapsor-runner store vacuum --store ./.synapsor/local.db
 ```
 
 Details: [Store Lifecycle](store-lifecycle.md).
 
+## Shared Postgres Ledger Setup
+
+The default runtime ledger is SQLite. For shared deployments, Runner now ships a
+Postgres ledger setup surface that creates the schema used for shared audit
+entries, proposal locks, and worker leases:
+
+```bash
+export SYNAPSOR_LEDGER_DATABASE_URL="postgresql://ledger_writer:..."
+
+synapsor-runner store shared-postgres migration --schema synapsor_runner
+synapsor-runner store shared-postgres apply-migration \
+  --url-env SYNAPSOR_LEDGER_DATABASE_URL \
+  --schema synapsor_runner \
+  --yes
+synapsor-runner store shared-postgres status \
+  --url-env SYNAPSOR_LEDGER_DATABASE_URL \
+  --schema synapsor_runner
+synapsor-runner store shared-postgres sync \
+  --store ./.synapsor/local.db \
+  --url-env SYNAPSOR_LEDGER_DATABASE_URL \
+  --schema synapsor_runner \
+  --yes
+synapsor-runner store shared-postgres restore \
+  --store ./.synapsor/restored.db \
+  --url-env SYNAPSOR_LEDGER_DATABASE_URL \
+  --schema synapsor_runner \
+  --yes
+```
+
+These commands do not print the database URL. `sync` upserts a stable snapshot
+of the local proposal/evidence/replay ledger into Postgres for shared audit,
+backup, and retention. `restore` rebuilds a local SQLite store from those
+shared ledger entries for recovery or offline investigation.
+
+Runner supports two shared Postgres modes:
+
+- `mirror`: bounded CLI mutations restore from Postgres into local SQLite,
+  mutate locally, then sync back under a schema-scoped advisory lock.
+- `runtime_store`: MCP serving uses Postgres as the primary
+  proposal/evidence/replay store instead of opening a local SQLite store.
+
+Local SQLite remains the default. Use `runtime_store` when several MCP sessions
+or runner processes need to share proposal/evidence/replay state through one
+ledger database. Use `mirror` when you want bounded operator handoff while still
+running CLI mutations against a local SQLite file.
+
+Mirror mode config:
+
+```json
+{
+  "storage": {
+    "sqlite_path": "./.synapsor/local.db",
+    "shared_postgres": {
+      "mode": "mirror",
+      "url_env": "SYNAPSOR_LEDGER_DATABASE_URL",
+      "schema": "synapsor_runner",
+      "lock_timeout_ms": 10000,
+      "max_entries": 10000
+    }
+  }
+}
+```
+
+```bash
+export SYNAPSOR_LEDGER_DATABASE_URL="postgresql://ledger_writer:..."
+
+synapsor-runner doctor \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+
+synapsor-runner propose support.propose_plan_credit --sample \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+
+synapsor-runner proposals approve latest --yes \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+
+synapsor-runner apply --all-approved --yes \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+When `storage.shared_postgres.mode` is `mirror`, `doctor` checks that the
+ledger URL environment variable is present and that `ledger_entries`,
+`proposal_locks`, `worker_leases`, and `rate_limit_buckets` exist in the
+configured schema. It reports
+environment variable names and table readiness only; it does not print database
+URLs or initialize the schema.
+
+Mirror mode restores the Postgres ledger into the local store before a mutation
+and syncs the local store back after the command, including failure events when
+they were recorded locally. While it runs, Runner holds a schema-scoped
+Postgres advisory lock so concurrent mirror-mode operators do not restore,
+mutate, and sync over one another. The default lock wait is 10 seconds; tune it
+with `--shared-ledger-lock-timeout-ms` or
+`SYNAPSOR_SHARED_LEDGER_LOCK_TIMEOUT_MS`.
+
+Mirror mode is explicit because the local SQLite store still executes the CLI
+mutation. It is useful for bounded operator workflows and finite workers
+(`worker run --once` or `--drain`); use `runtime_store` for long-lived MCP
+serving and shared worker loops that need one proposal/evidence/replay ledger.
+
+Runtime-store mode config:
+
+```json
+{
+  "storage": {
+    "shared_postgres": {
+      "mode": "runtime_store",
+      "url_env": "SYNAPSOR_LEDGER_DATABASE_URL",
+      "schema": "synapsor_runner",
+      "lock_timeout_ms": 10000
+    }
+  }
+}
+```
+
+When MCP serving starts in `runtime_store` mode, Runner opens the Postgres URL
+from `url_env`, auto-runs the shared-ledger migration, and serializes runtime
+mutations with a transaction-scoped advisory lock. The MCP tools still expose no
+database URLs or write credentials to the model.
+
+`runtime_store` covers MCP serving, CLI approval/apply, and supervised worker
+runs. For CLI mutations, Runner restores the shared ledger into a temporary
+local store while holding the Postgres advisory lock, runs the existing local
+mutation, then syncs the resulting ledger entries back to Postgres. A
+long-running `worker run --yes` repeats bounded drain cycles under that lock
+and sleeps between idle polls, so multiple workers can share one Postgres ledger
+without holding the lock while idle.
+
+The current bridge loads a bounded snapshot and serializes each mutation. It
+fails closed above `max_entries`; it is not an unbounded scalable database
+engine. `proposals`, `evidence`, `query-audit`, `receipts`, `replay`,
+`activity`, `metrics`, worker status, and the local UI can read the same shared
+queue with `--config`. Back up, verify, restore, and archive-before-retention
+with the commands in [Running A Small Runner Fleet](running-a-runner-fleet.md).
+
+For unattended policy-approved queues, declare reviewed aggregate `LIMIT`
+clauses first, then use the explicit batch command:
+
+```bash
+synapsor-runner apply --all-approved --yes \
+  --config ./synapsor.runner.json --store ./.synapsor/local.db \
+  --capability support.propose_plan_credit --tenant acme --max 20
+```
+
+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.
+
+Runner writes newline-delimited JSON events to stderr for model-facing tool
+rejections, operator decisions, and terminal writeback outcomes. These events
+contain safe codes and identifiers, never tool arguments, row values, database
+URLs, tokens, private keys, or free-form driver errors. Prometheus/OpenMetrics
+counters are available with `metrics show` and are grouped by trusted tenant
+and reviewed capability.
+
 ## Restart And Recovery
 
 Runner stores proposal/evidence/replay state before writeback.
@@ -183,7 +374,26 @@ synapsor-runner activity search --proposal wrp_... --store ./.synapsor/local.db
 ### Docker Compose Shape
 
 Use Compose to run the MCP server next to your app and database network. Keep
-secrets in environment variables or your platform secret manager.
+secrets in environment variables or your platform secret manager. To hydrate
+Runner env vars from AWS Secrets Manager at startup, pass a JSON map through
+`SYNAPSOR_SECRET_MAP`:
+
+```bash
+export SYNAPSOR_SECRET_MAP='{
+  "SYNAPSOR_DATABASE_READ_URL": "prod/synapsor/runner#read_url",
+  "SYNAPSOR_DATABASE_WRITE_URL": "prod/synapsor/runner#write_url",
+  "SYNAPSOR_RUNNER_HTTP_TOKEN": "prod/synapsor/runner#http_token"
+}'
+
+synapsor-runner mcp serve-streamable-http \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --secrets-provider aws-secretsmanager-cli \
+  --secret-map-env SYNAPSOR_SECRET_MAP
+```
+
+The AWS provider shells out to `aws secretsmanager get-secret-value`; the runner
+logs only how many target env vars were loaded or skipped.
 
 ```yaml
 services:
@@ -256,6 +466,8 @@ synapsor-runner config validate --config synapsor.runner.json
 synapsor-runner doctor --config synapsor.runner.json --report --redact --output synapsor-doctor.md
 synapsor-runner doctor --config synapsor.runner.json --check-writeback
 synapsor-runner tools preview --config synapsor.runner.json --store ./.synapsor/local.db
+curl --fail http://127.0.0.1:8766/healthz
+curl --fail http://127.0.0.1:8766/readyz
 ```
 
 Doctor reports should be redacted by default before sharing. They must not

package/docs/release-notes.md

@@ -1,7 +1,7 @@
 # Release Notes
 
-These notes track public Synapsor Runner behavior. Starting with `0.1.0`, the
-normal install path uses the untagged stable package:
+These notes track public Synapsor Runner behavior. Starting with `1.0.0`, the
+documented production-loop compatibility line uses the untagged stable package:
 
 ```bash
 npx -y -p @synapsor/runner synapsor-runner demo --quick
@@ -10,7 +10,48 @@ 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.
 
-## Unreleased
+## 1.1.0 (prepared, not published)
+
+### Bounded Small-Fleet Runtime
+
+- Fixes claim/context authority conflicts before serving and keeps
+  object-filtered receipts/activity scoped to the requested object.
+- Adds asymmetric session/operator identity, readiness, protected HTTP
+  metrics, bounded native source pools, and shared fleet rate limits.
+- Adds portable distinct-reviewer quorum in the OSS canonical spec and DSL.
+  Existing 1.0 contracts still default to one approval. Cloud/C++ enforcement
+  of this optional field is not claimed until independently verified there.
+- Adds bounded shared-ledger CLI/UI review, startup-safe schema migration,
+  dead-letter recovery, backup/restore/retention, and tested worker recovery
+  before write and after durable commit.
+- 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`,
+`@synapsor/dsl@1.1.0`, and `@synapsor/runner@1.1.0`.
+
+## 1.0.0
+
+### Production Approval Loop
+
+- Adds batch apply for approved proposals with independent per-proposal
+  outcomes, rerun-safe idempotency, and `--capability`, `--tenant`, and
+  `--max` filters.
+- Adds aggregate policy ceilings to canonical contracts and DSL authoring so
+  small proposals fall back to human review once daily count or total limits are
+  reached.
+- Adds signed operator-key approval/apply enforcement, tamper-evident approval
+  records, operational counters/logs, and a supervised local writeback worker.
+- Adds shared Postgres ledger support, runtime-store mode, per-session trusted
+  context, managed secret hydration, token rotation hooks, and Streamable HTTP
+  mTLS for scale-out deployments.
+- Keeps local SQLite as the default while allowing runtime-store workers to run
+  long-lived shared ledger drain loops under a Postgres advisory lock.
+- Declares the first semver contract for the documented CLI, schema, contract,
+  MCP result, writeback, approval, metrics, and replay surfaces.
+
+Prepared package versions: `@synapsor/spec@1.0.0`,
+`@synapsor/dsl@1.0.0`, and `@synapsor/runner@1.0.0`.
 
 ## 0.1.16
 
@@ -478,10 +519,9 @@ not change and must not be republished for this release.
 
 ## Stable Release Policy
 
-Use untagged `@synapsor/runner` for stable installs. Use `@alpha` or an exact
-prerelease only when intentionally testing preview behavior. Stable `0.1.x`
-releases should keep the compatibility promise documented in
-`docs/release-policy.md`.
+Use untagged `@synapsor/runner` for stable installs. Use an exact prerelease
+only when intentionally testing preview behavior. Stable `1.x` releases should
+keep the compatibility promise documented in `docs/release-policy.md`.
 
 The first stable `0.1.0` release was gated on: