@synapsor/runner 1.6.3 → 1.6.4

package/docs/local-mode.md

@@ -44,13 +44,13 @@ when you do not want to change your host Node version.
 Create a starter config without putting credentials in the file:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner init --engine postgres --mode review
+npx -y @synapsor/runner init --engine postgres --mode review
 ```
 
 For MySQL:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner init --engine mysql --mode review --output synapsor.mysql.runner.json
+npx -y @synapsor/runner init --engine mysql --mode review --output synapsor.mysql.runner.json
 ```
 
 The generated config uses environment-variable names for read/write URLs and trusted context. Edit the table, column, and capability names before serving tools.
@@ -63,8 +63,8 @@ persisted into proposals, evidence, query audit, runner state, or replay.
 For a reviewed own-database setup generated from explicit selections, use:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner init --spec onboarding-selection.json --non-interactive
-npx -y -p @synapsor/runner synapsor-runner doctor --config synapsor.runner.json
+npx -y @synapsor/runner init --spec onboarding-selection.json --non-interactive
+npx -y @synapsor/runner doctor --config synapsor.runner.json
 ```
 
 `doctor --config` checks config validation, required environment variables,
@@ -76,7 +76,7 @@ and the semantic MCP tool boundary without printing credential values.
 Use stdio for local MCP clients that launch Synapsor Runner:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp serve \
+npx -y @synapsor/runner mcp serve \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
 ```
@@ -87,7 +87,7 @@ MCP client:
 ```bash
 export SYNAPSOR_RUNNER_HTTP_TOKEN="$(node -e 'process.stdout.write(require("node:crypto").randomBytes(32).toString("base64url"))')"
 
-npx -y -p @synapsor/runner synapsor-runner mcp serve-streamable-http \
+npx -y @synapsor/runner mcp serve-streamable-http \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN
@@ -131,19 +131,19 @@ If neither is set, the CLI uses:
 List proposals:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner proposals list --store ./.synapsor/local.db
+npx -y @synapsor/runner proposals list --store ./.synapsor/local.db
 ```
 
 Show a proposal:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner proposals show wrp_123 --store ./.synapsor/local.db
+npx -y @synapsor/runner proposals show wrp_123 --store ./.synapsor/local.db
 ```
 
 Check a freshness-enabled proposal without copying its id:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner proposals check-freshness latest \
+npx -y @synapsor/runner proposals check-freshness latest \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
 ```
@@ -151,7 +151,7 @@ npx -y -p @synapsor/runner synapsor-runner proposals check-freshness latest \
 Approve:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner proposals approve wrp_123 \
+npx -y @synapsor/runner proposals approve wrp_123 \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --actor local_reviewer \
@@ -177,7 +177,7 @@ revalidates again because source data can change after approval. See
 Create a guarded writeback job from an approved proposal:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner proposals writeback-job wrp_123 \
+npx -y @synapsor/runner proposals writeback-job wrp_123 \
   --store ./.synapsor/local.db \
   --project local \
   --runner local_runner \
@@ -189,7 +189,7 @@ The generated job uses the public `synapsor.writeback-job.v1` protocol and can b
 ```bash
 export SYNAPSOR_DATABASE_WRITE_URL="postgresql://writer:<password>@localhost:5432/app"
 SYNAPSOR_ENGINE=postgres \
-npx -y -p @synapsor/runner synapsor-runner apply --job job.json --config synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner apply --job job.json --config synapsor.runner.json --store ./.synapsor/local.db
 ```
 
 When `--config` is passed, direct SQL writeback reads the writer connection from
@@ -201,7 +201,7 @@ Passing `--store` records the terminal `synapsor.execution-receipt.v1` locally.
 Reject:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner proposals reject wrp_123 \
+npx -y @synapsor/runner proposals reject wrp_123 \
   --store ./.synapsor/local.db \
   --reason "policy evidence is incomplete" \
   --yes
@@ -222,7 +222,7 @@ pilot, use [Shadow Studies](shadow-studies.md).
 Start a localhost-only review UI:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner ui --config synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner ui --config synapsor.runner.json --store ./.synapsor/local.db
 ```
 
 The UI shows setup summary, semantic tools, proposal states, exact diffs,
@@ -240,20 +240,20 @@ tools, MCP commit tools, or controls that widen configured tables/columns.
 Show replay:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner replay show wrp_123 --store ./.synapsor/local.db
-npx -y -p @synapsor/runner synapsor-runner replay show --proposal wrp_123 --store ./.synapsor/local.db
-npx -y -p @synapsor/runner synapsor-runner replay show --replay replay_wrp_123 --store ./.synapsor/local.db
-npx -y -p @synapsor/runner synapsor-runner replay show --evidence ev_123 --store ./.synapsor/local.db
+npx -y @synapsor/runner replay show wrp_123 --store ./.synapsor/local.db
+npx -y @synapsor/runner replay show --proposal wrp_123 --store ./.synapsor/local.db
+npx -y @synapsor/runner replay show --replay replay_wrp_123 --store ./.synapsor/local.db
+npx -y @synapsor/runner replay show --evidence ev_123 --store ./.synapsor/local.db
 ```
 
 Export replay:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner replay export wrp_123 \
+npx -y @synapsor/runner replay export wrp_123 \
   --store ./.synapsor/local.db \
   --output replay.json
 
-npx -y -p @synapsor/runner synapsor-runner replay export --proposal wrp_123 \
+npx -y @synapsor/runner replay export --proposal wrp_123 \
   --format markdown \
   --store ./.synapsor/local.db \
   --output replay.md

package/docs/mcp-audit.md

@@ -1,6 +1,6 @@
 # MCP database risk review
 
-`npx -y -p @synapsor/runner synapsor-runner audit <target>` performs a
+`npx -y @synapsor/runner audit <target>` performs a
 static MCP database risk review over an exported tool manifest, a remote MCP
 `tools/list` endpoint, or a stdio MCP server. The `mcp audit` subcommand is also
 available for users who look for the command under the MCP namespace.
@@ -26,7 +26,7 @@ MCP annotations are treated as hints, not enforcement.
 Built-in database MCP risk example:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit --example dangerous-db-mcp
+npx -y @synapsor/runner audit --example dangerous-db-mcp
 ```
 
 This bundled example does not require a source checkout or local examples file.
@@ -37,7 +37,7 @@ table/column inputs, and model-controlled tenant/principal fields.
 Human-readable output:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit ./tools-list.json
+npx -y @synapsor/runner audit ./tools-list.json
 ```
 
 The default terminal report groups repeated findings into the three most
@@ -46,32 +46,32 @@ 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
+npx -y @synapsor/runner audit ./tools-list.json --verbose
 ```
 
 Remote `tools/list` endpoint with a bearer token kept in the environment:
 
 ```bash
 SYNAPSOR_MCP_AUDIT_BEARER="..." \
-npx -y -p @synapsor/runner synapsor-runner audit https://mcp.example.com --format json
+npx -y @synapsor/runner audit https://mcp.example.com --format json
 ```
 
 Remote endpoint with a custom bearer-token environment variable:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit https://mcp.example.com --bearer-env MCP_AUDIT_TOKEN --format json
+npx -y @synapsor/runner audit https://mcp.example.com --bearer-env MCP_AUDIT_TOKEN --format json
 ```
 
 Stdio MCP server:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit 'stdio:node ./server.mjs' --timeout-ms 5000
+npx -y @synapsor/runner audit 'stdio:node ./server.mjs' --timeout-ms 5000
 ```
 
 JSON output:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit ./tools-list.json --format json
+npx -y @synapsor/runner audit ./tools-list.json --format json
 ```
 
 The JSON contract remains `synapsor.mcp-audit.v1`; its published schema is
@@ -80,19 +80,19 @@ The JSON contract remains `synapsor.mcp-audit.v1`; its published schema is
 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
+npx -y @synapsor/runner audit ./tools-list.json --format sarif > mcp-audit.sarif
 ```
 
 Markdown output for issues, PRs, or security review notes:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit --example dangerous-db-mcp --format markdown
+npx -y @synapsor/runner audit --example dangerous-db-mcp --format markdown
 ```
 
 Inspect a project-scoped Cursor configuration without launching anything:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit \
+npx -y @synapsor/runner audit \
   --mcp-config ./.cursor/mcp.json \
   --format markdown
 ```
@@ -102,7 +102,7 @@ as `requires_operator_verification`. To query one reviewed stdio command, name
 that exact server and give explicit consent:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit \
+npx -y @synapsor/runner audit \
   --mcp-config ./.cursor/mcp.json \
   --live-server synapsor \
   --yes \
@@ -132,7 +132,7 @@ Audit can create a separate review directory without editing or activating the
 source configuration:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit generate \
+npx -y @synapsor/runner audit generate \
   ./tools-list.json \
   --output ./synapsor-audit-candidates
 ```
@@ -141,7 +141,7 @@ Open the same blocked candidate directly in the secured local review
 workbench:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner audit generate \
+npx -y @synapsor/runner audit generate \
   ./tools-list.json \
   --output ./synapsor-audit-candidates \
   --open-ui

package/docs/mcp-client-setup.md

@@ -57,7 +57,7 @@ provisions the same environment value to Runner and the authorized client:
 ```bash
 export SYNAPSOR_RUNNER_HTTP_TOKEN="$(node -e 'process.stdout.write(require("node:crypto").randomBytes(32).toString("base64url"))')"
 
-npx -y -p @synapsor/runner synapsor-runner mcp serve-streamable-http \
+npx -y @synapsor/runner mcp serve-streamable-http \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN
@@ -69,7 +69,7 @@ OpenAI-safe aliases while keeping canonical Synapsor capability names in MCP
 metadata:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp serve-streamable-http \
+npx -y @synapsor/runner mcp serve-streamable-http \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
@@ -85,7 +85,7 @@ same time.
 Preview the exact alias mapping before wiring a client:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner tools preview \
+npx -y @synapsor/runner tools preview \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --alias-mode openai
@@ -101,7 +101,7 @@ with tenant/principal bound from verified claims. Details: [HTTP MCP](http-mcp.m
 Print a snippet without modifying any client files:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp config claude-desktop \
+npx -y @synapsor/runner mcp config claude-desktop \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
 ```
@@ -121,7 +121,7 @@ For OpenAI Agents SDK, generate the Streamable HTTP start command and Python
 snippet:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp client-config \
+npx -y @synapsor/runner mcp client-config \
   --client openai-agents \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
@@ -130,13 +130,13 @@ npx -y -p @synapsor/runner synapsor-runner mcp client-config \
 The older form is still supported:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp configure --client claude-desktop --config ./synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner mcp configure --client claude-desktop --config ./synapsor.runner.json --store ./.synapsor/local.db
 ```
 
 Write is opt-in and requires an explicit destination:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp configure \
+npx -y @synapsor/runner mcp configure \
   --client cursor \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
@@ -162,7 +162,7 @@ standalone local UI or terminal for human review.
 From the runner repository:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp serve --config ./examples/mcp-postgres-billing/synapsor.runner.json --store ./.synapsor/local.db
+npx -y @synapsor/runner mcp serve --config ./examples/mcp-postgres-billing/synapsor.runner.json --store ./.synapsor/local.db
 ```
 
 For reproducible deployments, pin an exact stable version in package manifests
@@ -172,7 +172,7 @@ the current `latest` release.
 For standard app/server HTTP MCP mode:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp serve-streamable-http \
+npx -y @synapsor/runner mcp serve-streamable-http \
   --config ./examples/mcp-postgres-billing/synapsor.runner.json \
   --store ./.synapsor/local.db \
   --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN
@@ -190,10 +190,7 @@ sessions, so do not use it for a shared identity deployment.
     "synapsor-runner": {
       "command": "npx",
       "args": [
-        "-y",
-        "-p",
-        "@synapsor/runner",
-        "synapsor-runner",
+        "-y", "@synapsor/runner",
         "mcp",
         "serve",
         "--config",
@@ -235,7 +232,7 @@ small tool-call test.
 First confirm what Runner exposes:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner tools preview \
+npx -y @synapsor/runner tools preview \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
 ```

package/docs/mcp-clients.md

@@ -39,7 +39,7 @@ Use stdio for Claude Desktop, Cursor, and other local MCP clients:
 {
   "command": "npx",
   "args": [
-    "-y", "-p", "@synapsor/runner", "synapsor-runner",
+    "-y", "@synapsor/runner",
     "mcp", "serve", "--config", "./synapsor.runner.json",
     "--store", "./.synapsor/local.db"
   ]

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

@@ -150,11 +150,15 @@ use Runner/spec/DSL 1.1 together. Omitted fields preserve 1.0 behavior.
 
 ## 1.6 Generated Authority And Supervised Execution
 
-Runner 1.6.3, Spec 1.6.0, and DSL 1.6.0 are additive. Existing hand-authored
+Runner 1.6.4, Spec 1.7.0, and DSL 1.7.0 are additive. Existing hand-authored
 DSL/JSON/config projects do not need Auto Boundary, Workbench, a generation
 lock, schema rescanning, or supervised execution. Contracts that omit the new
 fields retain their previous canonical normalization and digest.
 
+Spec/DSL 1.7.0 add optional reviewed relationship-path fields and `LINK`
+syntax. The legacy one-hop relationship form remains accepted and canonical;
+an unchanged legacy contract retains its exact normalized bytes and digest.
+
 Auto Boundary writes a generation lock only for authority it generated.
 Drift enforcement applies only when `synapsor.runner.json` explicitly
 references that lock under `generated_authority`; manually authored projects

package/docs/openai-agents-sdk.md

@@ -10,7 +10,7 @@ surface.
 ```bash
 export SYNAPSOR_RUNNER_HTTP_TOKEN="$(node -e 'process.stdout.write(require("node:crypto").randomBytes(32).toString("base64url"))')"
 
-npx -y -p @synapsor/runner synapsor-runner mcp serve-streamable-http \
+npx -y @synapsor/runner mcp serve-streamable-http \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
@@ -30,7 +30,7 @@ model and maps calls back to canonical Synapsor capability names such as
 ## Generate The Snippet
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner mcp client-config \
+npx -y @synapsor/runner mcp client-config \
   --client openai-agents \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \

package/docs/proposal-evidence-freshness.md

@@ -1,6 +1,6 @@
 # Proposal And Evidence Freshness
 
-Runner 1.6.1 adds an optional fail-closed freshness gate for proposals whose
+Runner provides an optional fail-closed freshness gate for proposals whose
 review depends on live source state.
 
 This closes two different review gaps without changing the model-facing MCP
@@ -11,8 +11,8 @@ surface:
 2. A proposal can declare reviewed supporting rows whose exact versions must
    still match before approval and again at apply.
 
-Target-row drift was already blocked by the exact conflict guard at apply.
-Version 1.6.1 does not replace that protection. It adds an earlier review-time
+Target-row drift is also blocked by the exact conflict guard at apply.
+Freshness does not replace that protection. It adds an earlier review-time
 check and extends the final transaction to declared same-source dependencies.
 
 ## What Freshness Does And Does Not Mean
@@ -36,10 +36,10 @@ new source read and create a new proposal with a new hash and review.
 
 ## Configuration
 
-Freshness is a Runner deployment overlay in `synapsor.runner.json`. Version
-1.6.1 adds no DSL clause and no canonical Spec field. Existing hand-authored
-DSL, canonical JSON, contract digests, and `tools/list` output remain unchanged
-when this optional section is absent.
+Freshness is a Runner deployment overlay in `synapsor.runner.json`. It adds no
+DSL clause and no canonical Spec field. Existing hand-authored DSL, canonical
+JSON, contract digests, and `tools/list` output remain unchanged when this
+optional section is absent.
 
 ```json
 {

package/docs/recipes.md

@@ -9,20 +9,20 @@ tenant key, conflict column, and business limits.
 List recipes:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner recipes list
+npx -y @synapsor/runner recipes list
 ```
 
 Inspect one:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner recipes show billing.late_fee_waiver
+npx -y @synapsor/runner recipes show billing.late_fee_waiver
 ```
 
 Initialize a starter config:
 
 ```bash
-npx -y -p @synapsor/runner synapsor-runner recipes init billing.late_fee_waiver --output synapsor.runner.json
-npx -y -p @synapsor/runner synapsor-runner config validate --config synapsor.runner.json
+npx -y @synapsor/runner recipes init billing.late_fee_waiver --output synapsor.runner.json
+npx -y @synapsor/runner config validate --config synapsor.runner.json
 ```
 
 Built-in recipes are JSON files under `recipes/`. They are starter data, not
@@ -31,8 +31,8 @@ domain, and initialize from your file:
 
 ```bash
 cp recipes/billing.late_fee_waiver.json my-recipe.json
-npx -y -p @synapsor/runner synapsor-runner recipes show ./my-recipe.json
-npx -y -p @synapsor/runner synapsor-runner recipes init ./my-recipe.json --output synapsor.runner.json
+npx -y @synapsor/runner recipes show ./my-recipe.json
+npx -y @synapsor/runner recipes init ./my-recipe.json --output synapsor.runner.json
 ```
 
 Available recipes:

package/docs/release-notes.md

@@ -4,18 +4,97 @@ 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.4 (prepared, not published)
+
+### 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.
+
+Prepared 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.
+No package is published by this change.
+
+Publish Spec first, then DSL, then the scoped Runner, and finally its exact
+version command alias. Force the final registry-only Runner dependency check
+with
+`VERIFY_PACKED_RUNNER_USE_LOCAL_SPEC=0 ./scripts/verify-packed-runner.sh` after
+Spec 1.7.0 is visible on npm, and verify the alias only after
+`@synapsor/runner@1.6.4` is visible.
+
+## 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 +144,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 +781,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>
 ```