@synapsor/runner 1.6.2 → 1.6.4

package/docs/reviewed-database-views.md

@@ -0,0 +1,132 @@
+# Reviewed Database Views For Derived Measures
+
+Scoped Explore deliberately has no formula or expression language. The model
+cannot invent ratios, arithmetic, functions, subqueries, or joins. When a
+useful measure needs reviewed database logic, put that logic in a
+database-owned view and expose only the resulting typed column through a named
+Synapsor capability.
+
+The authority split is:
+
+```text
+Database owner reviews formula, joins, cardinality, and base-table scope
+  -> view publishes a small typed row shape
+  -> contract author reviews the view columns and fixed predicate
+  -> Runner applies trusted scope and the named aggregate
+  -> model receives one scalar, never SQL or member rows
+```
+
+This is an explicit escape hatch, not automatic generation. Auto Boundary
+blocks a view whose row identity cannot be proven from catalog metadata. Review
+the view definition, scope, uniqueness, and grants before hand-authoring a
+capability.
+
+## PostgreSQL Hardened Pattern
+
+Use a `security_invoker` view so PostgreSQL checks permissions and row-level
+security (RLS) as the Runner read role, not as the view owner. A
+`security_barrier` also prevents unsafe predicate movement across the view
+boundary.
+
+The retail clean-room fixture defines this reviewed ratio:
+
+```sql
+CREATE VIEW public.reviewed_order_performance
+WITH (security_barrier = true, security_invoker = true) AS
+SELECT
+  orders.id AS order_id,
+  orders.merchant_id,
+  orders.assigned_manager_id,
+  orders.region_id,
+  ROUND(
+    (orders.net_revenue_cents::numeric /
+      NULLIF(orders.gross_revenue_cents, 0)) * 10000
+  )::integer AS net_revenue_retention_basis_points
+FROM public.orders;
+```
+
+The formula is fixed in a reviewed database migration. The model sees only
+`net_revenue_retention_basis_points`. It cannot change the numerator,
+denominator, scale, or source relation.
+
+For `database_scope.mode = "postgres_rls"`, Runner accepts a read view only
+when all of these checks pass:
+
+- the target is a normal PostgreSQL view used for `SELECT`;
+- both `security_invoker=true` and `security_barrier=true` are present;
+- the Runner role is not the view owner, a superuser, or `BYPASSRLS`;
+- every referenced table or nested view can be resolved from the catalog;
+- every referenced base table independently passes the existing FORCE RLS,
+  role, policy-operation, and trusted-setting checks;
+- every nested view passes the same view checks.
+
+An ordinary owner-rights view, an unverifiable dependency, a missing RLS
+setting, or any non-read operation fails closed before MCP serving.
+
+## Named Aggregate
+
+The public DSL fixes the trusted scope, formula output, region, aggregate, and
+minimum cohort:
+
+```sql
+CREATE AGENT CONTEXT retail_analytics_context
+  BIND tenant_id FROM ENVIRONMENT SYNAPSOR_TENANT_ID REQUIRED
+  BIND principal FROM ENVIRONMENT SYNAPSOR_PRINCIPAL REQUIRED
+  TENANT BINDING tenant_id
+  PRINCIPAL BINDING principal
+END
+
+CREATE CAPABILITY retail.average_net_revenue_retention_pacific
+  DESCRIPTION 'Return the privacy-suppressed average net-to-gross revenue retention rate for Pacific orders assigned to the trusted manager.'
+  RETURNS HINT 'Returns one scalar average in basis points or a suppression result; never order rows.'
+  USING CONTEXT retail_analytics_context
+  SOURCE retail_postgres
+  ON public.reviewed_order_performance
+  PRIMARY KEY order_id
+  TENANT KEY merchant_id
+  PRINCIPAL SCOPE KEY assigned_manager_id
+  AGGREGATE READ AVG net_revenue_retention_basis_points
+  SELECT WHERE region_id = 'region-pacific'
+  MIN GROUP SIZE 5
+  REQUIRE EVIDENCE
+END
+```
+
+Validate, compile, validate the Runner config, and serve:
+
+```bash
+npx -y @synapsor/runner dsl validate \
+  ./average-retained-revenue.synapsor.sql --strict
+
+npx -y @synapsor/runner dsl compile \
+  ./average-retained-revenue.synapsor.sql \
+  --out ./average-retained-revenue.contract.json \
+  --strict
+
+npx -y @synapsor/runner config validate \
+  --config ./synapsor.runner.json
+
+npx -y @synapsor/runner mcp serve \
+  --config ./synapsor.runner.json
+```
+
+The runnable packaged recipe is under
+`examples/retail-clean-room/view-recipe/`. Its clean-room gate proves that the
+result is exactly `9000` basis points for the trusted fixture scope, includes
+no member rows, and does not change the source database.
+
+## Review Checklist
+
+1. Prove the view has one intended row per counted entity.
+2. Prove joins cannot multiply rows or silently double-count values.
+3. Apply tenant and, where required, principal scope to every base relation.
+4. Keep sensitive source columns out of the view output.
+5. Grant the Runner role only `SELECT` on the view and required base objects.
+6. Test same-tenant other-principal and cross-tenant denial.
+7. Test zero denominators, nulls, rounding, and numeric overflow.
+8. Keep cohort suppression and result limits in the Synapsor capability.
+9. Treat a changed view definition as reviewed authority drift.
+
+For complex or ambiguous calculations, keep the capability disabled until the
+database migration, contract, and expected results have all been reviewed
+together.

package/docs/reviewed-relationships.md

@@ -0,0 +1,245 @@
+# Reviewed Relationship Paths
+
+Synapsor Runner can answer bounded aggregate questions across related tables
+without exposing a general join planner or SQL. The relationship is authority:
+Runner proposes it from database catalog evidence, a human reviews it, and the
+activated boundary fixes its exact path and semantics.
+
+This feature is part of local, development/staging-only Scoped Explore.
+Production receives only named capabilities created through Protect This Query.
+
+## The Safety Rule
+
+A model may select an already activated relationship **by name**. It cannot
+provide a table name, join key, join type, relationship path, or SQL fragment.
+
+Runner accepts only:
+
+- one to three relationship paths in a protected capability;
+- one or two links per path;
+- inspected foreign-key links whose target key is unique;
+- `many_to_one` cardinality with `max_fan_out: 1`;
+- trusted tenant and, where configured, principal scope on every relation;
+- an explicit human choice for missing related rows.
+
+Runner refuses:
+
+- one-to-many and many-to-many paths;
+- relationships inferred only from similar column names;
+- ambiguous or unproven cardinality;
+- more than two links in one path;
+- a plan using more than three reviewed paths;
+- a relationship whose catalog proof or generation lock is stale;
+- a related table whose trusted scope cannot be enforced;
+- formulas, derived measures, free-form joins, and model-selected identifiers.
+
+These limits permit reviewed star-style analysis. For example, a sales fact can
+group by an activated store path and an activated category path without
+multiplying the counted sales rows.
+
+## Why Fan-Out Matters
+
+Suppose one `sales_facts` row points to one store. Joining the store cannot
+create more sales rows, so the relationship is many-to-one and has a maximum
+fan-out of one.
+
+By contrast, joining a sale to all of its line items can turn one sale into
+several rows. A naive `SUM(sales_facts.amount_cents)` would then overstate
+revenue. Runner refuses that one-to-many path instead of silently returning a
+plausible but wrong number.
+
+## Demand-Driven Review
+
+Auto Boundary may discover more proven relationships than a developer needs.
+They are not all activated automatically.
+
+The intended flow is:
+
+1. Activate the small starter boundary.
+2. Ask a bounded aggregate question.
+3. If the question needs an inactive but catalog-proven path, Runner refuses the
+   plan and identifies the exact path and proof.
+4. Workbench shows that one relationship for operator review.
+5. The operator chooses missing-row semantics when required and activates the
+   exact new boundary digest.
+6. Retry the original question.
+
+The model cannot trigger step 5. Adding the path creates new authority, so it is
+an operator-plane action with a new digest. Existing unrelated confirmations
+remain valid; only dependent review state is invalidated.
+
+## Nullable Links
+
+An optional foreign key requires an explicit business decision:
+
+- `UNMATCHED EXCLUDE`: omit a counted row when its related record is missing;
+- `UNMATCHED KEEP NULL`: keep the counted row and return an empty/null group
+  value for the missing relationship.
+
+This is not cosmetic. The choice can change totals and cohort sizes, so Runner
+does not silently choose it. The decision is stored in the canonical contract
+and bound into its digest.
+
+## DSL Syntax
+
+The SQL-like Domain-Specific Language (DSL) supports a legacy one-hop form and
+the additive path form. Existing legacy contracts retain their canonical bytes
+and digest.
+
+Legacy one-hop form:
+
+```sql
+PROTECTED RELATIONSHIP store
+  ON store_id
+  REFERENCES public.stores.id
+  PRIMARY KEY id
+  TENANT KEY tenant_id
+```
+
+Reviewed path form:
+
+```sql
+PROTECTED RELATIONSHIP store LINK 1
+  ON store_id
+  REFERENCES public.stores.id
+  PRIMARY KEY id
+  TENANT KEY tenant_id
+  UNMATCHED EXCLUDE
+
+PROTECTED RELATIONSHIP category LINK 1
+  ON product_id
+  REFERENCES public.products.id
+  PRIMARY KEY id
+  TENANT KEY tenant_id
+  UNMATCHED KEEP NULL
+
+PROTECTED RELATIONSHIP category LINK 2
+  ON category_id
+  REFERENCES public.categories.id
+  PRIMARY KEY id
+  TENANT KEY tenant_id
+  UNMATCHED EXCLUDE
+```
+
+In that example:
+
+- `store` and `category` are user-defined path names;
+- `LINK 1` and `LINK 2` are DSL keywords and ordered link numbers;
+- `store_id`, `product_id`, and `category_id` are inspected local keys;
+- `public.stores.id`, `public.products.id`, and `public.categories.id` are
+  fixed reviewed targets;
+- `PRIMARY KEY`, `TENANT KEY`, `UNMATCHED EXCLUDE`, and
+  `UNMATCHED KEEP NULL` are DSL syntax;
+- the two `category` declarations form one depth-two path.
+
+Link declarations for one path must be contiguous and ordered. A protected read
+cannot mix the legacy form with the path form.
+
+## Canonical Contract
+
+The path form compiles to public, language-neutral JSON:
+
+```json
+{
+  "protected_read": {
+    "mode": "aggregate",
+    "relationships": [
+      {
+        "name": "category",
+        "links": [
+          {
+            "local_key": "product_id",
+            "schema": "public",
+            "table": "products",
+            "target_key": "id",
+            "primary_key": "id",
+            "tenant_key": "tenant_id",
+            "cardinality": "many_to_one",
+            "max_fan_out": 1,
+            "unmatched_rows": "keep_null"
+          },
+          {
+            "local_key": "category_id",
+            "schema": "public",
+            "table": "categories",
+            "target_key": "id",
+            "primary_key": "id",
+            "tenant_key": "tenant_id",
+            "cardinality": "many_to_one",
+            "max_fan_out": 1,
+            "unmatched_rows": "exclude"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+Measures, dimensions, time buckets, and fixed predicates refer to the reviewed
+path name. The canonical Spec is not a generic SQL or analytics Abstract Syntax
+Tree (AST); it represents fixed reviewed authority.
+
+## Scope And Privacy
+
+For every participating relation, Runner injects trusted tenant and configured
+principal predicates outside model arguments. Scope on only the starting table
+is insufficient.
+
+Aggregate privacy controls continue to apply after relationships are added:
+
+- minimum cohort suppression;
+- maximum groups and response size;
+- query, rate, extraction, and differencing budgets;
+- fixed reviewed dimensions and measures;
+- no pagination that bypasses the group bound.
+
+Adding dimensions can make cohorts smaller, so suppression is evaluated on the
+final grouped result. A relationship does not weaken kept-out fields: kept-out
+fields cannot be selected, filtered, grouped, sorted, joined, or counted
+distinctly.
+
+## Protect For Production
+
+Protect This Query freezes the exact reviewed paths, measures, dimensions,
+filters, ordering, limits, scope, and privacy controls into a disabled named
+capability. A human activates its exact digest. Scoped Explore can then be
+disabled; the protected capability remains available.
+
+Production does not advertise broad Explore tools and does not permit the model
+to add relationship authority.
+
+## When A View Is Better
+
+Runner intentionally does not support:
+
+- arbitrary relationship graphs;
+- many-to-many analytics;
+- derived formulas such as `revenue / capacity`;
+- model-defined expressions;
+- general-purpose join planning.
+
+For those cases, create a database view that computes the reviewed business
+meaning, grant Runner's reader access only to the safe projected columns, and
+inspect the view as a new resource. See [Reviewed Database
+Views](reviewed-database-views.md).
+
+This keeps business formulas and complex joins under ordinary database and code
+review while preserving Synapsor's field, scope, budget, proposal, and audit
+boundary.
+
+## Verification
+
+The repository release gates exercise:
+
+```bash
+corepack pnpm test:reviewed-relationships
+corepack pnpm test:auto-boundary-explore:packed
+corepack pnpm test:clean-room:community-solar
+corepack pnpm test:clean-room:retail
+```
+
+The live PostgreSQL and MySQL relationship test proves direct star paths,
+depth-two paths, both nullable-link choices, demand-driven activation, drift
+refusal, per-relation tenant/principal scope, suppression, and rejection of a
+deliberately wrong fan-out relationship.

package/docs/rfcs/006-reviewed-reversible-change-sets.md

@@ -1,6 +1,6 @@
 # RFC 006: Reviewed Reversible Change Sets
 
-Status: implemented and verified for the prepared Runner 1.4 release line
+Status: implemented (originally verified for the Runner 1.4 release line)
 
 ## Problem
 

package/docs/runner-bundles.md

@@ -41,11 +41,11 @@ cd ./synapsor-runner-bundle
 cp .env.example .env
 set -a && . ./.env && set +a
 
-npx -y -p @synapsor/runner synapsor-runner contract validate ./synapsor.contract.json
-npx -y -p @synapsor/runner synapsor-runner config validate --config ./synapsor.runner.json
-npx -y -p @synapsor/runner synapsor-runner tools preview --config ./synapsor.runner.json --store ./.synapsor/local.db
-npx -y -p @synapsor/runner synapsor-runner cloud connect --config ./synapsor.cloud.json
-npx -y -p @synapsor/runner synapsor-runner mcp serve --config ./synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner contract validate ./synapsor.contract.json
+npx -y @synapsor/runner config validate --config ./synapsor.runner.json
+npx -y @synapsor/runner tools preview --config ./synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner cloud connect --config ./synapsor.cloud.json
+npx -y @synapsor/runner mcp serve --config ./synapsor.runner.json --store ./.synapsor/local.db
 ```
 
 For proposal contracts, run the trusted worker in a separate
@@ -53,14 +53,14 @@ operator-controlled terminal:
 
 ```bash
 set -a && . ./.env && set +a
-npx -y -p @synapsor/runner synapsor-runner start --config ./synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner start --config ./synapsor.runner.json --store ./.synapsor/local.db
 ```
 
 After an MCP tool creates a local proposal, sync its reviewed diff and safe
 references to Cloud:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner cloud sync latest \
+npx -y @synapsor/runner cloud sync latest \
   --config ./synapsor.cloud.json \
   --store ./.synapsor/local.db
 ```

package/docs/runner-config-reference.md

@@ -40,6 +40,9 @@ Unknown keys fail when `strict` is true (the default).
 | `rate_limits` | No | Operational fixed-window limits; fleet-wide only with shared `runtime_store`. |
 | `metrics` | No | Separately authorized scrapeable HTTP metrics. Disabled by default. |
 | `graduated_trust` | No | Off-by-default, operator-only policy recommendation criteria and kill switch. |
+| `generated_authority` | Generated projects | Generation-lock path and required drift enforcement for generated authority only. |
+| `supervised_worker` | No | Default-off exact-digest allowlist for trusted automatic execution of approved proposals. |
+| `notifications` | No | Default-off quiet attention routing to JSONL or signed HTTPS webhooks. |
 | `executors` | No | App-owned writeback wiring. |
 | `cloud` | Cloud mode | Scoped Cloud adapter configuration. |
 
@@ -499,6 +502,129 @@ 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).
 
+## Supervised worker
+
+`supervised_worker` is a separate deployment opt-in for automatic execution of
+already-approved proposals. It does not change `AUTO APPROVE`; old and new
+auto-approved proposals still wait for manual apply unless both the contract
+and this exact-digest allowlist permit worker execution.
+
+```json
+{
+  "supervised_worker": {
+    "enabled": true,
+    "profile": "production",
+    "capabilities": [
+      {
+        "capability": "billing.propose_small_credit",
+        "contract_digest": "sha256:EXACT_ACTIVE_DIGEST",
+        "mode": "supervised_worker",
+        "concurrency": 1,
+        "queue_limit": 100,
+        "lease_seconds": 60,
+        "max_attempts": 5,
+        "proposal_ttl_seconds": 3600,
+        "rate_limit": {
+          "executions": 20,
+          "window_seconds": 60
+        },
+        "write_url_env": "BILLING_POSTGRES_WRITE_URL",
+        "worker_identity": "billing_worker",
+        "control_role": "runner_operator",
+        "require_least_privilege_writer": true,
+        "writer_posture_fingerprint": "sha256:REVIEWED_POSTURE_DIGEST",
+        "required_attention_sinks": ["operations"]
+      }
+    ]
+  }
+}
+```
+
+`profile` is `development`, `staging`, or `production`. Production requires
+verified operator identity and hardened writer posture. Every entry binds
+capability name, active contract digest, worker mode, queue/concurrency/rate
+bounds, proposal TTL, writer credential reference, and optional fixed worker
+identity/control role.
+
+`required_attention_sinks` is optional and default-off. When present, an
+otherwise eligible job remains queued until every named enabled notification
+sink has a healthy delivery record. Sink health never grants approval or
+execution authority.
+
+The active capability must itself contain
+`execution.supervised_worker = "allowed"`, compile from `ALLOW SUPERVISED
+WORKER APPLY`, use direct single-row guarded INSERT/UPDATE, and satisfy the
+receipt, trusted-scope, conflict/deduplication, and eligibility checks. See
+[Operator-Supervised Automatic Apply](supervised-automatic-apply.md).
+
+## Notifications
+
+`notifications` routes immutable redacted attention events. It is absent or
+`enabled: false` by default and starts no background dispatcher.
+
+```json
+{
+  "notifications": {
+    "enabled": true,
+    "workbench_url_env": "SYNAPSOR_WORKBENCH_URL",
+    "sinks": [
+      {
+        "id": "operations",
+        "type": "webhook",
+        "url_env": "SYNAPSOR_NOTIFY_WEBHOOK_URL",
+        "signing_secret_env": "SYNAPSOR_NOTIFY_SIGNING_SECRET",
+        "minimum_severity": "warning",
+        "events": [
+          "proposal.review_required",
+          "worker.dead_lettered",
+          "worker.unknown_outcome"
+        ],
+        "environments": ["production"],
+        "delivery": "immediate",
+        "max_attempts": 5,
+        "timeout_ms": 3000,
+        "max_response_bytes": 1024,
+        "replay_window_seconds": 300,
+        "allow_private_destinations": false,
+        "recovery_notifications": false,
+        "budgets": {
+          "per_minute": 10,
+          "per_hour": 100,
+          "cooldown_seconds": 600,
+          "retry_attempt_threshold": 3,
+          "degraded_duration_seconds": 120,
+          "queue_depth_threshold": 100,
+          "queue_age_seconds": 300
+        },
+        "quiet_hours": {
+          "start_utc_hour": 22,
+          "end_utc_hour": 7
+        }
+      }
+    ]
+  }
+}
+```
+
+Sink `type` is `webhook` or `jsonl`. JSONL requires
+`destination: "stdout"` and accepts no URL/signing fields. Webhook URLs and
+32-byte-or-longer signing secrets come only from the named environment
+variables.
+
+`delivery` is `immediate`, `digest`, or `all`. Each sink can filter fixed event
+names, qualified capability names, environments, and minimum severity.
+Per-minute/hour budgets, informational budgets, aggregation windows, cooldown,
+unresolved reminders, digest cadence, escalation delay, retry/degraded
+thresholds, queue thresholds, UTC quiet hours, and opt-in recovery messages
+control interruption volume. Critical events bypass ordinary quiet hours and
+budgets but still coalesce.
+
+Private webhook destinations require both
+`allow_private_destinations: true` and an exact
+`private_host_allowlist`. See [Human Attention And
+Notifications](human-attention-notifications.md) for event classes, commands,
+signature verification, SSRF protections, and quiet-default behavior.
+
 ## Rate limits
 
 ```json
@@ -554,6 +680,12 @@ it. See [Graduated Trust Recommendations](graduated-trust.md).
 
 ## Operator identity
 
+For the complete lifecycle from public DSL `APPROVAL ROLE`, through IdP group
+mapping and JWT verification, to the immutable approval record and independent
+apply decision, use [Approval Roles And Verified Operator
+Identity](approval-roles-and-operator-identity.md). The examples below are the
+configuration summary; that guide contains the tested local OIDC/JWKS flow.
+
 Local development compatibility uses an explicitly unverified environment
 identity:
 

package/docs/running-a-runner-fleet.md

@@ -287,9 +287,17 @@ Use the shared queue explicitly:
 synapsor-runner proposals list --config ./synapsor.runner.json
 synapsor-runner proposals show latest --config ./synapsor.runner.json
 synapsor-runner ui --config ./synapsor.runner.json
-synapsor-runner worker run --yes --config ./synapsor.runner.json
+synapsor-runner worker run --supervised --yes \
+  --worker-id billing_worker --config ./synapsor.runner.json
 ```
 
+The supervised path is disabled by default and requires contract permission
+plus a deployment allowlist for the exact digest. Existing `AUTO APPROVE`
+contracts remain manual-apply after upgrade. Worker leases, policy reservations,
+writer posture, source/evidence freshness, idempotency receipts, and UNKNOWN
+outcome recovery are covered in [Operator-Supervised Automatic
+Apply](supervised-automatic-apply.md).
+
 Dead-letter operations require verified operator identity:
 
 ```bash
@@ -305,6 +313,13 @@ Requeue preserves history and refuses if a durable applied/already-applied
 receipt already proves the effect. Discard closes the queue item without
 deleting proposals, receipts, or events.
 
+Use `attention show` and the Workbench Human Attention Inbox to inspect
+review-required, stale, limit, dead-letter, UNKNOWN, and reconciliation states
+without copying proposal IDs. Optional external notifications are disabled and
+quiet by default. A signed generic webhook can route selected coalesced
+incidents; it cannot approve or mutate state. See [Human Attention And
+Notifications](human-attention-notifications.md).
+
 ## Backup, Restore, And Retention
 
 ```bash

package/docs/schema-api-candidates.md

@@ -1,6 +1,6 @@
 # Reviewed Candidates From Prisma, Drizzle, And OpenAPI
 
-Runner 1.6.0 uses these same bounded static parsers as evidence in the
+Runner 1.6.4 uses these same bounded static parsers as evidence in the
 whole-application [Auto Boundary](auto-boundary-and-scoped-explore.md) flow.
 The database catalog remains authoritative for database structure; Prisma,
 Drizzle, OpenAPI, and existing Synapsor definitions contribute deterministic

package/docs/security-boundary.md

@@ -42,6 +42,36 @@ The model does not receive:
 - MCP endpoint tokens, JWTs, refresh tokens, client secrets, or TLS keys;
 - trusted tenant or principal authority as ordinary model arguments.
 
+## Optional Workbench model client
+
+Workbench Ask is a local client of that same reviewed surface, not another
+policy engine. It is available only from authenticated loopback Workbench in an
+explicit development/staging profile. Its provider may request only the exact
+active named capabilities plus valid local authoring tools. The request is
+dispatched through the official MCP SDK and the existing typed-plan/runtime
+validators; there is no parallel query or mutation executor.
+
+The operator chooses provider, model, endpoint, and credential source and
+acknowledges direct egress for the current authority digest. No model output can
+change those values. Provider credentials and bounded conversation state stay
+in local server memory and are not written to the project, ledger, browser
+storage, logs, evidence, receipts, or replay. Reviewed tool results may be sent
+directly to the provider after consent; Synapsor does not relay them.
+
+Official remote providers use fixed HTTPS origins. Custom remote endpoints
+require HTTPS; plaintext is restricted to loopback. Redirects are refused,
+resolved destinations are checked and pinned on every connection, and
+private/link-local/metadata/special remote addresses are blocked. Unknown
+tools, malformed arguments/responses, authority drift, oversized data, time or
+tool-loop exhaustion, and reported source mutation fail closed.
+
+Provider prose remains untrusted. A write tool can create only the normal inert
+proposal, and the Workbench directs the human to the separate operator path.
+Ask never receives activation, Protect, approval, apply, worker, notification,
+attention, or reconciliation tools. It is absent from production,
+unknown-profile, shared, remote, and non-loopback surfaces. See [Workbench Ask
+With Your Model](workbench-ask.md).
+
 ## Network transport and identity
 
 Local stdio is the preferred one-client path. The MCP client launches Runner and
@@ -169,6 +199,20 @@ outside the model-facing MCP server and verifies:
 
 If any authority check cannot be verified, the write fails closed.
 
+Manual apply remains the default, including after policy auto-approval. An
+eligible single-row direct INSERT or UPDATE may instead use operator-supervised
+automatic apply, but only when the activated contract explicitly permits the
+trusted worker and the deployment independently allowlists the exact
+capability/digest. The model controls neither opt-in. The separately operated
+worker leases approved work and invokes the same guarded-apply implementation
+as manual apply; it repeats current approval, policy, limit, scope, freshness,
+generation-lock, writer-posture, idempotency, and receipt checks immediately
+before execution. Source or supporting-evidence drift causes zero mutation.
+Ambiguous transaction outcomes require reconciliation and are never blindly
+retried. Hard DELETE, reversible changes, set writes, and app-owned/external
+effects are excluded from this first automatic path. See
+[Operator-Supervised Automatic Apply](supervised-automatic-apply.md).
+
 Strict freshness is intentionally limited to same-database direct SQL
 writeback. Runner rejects app-owned or cross-source strict freshness because it
 cannot claim one atomic transaction around those effects. Cloud can govern an
@@ -218,6 +262,16 @@ controls are not MCP tools. The UI does not expose raw SQL, database URLs, or
 write credentials, and it does not let a model widen reviewed tables, columns,
 scope, policy, or executor authority.
 
+The authoritative store also records redacted human-attention events and
+projects related events into a secured Workbench inbox. External delivery is
+disabled and quiet by default. When an operator enables it, a separate
+dispatcher can route selected coalesced incidents to a JSONL development sink
+or signed HTTPS webhook. Delivery is at least once, redacted, budgeted, and
+observable. A notification, webhook response, inbox acknowledgement, delivery
+replay, or MCP update hint never activates, approves, applies, cancels,
+recovers, or mutates anything. The ledger and Workbench remain the source of
+truth. See [Human Attention And Notifications](human-attention-notifications.md).
+
 Contract lint and tests are review aids rather than a proof of complete
 security. Capability breadth can still drift as narrow tools accumulate;
 surface-fitness lint makes high-signal generic, dense, poorly named, and