@synapsor/runner 1.4.123 → 1.5.0

package/docs/mcp-apps.md

@@ -0,0 +1,188 @@
+# Inline Proposal Review With MCP Apps
+
+Synapsor Runner proposal tools advertise a display-only MCP App. A compatible
+host can render the proposed business effect inline after the tool call. Hosts
+without MCP Apps support continue to receive the same JSON and text result.
+
+The app is a presentation surface, not an approval boundary:
+
+- it shows the requested action, semantic capability, trusted tenant/principal
+  provenance, evidence summary, kept-out-field status, exact diff, expected
+  source version, policy state, receipt state, and reversibility state;
+- it contains no database URL, write credential, approval token, review
+  challenge, or reusable operator authority;
+- it cannot call approve, apply, commit, or raw SQL tools because Runner does
+  not expose those tools through MCP;
+- approval and apply remain explicit operator actions in the standalone local
+  UI or terminal.
+
+## Protocol And SDK Baseline
+
+The implementation is pinned to:
+
+| Component | Version |
+| --- | --- |
+| MCP Apps specification | `2026-01-26` stable |
+| `@modelcontextprotocol/ext-apps` | `1.7.4` |
+| `@modelcontextprotocol/sdk` | `1.29.0` |
+
+Proposal tools declare the standard `ui://synapsor/proposal-review.html`
+resource through `_meta.ui.resourceUri`. Runner serves the resource as
+`text/html;profile=mcp-app` and uses the standard `ui/initialize`,
+`ui/notifications/initialized`, and `ui/notifications/tool-result` messages.
+The official registration helper also supplies the compatibility
+`ui/resourceUri` metadata key.
+
+Repository tests use the official MCP SDK client and linked in-memory
+transport. They verify tool discovery, resource discovery/read, Apps message
+schemas, structured and text fallback results, and the absence of
+model-callable approval/apply tools or embedded authority.
+
+The upstream Apps SDK currently lists ChatGPT, Claude, VS Code, Goose, Postman,
+and MCPJam as supported clients. Synapsor's repository CI does not exercise
+those product hosts, so this project does not claim host-specific compatibility
+beyond the official protocol tests. Host support varies by product version and
+deployment.
+
+Specification:
+[MCP Apps 2026-01-26](https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx).
+
+## Connect A Client
+
+Generate a client-native MCP snippet:
+
+```bash
+synapsor-runner mcp config claude-desktop \
+  --absolute-paths \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+Runner does not require an Apps-specific switch. A supporting host discovers
+the app from proposal-tool metadata and fetches the declared resource. A
+non-supporting host renders or exposes the normal text/structured tool result.
+
+Preview the model-facing boundary before connecting:
+
+```bash
+synapsor-runner tools preview \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+The tool list may include inspect and proposal capabilities. It must not
+include `execute_sql`, `approve`, `apply`, or `commit` tools.
+
+## Optional MCPB Installation
+
+The repository can build an MCP Bundle for hosts that install `.mcpb`
+artifacts:
+
+```bash
+corepack pnpm build:mcpb
+corepack pnpm verify:mcpb
+```
+
+The pinned build uses `@anthropic-ai/mcpb@2.1.2`, validates the `0.4`
+manifest, packs it, unpacks it again, scans its paths/placeholders, and writes
+an archive plus `SHA256SUMS` and `BUILD-INFO.json` under `dist/mcpb/`.
+The verification command launches the unpacked artifact with the official MCP
+client, checks semantic tool/resource discovery, reads the App resource, and
+confirms that no model-facing approval/apply tool is present.
+
+This profile is intentionally narrow:
+
+- it runs the standard `synapsor-runner contract bundle` environment names;
+- the installer asks for the Runner config, state directory, read/write URLs,
+  tenant, and principal;
+- sensitive values are installer configuration and are not embedded in the
+  archive;
+- contracts with custom environment names should use `mcp config` instead.
+
+The generated archive is **unsigned** and reports `signed: false`. Signing is
+a release-owner operation:
+
+```bash
+corepack pnpm exec mcpb sign \
+  --cert /secure/release-cert.pem \
+  --key /secure/release-key.pem \
+  ./dist/mcpb/synapsor-runner-<version>-unsigned.mcpb
+
+corepack pnpm exec mcpb verify \
+  ./dist/mcpb/synapsor-runner-<version>-unsigned.mcpb
+```
+
+Do not use `--self-signed` and present the result as an official release.
+The build inputs and manifest generation are repeatable, but the pinned packer
+records archive timestamps, so byte-for-byte archive hashes may differ between
+builds. The digest applies to the exact artifact that was built and reviewed.
+
+## Complete Human Review
+
+The inline card intentionally does not carry approval authority. Open the
+standalone operator UI:
+
+```bash
+synapsor-runner ui \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+Or review from a trusted terminal:
+
+```bash
+synapsor-runner proposals show <proposal_id> \
+  --store ./.synapsor/local.db
+
+synapsor-runner proposals approve <proposal_id> \
+  --store ./.synapsor/local.db
+
+synapsor-runner apply <proposal_id> \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+Operator identity, approval state, proposal identity, source version, trusted
+scope, and writeback guards are rechecked by Runner. Seeing a card never grants
+authority and never implies that the source database changed.
+
+## Why The Handoff Is Display-Only
+
+The selected stable Apps SDK provides standardized presentation metadata and
+app/host messaging, but it does not document a channel that Synapsor can prove
+is hidden from model-visible tool content, transcripts, and ordinary logs
+while carrying privileged review authority. Runner therefore does not embed a
+signed review challenge in the app resource, resource URI, result, or query
+string.
+
+If a future standard defines and tests a model-hidden authority channel, an
+inline approval flow would still need a one-time short-lived challenge bound
+to the exact proposal, operator session, purpose, and expiry. Until then, the
+standalone operator path is the security boundary.
+
+## Fallback Behavior
+
+| Client behavior | Result |
+| --- | --- |
+| Supports MCP Apps | Inline display-only proposal card |
+| Supports MCP but not Apps | JSON/text proposal result |
+| No graphical host | Terminal proposal commands |
+| Human wants a browser review surface | Standalone loopback local UI |
+
+All four paths use the same proposal review view model. Kept-out values remain
+absent; the card only states that the reviewed allowlist excluded them.
+
+## Security Checklist
+
+- Keep MCP and the local UI on loopback unless you follow the authenticated
+  production deployment guide.
+- Treat proposal/evidence handles as scoped audit data.
+- Never place database credentials or operator tokens in MCP client JSON.
+- Verify trusted tenant/principal provenance for shared HTTP deployments.
+- Keep least-privilege database roles and database-enforced isolation where
+  appropriate.
+- Treat `source_database_changed: false` as unchanged even when a proposal was
+  created successfully.
+
+See [MCP Client Configs](mcp-clients.md), [MCP Client Setup](mcp-client-setup.md),
+[Local Mode](local-mode.md), and [Security Boundary](security-boundary.md).

