@synapsor/runner 1.6.2 → 1.6.4

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

@@ -148,6 +148,48 @@ The equivalent DSL is `REQUIRE 2 APPROVALS` after `APPROVAL ROLE
 billing_lead`. Runner 1.0 does not understand this new optional semantic field;
 use Runner/spec/DSL 1.1 together. Omitted fields preserve 1.0 behavior.
 
+## 1.6 Generated Authority And Supervised Execution
+
+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
+continue to start without metadata inspection.
+
+The optional proposal permission:
+
+```json
+{
+  "execution": {
+    "supervised_worker": "allowed"
+  }
+}
+```
+
+compiles from:
+
+```sql
+ALLOW SUPERVISED WORKER APPLY
+```
+
+It applies nothing by itself. Automatic execution also requires a separate
+deployment policy for the exact capability and active digest. Existing
+`AUTO APPROVE` contracts continue to wait for manual apply, and no worker
+starts because Runner was upgraded. See
+[Operator-Supervised Automatic Apply](supervised-automatic-apply.md).
+
+Human-attention events and external notification sinks require no contract
+migration. Notifications are absent/disabled by default and emit no outbound
+traffic until an operator configures and explicitly runs the dispatcher.
+
 ## Validate
 
 ```bash

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/production.md

@@ -400,6 +400,45 @@ every skipped item includes a safe reason. Re-running is idempotent through
 durable receipts. Do not schedule batch apply for a policy that has no reviewed
 aggregate limits.
 
+For continuous execution, use the stricter default-off supervised mode rather
+than scheduling broad batch apply. `AUTO APPROVE` by itself remains
+manual-apply. A worker may consume approved work only when the active contract
+contains `execution.supervised_worker = "allowed"` and
+`supervised_worker.capabilities` independently names the exact same capability
+and digest. Production additionally requires verified operator controls and a
+live least-privilege writer-posture fingerprint.
+
+```bash
+synapsor-runner worker run --supervised --yes \
+  --worker-id billing_worker \
+  --config ./synapsor.runner.json
+```
+
+The worker accepts only eligible single-row direct INSERT/UPDATE shapes and
+reuses the manual guarded-apply implementation. Before execution it repeats
+approval, policy, limit, expiry, digest/lock, tenant/principal, target and
+supporting-evidence freshness, conflict/deduplication, receipt, writer-posture,
+and lease checks. Source or evidence drift produces zero mutation. DELETE,
+reversible changes, set writes, and app-owned/external effects are not eligible
+for this first automatic path. See [Operator-Supervised Automatic
+Apply](supervised-automatic-apply.md).
+
+Production operators can inspect the same queue and Human Attention Inbox in
+the secured Workbench or CLI:
+
+```bash
+synapsor-runner worker status --config ./synapsor.runner.json
+synapsor-runner attention show --config ./synapsor.runner.json
+```
+
+External delivery is disabled and quiet by default. When explicitly enabled,
+one signed generic webhook can route timely review, UNKNOWN, reconciliation,
+dead-letter, sustained-health, drift, posture, and critical-limit incidents.
+Successful applies remain in the ledger/Workbench unless a sink opts into an
+all-events route or digest. A webhook informs and cannot approve or mutate
+Runner state. See [Human Attention And
+Notifications](human-attention-notifications.md).
+
 Runner writes newline-delimited JSON events to stderr for model-facing tool
 rejections, operator decisions, and terminal writeback outcomes. These events
 contain safe codes and identifiers, never tool arguments, row values, database

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,13 +4,153 @@ 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.2 (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 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.
+- Workbench explains the boundary before exposing advanced details, highlights
+  only unresolved security decisions, and keeps one primary next action visible.
+  Generated read, aggregate, protected, and write authorities remain disabled
+  until the human activates the exact reviewed digest.
+- Project-aware `try call`, `try explore`, `try protect`, and guided action
+  paths remove repeated config/store flags and copied handles while preserving
+  the canonical DSL/Spec/runtime boundary and existing manual/headless paths.
+- The packaged FitFlow journey proves a real named read, privacy-suppressed
+  PM-style aggregate, Protect This Query, proposal-only model call, bounded
+  approval policy, guarded source write, receipt/replay, compensation, and
+  equivalent authority across Workbench, CLI, Cursor, Claude, Codex, and
+  generic stdio setup.
+- The packaged approval-role guide and simulated external OIDC/JWKS flow show
+  how `APPROVAL ROLE` maps to verified IdP claims and immutable decisions.
+  Reviewer and applier authority remain separate; invalid signatures, token
+  time/issuer/audience failures, missing or similar roles, key rotation errors,
+  proof tampering, and proof replay fail closed.
+- Operator-supervised automatic apply is a new default-off execution axis.
+  Contract permission and an independent deployment allowlist must match one
+  exact active digest. Existing `AUTO APPROVE` behavior remains manual-apply;
+  eligible single-row INSERT/UPDATE work uses the same guarded apply after
+  current policy, limit, scope, target/supporting-evidence freshness,
+  writer-posture, receipt, and fenced-lease revalidation.
+- The ledger and Workbench now project durable redacted human-attention events
+  for proposal, worker, boundary, schema, credential, policy, and sensitive
+  override states. External delivery is disabled and quiet by default. A
+  separate dispatcher supports coalescing, budgets, digests, JSONL development
+  output, and signed generic HTTPS webhooks that inform but never authorize.
+- Replaying a failed notification requires a fresh verified signed-key or OIDC
+  operator decision bound to the exact delivery revision and a recorded
+  reason. It requeues only the redacted event. Packed tests prove competing
+  dispatcher deduplication, zero immediate success noise under the default
+  preset, metadata-endpoint SSRF refusal, and an unchanged source database
+  across notification replay.
+- Workbench and CLI expose queue status, pause/drain, exact-digest
+  enable/disable/revoke, cancellation, dead-letter, UNKNOWN/reconciliation,
+  notification status/replay, and no-ID attention inspection outside MCP.
+- Supported JSON failure paths emit one parseable result with a stable error
+  code, preserved-state and source-change status, one recovery action, and
+  redacted diagnostics on stderr.
+- An explicit empty `capabilities` array is now valid zero-authority review
+  state. The optional canonical `execution.supervised_worker` permission and
+  public `ALLOW SUPERVISED WORKER APPLY` clause are additive. Spec and DSL
+  advance to `1.6.0` while preserving old contract normalization, digests, and
+  generated-lock support.
+
+Published package versions: `@synapsor/runner@1.6.3`,
+`@synapsor/spec@1.6.0`, and `@synapsor/dsl@1.6.0`.
+
+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)
 
 ### Registry-installable packaging hotfix
 
@@ -25,7 +165,7 @@ for the Synapsor Cloud CLI.
   therefore exercises the dependency-resolution path used by public `npx`.
 - Runtime behavior is unchanged from the proposal/evidence freshness release.
 
-Prepared package version: `@synapsor/runner@1.6.2`.
+Published package version: `@synapsor/runner@1.6.2`.
 `@synapsor/spec@1.5.0` and `@synapsor/dsl@1.5.0` remain unchanged.
 
 ## 1.6.1 (published 2026-07-23; install-broken)
@@ -641,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>
 ```

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: