@synapsor/runner 1.6.1 → 1.6.3

package/docs/README.md

@@ -18,6 +18,10 @@ no-database demo, wire your database, then read deeper concepts.
   you adopt Runner.
 - [README](../README.md): audit-first proof, no-database demo, safety diagram,
   and the shortest own-database path.
+- [Database To First Safe Tool](guided-onboarding.md): one public command,
+  five-minute first read, ten-minute Explore to Protect, fifteen-minute
+  proposal, resumable setup, guarded development writeback, and host-neutral
+  client handoff.
 - [Troubleshooting First Run](troubleshooting-first-run.md): common first-run
   failures, redacted diagnostics, and fixes.
 
@@ -47,6 +51,8 @@ no-database demo, wire your database, then read deeper concepts.
 
 ## 04 Connect Your DB
 
+- [Database To First Safe Tool](guided-onboarding.md): the complete
+  review-by-exception golden path using the packed npm package.
 - [Auto Boundary, Scoped Explore, And
   Protect](auto-boundary-and-scoped-explore.md): deterministically inspect a
   whole staging application, review one digest-bound boundary, ask bounded row
@@ -95,6 +101,9 @@ no-database demo, wire your database, then read deeper concepts.
 - [Capability Authoring](capability-authoring.md): define read/proposal
   capabilities, model-facing descriptions, result envelopes, trusted context,
   and writeback guards.
+- [Approval Roles And Verified Operator Identity](approval-roles-and-operator-identity.md):
+  trace `APPROVAL ROLE` through IdP claims, immutable approval evidence, and
+  the independent apply-role decision.
 - [DSL Reference](dsl-reference.md): complete supported grammar, clause order,
   compiled meaning, and constraints.
 - [Runner Config Reference](runner-config-reference.md): every public wiring
@@ -141,6 +150,14 @@ no-database demo, wire your database, then read deeper concepts.
 
 - [Local Mode](local-mode.md): local store, proposals, approval, replay, and
   writeback flow.
+- [Operator-Supervised Automatic Apply](supervised-automatic-apply.md):
+  separate approval from execution, require contract and deployment opt-in for
+  one exact digest, run the trusted worker, and understand revalidation,
+  eligibility, retries, controls, and UNKNOWN outcomes.
+- [Human Attention And Notifications](human-attention-notifications.md):
+  durable attention events, the no-ID Workbench inbox, quiet defaults,
+  coalescing and digests, signed generic webhooks, delivery recovery, and the
+  optional supervision-health gate.
 - [Shadow Studies](shadow-studies.md): compare what an agent would propose
   with explicit authorized outcomes before granting write authority.
 - [Writeback Executors](writeback-executors.md): app-owned writeback handlers
@@ -162,8 +179,11 @@ no-database demo, wire your database, then read deeper concepts.
 - [Store Lifecycle](store-lifecycle.md): active-store leases, prune safety,
   deleted-store behavior, and concurrent server guardrails.
 - `synapsor-runner activity search`, `evidence`, `query-audit`, `receipts`,
-  `events tail`, and `events webhook`: local evidence, audit, receipt, replay,
-  and lifecycle inspection.
+  `events tail`, `attention show`, and `notifications status`: local evidence,
+  audit, receipt, replay, complete lifecycle history, and human-attention
+  inspection. The legacy development lifecycle webhook remains documented in
+  [Local Mode](local-mode.md); production attention delivery uses the signed,
+  quiet notification pipeline.
 - `examples/mysql-refund-agent/`: MySQL order/refund review example using the
   same proposal, approval, guarded writeback, and replay loop.
 - [Scoped Ledger Reports](compliance-reports.md): object/principal JSON,

package/docs/agent-guided-setup.md

@@ -0,0 +1,239 @@
+# Agent-Guided Synapsor Setup
+
+This guide lets Claude Code, Codex, Cursor, or another coding agent help a
+developer set up Synapsor Runner without taking over a human security decision.
+It uses the same local-first flow a developer runs directly. No Synapsor
+account, Cloud login, model API key, global installation, or database
+replication is required.
+
+## Copyable Prompt
+
+```text
+Set up Synapsor Runner for this project.
+
+Use DATABASE_URL from my environment. Run the setup yourself and explain each
+step briefly. Stop only when I must review the data boundary or make another
+human-authority decision. Never ask me to paste credentials into chat, and
+never activate, approve, or apply anything for me.
+
+Finish by driving one safe tool, showing what the agent can and cannot access,
+and giving me the MCP configuration for my client.
+```
+
+## Rules For The Coding Agent
+
+The coding agent may inspect project files, check tool availability, run the
+documented CLI, explain failures, and resume completed work.
+
+The coding agent must not:
+
+- ask the user to paste a database URL, password, token, or private key into
+  chat;
+- print or persist the value of `DATABASE_URL` or another credential;
+- choose a tenant or principal boundary;
+- decide that a sensitive or uncertain field is safe to expose;
+- activate an exploration boundary or named capability;
+- approve, reject, apply, reconcile, or revert a proposal;
+- run writeback setup with `--apply`;
+- weaken a failed role, RLS, schema-lock, profile, or transport check;
+- replace an existing generated project or use `--force` without a human
+  choosing the destructive path;
+- fetch or execute setup code other than the documented npm package command.
+
+The model-facing MCP surface never contains activation, approval, or apply
+tools. A coding agent operating the terminal must preserve the same separation.
+
+## Guided Procedure
+
+### 1. Verify Local Prerequisites
+
+Run:
+
+```bash
+node --version
+test -n "${DATABASE_URL:-}"
+npx -y @synapsor/runner@latest --version
+```
+
+Do not run `echo "$DATABASE_URL"` or otherwise reveal its value. Runner
+requires Node 22.13 or newer.
+
+Report one sentence:
+
+```text
+Node, the Runner package, and an exported DATABASE_URL are available.
+Next: inspect metadata and open the local boundary review.
+```
+
+If `DATABASE_URL` is absent, stop and say:
+
+```text
+DATABASE_URL is not exported in this shell. Export it locally, without pasting
+it into chat, then ask me to continue.
+```
+
+### 2. Start Or Resume The Guided Project
+
+From the intended project directory, run:
+
+```bash
+npx -y @synapsor/runner@latest start --from-env DATABASE_URL
+```
+
+For a fresh interactive project, Runner performs metadata-only inspection,
+creates disabled review artifacts, validates the generated project, initializes
+the local ledger, and starts the secured loopback Workbench. It prints one
+local URL if a browser cannot be opened.
+
+For an existing guided project, the same command resumes it. Resume and Try do
+not rescan the database, rewrite files, or change a digest. Do not add
+`--force`. A schema rescan or reset is a separate human choice in Workbench.
+
+Report:
+
+```text
+Runner created or resumed a disabled local boundary. No source rows were read
+and the database was not changed.
+Next: review the security exceptions in Workbench.
+```
+
+Then stop. The human must review:
+
+- fields kept out and fields still uncertain;
+- exact row identity;
+- trusted tenant and principal scope;
+- aggregate-safe dimensions and measures;
+- database-role and RLS posture;
+- the exact digest being activated.
+
+Do not click or call activation endpoints for the user.
+
+### 3. Continue After Human Activation
+
+After the user confirms that Workbench shows an active reviewed boundary,
+continue in the same Workbench session. The built-in Explore form performs the
+first bounded read and PM-style aggregate without SQL or plan JSON.
+
+The coding agent may verify the active local surface without copying an opaque
+handle:
+
+```bash
+npx -y @synapsor/runner@latest try call --list --format json
+```
+
+If no named capability is active yet, that is expected: a temporary local
+Scoped Explore boundary is not a production named tool. Ask the user to run the
+suggested aggregate in Workbench and select **Protect this analysis**.
+
+Protect creates public DSL, canonical JSON, tests, and a disabled named
+capability. Stop again for exact-digest human activation. Do not activate it
+for the user.
+
+### 4. Verify The First Named Tool
+
+After the human activates a protected named capability, run:
+
+```bash
+npx -y @synapsor/runner@latest try call --list --format json
+```
+
+Use the tool name returned by that command. For a tool with generated sample
+input, run:
+
+```bash
+npx -y @synapsor/runner@latest try call <tool-name> --sample --json
+```
+
+Do not invent tenant or principal arguments. Trusted scope comes from the
+reviewed environment/session binding outside model input.
+
+Report:
+
+```text
+Your first safe named tool is working.
+The result used only reviewed fields and trusted scope.
+Source database changed: no.
+Next: connect the same reviewed tool surface to your MCP client.
+```
+
+### 5. Present MCP Setup
+
+Workbench displays ready-to-copy configurations for:
+
+- Cursor project MCP;
+- Claude-compatible local stdio MCP;
+- Codex;
+- generic stdio MCP.
+
+All hosts launch the same reviewed Runner project. None receives a broader
+authority surface.
+
+For a terminal-rendered generic configuration, run:
+
+```bash
+npx -y @synapsor/runner@latest mcp config --absolute-paths
+```
+
+Do not write into a client configuration without explicit user consent. Cursor
+has a separate consent-gated installer:
+
+```bash
+npx -y @synapsor/runner@latest mcp install cursor --project --dry-run
+```
+
+Show the dry-run result first. Installation remains a human choice.
+
+## Guided Write Action
+
+After the first safe read, Workbench can generate one bounded write action.
+Schema structure supplies candidates only. The human decides business intent,
+allowed fields, values or transitions, trusted scope, version guard, reviewer,
+limits, optional bounded policy approval, receipt mode, and compensation.
+
+The generated action starts disabled. Its first model-facing call creates an
+exact proposal and must say:
+
+```text
+Proposal created.
+Source database changed: no.
+The model cannot approve or apply this proposal.
+```
+
+Stop at action activation, proposal approval, writeback setup, apply, and
+revert. Those are human or trusted-operator decisions outside MCP.
+
+Manual apply is the default. An operator may separately configure
+digest-bound supervised execution for eligible production actions. In that
+mode, the response must disclose that reviewed policy may approve and a trusted
+worker may later apply the proposal without a per-request click. The coding
+agent still cannot enable, start, pause, configure, or control that worker. See
+[Operator-Supervised Automatic Apply](supervised-automatic-apply.md).
+
+## Recovery
+
+Use the one next action Runner prints. Preserve the current project and review
+state.
+
+| Failure | Required response |
+| --- | --- |
+| Connection failed | Confirm the local environment variable and network path without printing the credential, then rerun `start`. |
+| Privileged, writable, owner, `BYPASSRLS`, or unverifiable read role | Stop source-row exploration. Ask the user to supply a verifiably read-only role. |
+| Tenant, principal, or row identity unresolved | Stop and direct the human to the highlighted Workbench exception. |
+| Sensitive field blocked | Keep it out unless a human records a reasoned field decision. |
+| Existing generated project | Run the same `start` command and choose Resume. Do not use `--force`. |
+| Stale generation lock | Preserve active named capabilities; choose Rescan and review changes. |
+| Workbench port unavailable | Use the single alternate loopback URL Runner prints or free the occupied local port. |
+| Writeback prerequisites missing | Keep the proposal unchanged. Use `writeback setup` for a preview only and stop for human review. |
+
+## What The Developer Should Understand
+
+At the end, ask the developer to explain these four facts:
+
+1. The model never receives raw SQL authority.
+2. Reads are limited to reviewed fields under trusted tenant and principal
+   scope.
+3. Model-facing writes create proposals rather than committing changes.
+4. The model cannot activate authority, approve proposals, or apply writes.
+
+If any answer is unclear, reopen the Workbench Overview. Do not expand authority
+to make onboarding appear successful.

package/docs/approval-roles-and-operator-identity.md

@@ -0,0 +1,353 @@
+# Approval Roles And Verified Operator Identity
+
+This guide explains how a role written in a Synapsor capability becomes a
+verified human approval. The short version is:
+
+```text
+Contract says who may approve
+  -> identity provider says who the operator is and which groups they hold
+  -> Runner verifies a fresh token and exact role
+  -> ledger records the exact decision without storing the bearer token
+  -> a separate verified operator authorizes apply
+```
+
+Approval and apply are outside the model-facing MCP tool surface. An agent
+cannot supply an operator token, select its own role, approve a proposal, or
+commit a write.
+
+## What `APPROVAL ROLE` Means
+
+This public DSL:
+
+```sql
+CREATE CAPABILITY membership.freeze_membership
+  ...
+  APPROVAL ROLE membership_reviewer
+  ...
+;
+```
+
+means that an operator approving this capability's proposal must have the exact
+role string `membership_reviewer` in a verified identity.
+
+`membership_reviewer` is an author-chosen Synapsor contract role. It is not:
+
+- a PostgreSQL role;
+- an operating-system user or group;
+- an MCP or model role;
+- an API key or secret;
+- permission to apply the write.
+
+The contract fixes the required role. The model cannot put a different role in
+a tool argument.
+
+## The Complete Identity Chain
+
+1. A contract author writes `APPROVAL ROLE membership_reviewer`.
+2. An identity administrator maps real people to an IdP group. For example,
+   members of `example-membership-reviewers` receive
+   `membership_reviewer` in the token's `groups` claim.
+3. Runner's `operator_identity` configuration fixes the token source, allowed
+   algorithm, public-key source, issuer, audience, subject claim, roles claim,
+   and apply roles.
+4. For every approval, Runner reads a fresh token from environment, a protected
+   token file, or stdin.
+5. Runner verifies the asymmetric algorithm, signature and JWKS key, issuer,
+   audience, `exp`, and `nbf`. It then reads a safe subject and the configured
+   roles claim.
+6. Runner requires an exact role match. `membership_reviewer_backup` does not
+   satisfy `membership_reviewer`.
+7. The approval is bound to the immutable proposal ID, version, and hash, the
+   action `approve`, the verified subject, and the decision time.
+8. Runner stores the verified identity metadata and an attested decision proof.
+   It never stores the bearer token.
+9. Apply is a second operator decision. A fresh verified identity must satisfy
+   `operator_identity.apply_roles`; approval does not imply commit authority.
+
+At apply time Runner also verifies the stored approval proof against the exact
+proposal. A changed proposal ID, version, hash, role, subject, decision, or
+attestation fails before source mutation.
+
+## Development-Only Identity
+
+For one-user local development, `dev_env` preserves the lightweight workflow:
+
+```json
+{
+  "operator_identity": {
+    "provider": "dev_env",
+    "actor_env": "SYNAPSOR_OPERATOR_ID",
+    "roles_env": "SYNAPSOR_OPERATOR_ROLES",
+    "apply_roles": ["writeback_operator"]
+  }
+}
+```
+
+```bash
+export SYNAPSOR_OPERATOR_ID="local-reviewer"
+export SYNAPSOR_OPERATOR_ROLES="membership_reviewer,writeback_operator"
+
+synapsor-runner proposals approve latest \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --yes
+```
+
+`dev_env` is explicitly unverified. Environment text is trusted as entered. Do
+not use it for a shared Runner, production, or a decision that must prove who
+approved it. Use `jwt_oidc` or `signed_key` there.
+
+## Production-Style OIDC Configuration
+
+The following block is parsed and used by the packed OIDC integration test.
+The simulated issuer uses the same shape, but this is not Okta, Entra, Auth0,
+or any other vendor certification.
+
+<!-- synapsor-oidc-operator-config:start -->
+```json
+{
+  "provider": "jwt_oidc",
+  "apply_roles": ["writeback_operator"],
+  "token_env": "SYNAPSOR_OPERATOR_TOKEN",
+  "roles_claim": "groups",
+  "subject_claim": "sub",
+  "attestation_secret_env": "SYNAPSOR_OPERATOR_ATTESTATION_SECRET",
+  "algorithms": ["RS256"],
+  "jwks_url_env": "SYNAPSOR_OPERATOR_JWKS_URL",
+  "issuer": "https://identity.example.test/oidc",
+  "audience": "synapsor-operators",
+  "clock_skew_seconds": 0,
+  "jwks_cache_seconds": 60,
+  "jwks_cooldown_seconds": 1,
+  "fetch_timeout_ms": 2000,
+  "max_response_bytes": 8192
+}
+```
+<!-- synapsor-oidc-operator-config:end -->
+
+Place that object at `operator_identity` in `synapsor.runner.json`. The
+configuration uses environment-variable names, not their secret values.
+
+The IdP mapping for this example is:
+
+| IdP group | JWT `groups` value | Synapsor purpose |
+| --- | --- | --- |
+| `example-membership-reviewers` | `membership_reviewer` | Satisfies the capability's exact `APPROVAL ROLE`. |
+| `example-writeback-operators` | `writeback_operator` | Satisfies the independent `apply_roles` gate. |
+
+Configure this mapping in the IdP. Runner does not infer it from database roles
+or group names.
+
+### What Each Setting Does
+
+| Setting | Meaning |
+| --- | --- |
+| `algorithms` | Exact asymmetric algorithms Runner accepts. OIDC operator identity supports `RS256` and `ES256`; do not infer this from the token header. |
+| `jwks_url_env` | Environment variable containing the IdP's public JWKS URL. Remote URLs must use HTTPS; HTTP is accepted only on loopback for development. |
+| `issuer` / `audience` | Values Runner requires in `iss` and `aud`. |
+| `subject_claim` | Verified top-level claim used as the operator identity. |
+| `roles_claim` | Verified top-level claim containing exact Synapsor role strings. |
+| `token_env` | Environment variable holding the short-lived operator bearer token for this command. |
+| `attestation_secret_env` | Environment variable holding at least 32 bytes of Runner-side key material used to attest the redacted stored decision. |
+| `apply_roles` | Roles accepted for the separate apply decision. |
+
+The attestation secret is not the OIDC token and not an IdP client secret.
+Runner uses it locally to make the stored, token-free identity proof
+tamper-evident. Every trusted process that verifies the same ledger needs the
+same protected value. Keep it out of source control, MCP configuration, logs,
+and model context.
+
+## Run The Local OIDC/JWKS Fixture
+
+The npm package includes a synthetic localhost-only issuer. It generates
+ephemeral RS256 private keys in memory, serves only public keys at `/jwks`, and
+mints fixed test identities. It must never be used as a real identity provider.
+
+In terminal 1:
+
+```bash
+export SYNAPSOR_EXAMPLE_OIDC_PORT=9411
+node ./node_modules/@synapsor/runner/examples/operator-oidc/issuer.mjs
+```
+
+It prints one JSON object describing:
+
+```text
+JWKS:    http://127.0.0.1:9411/jwks
+Issuer:  https://identity.example.test/oidc
+Audience: synapsor-operators
+```
+
+The server holds the private keys only in memory. Stop it after the walkthrough.
+
+In terminal 2, from a Synapsor project that has one pending
+`membership_reviewer` proposal:
+
+```bash
+export SYNAPSOR_OPERATOR_JWKS_URL="http://127.0.0.1:9411/jwks"
+export SYNAPSOR_OPERATOR_ATTESTATION_SECRET="$(openssl rand -base64 32)"
+
+export SYNAPSOR_OPERATOR_TOKEN="$(
+  curl -fsS http://127.0.0.1:9411/token/reviewer |
+    node -pe 'JSON.parse(require("node:fs").readFileSync(0,"utf8")).access_token'
+)"
+
+synapsor-runner proposals approve latest \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --yes \
+  --json
+
+unset SYNAPSOR_OPERATOR_TOKEN
+```
+
+The token is supplied through the environment and is not a command-line
+argument. For a real deployment, inject a short-lived token through a protected
+process environment, protected token file, or stdin. Never commit it.
+
+The fixture's apply identity uses a rotated key. Keep the old and new public
+keys overlapped during rotation:
+
+```bash
+curl -fsS -X POST http://127.0.0.1:9411/rotate
+
+export SYNAPSOR_OPERATOR_TOKEN="$(
+  curl -fsS http://127.0.0.1:9411/token/applier |
+    node -pe 'JSON.parse(require("node:fs").readFileSync(0,"utf8")).access_token'
+)"
+
+synapsor-runner apply latest \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --json
+
+unset SYNAPSOR_OPERATOR_TOKEN
+```
+
+This second token has `writeback_operator`, not
+`membership_reviewer`. It authorizes apply only after Runner verifies the
+stored approval and all guarded-write prerequisites.
+
+### Token File Or Stdin
+
+Configure exactly one token source.
+
+For a protected token file, replace `token_env` with:
+
+```json
+{
+  "token_file_env": "SYNAPSOR_OPERATOR_TOKEN_FILE"
+}
+```
+
+Set the environment variable to a mode-`0600` file outside the repository.
+Delete the file after the decision.
+
+For stdin, replace `token_env` with:
+
+```json
+{
+  "token_stdin": true
+}
+```
+
+Use `--yes` so confirmation does not compete for stdin:
+
+```bash
+printf '%s\n' "$SHORT_LIVED_OPERATOR_TOKEN" |
+  synapsor-runner proposals approve "$PROPOSAL_ID" \
+    --config ./synapsor.runner.json \
+    --store ./.synapsor/local.db \
+    --yes
+```
+
+Do not pass a token as a CLI argument.
+
+## What The Ledger Stores
+
+Inspect the full lifecycle without copying an opaque ID:
+
+```bash
+synapsor-runner replay show latest \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --json
+```
+
+The approval record has this shape:
+
+```json
+{
+  "proposal_version": 1,
+  "proposal_hash": "sha256:...",
+  "approver": "reviewer@example.test",
+  "status": "approved",
+  "identity": {
+    "provider": "jwt_oidc",
+    "verified": true,
+    "subject": "reviewer@example.test",
+    "roles": ["membership_reviewer"],
+    "key_id": "fitflow-key-1",
+    "algorithm": "RS256",
+    "issuer": "https://identity.example.test/oidc",
+    "decision": {
+      "schema_version": "synapsor.operator-decision.v1",
+      "action": "approve",
+      "proposal_id": "wrp_...",
+      "proposal_version": 1,
+      "proposal_hash": "sha256:...",
+      "subject": "reviewer@example.test",
+      "issued_at": "..."
+    },
+    "decision_hash": "sha256:...",
+    "signature": "...",
+    "integrity_hash": "sha256:..."
+  }
+}
+```
+
+`signature` is Runner's HMAC attestation over the redacted verified identity
+and exact decision. It is not the original OIDC JWT signature. The bearer token
+is absent.
+
+The replay also contains a `writeback_authorized` event for the independently
+verified apply identity and the normal guarded-write receipt.
+
+## JWKS Caching And Key Rotation
+
+For a long-running Runner process, remote JWKS keys are held in memory for
+`jwks_cache_seconds` (default 600 seconds). An unknown `kid` may trigger a
+bounded refresh after `jwks_cooldown_seconds` (default 30 seconds). Fetches have
+a timeout and maximum response size, reject redirects, and accept public keys
+only. A one-shot CLI command starts with an empty in-memory cache.
+
+During rotation:
+
+1. Publish the new public key while retaining the old key.
+2. Wait at least the configured cache lifetime plus expected clock skew.
+3. Start issuing tokens with the new `kid`.
+4. Keep the overlap long enough for long-running processes to refresh.
+5. Remove the old key only after old tokens and caches have expired.
+
+Runner's verifier tests exercise an in-process unknown-`kid` refresh. The packed
+approval integration uses the old key for approval, publishes an overlapping
+new key, and uses the new key for the independent apply decision.
+
+## Fail-Closed Troubleshooting
+
+| Failure | What Runner does | Remediation |
+| --- | --- | --- |
+| Missing or similar role | Refuses the decision; proposal stays pending. | Map the exact contract role into the configured roles claim. Do not rename the role at runtime. |
+| Wrong issuer or audience | Rejects JWT verification. | Match the exact IdP issuer and application audience. |
+| Unknown `kid` | Refreshes only within the bounded JWKS policy, then rejects if no public key matches. | Publish overlapping keys and wait for the cooldown/cache policy. |
+| Invalid signature | Rejects the token. | Obtain a fresh token from the configured issuer; do not bypass verification. |
+| Expired or not-yet-valid token | Rejects the token. | Fix clock synchronization and obtain a currently valid token. Keep clock skew narrow. |
+| Unsafe subject or malformed roles | Refuses identity resolution. | Emit a safe top-level string subject and an array or delimited string of safe role names. |
+| JWKS endpoint unavailable | Fails closed when a required key cannot be resolved. | Restore HTTPS/network/DNS service or use a reviewed public-key source. Do not fall back to `dev_env`. |
+| Missing or short attestation secret | Refuses to record the decision. | Supply at least 32 bytes of protected Runner-side key material. |
+| Stored identity proof changed | Apply fails before source mutation. | Investigate ledger integrity. Create a new proposal and approval; do not edit the proof. |
+| Approver lacks an apply role | Apply is refused even after approval. | Use a separately verified operator whose token has one configured `apply_roles` value. |
+
+Database availability, database roles, and MCP arguments never substitute for a
+verified operator identity. Keep database least privilege and RLS beneath this
+operator decision boundary.