@synapsor/runner 1.6.3 → 1.6.5

package/docs/release-notes.md

@@ -4,18 +4,111 @@ 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
+npx -y @synapsor/runner demo --quick
 ```
 
 The OSS runner command is `synapsor-runner`. The `synapsor` command is reserved
 for the Synapsor Cloud CLI.
 
-## 1.6.3 (prepared, not published)
+## 1.6.5 (prepared, not published)
+
+### Managed Claude Code and VS Code project MCP installs
+
+- The same reviewed, backup-producing project lifecycle previously available
+  for Cursor now manages Claude Code `.mcp.json` and VS Code
+  `.vscode/mcp.json`.
+- Install previews preserve unrelated project settings, pin the exact Runner
+  version, write no credentials or trusted scope, and refuse unowned or
+  tampered `synapsor` entries. Reinstall is idempotent and uninstall removes
+  only Runner's intact entry.
+- VS Code JSONC comments and trailing commas survive install and uninstall.
+  `mcp status <client> --project --check-launch` validates the generated
+  command against the exact reviewed MCP tool list.
+- README, Workbench, onboarding, host recipes, and `doctor` now present Cursor,
+  Claude Code, and VS Code as peer project clients. Existing Cursor commands
+  and configuration remain compatible.
+
+Prepared package versions: `@synapsor/runner@1.6.5` and
+`synapsor-runner@1.6.5`. Spec 1.7.0 and DSL 1.7.0 are unchanged. No package is
+published by this change.
+
+## 1.6.4 (published 2026-07-25)
+
+### Review-correct onboarding and reviewed relationship paths
+
+- Generated-boundary review now uses dependency-scoped invalidation and stale
+  revision checks. Editing one resource does not erase unrelated human
+  decisions, while stale browser state cannot overwrite a newer review.
+- Workbench starts with a small useful resource pack, explains current agent
+  authority and source-change status in plain language, keeps advanced
+  permissions behind progressive disclosure, and preserves one recommended
+  next action. Project resume and nested config discovery retain existing work.
+- A fresh `npx -y @synapsor/runner start` can accept the database URL through a
+  hidden terminal prompt, or load only a selected `DATABASE_URL` from an
+  explicitly confirmed local environment file. In the conservative local
+  development fast lane, at most two plain questions and one recorded
+  digest-bound human gesture lead to a real read without exporting the URL,
+  editing generated files, or weakening staging/production review.
+- Deterministic classification is more conservative across unfamiliar domains.
+  Database, Prisma, Drizzle, OpenAPI, and existing Synapsor evidence can improve
+  names and structure but cannot grant authority or resolve ambiguous trusted
+  scope.
+- Protected aggregate reads may contain up to three activated reviewed
+  relationship paths. Each path has one or two catalog-proven many-to-one
+  links with fan-out one. The model can select an activated path by name but
+  cannot provide a table, key, join type, or activation decision.
+- A question needing an inactive proven path fails closed and stages that exact
+  path for operator review. Optional links require an explicit missing-row
+  choice because excluding versus retaining an unmatched counted row can change
+  totals. The reviewed choice and structural proof are digest-bound.
+- Scope is enforced independently on every relation. Cohort suppression runs
+  after final grouping. One-to-many, many-to-many, ambiguous, stale, over-depth,
+  and model-improvised joins remain refused; complex formulas and relationship
+  graphs use reviewed database views.
+- Packed Community Solar and Retail clean-room journeys and live
+  PostgreSQL/MySQL relationship gates cover unfamiliar-domain onboarding,
+  PM-style analysis, demand-driven review, nullable semantics, drift,
+  suppression, scope, and deliberate fan-out rejection.
+- Workbench now offers an optional local **Ask with your model** client over the
+  exact active MCP/runtime tools. OpenAI, Anthropic, and custom
+  OpenAI-compatible adapters use explicit digest-bound direct-egress consent,
+  in-memory credentials/history, bounded tool loops, escaped provider prose,
+  and proposal-only writes. The no-model composer remains the default.
+- Remote provider requests use fixed official origins or an operator-selected
+  HTTPS custom origin, refuse redirects, validate and pin DNS on every
+  connection, block private/special/metadata targets, redact errors, and
+  support Node 22's multi-address lookup contract. Plain HTTP remains
+  loopback-only.
+- Both packed clean-room domains now pass the real Ask UI. The Retail journey
+  shows a kept-out-field refusal; Community Solar shows a source-unchanged
+  proposal. An owner-authorized live OpenAI `gpt-5-mini` acceptance run used
+  the same official-MCP path, matched its aggregate result, and passed exact-key
+  project/ledger/browser/output/evidence scans. Anthropic and generic
+  compatible claims are limited to the documented tested protocol matrix.
+- Human-facing commands now use the shortest true form: direct `npx` for first
+  acquisition and `synapsor-runner <command>` after installation. The optional
+  unscoped `synapsor-runner` npm package contains no runtime or authority logic;
+  it delegates to the exact matching scoped Runner version. Existing explicit
+  package, pinned, CI, and machine-readable invocations remain compatible.
+- Generated DSL previews use one local, escaped, copy-exact syntax highlighter
+  in light and dark themes with no CDN or unsafe HTML fallback. Activity and
+  human review details use the full Workbench width instead of a compressed
+  side column, including mobile layouts.
+- Existing hand-authored and published `1.6.3` projects do not need the new
+  relationship fields, generation review, or Workbench. Legacy contracts keep
+  their exact normalized bytes/digests and existing tool lists remain
+  unchanged unless the feature is adopted.
+
+Published package versions: `@synapsor/runner@1.6.4`,
+`@synapsor/spec@1.7.0`, `@synapsor/dsl@1.7.0`, and the optional
+`synapsor-runner@1.6.4` command alias.
+
+## 1.6.3 (published 2026-07-24)
 
 ### Guided adoption without weaker authority
 
 - A fresh interactive
-  `npx -y @synapsor/runner@latest start --from-env DATABASE_URL` now drives one
+  `npx -y @synapsor/runner start --from-env DATABASE_URL` now drives one
   resumable metadata-inspection, review-by-exception, exact-digest activation,
   first safe read, and MCP setup journey. It requires no account, model key,
   Cloud control plane, global install, or manual project files.
@@ -65,14 +158,11 @@ for the Synapsor Cloud CLI.
   advance to `1.6.0` while preserving old contract normalization, digests, and
   generated-lock support.
 
-Prepared package versions: `@synapsor/runner@1.6.3`,
+Published package versions: `@synapsor/runner@1.6.3`,
 `@synapsor/spec@1.6.0`, and `@synapsor/dsl@1.6.0`.
-No package is published by this change.
 
-The pre-release clean-install gate uses the locally packed public Spec until
-Spec 1.6.0 is on npm. After publishing Spec first, force the registry-only
-Runner dependency check with
-`VERIFY_PACKED_RUNNER_USE_LOCAL_SPEC=0 ./scripts/verify-packed-runner.sh`.
+The pre-release clean-install gate used the locally packed public Spec until
+Spec 1.6.0 reached npm, then returned to the registry-only dependency proof.
 
 ## 1.6.2 (published 2026-07-23)
 
@@ -705,7 +795,7 @@ not change and must not be republished for this release.
 ### Public npm DX
 
 - Prepares the spec-ready Runner package for the normal untagged npm path so
-  developers can use `npx -y -p @synapsor/runner synapsor-runner ...` without
+  developers can use `npx -y @synapsor/runner ...` without
   knowing about the temporary `next` release-candidate tag.
 - Keeps the same contract/spec functionality as `0.1.2`; this is a release
   hygiene patch for public install and README/package-page verification.

package/docs/release-policy.md

@@ -7,7 +7,7 @@ shared runtime-store deployment are part of the documented compatibility
 surface. Use the stable package for normal installs:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner demo --quick
+npx -y @synapsor/runner demo --quick
 npm install -g @synapsor/runner
 ```
 
@@ -38,9 +38,10 @@ Alpha releases must keep the safety boundary intact:
 - no generic model-generated INSERT/DELETE/UPSERT/DDL/multi-row SQL;
 - proposal-first write path stays explicit.
 
-## Stable Expectations
+## Stable Release Expectations
 
-A stable `0.1.0` release should only be tagged after:
+Every stable release must preserve the safety boundary and should be tagged
+only after:
 
 - npm README commands match the published package;
 - `synapsor-runner demo --quick` works from a clean directory;
@@ -62,7 +63,7 @@ A stable `0.1.0` release should only be tagged after:
 - there are no known docs/code mismatches around transport, credentials,
   receipt tables, or handler expectations.
 
-## 1.0 Stability Gate
+## Historical 1.0 Stability Gate
 
 Do not tag `1.0.0` only because the package is useful. `1.0.0` is the public
 semver contract for the Runner production approval loop, and it should be cut
@@ -89,7 +90,7 @@ versioning. Breaking changes require a new major version, except for security
 fixes that close a vulnerability while preserving the safest possible
 compatibility path.
 
-## 1.1 Fleet Gate
+## Historical 1.1 Fleet Gate
 
 Do not publish `1.1.0` until all 1.0 gates remain green and the local synthetic
 fleet verifier proves:
@@ -167,15 +168,27 @@ Before publishing any release:
 ./scripts/verify-release-gate.sh
 ```
 
+For a coordinated Spec/DSL/Runner release, publish in dependency order:
+
+1. `@synapsor/spec`;
+2. `@synapsor/dsl`;
+3. `@synapsor/runner`;
+4. the optional `synapsor-runner` command alias, when prepared.
+
+The alias must have the same version as the scoped Runner and depend on that
+exact registry version. It contains no independent runtime or authority logic.
+Run `corepack pnpm verify:packed-runner-alias` before publishing it, and do not
+publish it until the matching scoped Runner is visible on npm.
+
 After publishing an alpha prerelease:
 
 ```bash
-VERIFY_PUBLISHED_ALPHA=1 ./scripts/verify-release-gate.sh 0.1.0-alpha.17
+VERIFY_PUBLISHED_ALPHA=1 ./scripts/verify-release-gate.sh <prerelease-version>
 ```
 
 After publishing/promoting stable `latest`, verify the stable channel from a
 clean temporary directory:
 
 ```bash
-./scripts/verify-published-stable.sh 0.1.0
+./scripts/verify-published-stable.sh <stable-version>
 ```

package/docs/reversible-change-sets.md

@@ -1,6 +1,6 @@
 # Reviewed Reversible Change Sets
 
-Synapsor Runner 1.4 can capture a bounded inverse for an opt-in direct database
+Synapsor Runner can capture a bounded inverse for an opt-in direct database
 write. This is **reviewed compensation**, not rollback or database time travel.
 
 The operator flow is deliberately two separate approval loops:

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/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