package/docs/mcp-audit.md

@@ -37,6 +37,15 @@ Human-readable output:
 npx -y -p @synapsor/runner synapsor-runner audit ./tools-list.json
 ```
 
+The default terminal report groups repeated findings into the three most
+important root causes. It shows affected tools, a short blast-radius statement,
+and one next action instead of repeating the same explanation for every tool.
+Use the complete view when triaging every finding:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner audit ./tools-list.json --verbose
+```
+
 Remote `tools/list` endpoint with a bearer token kept in the environment:
 
 ```bash
@@ -62,6 +71,15 @@ JSON output:
 npx -y -p @synapsor/runner synapsor-runner audit ./tools-list.json --format json
 ```
 
+The JSON contract remains `synapsor.mcp-audit.v1`; its published schema is
+[`schemas/mcp-audit-report.schema.json`](../schemas/mcp-audit-report.schema.json).
+
+SARIF 2.1.0 output for code-scanning ingestion:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner audit ./tools-list.json --format sarif > mcp-audit.sarif
+```
+
 Markdown output for issues, PRs, or security review notes:
 
 ```bash
@@ -75,6 +93,42 @@ During local development, the repo-local wrapper can run the same command:
 ./bin/synapsor-runner audit ./tools-list.json --format json
 ```
 
+## Generate review candidates
+
+Audit can create a separate review directory without editing or activating the
+source configuration:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner audit generate \
+  ./tools-list.json \
+  --output ./synapsor-audit-candidates
+```
+
+The generator uses the same parser and findings as `audit`. It writes:
+
+- a canonical `@synapsor/spec` contract;
+- a strict-shadow Runner scaffold with no configured source;
+- deny, redaction, and operator-boundary test candidates;
+- before/after model tool-surface reports;
+- a `REVIEW.md` checklist.
+
+Generated candidates do not carry authority. Every proposal has
+`writeback.mode: none`, the Runner scaffold is `shadow`, and the source map is
+empty. Subject identifiers and visible/write fields are conspicuous
+`review_required_*` placeholders. Input fields that look like SQL, dynamic
+identifiers, tenant/principal scope, credentials, approval identity, or row
+version are omitted rather than copied into model arguments.
+
+The output excludes raw descriptions, defaults, examples, enum values, bearer
+tokens, and credentials. Unknown business meaning becomes a TODO. A developer
+must inspect the real schema, choose trusted tenant/principal bindings, run the
+generated tests and a Shadow study, then deliberately copy reviewed definitions
+into an active contract.
+
+Generation refuses an existing directory. `--force` only replaces a directory
+that carries Runner's `synapsor.audit-candidates.v1` ownership marker; it will
+not overwrite an arbitrary hand-edited directory.
+
 ## Supported inputs
 
 The audit accepts common exported shapes:

package/docs/mcp-client-setup.md

@@ -11,9 +11,14 @@ or SDK. The simplest local-client contract is stdio. Standard HTTP MCP is
 available through Streamable HTTP when your agent connects to a long-running
 Runner service.
 
-Command examples use the published alpha package through `npx`. From a source
-checkout, use `./bin/synapsor-runner ...` only when you intentionally want the local
-source wrapper.
+Proposal tools also advertise a standard display-only
+[MCP App](mcp-apps.md). Supporting hosts discover it from tool metadata;
+other clients keep the same text/JSON proposal result. Approval and apply
+remain outside MCP in both cases.
+
+Command examples use the stable untagged package through `npx`. From a source
+checkout, use `./bin/synapsor-runner ...` only when you intentionally want the
+local source wrapper.
 
 Checked examples live in:
 
@@ -136,6 +141,11 @@ backup before writing. Noninteractive scripts must add `--yes`.
 The command writes only the local stdio MCP command and args. It does not write
 database URLs or passwords into the client config.
 
+No separate Apps flag is required. A compatible host discovers
+`ui://synapsor/proposal-review.html` from proposal-tool metadata. The app can
+display the exact diff, but it has no approval/apply authority; use the
+standalone local UI or terminal for human review.
+
 ## Start Command
 
 From the runner repository:
@@ -144,7 +154,9 @@ From the runner repository:
 npx -y -p @synapsor/runner synapsor-runner mcp serve --config ./examples/mcp-postgres-billing/synapsor.runner.json --store ./.synapsor/local.db
 ```
 
-For the alpha package, keep the package tag explicit in client configuration.
+For reproducible deployments, pin an exact stable version in package manifests
+and MCP client configuration. The untagged examples above intentionally resolve
+the current `latest` release.
 
 For standard app/server HTTP MCP mode:
 

package/docs/mcp-clients.md

@@ -4,6 +4,11 @@ Synapsor Runner exposes reviewed semantic tools over standard MCP. The model
 receives inspect/propose capabilities; it does not receive raw SQL, database
 credentials, approval commands, or apply commands.
 
+Proposal tools advertise a display-only [MCP App](mcp-apps.md). Hosts that
+implement the Apps extension can render the exact proposal diff inline.
+Clients without it receive the same structured/text result, and human approval
+still occurs in the standalone operator UI or terminal.
+
 The complete copy-paste templates live in:
 
 - [`examples/support-plan-credit/mcp-client-examples/`](../examples/support-plan-credit/mcp-client-examples/)
@@ -110,6 +115,9 @@ The preview must list semantic capabilities and must not list `execute_sql`,
 approval/apply tools, database URLs, write credentials, or model-controlled
 tenant authority.
 
+MCP App discovery is automatic from the proposal tool's
+`_meta.ui.resourceUri`; it does not require credentials in the client snippet.
+
 ## Troubleshooting
 
 - `ENOENT` or missing config: use absolute config/store paths.

package/docs/production.md

@@ -94,6 +94,14 @@ Read credential:
 - can `SELECT` only the tables/views used by capabilities;
 - should be restricted by views/RLS where possible.
 
+Name the scope mode in production reviews. The compatibility default is
+application-level Runner predicates with a shared credential. PostgreSQL can
+add database-enforced RLS to catch omitted predicates and pooled-context
+leakage. Tenant-bound credentials or isolated processes remove
+organization-wide authority from a Runner process. See
+[Database-Enforced Tenant And Principal
+Scope](database-enforced-scope.md).
+
 Write credential for direct `sql_update`:
 
 - can use only the operation-specific business DML and reviewed columns;

package/docs/release-notes.md

@@ -10,7 +10,45 @@ 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.4.123 (prepared, not published)
+## 1.5.0 (prepared, not published)
+
+### Complete guarded-action developer proof
+
+- `synapsor-runner try --prove` now demonstrates the complete embedded
+  business-action boundary without an account, database, Docker daemon, MCP
+  client, or model key: scoped evidence, exact `late_fee_cents: 5500 -> 0`
+  proposal, no pre-approval mutation, guarded commit, duplicate-free retry,
+  changed-intent collision refusal, stale conflict, receipt, and replay.
+- Deployments can explicitly select application-level shared-credential scope,
+  PostgreSQL RLS defense in depth, or a tenant-bound credential resolver.
+  Diagnostics report the active assurance and remaining trust boundary;
+  hardened modes fail closed when prerequisites are missing.
+- Strict Shadow Mode now has durable studies, bounded case imports,
+  authoritative human outcomes, deterministic comparison/readiness reports,
+  and effect-level regression fixtures. No study or evaluation path grants
+  authority or writes source data.
+- Proposal tools advertise a standard display-only MCP App where the host
+  supports it. The app and standalone local UI share one reviewer-facing view;
+  approval/apply authority and privileged tokens remain outside MCP.
+- `audit` can generate disabled canonical replacement candidates, while
+  Prisma, Drizzle, and OpenAPI generators create bounded review-only candidate
+  contracts without executing adopter source.
+- The `support-billing-agent` reference now provides a live disposable
+  PostgreSQL/RLS proof for tenant/principal scope, kept-out fields, proposal,
+  approval/apply, receipt/retry, stale conflict, replay, strict shadow, and
+  effect regression.
+- The bundled app-owned handler helper now uses a pre-provisioned receipt table
+  without requiring schema `CREATE`; DDL is attempted only when the table is
+  absent. The source-workspace and packed billing-handler examples both verify
+  transactional apply and idempotent retry.
+- The public README leads with `try --prove`, keeps MCP database-risk audit
+  immediately second, and distinguishes application scope, PostgreSQL RLS, and
+  tenant-bound isolation without overstating any of them.
+
+Prepared package version: `@synapsor/runner@1.5.0`. Spec, DSL, and Cloud CLI
+packages are unchanged. Nothing has been published by this repository change.
+
+## 1.4.123 (2026-07-17)
 
 ### Advisory capability-surface fitness lint
 
@@ -25,10 +63,10 @@ for the Synapsor Cloud CLI.
   CI policy gate with `--strict` or `--fail-on warning`; canonical validity and
   runtime enforcement are unchanged.
 
-Prepared package version: `@synapsor/runner@1.4.123`. Spec, DSL, and Cloud CLI
+Published package version: `@synapsor/runner@1.4.123`. Spec, DSL, and Cloud CLI
 packages are unchanged.
 
-## 1.4.122 (2026-07-16)
+## 1.4.122 (2026-07-17)
 
 ### Trusted principal scope and Cloud-linked authority
 
@@ -54,11 +92,11 @@ packages are unchanged.
   projects, scoped credentials, Runner connections, proposal decisions, and
   audit records. Runner keeps the `synapsor-runner` binary and local boundary.
 
-Prepared package versions: `@synapsor/spec@1.4.2`,
+Published package versions: `@synapsor/spec@1.4.2`,
 `@synapsor/dsl@1.4.3`, `@synapsor/runner@1.4.122`, and
 `@synapsor/cli@0.1.0-beta.1`.
 
-## 1.4.121 (prepared, not published)
+## 1.4.121 (2026-07-15)
 
 ### Contract trust surface and bounded-set parser correctness
 
@@ -90,10 +128,10 @@ Prepared package versions: `@synapsor/spec@1.4.2`,
 - C++/Cloud validators and exporters preserve the new additive enum/aggregate
   fields for canonical round-trip compatibility.
 
-Prepared package versions: `@synapsor/spec@1.4.1`,
+Published package versions: `@synapsor/spec@1.4.1`,
 `@synapsor/dsl@1.4.2`, and `@synapsor/runner@1.4.121`.
 
-## 1.4.12 (prepared, not published)
+## 1.4.12 (2026-07-14)
 
 ### Runtime-store smoke-call consistency
 
@@ -108,10 +146,10 @@ Prepared package versions: `@synapsor/spec@1.4.1`,
 - Local SQLite and mirror modes retain their existing behavior; no source row
   changes before the normal external approval/apply path.
 
-Prepared package version: `@synapsor/runner@1.4.12`.
+Published package version: `@synapsor/runner@1.4.12`.
 `@synapsor/dsl` remains `1.4.1`; `@synapsor/spec` remains `1.4.0`.
 
-## 1.4.1 (prepared, not published)
+## 1.4.1 (2026-07-14)
 
 ### Bounded-set digest compatibility patch
 
@@ -131,10 +169,10 @@ Prepared package version: `@synapsor/runner@1.4.12`.
   authority, hand-built semantic tools, structural enforcement, build-vs-adopt
   fit, and regulated-data boundaries.
 
-Prepared package versions: `@synapsor/dsl@1.4.1` and
+Published package versions: `@synapsor/dsl@1.4.1` and
 `@synapsor/runner@1.4.1`. `@synapsor/spec` remains `1.4.0`.
 
-## 1.4.0 (prepared, not published)
+## 1.4.0 (2026-07-14)
 
 ### Reviewed Reversible Change Sets
 
@@ -149,7 +187,7 @@ Prepared package versions: `@synapsor/dsl@1.4.1` and
 - Keeps hard DELETE restoration, app-owned handlers, payments, messages, and
   other external effects outside Runner's automatic compensation claim.
 
-Prepared package versions: `@synapsor/spec@1.4.0`,
+Published package versions: `@synapsor/spec@1.4.0`,
 `@synapsor/dsl@1.4.0`, and `@synapsor/runner@1.4.0`.
 
 ## 1.3.0 (prepared, not published)
@@ -254,7 +292,7 @@ Released package versions: `@synapsor/spec@1.1.0`,
 - 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`,
+Released package versions: `@synapsor/spec@1.0.0`,
 `@synapsor/dsl@1.0.0`, and `@synapsor/runner@1.0.0`.
 
 ## 0.1.16

package/docs/release-policy.md

@@ -11,8 +11,12 @@ npx -y -p @synapsor/runner synapsor-runner demo --quick
 npm install -g @synapsor/runner
 ```
 
-Use `@alpha` or an exact prerelease only when intentionally testing the moving
-preview channel.
+Use an exact prerelease or a named preview tag only when intentionally testing
+preview behavior. Check the tags that currently exist before documenting one:
+
+```bash
+npm dist-tag ls @synapsor/runner
+```
 
 ## Alpha Expectations
 
@@ -128,9 +132,9 @@ internals. Local store migrations may happen inside `1.x` and later minor
 versions, but documented CLI inspection commands should remain the supported way
 to read the store.
 
-Alpha users should pin an exact alpha version in package.json, CI, and MCP
-client snippets. Use `@alpha` only when intentionally testing the moving
-preview channel.
+Prerelease users should pin an exact version in package.json, CI, and MCP
+client snippets. Do not assume an `alpha`, `beta`, or `next` tag exists; inspect
+the registry tags first.
 
 ## Result Envelope Migration
 

package/docs/runner-config-reference.md

@@ -114,6 +114,14 @@ not print database URLs or create the schema.
       "write_url_env": "BILLING_POSTGRES_WRITE_URL",
       "read_only": false,
       "statement_timeout_ms": 3000,
+      "database_scope": {
+        "mode": "postgres_rls",
+        "tenant_setting": "synapsor.tenant_id",
+        "principal_setting": "synapsor.principal"
+      },
+      "credential_scope": {
+        "mode": "shared"
+      },
       "receipts": {
         "authority": "source_db",
         "provisioning": "precreated",
@@ -138,6 +146,23 @@ adapter-specific reviewed SSL options when used.
 
 A contract's `SOURCE billing_postgres` must exactly match a `sources` key.
 
+`database_scope.mode` defaults to `application`: Runner enforces trusted
+tenant/principal predicates with the configured database credential.
+`postgres_rls` is PostgreSQL-only and requires fixed, distinct
+`tenant_setting` and `principal_setting` names. Runner binds them
+transaction-locally and refuses serving/writeback when RLS, FORCE, role, or
+operation-policy prerequisites cannot be attested.
+
+`credential_scope.mode` defaults to `shared`. `tenant_resolver` names a
+programmatic `TenantCredentialResolver`; credentials remain outside the
+contract/config and pools are partitioned by trusted scope and credential
+identity. The stock CLI does not load executable resolver modules, so CLI-only
+deployments should run one tenant-bound process/credential per tenant.
+
+See [Database-Enforced Tenant And Principal
+Scope](database-enforced-scope.md) for the guarantee matrix, PostgreSQL policy
+example, resolver interface, doctor canary, and MySQL alternatives.
+
 Long-running servers reuse native driver pools. Optional `pool` keys are
 `max_connections` (default 10), `connection_timeout_ms` (3000),
 `idle_timeout_ms` (30000), `queue_timeout_ms` (5000), and `queue_limit`

package/docs/schema-api-candidates.md

@@ -0,0 +1,68 @@
+# Reviewed Candidates From Prisma, Drizzle, And OpenAPI
+
+Use these generators after schema or API inspection when you want a review
+starting point without granting authority:
+
+```bash
+synapsor-runner init from-prisma ./prisma/schema.prisma \
+  --output ./synapsor-prisma-candidates
+
+synapsor-runner init from-drizzle ./src/schema.ts \
+  --output ./synapsor-drizzle-candidates
+
+synapsor-runner init from-openapi ./openapi.yaml \
+  --output ./synapsor-openapi-candidates
+```
+
+Each command writes a separate deterministic directory containing:
+
+- `synapsor.candidate.contract.json`: canonical `@synapsor/spec` candidates;
+- `synapsor.candidate.runner.json`: source-less strict Shadow configuration;
+- `synapsor.candidate.contract-tests.json`: deny, redaction, and operator
+  boundary test candidates;
+- `generation-review.json`: stable machine-readable review findings;
+- `REVIEW.md`: the human review checklist;
+- `.synapsor-schema-candidates.json`: Runner's ownership marker.
+
+No candidate is active. Proposal writeback is `none`, no database source is
+configured, and tenant/principal authority remains a visible placeholder.
+Generation never edits the input or an active Runner configuration.
+
+## What Is And Is Not Inferred
+
+The generators can suggest structural facts and likely review targets:
+
+- objects, fields, table mappings, primary keys, and version-like fields;
+- potential tenant/principal fields based on names;
+- potentially sensitive and kept-out fields;
+- possible read and proposal capability names;
+- operations that need business logic or an app-owned handler.
+
+They do not decide which tenant or principal is authoritative, which fields are
+safe to expose, which writes are valid, business bounds, approval policy, or
+auto-approval. A field-name heuristic is not data classification.
+
+Review `generation-review.json` and `REVIEW.md`, replace every
+`review_required_*` placeholder, run the generated tests and a
+[Shadow study](shadow-studies.md), then deliberately copy reviewed definitions
+into an active contract through code review.
+
+## Input Safety
+
+Input is bounded to 2 MiB, 50 objects, 128 fields per object, and 200 generated
+capabilities. Deep or oversized structures fail closed.
+
+- Prisma uses Runner's bounded lexer/parser. Datasource URLs, defaults, enum
+  values, generators, and plugins are not copied or run.
+- Drizzle is untrusted executable TypeScript. Runner parses a documented static
+  `pgTable`/`mysqlTable` object-literal subset with the TypeScript AST. It never
+  imports, transpiles, type-checks, executes, or resolves the application.
+  Dynamic table names fail; unsupported dynamic columns are called out for
+  review.
+- OpenAPI 3 JSON/YAML is parsed locally. Network/external references are
+  rejected. Server URLs, examples, defaults, enum values, callbacks, webhooks,
+  and credentials are not copied.
+
+Existing output is never replaced unless `--force` points to a directory with
+Runner's matching ownership marker. Hand-edited directories are refused even
+with `--force`.

package/docs/security-boundary.md

@@ -50,6 +50,16 @@ Trusted context comes from local configuration, environment bindings, or Cloud
 session context in Cloud mode. Tenant, principal, and authorization scope must
 not be accepted from the model as authority.
 
+With a shared credential, these checks are application-level enforcement and
+depend on Runner's fixed predicate implementation. Optional PostgreSQL RLS mode
+adds an independent database check for omitted predicates and pooled-context
+leakage. Tenant-bound credentials or isolated deployments provide the stronger
+boundary when a Runner process must not hold organization-wide authority.
+PostgreSQL RLS does not protect against a fully compromised process that can
+choose arbitrary trusted settings, and MySQL has no native RLS equivalent. See
+[Database-Enforced Tenant And Principal
+Scope](database-enforced-scope.md).
+
 A capability may declare `principal_scope_key` (DSL: `PRINCIPAL SCOPE KEY`) to
 narrow rows inside a tenant. Runner then adds both fixed, parameterized guards: